[blueflow]

As mentioned correctly in [2], DNS issues with musl stem from the fact that it follows the DNS specs strictly and exposed bugs in certain DNS servers.

For an HTTP server replying with 200 OK instead of an 404 Not Found upon ENOENT, the situation is clear that this is not a client-side bug. The same should be assumed of DNS/NXDOMAIN.

[xnyanta]

As much as I agree with your reasoning, I have experienced this kind of breakage first-hand due to cloudflare and DNSSEC and will continue using DNS resolving code that doesn't cause me pain and suffering (anything that isn't musl) because making this work with musl is quite literally out of my control.

[kenmacd]

Wait, are you me? I tried to convince musl to not break in this case (https://www.openwall.com/lists/musl/2022/12/04/1), but mostly got a "we're right, cloudflare's wrong" answer. Tweeted at Cloudflare about the issue (https://twitter.com/KennyMacDermid/status/160055878578481971...) and never heard back. I really don't care who's right, and can't change who's using Cloudflare+DNSSEC, so instead I just don't use musl.

[Previous comment](https://news.ycombinator.com/item?id=35058094): ---

My personal 'musl broke it' story comes from resolving domains from Cloudflare that use DNSSEC in a K8 cluster. Basically this:

  - K8 sets container to use `ndot:5`, causing the search list to be used
  - Musl walks that search list looking for domain
  - Cloudflare does not set the NXDOMAIN flag on a DNSSEC domain but does include an NSEC record (if you query with the dnssec flag).
  - Musl takes this 'NOERROR' reply and returns an EAI_NODATA.

Is Cloudflare wrong? I don't know, maybe. They say some things about the standards[0] and that it's technically 'right'. I don't see why they couldn't change the behaviour for queries without the dnssec flag, but I digress.

The issue is that every other libc I tested will continue searching and actually resolve the domain. Musl is the odd one out, and _only_ in the case where the search list ends up with domain using Cloudflare and dnssec.

Even if Musl is 'right' here, when it disagrees with major implementations and a major DNS nameserver does it really matter?

[0]: https://blog.cloudflare.com/black-lies/ ---

[xnyanta]

> Wait, are you me?

If you hadn't made that HN post I would probably still be scratching my head as to why I have intermittent DNS resolution issues in my personal Kubernetes cluster. I've been having them for years only for some specific software (my mediaserver stack, packaged by linuxserver.io). Since this isn't mission critical stuff I just shrugged it off and dealt with it. Eventually I read your post and it all clicked. I can't find any maintained distributions for that software that don't use alpine/musl sadly so I added[1] dnsConfigs to all of my deployments using musl to force ndots to 1 and accept the fact that all of my cluster name resolution for those deployments will have to be fully qualified. It's a really frustrating situation and made me realize how badly musl plagues the container ecosystem due to its use in Alpine Linux and alpine's popularity because of the small images it produces. Alpine Linux and musl are on my shitlist for life.

1: https://github.com/starcraft66/infrastructure/commit/3b53bb0...

[tptacek]

musl doesn't implement TCP DNS at all. When it gets a respond with the truncation bit set, it just assumes the completed records in the truncated response were sufficient, the best records even, and proceeds as if the lookup succeeded. It's hard to take seriously claims that it's strictly implementing the protocol.

[howenterprisey]

It does as of a month or so ago. https://news.ycombinator.com/item?id=36494177