DNS resolver does not resolve CNAME-based DKIM records #3

New issue

Closed

opened 2026-09-05 11:57:27 +00:00 by steve · 1 comment

steve commented

2026-09-05 11:57:27 +00:00

Owner

Having some issues with a CNAME based record and large responses.

CNAME handling: Is support planned for following CNAMEs when resolving TXT records, such as protonmail._domainkey.proton.me., where the TXT record exists at the CNAME target?

No hardcoded UDP: Is support planned for selecting the appropriate DNS transport and retrying over TCP when a UDP response is truncated or too large?

We tried a custom dns resolver as a workaround which successfully resolved the problematic record that was both under a CNAME and had a large response. Could probably replace the current solution using miekg/dns.

(from Raademar https://github.com/turscar/dkim2/issues/3)

Having some issues with a CNAME based record and large responses. CNAME handling: Is support planned for following CNAMEs when resolving TXT records, such as protonmail._domainkey.proton.me., where the TXT record exists at the CNAME target? No hardcoded UDP: Is support planned for selecting the appropriate DNS transport and retrying over TCP when a UDP response is truncated or too large? We tried a custom dns resolver as a workaround which successfully resolved the problematic record that was both under a CNAME and had a large response. Could probably replace the current solution using miekg/dns. (from Raademar https://github.com/turscar/dkim2/issues/3)

steve added the

bug

label

2026-09-05 11:57:27 +00:00

steve self-assigned this

2026-09-05 11:57:27 +00:00

steve commented

2026-09-05 12:01:38 +00:00

Author

Owner

I already have a TODO to migrate the default resolver to using net.Resolver, which should resolve these issues. (The existing miekg resolver is as much a demo as anything else).

steve referenced this issue from a commit

2026-09-05 15:07:13 +00:00

Replace KeyResolver interface with one that is implemented by [net.Resolver]. Removes non-stdlib DNS dependencies. Closes #3.

steve closed this issue

2026-09-05 15:07:13 +00:00