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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
