Open mateusz834 opened 11 months ago
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.
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?
I have an interest in this as part of the need for a dnssec-aware non-validating stub resolver package. Perhaps https://github.com/golang/go/issues/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?
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):
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.
https://github.com/golang/go/issues/13279#issuecomment-1340957136
Change https://go.dev/cl/530876 mentions this issue: net: report detailed DNS errors with Extended DNS Errors
@ianlancetaylor @neild
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 supportEDNS(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- (https://github.com/golang/go/issues/63116#issuecomment-1732561214)