You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This nameserver doesn't even understand DNSSEC, but a recursive DNSSEC resolver will return SERVFAIL in this case which is not an acceptable answer for DANE and the website breaks.
A DANE client should not expect that all nameservers will answer reliably for the TLSA record type.
To avoid breaking services that use such nameservers, we should:
Determine if either A or AAAA records of the host are in a DNSSEC-signed zone
If the zone is unsigned, it's safe to skip result of the TLSA lookup without risking a downgrade attack.
Credits to @vdukhovni for telling me about this idea
The text was updated successfully, but these errors were encountered:
* Pass ctx to resolver functions
* Allow specifying network ip, ip4 or ip6 similar to Go's built-in resolver
* Return security status of ip lookups (needed for issue #13)
* Use a common implemenation for lookup ip/tlsa in recursive and stub resolvers
* Use more suitable names
* Add more tests
Some nameservers timeout or return SERVFAIL for any record type they don't understand
An example of such a server found in the wild (at the time of writing)
This nameserver doesn't even understand DNSSEC, but a recursive DNSSEC resolver will return SERVFAIL in this case which is not an acceptable answer for DANE and the website breaks.
A DANE client should not expect that all nameservers will answer reliably for the TLSA record type.
To avoid breaking services that use such nameservers, we should:
Credits to @vdukhovni for telling me about this idea
The text was updated successfully, but these errors were encountered: