[GH-ISSUE #1965] Resolution fails for a subdomain but not for the root domain #830

New issue

Closed

opened 2026-03-16 00:28:34 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @thosmos on GitHub (Jun 9, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1965

We're attempting to use trust-dns as a local DNS server for an IPv4 NAT network of about 150 OpenWRT routers to reduce the impact on public DNS servers. So far it's working for the most part, but it's failing on some subdomains like downloads.openwrt.org that work when querying via other DNS servers. I'm wondering if this is a bug or a configuration problem. 172.168.0.254 is the internal gateway IP where trust-dns is running.

% resolve openwrt.org -n 172.168.0.254:53 
Querying for openwrt.org A from tcp:172.168.0.254:53, udp:172.168.0.254:53
Success for query openwrt.org IN A
	openwrt.org. 2512 IN A 139.59.209.225

% resolve downloads.openwrt.org -n 172.168.0.254:53
Querying for downloads.openwrt.org A from tcp:172.168.0.254:53, udp:172.168.0.254:53
Error: ResolveError { kind: NoRecordsFound { query: Query { name: Name("downloads.openwrt.org."), query_type: A, query_class: IN }, soa: None, negative_ttl: None, response_code: NoError, trusted: true } }

% resolve downloads.openwrt.org -n 1.0.0.1:53
Querying for downloads.openwrt.org A from tcp:1.0.0.1:53, udp:1.0.0.1:53
Success for query downloads.openwrt.org IN A
	downloads.openwrt.org. 2367 IN CNAME mirror-02.infra.openwrt.org.
	mirror-02.infra.openwrt.org. 1316 IN A 168.119.138.211

Originally created by @thosmos on GitHub (Jun 9, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1965 We're attempting to use trust-dns as a local DNS server for an IPv4 NAT network of about 150 OpenWRT routers to reduce the impact on public DNS servers. So far it's working for the most part, but it's failing on some subdomains like `downloads.openwrt.org` that work when querying via other DNS servers. I'm wondering if this is a bug or a configuration problem. `172.168.0.254` is the internal gateway IP where trust-dns is running. ``` % resolve openwrt.org -n 172.168.0.254:53 Querying for openwrt.org A from tcp:172.168.0.254:53, udp:172.168.0.254:53 Success for query openwrt.org IN A openwrt.org. 2512 IN A 139.59.209.225 % resolve downloads.openwrt.org -n 172.168.0.254:53 Querying for downloads.openwrt.org A from tcp:172.168.0.254:53, udp:172.168.0.254:53 Error: ResolveError { kind: NoRecordsFound { query: Query { name: Name("downloads.openwrt.org."), query_type: A, query_class: IN }, soa: None, negative_ttl: None, response_code: NoError, trusted: true } } % resolve downloads.openwrt.org -n 1.0.0.1:53 Querying for downloads.openwrt.org A from tcp:1.0.0.1:53, udp:1.0.0.1:53 Success for query downloads.openwrt.org IN A downloads.openwrt.org. 2367 IN CNAME mirror-02.infra.openwrt.org. mirror-02.infra.openwrt.org. 1316 IN A 168.119.138.211 ```

kerem closed this issue

2026-03-16 00:28:39 +03:00

kerem commented

2026-03-16 00:28:45 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 9, 2023):

Have you enabled debug logging on the trust-dns server? Do those show any indication on why it might not be getting a proper response?

The resolve command is essentially the same logic as what the server is using with the Forwarder configuration. Are you using that setting or the Recursor (recursive resolution isn't well tested and considered experimental right now)?

@bluejekyll commented on GitHub (Jun 9, 2023): Have you enabled debug logging on the `trust-dns` server? Do those show any indication on why it might not be getting a proper response? The `resolve` command is essentially the same logic as what the server is using with the `Forwarder` configuration. Are you using that setting or the `Recursor` (recursive resolution isn't well tested and considered experimental right now)?

kerem commented

2026-03-16 00:28:50 +03:00

Author

Owner

@thosmos commented on GitHub (Jun 12, 2023):

Well this is strange, the debug logs show some resolutions happening, but not the ones I'm attempting, whether they fail or succeed. Yes the config is set to the recursor setting. I tried changing it to forward but got an error about missing a name_servers field. Where are the docs for these config options?

@thosmos commented on GitHub (Jun 12, 2023): Well this is strange, the debug logs show some resolutions happening, but not the ones I'm attempting, whether they fail or succeed. Yes the config is set to the `recursor` setting. I tried changing it to `forward` but got an error about missing a `name_servers` field. Where are the docs for these config options?

kerem commented

2026-03-16 00:28:55 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 12, 2023):

oh, it's good to hear that the recursor kinda works. I'll use your example to try and workout what's going on with that.

For the forwarding option, we don't have a lot of docs, apologies, here's the best example that I have: github.com/bluejekyll/trust-dns@a614257fb0/tests/test-data/test_configs/example_forwarder.toml

@bluejekyll commented on GitHub (Jun 12, 2023): oh, it's good to hear that the `recursor` kinda works. I'll use your example to try and workout what's going on with that. For the forwarding option, we don't have a lot of docs, apologies, here's the best example that I have: https://github.com/bluejekyll/trust-dns/blob/a614257fb0b57471c0903d0c88e15528a69faac5/tests/test-data/test_configs/example_forwarder.toml

kerem commented

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

Author

Owner

@thosmos commented on GitHub (Jun 13, 2023):

That worked and we're now getting reliable resolutions from downstream routers. Thanks for your work on this!

@thosmos commented on GitHub (Jun 13, 2023): That worked and we're now getting reliable resolutions from downstream routers. Thanks for your work on this!

kerem referenced this issue

2026-03-16 02:21:40 +03:00

[PR #830] [CLOSED] Bump untrusted from 0.6.2 to 0.7.0 #1718