net: validate DNSSEC in Go's DNS resolver

[bradfitz]

DNSSEC is being deployed.

We should support it eventually.

[mwwaters]

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. Vendor dnssec and add exported functions to net such as LookupIPAddrSecure, LookupMXSecure, etc.

2. Add a LookupBytes function returns the byte slice of the DNS response for the caller. The net package still checks query's Header and Question. The call will have to re-parse the byte slice but can skip over the question. From exchange() up the call stack, a []byte return would need to be added.

3. LookupRRSet function which uses duplicate structures defined in the net package. The dnssec package can take net package's structures and transform them back to dnsmessage package. Using the dnsmessage structures is not an option since the caller's dnsmessage package is different than the vendored package.

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

[ianlancetaylor]

Vendoring dnssec is OK; we've already got dnsmessage in vendor/golang_org/x/net/dns/dnsmessage.

Why LookupIPAddrSecure? Why not just make LookupIPAddr use DNSSEC if available?

[mwwaters]

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

[mikioh]

@mwwaters,

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.

@iangudger, thoughts?

[iangudger]

I am all for adding DNSSEC and other features to both x/net/dns and the standard library. The approach listed by @mikioh sounds reasonable to me.

That said, do @mikioh or @bradfitz (or someone else?) have the bandwidth to review changes like this?

[mwwaters]

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

[halturin]

is it still a thing? any chance to have it as a part of std lib?

[mateusz834]

Probably this assumes that we will have to put the root KSK keys in the binary, but I don't think that we will be able to implement RFC 5011 in the net package here (for root KSK rollovers).
Also i don't see any reason to validate DNSSEC inside the Go resolver. DNSSEC validation should be done by external resolvers.