[GH-ISSUE #2705] tls_dns_name is not fully respected #1043

New issue

Closed

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

kerem commented

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

Owner

Originally created by @k26pl on GitHub (Jan 3, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2705

Describe the bug
I am using upstream dns (nextdns) that depends on tls subdomain to load correct config.
NameServerConfigGroup is configured with correct ip and tls_dns_name, but correct config is not loaded by nextdns.
this dns name works correctly in other programs (firefox, android private dns, resolved)

To Reproduce

     //dns server will be exposed on 127.11.2.6
     //<id> should be changed to valid nextdns profile id,
     // i can generate one for testing if anyone doesn't want to
     // create account
     let nscg = NameServerConfigGroup::from_ips_https(&[
                    IpAddr::V4(Ipv4Addr::new(45, 90, 28, 0)),
                    IpAddr::V4(Ipv4Addr::new(45, 90, 30, 0)),
                ], 443, 
               // tls_dns_name:
               String::from("<id>.dns.nextdns.io"),
               true);
      let cfg = ForwardConfig {
                name_servers: nscg,
                options: None,
            };
     let fa = ForwardAuthority::try_from_config(
                Name::from_str(".").unwrap(),
                hickory_server::authority::ZoneType::Forward,
                &cfg,
            )
            .unwrap();
     let mut cat = Catalog::new();
     cat.upsert(LowerName::from_str(".").unwrap(), Box::new(Arc::new(fa)));
     let sock_udp = UdpSocket::bind(("127.11.2.6", 53))
             .await.unwrap();
     let mut s = ServerFuture::new(cat);
     s.register_socket(sock_udp);
     s.block_until_done().await.unwrap();

Expected behavior
It should be possible to configure tls_dns_name to be sent in alpn and sni

System:

OS: Linux 6.12.6-203.bazzite.fc41.x86_64
Architecture: x86_64
Version Fedora Linux 41 (Container Image)
rustc version: rustc 1.83.0 (90b35a623 2024-11-26)

Version:
Crate: hickory-server: "0.24.2"
Version: 0.24.2

Additional context
The server appears not to set server name in ALPN
hickory-resolver/src/tls/dns_over_rustls.rs line 71 disables sni without option to easily change it
Additionally on DoH the request query seems to be hardcoded to /dns-query, which does not allow https://dns.nextdns.io/ urls to work

Originally created by @k26pl on GitHub (Jan 3, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2705 **Describe the bug** I am using upstream dns (nextdns) that depends on tls subdomain to load correct config. NameServerConfigGroup is configured with correct ip and tls_dns_name, but correct config is not loaded by nextdns. this dns name works correctly in other programs (firefox, android private dns, resolved) **To Reproduce** ``` //dns server will be exposed on 127.11.2.6 //<id> should be changed to valid nextdns profile id, // i can generate one for testing if anyone doesn't want to // create account let nscg = NameServerConfigGroup::from_ips_https(&[ IpAddr::V4(Ipv4Addr::new(45, 90, 28, 0)), IpAddr::V4(Ipv4Addr::new(45, 90, 30, 0)), ], 443, // tls_dns_name: String::from("<id>.dns.nextdns.io"), true); let cfg = ForwardConfig { name_servers: nscg, options: None, }; let fa = ForwardAuthority::try_from_config( Name::from_str(".").unwrap(), hickory_server::authority::ZoneType::Forward, &cfg, ) .unwrap(); let mut cat = Catalog::new(); cat.upsert(LowerName::from_str(".").unwrap(), Box::new(Arc::new(fa))); let sock_udp = UdpSocket::bind(("127.11.2.6", 53)) .await.unwrap(); let mut s = ServerFuture::new(cat); s.register_socket(sock_udp); s.block_until_done().await.unwrap(); ``` **Expected behavior** It should be possible to configure tls_dns_name to be sent in alpn and sni **System:** - OS: Linux 6.12.6-203.bazzite.fc41.x86_64 - Architecture: x86_64 - Version Fedora Linux 41 (Container Image) - rustc version: rustc 1.83.0 (90b35a623 2024-11-26) **Version:** Crate: hickory-server: "0.24.2" Version: 0.24.2 **Additional context** The server appears not to set server name in ALPN hickory-resolver/src/tls/dns_over_rustls.rs line 71 disables sni without option to easily change it Additionally on DoH the request query seems to be hardcoded to /dns-query, which does not allow https://dns.nextdns.io/<id> urls to work

kerem closed this issue

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

kerem commented

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

Author

Owner

@djc commented on GitHub (Jan 3, 2025):

Suggest trying one of the 0.25.0 alphas which should have quite a few improvements on this front. There is also support for changing the query path.

(Note that the server name does not interact with ALPN, so not sure what you mean by that.)

@djc commented on GitHub (Jan 3, 2025): Suggest trying one of the 0.25.0 alphas which should have quite a few improvements on this front. There is also support for changing the query path. (Note that the server name does not interact with ALPN, so not sure what you mean by that.)

kerem commented

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

Author

Owner

@k26pl commented on GitHub (Jan 4, 2025):

(Note that the server name does not interact with ALPN, so not sure what you mean by that.)
I have made test tls server that logs alpn and sni. sni is not received, alpn has servername set to false. From docs it appears it should be the name from sni packet

It works well on alpha, thanks for help

@k26pl commented on GitHub (Jan 4, 2025): > (Note that the server name does not interact with ALPN, so not sure what you mean by that.) I have made test tls server that logs alpn and sni. sni is not received, alpn has servername set to false. From docs it appears it should be the name from sni packet It works well on alpha, thanks for help

kerem referenced this issue

2026-03-16 03:43:24 +03:00

[PR #1058] [MERGED] Properly reuse connections, for TCP, TLS, and HTTPS #1930

kerem referenced this issue

2026-03-16 03:59:46 +03:00

[PR #1058] [MERGED] Properly reuse connections, for TCP, TLS, and HTTPS #1934