net: report detailed DNS errors with Extended DNS Errors in the go resolver

[mateusz834]

Currently when a query fails we return a "server misbehaving" error. RFC 8914 allows the resolver to include detailed errors about the failure of a DNS query. It would be nice to support it in the pure go resolver. We already support EDNS(0), so it should be fairly easy to add.

The only thing that I am not sure about is the optional EXTRA-TEXT field of the EDE Option, it would be nice to include it in the error, but it can be an arbitrary UTF-8 string. We should probably not include arbitrary characters in the error string. Not sure about that.

CC @mjl- (#63116 (comment))

[mjl-]

For seeing this in action, try dig dnssec-failed.org @1.1.1.1, dig dnssec-failed.org @8.8.8.8 or dig dnssec-failed.org @127.0.0.1 against a locally installed unbound with ede enabled:

# cat /etc/unbound/unbound.conf.d/ede.conf
server:
    ede: yes
    val-log-level: 2

I have an interest in this as part of the need for a dnssec-aware non-validating stub resolver package. Perhaps #13279 should be involved.

As for the error message, it could be prefixed with "error from remote: ...", and if deemed dangerous, we could show only non-control, ascii-only strings.

[seankhliao]

maybe a custom error type to be used with errors.As and the extra text as a field not included in the default Error() string?

[mateusz834]

I have an interest in this as part of the need for a dnssec-aware non-validating stub resolver package. Perhaps #13279 should be involved.

Could you elaborate more about your use case for this? What is your use case for the exported extended DNS errors type? Why there is a need for #13279, are you interested in the AD bit access?

[mjl-]

Could you elaborate more about your use case for this? What is your use case for the exported extended DNS errors type? Why there is a need for #13279, are you intrested in the AD bit access?

I am adding support for (outgoing) DANE and TLS-RPT to my mail server (mox). For TLS reporting, I need to be able to say why a delivery attempt over SMTP failed. One of those reasons is:

"dnssec-invalid": This indicates that no valid records were returned from the recursive resolver.

See https://datatracker.ietf.org/doc/html/rfc8460#section-4.3.2.1 I currently think that case is for responses from a resolver without AD bit. And also for a servfail with some of the EDE codes (those about failing dnssec), but not all (the last third of the error codes). So yes, I also need the "authentic data" bit. And I'll be needing a LookupTLSA function (and others will want more lookup functions, e.g. for sshfp, smimea, etc). I started prototyping a resolver based on github.com/miekg/dns that adds an "authentic data" bool return value to each Lookup function. Though I'm starting to think it could be better to change that bool into a struct so additional result fields can be added in the future. At some point I would like more control over the resolver (but this is getting off-topic so feel free to ignore): - Ignore /etc/hosts (for some freshly setup cloud vm's it causes the fqdn to resolve to a loopback ip instead of the actual public ips). - Probably a few functions that keep behaviour closer to DNS (e.g. LookupCNAME now returns no error if a cname record doesn't exist, instead of nxdomain, that surprised me). - I would also like a full dnssec-validating caching recursive resolver as a Go package. "Validating" so lookups can always be secure and I don't have to tell users to install a local dnssec-validating recursive resolver (like unbound, or let them change a systemd-resolved config to enable dnssec validation), though with some more time it may become the default on systems (I think that's what the internet is hoping for). And "caching" (with option to ignore the cache) so the dns setup checks I'm doing can find mismatch between cached records and the current authoritative records, useful after the user made dns changes. But such a resolver is a lot of work, and is currently more a nice-to-have than requirement.

[mateusz834]

I am adding support for (outgoing) DANE and TLS-RPT to my mail server (mox). For TLS reporting, I need to be able to say why a delivery attempt over SMTP failed. One of those reasons is:
"dnssec-invalid": This indicates that no valid records were returned from the recursive resolver.

When the dnssec-invalid should be returned? On DNSSEC failures from LookupHost (A/AAAA), LookupMX or failures from the TLSA record query.

So yes, I also need the "authentic data" bit. And I'll be needing a LookupTLSA function (and others will want more lookup functions, e.g. for sshfp, smimea, etc). I started prototyping a resolver based on github.com/miekg/dns that adds an "authentic data" bool return value to each Lookup function. Though I'm starting to think it could be better to change that bool into a struct so additional result fields can be added in the future..

I don't think we will ever add LookupTLSA (see #35061).

• Ignore /etc/hosts (for some freshly setup cloud vm's it causes the fqdn to resolve to a loopback ip instead of the actual public ips).

That can be solved by a proper DNS resolver and by querying the A/AAAA resources. LookupHost needs to support hosts file, because we emulate getaddrinfo.

• Probably a few functions that keep behaviour closer to DNS (e.g. LookupCNAME now returns no error if a cname record doesn't exist, instead of nxdomain, that surprised me).

Also note it is broken now #59943.

I would also like a full dnssec-validating caching recursive resolver as a Go package.

#13279 (comment)

[gopherbot]

Change https://go.dev/cl/530876 mentions this issue: net: report detailed DNS errors with Extended DNS Errors

[thanm]

@ianlancetaylor @neild