the tragedy of gethostbyname (2022)
4 points by kokada
4 points by kokada
This article is a very long-winded argument that it was unreasonable for anyone to expect musl’s stub resolver to work properly or conform to RFC 5966 (2010), RFC 7766 (2016), RFC 9210 (2022), which all say DNS implementations MUST support queries over TCP. The reasoning is that because gethostbyname() is a multiprotocol API, it’s OK for musl to ship broken protocol modules; and because sysadmins can disable protocol modules in a way that prevents software from working, it’s OK if musl’s protocol modules don’t work properly when enabled. And because gethostbyname() predates the DNS, it’s OK for its DNS support to be broken, and therefore getaddrinfo() (which was designed for DNS lookups) can be broken too. But because everyone was repeatedly complaining that DNS should work properly, musl begrudgingly fixed its stub resolver, but the official musl opinion is that musl will always be unreliable and the complainers were wrong to use musl.
That seems like the most uncharitable interpretation you can pose. The more charitable interpretation would be that:
If you are an application developer you should not be depending on this api for dns resolution for reasons around how the standard is implemented in practice. (This is in fact true. You can not in fact depend on this api to give you all the kinds of dns support you need)
Musl is landing support for dns over tcp which will allow folks using alpine to get that behavior but it wasn't a goal initially there.