3 ms·

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 `ndo

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/ https://blog.cloudflare.com/black-lies/

benmmurphy 4y ago
the solution is for the resolver to not use DNSSEC because it is broken. I have a domain that we hit and looking at the query stats we have for it I have a strong suspicion that it is returning invalid DNSSEC signatures when it is rolling over the signatures. I suspect it is either not rolling them fast enough and serving stale signatures or rolling them too quickly and serving signatures that are not valid for the current time. we do parallel queries to public recursive nameservers and the name servers we were using we returning SERVFAIL errors. its possible when making queries to recursive name servers to disable checking DNSSEC and we have enabled that option now.
- kenmacd 4y ago
  Maybe. The problem is that I couldn't control the DNS settings where this code was run, nor could I control what ended up in the search domain. The query did not have the +dnssec flag, but that didn't actually help because Cloudflare wasn't setting NXDOMAIN either way. This was in golang code, so I ended up switching to `netdns=go` because like all the other libc's, the golang resolving code worked fine.

benmmurphy 4y ago

the solution is for the resolver to not use DNSSEC because it is broken. I have a domain that we hit and looking at the query stats we have for it I have a strong suspicion that it is returning invalid DNSSEC signatures when it is rolling over the signatures. I suspect it is either not rolling them fast enough and serving stale signatures or rolling them too quickly and serving signatures that are not valid for the current time. we do parallel queries to public recursive nameservers and the name servers we were using we returning SERVFAIL errors. its possible when making queries to recursive name servers to disable checking DNSSEC and we have enabled that option now.

kenmacd 4y ago
Maybe. The problem is that I couldn't control the DNS settings where this code was run, nor could I control what ended up in the search domain. The query did not have the +dnssec flag, but that didn't actually help because Cloudflare wasn't setting NXDOMAIN either way. This was in golang code, so I ended up switching to `netdns=go` because like all the other libc's, the golang resolving code worked fine.