Bug 27929

When a query for both IPv4 and IPv6 records is performed, glibc's stub resolver will treat ServFail for one of the two as equivalent to nonexistence (NODATA) as long as the other succeeds (and has data? not sure if this happens if it's NODATA). This creates an opportunity for an attacker to silently forge nonexistence of one or the other in an environment where the user has DNSSEC-validating nameservers and (rightly) expects all results for signed zones to be authentic.

I became aware of this behavior because a musl libc user shipping software linked to musl found that musl's stub resolver failed in an environment where glibc's was succeeding, and the underlying cause was a buggy consumer-router product returning ServFail in place of NODATA. I'm reaching out the the vendor to get that fixed, but I suspect glibc is doing this intentionally for compatibility with broken nameservers like the ones we encountered. However, I don't think there's been consideration of how this lax interpretation of results impacts the integrity of results in an environment with DNSSEC validation.

The behavior probably needs to be made optional and documented.

Multiple other stub resolver implementations were found to have the same behavior here. As this undermines DNSSEC, I would like to pursue a CVE assignment for the issue across multiple stub resolvers. I believe having this recognized as a vulnerability would aid in convincing vendors with buggy nameservers to fix them.

Real world impact is probably fairly low, which is why I've reported publicly rather than through private security channels. I don't believe it's possible to completely forge nonexistence of the name, only of one or the other address. This could still have nontrivial security impact in the event that the address families have routing with different privacy or cost properties, or if results are filtered for family such that the end result is an apparently-validated nonexistence for the name rather than a lookup failure.