Bullshit. gethostbyname() needs to work. If it asks a question that takes larger than the maximum UDP packet size, and triggers a "truncated response" from the server, it needs to repeat the request with TCP. It always needed to do that. Resolvers have done that since the nineteen eighties. If you can't do that, don't include gethostbyname() in the library; don't make a fake one that doesn't work. Certainly, don't have a broken gethostbyname() and then tell developers it's their fault for not using a third-party DNS library.

With RFC 9210 being published now, which requires DNS over TCP, I think it's fair to say that musl libc does not implement DNS resolution.

You can't publish a new RFC about DNS and declare every noncompliant implementation "not DNS". But RFCs are totally besides the point. TCP DNS resolution has been a field requirement for decades. There's nothing new about it; it's been standardized since the 1980s.

It also needs to support whatever hostname resolution systems the local system administrator has chosen to use. DNS is the most common, yes, but mDNS is in common use (for .local hostnames, via Avahi or mDNSResponder), you might need LLMNR to interoperate with Windows environments, and in legacy environments you might also need to support things like NetBIOS Name Service (Samba nss_winbind) or even NIS

(There is a deep irony here that mDNS, LLMNR and NBNS all use the DNS packet format on the wire!)

Sometimes the argument given is that these resolvers should be implemented via a service which listens on localhost, with resolv.conf pointed at. Unfortunately, this assumes you can translate the responses from querying all of these protocols to DNS packets. This isn't true: There's no way to encode an IPv6 address scope in a DNS packet (because they're machine-local considerations). In mDNS and LLMNR, this isn't a problem because the scope is implicit - take it from the sockaddr_in6 of the received packet. This means link local addressing doesn't work.

(n.b. gethostbyname can't support link local addressing either, but getaddrinfo can. This is one reason for gethostbyname's deprecation in favor of the latter API)

tell that rich, please.

the title should really be the tragedy of musl

And the gethostbyname() calls might be in a dependency of another dependency and that's when the real fun begins :)

This is likely a response to Alpine not supporting DNS protocol fully (RF9210 to be precise). https://news.ycombinator.com/item?id=30642632

The blog talks about "use of DNS for bulk data distribution, such as in DNSSEC, DKIM and other applications", but it's not just that -- even for a most basic use, "ask a hostname from user and connect to that host", musl will fail if the response contains too many IP addresses.

9210? Try 1035. This stuff has been well-specified since the 1980s.

The conclusion reached by the author is filled with incredible hubris. In reality, musl literally abandon portability and compatibility by taking this stance, which makes the entire library worthless for use with code developed on standards compliant implementations.

In turn, this decision undermines - if not actively destroys - the potential value of Alpine as a distribution, because it potentially represents the tip of an iceberg of other compatibility issues.

After running into this issue, I gave up on Alpine entirely, because I do not have any inclination to support people or projects that actively choose to go against established standards.