Unsupported DNSSEC algorithms should not lead to SERVFAIL.

[Petr Menšík]

I was thinking about something similar. I think it would be nice to 
maintain 3rd party distributed negative trust anchors. Because if you 
have a good implementation of DNSSEC validation, which bind9 in all 
versions in my opinion, your failures are either problem with broken 
upstream forwarders or errors on the authoritative side.

I think something like discontinued dlv.isc.org would be useful, but 
with a modified behavior. Only if the bind would fail to validate 
answer, which is supposed to be validated, consult this kind of 
subdomain. If bind could receive such zone by zone transfer, it could 
even bring custom positive trust anchors.

Example:

example.com operators screw operations and it is known problem for a 
limited time.

recursive validator would emit SERVFAIL for any example.com records. But 
it would try DS query on example.com.nta.example.org. If it had 
non-NXDOMAIN response, add NTA into local daemon with time of TTL.

That would allow operators of smaller resolvers to shared the burden and 
have a single place to maintain NTA sources. I think big operators have 
dedicated teams to distribute such negative trust anchors. 
nta.example.org should be signed by dnssec in this case. I think 
something similar would help with deployment of DNSSEC validation even 
to non-specialists. Which usually do not have enough knowledge to 
verify, whether this is a genuine attack or an operator error.

Nonetheless, this report is indeed a valid bug in bind9 and it generates 
SERVFAIL where it should not. It does not happen often, but this is bug 
on bind side.

Cheers,
Petr

On 03/11/2025 23:22, Richard Laager via bind-users wrote:
> On 2025-10-30 12:21, Kelsey Cummings wrote:
>> in a service provider context, our job is to do our best to resolve 
>> DNS as quickly and as well as possible for our customers.  If google 
>> and cloudflare resolve the domains and we can't, the customer does 
>> not care in the slightest why, only that they're not able to get to 
>> their work, school or other public resource. This just results in 
>> them migrating away from our recursive clusters to these public 
>> resources for good. 
>
> I wanted to second this sentiment.
>
> I have run into multiple issues where BIND fails to resolve things 
> that the public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) resolve just 
> fine. The answer each time has been that the authoritative side is 
> doing DNS wrong. And, in each case, I ultimately agree with the BIND 
> developers that the authoritative side is wrong. However, that simply 
> does not matter to my customers. If they can resolve the name 
> everywhere else, then they view me as the problem. And when other 
> resolvers resolve it just fine, it's hard to get the authoritative 
> side to care either. I'm just one little ISP in the middle of nowhere.
>
> Granted, I understand that BIND is open source and you have no 
> obligation to me.
>
> -- 
> Richard
>
-- 
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB