[dns-operations] NTA for DE installed on 1.1.1.1 around an hour ago

[Carsten Strotmann]

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