starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #1868] Trust-DNS does not work in IPv4-only environment #799

New issue

Open

opened 2026-03-16 00:17:13 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 00:17:13 +03:00

Owner

Originally created by @msrd0 on GitHub (Dec 28, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1868

Describe the bug
Whenever I connect to my parent's WiFi, trust-dns stops working, and I do not get any DNS resolving at all. My parents have a very old legacy internet connection that only has an IPv4 address. I'm using the same configuration that I use in other networks, so naturally I have both IPv4 and IPv6 addresses to forward to. If I remove those IPv6 addresses (first two name_servers) from the config, trust-dns works fine.

To Reproduce

Install trust-dns:
```
yay -S trust-dns
```

Write /etc/named.toml

listen_addrs_ipv4 = ["127.0.0.1"]
listen_addrs_ipv6 = ["::1"]
listen_port = 53

[[zones]]
zone = "."
zone_type = "Forward"

[zones.stores]
type = "forward"

[[zones.stores.name_servers]]
socket_addr = "[2606:4700:4700::1111]:853"
protocol = "tls"
tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com"
trust_nx_responses = false

[[zones.stores.name_servers]]
socket_addr = "[2606:4700:4700::1001]:853"
protocol = "tls"
tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com"
trust_nx_responses = false

[[zones.stores.name_servers]]
socket_addr = "1.1.1.1:853"
protocol = "tls"
tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com"
trust_nx_responses = false

[[zones.stores.name_servers]]
socket_addr = "1.0.0.1:853"
protocol = "tls"
tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com"
trust_nx_responses = false

Start named.service via systemd

Try to do a dns lookup

$ drill msrd0.de
Error: error sending query: Could not send or receive, because of network error

Expected behavior
I get a response rather than a network error.

System:

OS: ArchLinux
Architecture: x86_64
Version: Rolling Release
rustc version: 1.66

Version:
Crate: trust-dns
Version: 0.22.0

Additional context
Trust-dns does not indicate any errors in its log:

$ sudo systemctl status named
[sudo] password for msrd0:
● named.service - TRUST-DNS server
     Loaded: loaded (/etc/systemd/system/named.service; enabled; preset: disabled)
     Active: active (running) since Wed 2022-12-28 11:07:00 CET; 2min 0s ago
   Main PID: 590 (named)
      Tasks: 5 (limit: 9408)
     Memory: 18.4M
        CPU: 215ms
     CGroup: /system.slice/named.service
             └─590 /usr/bin/named

Dec 28 11:08:36 ACER-SP314-51 named[590]: 1672222116:INFO:trust_dns_server::server::server_future:771:request:41536 src:UDP://::1#39573 QUERY:radicale.msrd0.de.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:08:44 ACER-SP314-51 named[590]: 1672222124:INFO:trust_dns_server::server::server_future:771:request:47544 src:UDP://::1#51488 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:08:45 ACER-SP314-51 named[590]: 1672222125:INFO:trust_dns_server::server::server_future:771:request:31124 src:UDP://::1#55179 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:08:50 ACER-SP314-51 named[590]: 1672222130:INFO:trust_dns_server::server::server_future:771:request:31124 src:UDP://::1#55179 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:08:50 ACER-SP314-51 named[590]: 1672222130:INFO:trust_dns_server::server::server_future:771:request:43374 src:UDP://::1#55333 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:08:55 ACER-SP314-51 named[590]: 1672222135:INFO:trust_dns_server::server::server_future:771:request:31124 src:UDP://::1#41384 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:08:55 ACER-SP314-51 named[590]: 1672222135:INFO:trust_dns_server::server::server_future:771:request:43374 src:UDP://::1#55333 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:09:00 ACER-SP314-51 named[590]: 1672222140:INFO:trust_dns_server::server::server_future:771:request:55726 src:UDP://::1#47138 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:09:00 ACER-SP314-51 named[590]: 1672222140:INFO:trust_dns_server::server::server_future:771:request:43374 src:UDP://::1#56296 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA
Dec 28 11:09:05 ACER-SP314-51 named[590]: 1672222145:INFO:trust_dns_server::server::server_future:771:request:17793 src:UDP://::1#60414 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA

Originally created by @msrd0 on GitHub (Dec 28, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1868 **Describe the bug** Whenever I connect to my parent's WiFi, trust-dns stops working, and I do not get any DNS resolving at all. My parents have a very old legacy internet connection that only has an IPv4 address. I'm using the same configuration that I use in other networks, so naturally I have both IPv4 and IPv6 addresses to forward to. If I remove those IPv6 addresses (first two name_servers) from the config, trust-dns works fine. **To Reproduce** - Install trust-dns: ```bash yay -S trust-dns ``` - Write `/etc/named.toml` ```toml listen_addrs_ipv4 = ["127.0.0.1"] listen_addrs_ipv6 = ["::1"] listen_port = 53 [[zones]] zone = "." zone_type = "Forward" [zones.stores] type = "forward" [[zones.stores.name_servers]] socket_addr = "[2606:4700:4700::1111]:853" protocol = "tls" tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com" trust_nx_responses = false [[zones.stores.name_servers]] socket_addr = "[2606:4700:4700::1001]:853" protocol = "tls" tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com" trust_nx_responses = false [[zones.stores.name_servers]] socket_addr = "1.1.1.1:853" protocol = "tls" tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com" trust_nx_responses = false [[zones.stores.name_servers]] socket_addr = "1.0.0.1:853" protocol = "tls" tls_dns_name = "1dot1dot1dot1.cloudflare-dns.com" trust_nx_responses = false ``` - Start `named.service` via systemd - Try to do a dns lookup ```bash $ drill msrd0.de Error: error sending query: Could not send or receive, because of network error ``` **Expected behavior** I get a response rather than a network error. **System:** - OS: ArchLinux - Architecture: x86_64 - Version: Rolling Release - rustc version: 1.66 **Version:** Crate: trust-dns Version: 0.22.0 **Additional context** Trust-dns does not indicate any errors in its log: ``` $ sudo systemctl status named [sudo] password for msrd0: ● named.service - TRUST-DNS server Loaded: loaded (/etc/systemd/system/named.service; enabled; preset: disabled) Active: active (running) since Wed 2022-12-28 11:07:00 CET; 2min 0s ago Main PID: 590 (named) Tasks: 5 (limit: 9408) Memory: 18.4M CPU: 215ms CGroup: /system.slice/named.service └─590 /usr/bin/named Dec 28 11:08:36 ACER-SP314-51 named[590]: 1672222116:INFO:trust_dns_server::server::server_future:771:request:41536 src:UDP://::1#39573 QUERY:radicale.msrd0.de.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:08:44 ACER-SP314-51 named[590]: 1672222124:INFO:trust_dns_server::server::server_future:771:request:47544 src:UDP://::1#51488 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:08:45 ACER-SP314-51 named[590]: 1672222125:INFO:trust_dns_server::server::server_future:771:request:31124 src:UDP://::1#55179 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:08:50 ACER-SP314-51 named[590]: 1672222130:INFO:trust_dns_server::server::server_future:771:request:31124 src:UDP://::1#55179 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:08:50 ACER-SP314-51 named[590]: 1672222130:INFO:trust_dns_server::server::server_future:771:request:43374 src:UDP://::1#55333 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:08:55 ACER-SP314-51 named[590]: 1672222135:INFO:trust_dns_server::server::server_future:771:request:31124 src:UDP://::1#41384 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:08:55 ACER-SP314-51 named[590]: 1672222135:INFO:trust_dns_server::server::server_future:771:request:43374 src:UDP://::1#55333 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:09:00 ACER-SP314-51 named[590]: 1672222140:INFO:trust_dns_server::server::server_future:771:request:55726 src:UDP://::1#47138 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:09:00 ACER-SP314-51 named[590]: 1672222140:INFO:trust_dns_server::server::server_future:771:request:43374 src:UDP://::1#56296 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA Dec 28 11:09:05 ACER-SP314-51 named[590]: 1672222145:INFO:trust_dns_server::server::server_future:771:request:17793 src:UDP://::1#60414 QUERY:chat.signal.org.:A:IN qflags:RD response:NoError rr:2/0/0 rflags:RD,RA ```

kerem added the

perf

platform:linux

has workaround

labels

2026-03-16 00:17:13 +03:00

kerem commented

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

Author

Owner

@djc commented on GitHub (Dec 30, 2022):

Do you want to try with current main? I wonder if the changes from #1861 help with this.

@djc commented on GitHub (Dec 30, 2022): Do you want to try with current main? I wonder if the changes from #1861 help with this.

kerem commented

2026-03-16 00:17:29 +03:00

Author

Owner

@msrd0 commented on GitHub (Dec 31, 2022):

Yes, it works on main. However, the startup delay (I assume that's the time it takes trust-dns to figure out that the IPv6 entries are unavailable) is pretty long (like half a minute to a minute or so).

Also interestingly both versions, main and latest release, work when I connect via USB2Ethernet. I wonder what the difference is, as both wired and wifi connections have an IPv4, IPv6 and link-local IPv6 address (IPv6 can be used to connect to other devices in the same network, but the router only has IPv4 access to the internet).

When I try ping with an IPv6 address, I get an instant failure, so I think it should be possible to immediately fail the IPv6 entries (The reply comes from the IPv6 address of the router):

$ ping -6 '2606:4700:4700::1111'
PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes
From fde0:30a6:4103:1:7a94:b4ff:fe0b:c078 icmp_seq=1 Destination unreachable: No route

Update: When I'm only connected to wifi, the first few ping packets get lost, and only at about packet 9 the router starts replying with No route. That's probably the difference.

@msrd0 commented on GitHub (Dec 31, 2022): Yes, it works on main. However, the startup delay (I assume that's the time it takes trust-dns to figure out that the IPv6 entries are unavailable) is pretty long (like half a minute to a minute or so). Also interestingly both versions, main and latest release, work when I connect via USB2Ethernet. I wonder what the difference is, as both wired and wifi connections have an IPv4, IPv6 and link-local IPv6 address (IPv6 can be used to connect to other devices in the same network, but the router only has IPv4 access to the internet). When I try ping with an IPv6 address, I get an instant failure, so I think it should be possible to immediately fail the IPv6 entries (The reply comes from the IPv6 address of the router): ``` $ ping -6 '2606:4700:4700::1111' PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes From fde0:30a6:4103:1:7a94:b4ff:fe0b:c078 icmp_seq=1 Destination unreachable: No route ``` **Update:** When I'm only connected to wifi, the first few ping packets get lost, and only at about packet 9 the router starts replying with No route. That's probably the difference.

kerem commented

2026-03-16 00:17:34 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 2, 2023):

Choosing routable interfaces could probably be better than we are doing today. I know we have issues in a few locations related to that. IPv6 happens to generally have many more interfaces available, which creates a general problem there. I'm open to suggestions on how to improve the way the code functions today. It's definitely something that needs to be revisited for mDNS as well.

@bluejekyll commented on GitHub (Jan 2, 2023): Choosing routable interfaces could probably be better than we are doing today. I know we have issues in a few locations related to that. IPv6 happens to generally have many more interfaces available, which creates a general problem there. I'm open to suggestions on how to improve the way the code functions today. It's definitely something that needs to be revisited for mDNS as well.