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/ ---