--- Begin Message ---
Hi Marco,
On 11 May 2026, at 13:53, Marco Davids wrote:
> Hi Carsten,
>
> Op 11-05-2026 om 12:46 schreef Carsten Strotmann:
>> My guess is that DeNIC did know early that the incident wasn't an attack,
>> but that information was not communicated. A note on "status.denic.de" would
>> have helped.
>
> If this was indeed an attack, then any information published on
> 'status.denic.de' cannot be fully trusted.
it would have helped, even though as you mention it cannot be "fully" trusted.
A completely external information feet would be even better.
>
> But to me it was fairly clear that it was an operational issue, based on
> signals we were already seeing come in at an early stage, from various
> sources.
Yes, "we" (as in the people in the DNSSEC/DNS/OARC community) had the
information, but many operators of DNSSEC validating resolver out there have
not.
I'm not talking about me or you, we have means to get the information. I have
contact into DeNIC (that I did not use last week, because DeNIC people had
better work to do than answering my questions).
But the "normal/mortal" admin of a university/company/organisation DNSSEC
validating resolver, she doesn't have access to this information "we" have and
also she might not have the knowledge/experience to interpret the signals seen.
>
> Speaking of trust: users place trust not only in DNSSEC, but also in the
> resolver they choose to use.
Exactly.
I would like see a Internet where users can trust smaller, independent DNSSEC
resolvers in their local networks, not only a few large public resolver.
That requires that "we" (as in the DNS/DNSSEC people that steer the protocol
development) give the admins that run DNSSEC validating resolver enough tools
and information to do so securely. And in my view, this is not the case today.
A admin of a DNSSEC validating resolver today is not able to easily find the
information required to make an informed decision to active an NTA or not.
> If you don't trust a resolver like Cloudflare's to do the right thing, you
> may want to consider alternatives or run your own resolver.
That's the point. Cloudflare did the correct thing, they are big and important
enough to get the information needed to decide to implement a NTA or not.
But operators of (smaller) DNSSEC validating resolvers are not able to get that
information. They are left in the dark.
I see the danger that these operators will activate NTA whenever there is a
problem with a DNSSEC signed zone, disabling security for their users, because
they have no means to get the required information to make an informed decision.
>
>> Maybe it would help to have a technical/automated way to get a "NTA
>> subscription", maybe as part of an extension to response policy zones (RPZ).
>
> I'm not sure if that is the right way to go. What if such a 'centralised
> service' gets compromised?
Sorry, I wasn't clear in my previous mails. I have two independent proposals
for discussion:
1) a central entity that publishes trusted information on DNSSEC issues. These
informations would be on a web-page, and operators of validating DNSSEC
resolver would go there once they experience DNSSEC resolution issues. There
would be no automation, not feed of NTA-data from such a central entity. I
would only be a clear signal that is easy to find and will help operators to
decide on NTA activation. While the possibility that an attacker can compromise
both a large/important DNS zone *AND* the entity publishing that signal is not
zero, it is much harder than compromising one target alone.
2) a way to subscribe to NTA-data from a trusted source, similar to RPZ. There
would be not a single provider of such a feed, but multiple, as there are today
for RPZ data.
so yes, having a single source of an NTA feed that will get deployed
automatically is a very bad idea.
>
> Lastly, I appreciate the policy and transparency of Quad9:
>
> https://quad9.net/service/negative-trust-anchors/<https://quad9.net/service/negative-trust-anchors/>
>
> They openly acknowledge that the risk of users leaving them is one of their
> criteria, which makes total sense to me.
>
I fully agree, Quad9 "NTA Addition Criteria" and open communication of enabled
NTAs should become "best practice" for larger resolver operators.
Greetings
Carsten
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
