The article is missing a reference to RFC 7766 which clarified in 2016 that stub resolvers MUST implement DNS-over-TCP. There’s a whole series of RFCs about DNS over TCP because of boneheads who break things by not supporting it.
Better is different. If it was the same as everything else, it couldn’t be better; it would just be the same.
Different is worse. If everything else works one way, the one thing that works the other way is worse from the point of view of predictability, regularity, etc.
About a month ago I stumbled upon issues with DNS resolving inside docker containers of domains local to the host machine. I could have used this article then. :)
Why would someone choose to use a non-standard libc?
Was RMS right to insist on using the term GNU/Linux to describe the platform? I don’t want people to think that the software I write only relies on a Linux kernel to work correctly.
The Linux kernel and glibc have been developed and released in tandem for as long as I can remember. I don’t see how swapping out a key component could be expected to work well, even if it works a bit, sometimes.
I’ve worked on a musl port for another kernel, so I’m glad it exists.
It does work well. The DNS issue (which is now resolved) was basically the only glaring issue with musl outside of proprietary software (which often depends on glibc, IMO they should statically link their libc but glibc doesn’t really support that)
As it happens, musl began supporting DNS over TCP this May.
The article is missing a reference to RFC 7766 which clarified in 2016 that stub resolvers MUST implement DNS-over-TCP. There’s a whole series of RFCs about DNS over TCP because of boneheads who break things by not supporting it.
That doesn’t mean it’s not a bug. It’s just a bug in the design rather than in the implementation.
Better is different. If it was the same as everything else, it couldn’t be better; it would just be the same.
Different is worse. If everything else works one way, the one thing that works the other way is worse from the point of view of predictability, regularity, etc.
Better is worse. QED.
I would second this that this is no longer an issue in more modern Alpine images.
About a month ago I stumbled upon issues with DNS resolving inside docker containers of domains local to the host machine. I could have used this article then. :)
Why would someone choose to use a non-standard libc?
Was RMS right to insist on using the term GNU/Linux to describe the platform? I don’t want people to think that the software I write only relies on a Linux kernel to work correctly.
They cover all of the reasons here https://musl.libc.org/about.html
Because Linux isn’t a monoculture, and musl is (largely) standards-compliant so it’s not really non-standard.
The Linux kernel and glibc have been developed and released in tandem for as long as I can remember. I don’t see how swapping out a key component could be expected to work well, even if it works a bit, sometimes.
I’ve worked on a musl port for another kernel, so I’m glad it exists.
It does work well. The DNS issue (which is now resolved) was basically the only glaring issue with musl outside of proprietary software (which often depends on glibc, IMO they should statically link their libc but glibc doesn’t really support that)