[GH-ISSUE #249] Document resolver differences from glibc and/or musl #414

New issue

Open

opened 2026-03-15 22:22:59 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 22:22:59 +03:00

Owner

Originally created by @briansmith on GitHub (Oct 24, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/249

See http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Name_Resolver_.2F_DNS for an example of the kind of documentation I'm talking about. It would be useful to know whether Trust-DNS intends to implement the musl behavior of the glibc behavior or a different thing yet, by default and/or when it is configured through resolv.conf.

That link failed to load for me today. Here's a link to Google's cached copy: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwiki.musl-libc.org%2Fwiki%2FFunctional_differences_from_glibc%23Name_Resolver_.2F_DNS. And here's the current text:

Name Resolver / DNS

Traditional resolvers, including glibc's, make use of multiple nameserver lines in resolv.conf by trying each one in sequence and falling to the next after one times out. musl's resolver queries them all in parallel and accepts whichever response arrives first. This can increase network load (this is mitigated by only supporting up to three nameservers, and can be mitigated further at the configuration level by only configuring one nameserver) but drastically improves performance and reliability of DNS lookups, especially if diverse nameservers are used. An ideal configuration is:

Caching nameserver on localhost (near-zero latency for locally cached results, but typically smallest cache size, and slowest for queries not serviceable from cache)

ISP nameserver (very low latency for cached results, typically moderate cache size, and moderate performance for queries not serviceable from cache)

8.8.8.8 (somewhat higher latency but tends to have the whole DNS tree cached)

musl's resolver previously did not support the "domain" and "search" keywords in resolv.conf. This feature was added in version 1.1.13, but its behavior differs slightly from glibc's: queries with fewer dots than the ndots configuration variable are processed with search first then tried literally (just like glibc), but those with at least as many dots as ndots are only tried in the global namespace (never falling back to search, which glibc would do if the name is not found in the global DNS namespace). This difference comes from a consistency requirement not to return different results subject to transient failures or to global DNS namespace changes outside of one's control (addition of new TLDs).

glibc supports IDN (non-ASCII name lookups via DNS) but requires the use of custom non-standard flags to getaddrinfo and getnameinfo to convert such names to/from the internal representation used in the DNS system (Punycode). musl does not yet support IDN conversions at all (but programs that know about IDN/Punycode and do the conversions themselves can of course lookup such names), but when support is added, it will always be enabled rather than requiring explicit options from the application.

Originally created by @briansmith on GitHub (Oct 24, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/249 See http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Name_Resolver_.2F_DNS for an example of the kind of documentation I'm talking about. It would be useful to know whether Trust-DNS intends to implement the musl behavior of the glibc behavior or a different thing yet, by default and/or when it is configured through resolv.conf. That link failed to load for me today. Here's a link to Google's cached copy: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwiki.musl-libc.org%2Fwiki%2FFunctional_differences_from_glibc%23Name_Resolver_.2F_DNS. And here's the current text: > Name Resolver / DNS > > Traditional resolvers, including glibc's, make use of multiple nameserver lines in resolv.conf by trying each one in sequence and falling to the next after one times out. musl's resolver queries them all in parallel and accepts whichever response arrives first. This can increase network load (this is mitigated by only supporting up to three nameservers, and can be mitigated further at the configuration level by only configuring one nameserver) but drastically improves performance and reliability of DNS lookups, especially if diverse nameservers are used. An ideal configuration is: > > * Caching nameserver on localhost (near-zero latency for locally cached results, but typically smallest cache size, and slowest for queries not serviceable from cache) > * ISP nameserver (very low latency for cached results, typically moderate cache size, and moderate performance for queries not serviceable from cache) > * 8.8.8.8 (somewhat higher latency but tends to have the whole DNS tree cached) > > musl's resolver previously did not support the "domain" and "search" keywords in resolv.conf. This feature was added in version 1.1.13, but its behavior differs slightly from glibc's: queries with fewer dots than the ndots configuration variable are processed with search first then tried literally (just like glibc), but those with at least as many dots as ndots are only tried in the global namespace (never falling back to search, which glibc would do if the name is not found in the global DNS namespace). This difference comes from a consistency requirement not to return different results subject to transient failures or to global DNS namespace changes outside of one's control (addition of new TLDs). > > glibc supports IDN (non-ASCII name lookups via DNS) but requires the use of custom non-standard flags to getaddrinfo and getnameinfo to convert such names to/from the internal representation used in the DNS system (Punycode). musl does not yet support IDN conversions at all (but programs that know about IDN/Punycode and do the conversions themselves can of course lookup such names), but when support is added, it will always be enabled rather than requiring explicit options from the application.

kerem added the

docs

crate:resolver

platform:linux

labels

2026-03-15 22:22:59 +03:00

kerem commented

2026-03-15 22:23:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 24, 2017):

Where do you want to see this documentation? At the moment it's spread around the individual libraries, etc. I tried to match glibc where I agreed with it, but I don't want to support any of the decisions that I consider to be incorrect in their implementation.

@bluejekyll commented on GitHub (Oct 24, 2017): Where do you want to see this documentation? At the moment it's spread around the individual libraries, etc. I tried to match glibc where I agreed with it, but I don't want to support any of the decisions that I consider to be incorrect in their implementation.

kerem commented

2026-03-15 22:23:15 +03:00

Author

Owner

@briansmith commented on GitHub (Oct 24, 2017):

Where do you want to see this documentation?

In -resolver's README.md.

I tried to match glibc where I agreed with it, but I don't want to support any of the decisions that I consider to be incorrect in their implementation.

That's great. The main thing that a potential user needs to know is what is different, so they can decide to swap out their use of glibc for Trust-DNS.

@briansmith commented on GitHub (Oct 24, 2017): > Where do you want to see this documentation? In -resolver's README.md. > I tried to match glibc where I agreed with it, but I don't want to support any of the decisions that I consider to be incorrect in their implementation. That's great. The main thing that a potential user needs to know is what is different, so they can decide to swap out their use of glibc for Trust-DNS.

kerem referenced this issue

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

[PR #414] [CLOSED] Bump env_logger from 0.5.6 to 0.5.8 #1425