[GH-ISSUE #2715] Recursor: using encrypted transports to authoritative name servers #1044

New issue

Open

opened 2026-03-16 01:25:22 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 01:25:22 +03:00

Owner

Originally created by @divergentdave on GitHub (Jan 10, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2715

Is your feature request related to a problem? Please describe.
Currently, the recursor uses Do53 only to query authoritative name servers. This leaves these queries vulnerable to off-path spoofing attacks, BGP attacks, privacy impacts, etc. DNSSEC can provide integrity, but it only applies to zones that adopt it. Using encrypted transports to authoritative servers would close this hole, but bootstrapping this trust will require coordination and new specs.

Describe the solution you'd like
RFC 9539 defines an opportunistic mechanism to use encrypted transports when supported. Since this is opportunistic, it won't protect against all attackers, and the encrypted connection may not be authenticated, but it could be a good stepping stone to stronger encryption negotiation mechanisms.

Alternately, Let's Encrypt is interested in configuring a list of authoritative name servers and specifying which encrypted protocol to use with them. This would be more high-touch, but it could be deployed before a negotiation scheme is specified, and would not be vulnerable to downgrade attacks like RFC 9539.

Originally created by @divergentdave on GitHub (Jan 10, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2715 **Is your feature request related to a problem? Please describe.** Currently, the recursor uses Do53 only to query authoritative name servers. This leaves these queries vulnerable to off-path spoofing attacks, BGP attacks, privacy impacts, etc. DNSSEC can provide integrity, but it only applies to zones that adopt it. Using encrypted transports to authoritative servers would close this hole, but bootstrapping this trust will require coordination and new specs. **Describe the solution you'd like** [RFC 9539](https://datatracker.ietf.org/doc/html/rfc9539) defines an opportunistic mechanism to use encrypted transports when supported. Since this is opportunistic, it won't protect against all attackers, and the encrypted connection may not be authenticated, but it could be a good stepping stone to stronger encryption negotiation mechanisms. Alternately, Let's Encrypt is interested in configuring a list of authoritative name servers and specifying which encrypted protocol to use with them. This would be more high-touch, but it could be deployed before a negotiation scheme is specified, and would not be vulnerable to downgrade attacks like RFC 9539.