deNIC-Incident vom 5. Mai 2026

Oder: Wie ich lernte, NTAs zu lieben.

Peter Eckel <pe@sys4.de>

Feierabend

"Schnell noch schauen, wo mein Paket steckt, und dann gemütlich einen Film sehen" - so der Plan.

DHL-App funktioniert nicht

Nein, ich bin nicht offline
Kurzer Check: dhl.de wird nicht aufgelöst
… "das ist dann wohl ein Problem bei DHL"
Nun zum Film!

Eine Filmlänge später

Nachricht eines lieben Freundes: Alles brennt!

Na gut … oops.

Erste Checks

Es ist nicht nur DHL
Es scheint nur .de betroffen zu sein
Das aber auch gründlich!
Verdacht: DNSSEC in der .de-Zone ist kaputt

DNSviz

Das ist definitiv etwas Größeres!
Signierung der .de-Zone ist kaputt
Alle DNSSEC-validierenden DNS-Resolver haben jetzt ein Problem mit .de

Alle? Nicht alle!

Hinweis des schon nicht mehr ganz so verzweifelten Freundes
Mit quad9 als Resolver geht es!
Was machen die anders?

Irgendwas dämmert!

Da war doch was beim DDI-Roundtable im April
NTA - Negative Trust Anchors
Ich hatte ein wenig recherchiert, und quad9 war eine Quelle
Generell werden NTAs kritisch gesehen
quad9 setzt NTAs nur spärlich ein und dokumentiert dies
Schauen wir mal …

Bingo!

NTA in BIND9

Ein NTA in kann in BIND9 sehr einfach gesetzt werden
rndc nta de [view]
Angabe einer Lifetime ist möglich
Wir haben ein Problem, das zu unserer Lösung paßt!

Kurzer Test

[root@medusa05 ~]# rndc nta -lifetime 86400 de internal
Negative trust anchor added: de/internal, expires 06-May-2026 22:31:56.000
[root@medusa05 ~]# delv @medusa05 dhl.de. a
; unsigned answer
dhl.de.        20    IN    A    23.197.143.114
[root@medusa05 ~]# delv @medusa05 dhl.de. aaaa
; unsigned answer
dhl.de.        20    IN    AAAA 2a02:26f0:2780:992::4213
dhl.de.        20    IN    AAAA 2a02:26f0:2780:98e::4213

→ Klappt.

Dann in die Fläche damit!

pete@macallan % ansible -bKa 'rndc nta -lifetime 86400 de internal' dns_resolver
BECOME password:
medusa05 | CHANGED | rc=0 >>
Negative trust anchor added: de/internal, expires 06-May-2026 22:35:23.000
medusa06 | CHANGED | rc=0 >>
Negative trust anchor added: de/internal, expires 06-May-2026 22:35:23.000
medusa09 | CHANGED | rc=0 >>
Negative trust anchor added: de/internal, expires 06-May-2026 22:35:23.000
medusa10 | CHANGED | rc=0 >>
Negative trust anchor added: de/internal, expires 06-May-2026 22:35:23.000

Und bei unbound?

Die Lösung ist nicht ganz so elegant
Anpassung im Config-File
domain-insecure: de
Man muß daran denken, das wieder herauszunehmen
Ob das dann wohl passiert?
Freundschaft ist nicht (immer) transitiv: Ich mag den vi, besagter Freund leider nicht.

unbound interaktiv

Es geht aber auch ohne Änderung des Konfigurationsfiles:

# unbound-control insecure_add de
ok
# unbound-control list_insecure
de.
# unbound-control insecure_remove de
ok
# unbound-control list_insecure

Der NTA verschwindet dann spätestens beim nächsten Restart des unbound-Daemons. Eine zeitliche Beschränkung wie bei BIND 9 gibt es hier leider nicht.

Die Geister, die ich rief …

… werde ich auch leicht wieder los:

pete@macallan % ansible -bKa 'rndc nta -remove de internal' dns_resolver
BECOME password:
medusa05 | CHANGED | rc=0 >>
Negative trust anchor not found: de/internal
medusa06 | CHANGED | rc=0 >>
Negative trust anchor removed: de/internal
medusa09 | CHANGED | rc=0 >>
Negative trust anchor removed: de/internal
medusa10 | CHANGED | rc=0 >>
Negative trust anchor removed: de/internal

Man kann natürlich auch einfach warten, bis die Lifetime abgelaufen ist.

Bei unbound ist es Handarbeit, oder erfordert einen Restart, wenn man unbound-control zum Setzen des NTA verwendet hat.

Fazit

NTA sind keine "schöne" Lösung
Dies besonders dann nicht, wenn man sie dauerhaft verwendet oder nach der Lösung des adressierten Problems vergißt
Aber: Besondere Situationen erfordern besondere Maßnahmen
Eine kaputte TLD fällt ganz sicher in diese Kategorie

Links

quad9 zu NTAs

RFC 7646

Blogartikel bei sys4.de