Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
net: validate DNSSEC in Go's DNS resolver #13279
referenced this issue
Nov 17, 2015
referenced this issue
Nov 22, 2015
referenced this issue
Jul 1, 2018
I am working on a proposal for adding DNSSEC to Go. DNSSEC validation requires multiple queries up to the DNSKEY RRSet of root.
There are a few solutions I have considered for the proposal. All solutions will have x/net/dns/dnsmessage adding necessary RRs and a new package, x/net/dns/dnssec, to perform validation. Any solution will also have to support EDNS0 in case of DNSSEC queries. The three possible solutions include:
#1 is the cleanest if the extra dependency is acceptable. #2 is clean for unix, but ugly for Windows. Windows 7 and up can support DNSSEC lookups, but the bytes of the DNS response would have to be reconstructed. #3 has duplication of code and two copies made of the unpacked response.
I would lean towards #1, but do not know how serious the dependency issue is. If the dependency issue is a deal-breaker, then I can make a proposal for #3. The proposal would target Go 1.13's release cycle.
The most immediate reason is systemd-resolved's stub resolver (the 127.0.0.53 /etc/resolv.conf server) always strips out DNSSEC records. On my own computer (Ubuntu 18.04), "dig . DNSKEY" gave an empty result while "dig @126.96.36.199 . DNSKEY" gave the expected result. I had to disable systemd-resolved to get a DNSKEY lookup. Ubnutu Bug Report
To soft-fail the lookup routine, one way is to have always require valid DNSSEC if DNSKEY/RRSIG for root is successful. It is unlikely to have records stripped out for other queries if the root DNSKEY lookup is successful. To hard-fail, what about adding a parameter such as "DNSSECStrict" to Resolver? Hard-fail means either getting validation of either NSEC of a DS record or full validation.
I would also like a LookupTXTSecure function in particular, so the caller could know the TXT record was verified. Verifying TXT records in particular has a use for the MTA-STS proposal and for DMARC/DKIM records. DNS-01 challenges with ACME could also use knowledge of whether TXT records are secure, though CAs would also need a CAA record lookup. LookupTXTSecure could be added later though, in a different issue and CL.
I'm not sure what's the goal of this issue but enabling security-aware DNS stub resolver as defined in RFC 4033 sounds reasonable, I mean, not entering the territory of DNSSEC-based technologies such as DANE, DSO or other fancy features from IETF dnsop-wg.
As you mentioned, a small start is always preferable, for example, 1) add a few RRs to dns/dnsmessage package of x/net, 2) create dns/dnssec package of x/net for implementing a validator for stub resolver, 3) stop, take a breath and re-consider adaptation to the standard library; API surface (e.g., why not extending net.Resolver?), dependency management (especially for cipher suite packages), etc. I feel like having dns/dnslookup package of x/net is not so bad.
@mikioh I should have been more clear that any changes within net would come after dns/dnsmessage and dns/dnssec are built out. Those changes are relatively straightforward compared with changes touching the API. In RFC 4033, a validating security-aware stub resolver needs to get the DNSSEC records. There are difficult issues with changing the behavior of Go's resolver, given how DNSSEC will fail for many installations. @iangudger I assumed there wouldn't be time for code review until the next release cycle. The process could start with new RRs for dnsmessage this cycle though.…
On Wed, Oct 3, 2018 at 3:36 AM Ian Gudger ***@***.***> wrote: I am all for adding DNSSEC and other features to both x/net/dns and the standard library. The approach listed by @mikioh <https://github.com/mikioh> sounds reasonable to me. That said, do @mikioh <https://github.com/mikioh> or @bradfitz <https://github.com/bradfitz> (or someone else?) have the bandwidth to review changes like this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13279 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKOIc680fmOrNJRFWMKbEVbQu8PnRCKiks5uhGkNgaJpZM4GjNFX> .