Der np-Tag von DMARCbis und sein blinder DNSSEC-Fleck: das muss jeder Admin prüfen

Q: Schützt der np-Tag meine nicht existierenden Subdomains wirklich?

Ja, aber unter einer Bedingung, die nicht immer erfüllt ist: Das DNS muss für nicht existierende Namen ein echtes NXDOMAIN zurückgeben. Ist deine Zone DNSSEC-signiert und setzt Compact Denial of Existence ein, gibt sie stattdessen NOERROR zurück. Der DMARC-Evaluator glaubt dann, die Subdomain existiere, verwirft np und wendet sp an. Ist sp freizügiger als np , wird der Schutz ohne jedes Signal ausgehebelt.

Q: Bricht Compact Denial of Existence auch SPF oder DKIM?

Nein. SPF und DKIM hängen nicht von der Erkennung der Nichtexistenz einer Subdomain ab. Compact Denial betrifft nur die DMARCbis-Logik, die zwischen sp und np wählt, je nachdem ob der Name existiert oder nicht. Deine SPF- und DKIM-Prüfungen sowie die p -Richtlinie deiner Root-Domain sind nicht betroffen.

Q: Bin ich betroffen, wenn ich kein DNSSEC nutze?

In der Regel nein: Eine unsignierte Zone gibt für nicht existierende Namen ein klassisches NXDOMAIN zurück, und np greift normal. Eine Ausnahme: die Wildcards. Ein *.captaindns.com -Eintrag als A oder AAAA lässt jeden Namen aus Sicht des DNS "existieren", was np auch ohne DNSSEC aufhebt. Prüfe, dass du keinen weiten Wildcard hast.

Q: Muss ich DNSSEC deaktivieren, damit np funktioniert?

Nein, auf keinen Fall. DNSSEC schützt die Integrität deiner DNS-Antworten, und es zu deaktivieren würde weit schwerere Risiken öffnen als der blinde Fleck von np . Der richtige Fix ist nicht, DNSSEC anzurühren, sondern sp in deinem DMARC-Eintrag an np auszurichten, damit der Schutz nicht mehr vom Antwortcode abhängt.

Q: Welche Richtlinie sollte ich veröffentlichen, um trotz des blinden Flecks geschützt zu sein?

Mach sp so streng wie np . Zum Beispiel v=DMARC1; p=reject; sp=reject; np=reject . Mit sp=reject ist es egal, ob der Empfänger die Subdomain für existierend oder nicht existierend hält: In beiden Fällen weist er ab. Das ist die einzige Konfiguration, die den blinden Fleck schließt, egal wie sich deine DNSSEC-Zone verhält. Veröffentliche zuerst eigene Einträge auf deinen legitim sendenden Subdomains.

Q: Beheben öffentliche Resolver wie 8.8.8.8 das Problem?

Nein. Unsere Tests bestätigen, dass 8.8.8.8, 1.1.1.1 und 9.9.9.9 das NOERROR einer Compact-Denial-Zone weiterreichen, ohne NXDOMAIN zu rekonstruieren. Das optionale CO-Flag (Compact Answers OK), das diese Rekonstruktion erlauben würde, ist standardmäßig nicht aktiviert. Der DMARC-Evaluator hinter diesen Resolvern erhält also tatsächlich ein NOERROR .

Q: Ist Google Cloud DNS wirklich verschont?

Ja, laut unseren Tests. Eine Abfrage nach einem nicht existierenden Namen auf einer von Google Cloud DNS signierten Zone gibt ein klassisches status: NXDOMAIN zurück, mit Abwesenheitsnachweis per NSEC3. Der np -Tag greift also normal. Das ist das Gegenbeispiel, das zeigt: Das Problem ist nicht DNSSEC inhärent, sondern der Compact-Denial-Entscheidung mancher Anbieter.

Q: Wird die IETF dieses Verhalten korrigieren?

Die Frage wurde in der dmarc-Arbeitsgruppe der IETF angesprochen, aber bis heute ist keine Lösung beschlossen und die RFC 9989 behandelt sie nicht. Drei Ansätze existieren (den Pseudo-Typ NXNAME lesen, das CO-Flag verallgemeinern, NODATA wieder aufnehmen), keiner hat einen Zeitplan. Rechne nicht mit einem schnellen Fix: Sichere jetzt auf Konfigurationsseite ab.

Q: Ersetzt der np-Tag sp?

Nein, sie ergänzen sich. Der sp -Tag gilt für Subdomains, die in deinem DNS existieren, np für die, die nicht existieren. Die Fallback-Kette läuft von np über sp zu p . Gerade weil der Empfänger auf sp zurückfällt, wenn er die Nichtexistenz nicht bestätigen kann, erzeugt die Differenz zwischen den beiden Werten den blinden Fleck.

Von CaptainDNS
Veröffentlicht am 7. Juli 2026

Der np-Tag von DMARCbis, der eigentlich nicht existierende Subdomains blockieren soll, wird durch eine NOERROR-Antwort auf einer DNSSEC-Zone mit Compact Denial umgangen

TL;DR

Der np-Tag von DMARCbis (RFC 9989, Mai 2026) wendet eine Richtlinie auf Subdomains an, die es in deinem DNS nicht gibt. Das ist die neue Waffe gegen das Spoofing frei erfundener Subdomains.
np hängt an einer einzigen Sache: dem Antwortcode NXDOMAIN. Der DMARC-Evaluator löst ihn nur aus, wenn das DNS per striktem NXDOMAIN bestätigt, dass der Name nicht existiert.
Viele moderne DNSSEC-Zonen antworten mit NOERROR, nicht mit NXDOMAIN. Um Signaturen zu sparen, setzen sie auf Compact Denial of Existence oder auf "black lies". Der Evaluator glaubt dann, die Subdomain existiere, und fällt auf sp zurück.
Ergebnis: np=reject wird ohne die geringste Fehlermeldung ausgehebelt, sobald sp freizügiger ist. Eine gefälschte E-Mail von rechnung.captaindns.com kommt durch.
Der Fix passt in eine einzige Konfigurationszeile: sp genauso streng wie np machen und für deine legitim sendenden Subdomains eigene DMARC-Einträge veröffentlichen.

DMARCbis ist ein veröffentlichter Standard. Die RFC 9989, 9990 und 9991 (Mai 2026) ersetzen die alte RFC 7489 und führen den np-Tag ein, endlich eine saubere Antwort auf ein altes DMARC-Loch: die Subdomain, die nie deklariert wurde. Vor np konnte ein Angreifer von rechnung.captaindns.com senden, ohne dass irgendeine Richtlinie griff, weil dieser Name nirgends in der Zone existierte. Der np-Tag schließt diese Tür, in der Theorie.

In der Theorie. Denn np stützt sich auf ein präzises DNS-Signal, den Code NXDOMAIN, und dieses Signal ist aus einem großen Teil der real ausgerollten DNSSEC-Zonen klammheimlich verschwunden. Auf einer von Cloudflare, AWS Route 53, Microsoft Azure DNS oder NS1 signierten Zone liefert eine Abfrage nach einem nicht existierenden Namen kein NXDOMAIN. Sie liefert NOERROR. Und für einen DMARC-Evaluator heißt NOERROR: diese Subdomain existiert. Er wendet dann sp an, nicht np. Ist sp freizügiger, verpufft der Schutz.

Fazit. Wen es betrifft: jede Domain, die sich auf ein np verlässt, das strenger ist als sp, und auf einer DNSSEC-Zone mit Compact Denial gehostet wird. Schweregrad: stille Verschlechterung, kein Ausfall. Nichts bricht, kein Log-Eintrag entsteht, deine legitime E-Mail läuft wie zuvor. Nur das Anti-Spoofing-Versprechen von np wird ausgehöhlt. Das ist keine DNSSEC-Schwachstelle: DNSSEC tut genau das, was von ihm verlangt wird. Es ist eine Annahme von DMARCbis, die dem modernen DNS nicht mehr standhält.

Prüfe die DMARCbis- und DNSSEC-Kompatibilität deiner Domain

DMARCbis Checker DNSSEC prüfen

Wozu dient der np-Tag und worin unterscheidet er sich von sp?

Der np-Tag legt die DMARC-Richtlinie für Subdomains fest, die im DNS nicht existieren, während sp die Richtlinie für existierende Subdomains bestimmt. Der Unterschied hängt an einem einzigen Wort: nicht existierend. Genau darin liegt das ganze Problem.

Nehmen wir noch einmal das Problem, das np löst. Deine Domain captaindns.com veröffentlicht ihre Mailserver, ihre SPF- und DKIM-Einträge, eine strenge DMARC-Richtlinie. Aber ein Angreifer braucht keine Subdomain, die du deklariert hast. Er erfindet seine eigene. Er verschickt eine gefälschte Rechnung von rechnung.captaindns.com, einem Namen, den du nie in deiner Zone angelegt hast. Unter DMARC v1 stieg für nicht deklarierte Namen keine Richtlinie zuverlässig bis auf diese Ebene hinab, und das Spoofing blieb unter dem Radar. Der np-Tag stopft genau dieses Loch. Den vollständigen Kontext des Standards findest du in unserem DMARCbis-Leitfaden.

DMARCbis unterscheidet also drei Geltungsbereiche, mit einer strengen Fallback-Kette:

Tag	Gilt für	Werte	Fallback, wenn fehlt
`p`	Die Organisationsdomäne selbst	`none` / `quarantine` / `reject`	Keiner (Pflicht)
`sp`	Subdomains, die im DNS existieren	`none` / `quarantine` / `reject`	Fällt auf `p` zurück
`np`	Nicht existierende Subdomains (`NXDOMAIN`)	`none` / `quarantine` / `reject`	Fällt auf `sp`, dann `p` zurück

Ein typischer Anwendungsfall: p=none, sp=none, np=reject

Die häufigste Konfiguration bei Organisationen, die np ausrollen, sieht so aus:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=none; sp=none; np=reject; rua=mailto:dmarc@captaindns.com"

Die Logik des Administrators ist vernünftig. Die Root-Domain steht auf Beobachtung (p=none), weil man den legitimen Verkehr überwachen muss, bevor man verschärft. Die realen Subdomains ebenfalls (sp=none), solange man die sendenden Dienste noch kartiert. Aber niemand hat einen legitimen Grund, nicht existierende Subdomains zu nutzen: also weist man sie am besten sofort ab (np=reject). Das ist der richtige Reflex. Das Problem ist nicht die Logik. Das Problem ist, dass dieses np=reject auf einer modernen DNSSEC-Zone womöglich nie ausgelöst wird.

Merke dir die Fallback-Mechanik: np wird nur herangezogen, wenn der Empfänger festgestellt hat, dass die Subdomain nicht existiert. Andernfalls wendet er sp an. Die gesamte Schwachstelle steckt in diesem "hat festgestellt, dass die Subdomain nicht existiert".

Wie entscheidet DMARCbis, dass eine Subdomain nicht existiert?

DMARCbis betrachtet eine Subdomain nur dann als nicht existierend, wenn das DNS den Code NXDOMAIN zurückgibt. Das ist ein striktes Kriterium, geerbt von einem DNS-Prinzip, das die RFC 8020 festhält: "nichts darunter". Gibt ein Name NXDOMAIN zurück, dann existieren dieser Name und alles, was darunter existieren könnte, nicht. Der DMARC-Empfänger stützt sich auf diese Garantie, um zwischen sp und np zu wählen.

Das Wort NXDOMAIN ist hier alles andere als beiläufig. Es bedeutet nicht "ich habe nichts gefunden". Es bedeutet ganz genau "dieser Name existiert nicht in der Zone". Und das DNS unterscheidet zwei Fälle von Abwesenheit, die oft verwechselt werden.

Der Unterschied zwischen `NXDOMAIN` und `NODATA`

Zwei DNS-Antworten bedeuten "Abwesenheit", aber sie sagen nicht dasselbe. Der DMARC-Empfänger reagiert nur auf die erste.

NXDOMAIN (Statuscode NXDOMAIN): Der Name selbst existiert nicht. Kein Eintrag, keines Typs, unter diesem Namen. Das ist, was DMARCbis erwartet, um np auszulösen.
NODATA (Statuscode NOERROR, leerer Antwortabschnitt): Der Name existiert, aber nicht für den abgefragten Typ. Zum Beispiel hat blog.captaindns.com einen AAAA-Eintrag, aber keinen MX. Die MX-Abfrage liefert NOERROR ohne Daten. Der Name existiert. np greift nicht.

Diese Unterscheidung ist in einem klassischen DNS vollkommen logisch. Ein Angreifer, der von einer erfundenen Subdomain sendet, löst ein NXDOMAIN aus, weil der Name nie angelegt wurde. np greift. Alles gut. Die Verschiebung passiert, wenn die Zone mit DNSSEC signiert ist und beschließt, nie wieder NXDOMAIN zurückzugeben.

Die Verschärfung, die DMARCbis einführt

Ein historisches Detail erklärt, warum die Lücke größer ist, als man denkt. Die frühere experimentelle Erweiterung, die RFC 9091 (PSD DMARC), war toleranter: Um über die Existenz einer Subdomain zu urteilen, akzeptierte sie auch ein Fehlen von Daten bei den Typen A, AAAA und MX, nicht nur ein reines NXDOMAIN. Anders gesagt, ein NODATA bei diesen Typen zählte als "diese Subdomain empfängt keine E-Mail".

DMARCbis hat diesen Test verschärft. Die RFC 9989 stützt sich allein auf NXDOMAIN als Signal für Nichtexistenz. Diese Wahl macht den Standard auf dem Papier sauberer: ein einziges Kriterium, ohne Typ-Mehrdeutigkeit. Aber sie entfernt das Netz, das unter der RFC 9091 einen Teil der DNSSEC-Zonen aufgefangen hätte, die mit NOERROR antworten. Die Verschärfung, gedacht für Strenge, ist genau das, was den blinden Fleck gegenüber Compact Denial öffnet.

Was ist Compact Denial of Existence?

Compact Denial of Existence ist eine DNSSEC-Technik, die die Nichtexistenz eines Namens nachweist, indem sie NOERROR mit einem einzigen, spontan synthetisierten NSEC-Eintrag zurückgibt, statt des klassischen NXDOMAIN. Viele große DNS-Anbieter mit signierten Zonen haben sie aus einem einfachen Grund übernommen: den Kosten.

Eine Abwesenheit in DNSSEC nachzuweisen ist teuer. Die klassische Methode (NSEC oder NSEC3) verlangt, Einträge zurückzugeben, die den abgefragten Namen in der kanonischen Reihenfolge der Zone einrahmen, jeder begleitet von seiner RRSIG-Signatur. Für einen Dienst, der Millionen Zonen signiert und Fluten von Abfragen nach nicht existierenden Namen sieht (Scans, Tippfehler, Sonden), bedeutet das, ständig Signaturen zu berechnen, zu speichern und zu übertragen. Compact Denial umgeht das Problem: Statt die echten Nachbarn aufzuspüren, erzeugt der Server spontan ein minimales NSEC-Intervall rund um den abgefragten Namen, signiert es einmal und antwortet mit NOERROR. Weniger Rechenaufwand, weniger Bytes auf der Leitung, eine einzige Signatur.

Um zu signalisieren, dass die Abwesenheit echt ist und kein bloßes NODATA, markiert die Technik die Antwort mit einem Pseudo-Typ namens NXNAME (Typ 128). Ein Resolver, der diese Markierung versteht, weiß, dass sich hinter diesem NOERROR ein "der Name existiert nicht" verbirgt. Der Haken: Diese Übersetzung bleibt im Resolver, sie steigt nicht als NXDOMAIN bis zum DMARC-Evaluator hinauf.

Das CO-Flag, das alles ändern könnte

Die Spezifikation sieht ein Sicherheitsnetz vor, in der Theorie. Ein optionales Flag auf Resolver-Seite, "CO" (Compact Answers OK), erlaubt dem Resolver anzukündigen, dass er Compact Denial beherrscht, und im Gegenzug ein echtes NXDOMAIN für seinen Client zu rekonstruieren, wenn die Antwort die NXNAME-Markierung trägt. Auf dem Papier schließt dieser Mechanismus den blinden Fleck.

In der Praxis aktiviert es niemand. Die großen öffentlichen Resolver setzen dieses Flag nicht standardmäßig, und der DMARC-Evaluator, der hinter ihnen läuft, erhält das rohe NOERROR. Der Fix existiert im Text, nicht im echten Datenverkehr.

Zum Weiterlesen. NSEC und NSEC3 sind die beiden historischen Mechanismen für den Abwesenheitsnachweis in DNSSEC; NSEC3 hasht die Namen, um die Zonenaufzählung zu erschweren, NSEC legt sie im Klartext offen. Das aggressive Caching der Resolver (RFC 8198) erlaubt, einen NSEC-Nachweis wiederzuverwenden, um ohne Abfrage weitere nicht existierende Namen abzudecken, doch auch es stellt den Code NXDOMAIN nicht wieder her, wenn der Nachweis ein synthetisches NSEC in NOERROR ist. Der Cache beschleunigt, er korrigiert nichts für np.

Das Szenario Schritt für Schritt: wenn `NOERROR` np auf sp zurückfallen lässt

Hier der vollständige Ablauf, vom betrügerischen Versand bis zur Zustellung. Die Zone captaindns.com ist mit Compact Denial signiert und veröffentlicht p=none; sp=none; np=reject. Ein Angreifer verschickt eine gefälschte Rechnung von rechnung.captaindns.com, einer Subdomain, die es in der Zone nicht gibt.

Die Mail trifft ein beim Empfänger mit From: buchhaltung@rechnung.captaindns.com. Die SPF- und DKIM-Authentifizierung schlägt fehl, was zu erwarten ist: Der Angreifer kontrolliert die Domain nicht.
Der Empfänger startet den DMARCbis-Tree-Walk und arbeitet sich die Labels hinauf, bis er die Richtlinie findet. Er entdeckt sie auf _dmarc.captaindns.com: p=none; sp=none; np=reject.
Jetzt muss er entscheiden: Existiert diese Subdomain rechnung.captaindns.com oder nicht? Von seiner Antwort hängt die Wahl zwischen sp (existierend) und np (nicht existierend) ab.
Er fragt das DNS ab nach rechnung.captaindns.com. Die Zone ist mit Compact Denial signiert.
Die Antwort kommt als NOERROR zurück, mit einem synthetisierten NSEC, das die NXNAME-Markierung trägt. Der Statuscode, den der DMARC-Evaluator liest, ist NOERROR, nicht NXDOMAIN.
Der Empfänger schließt daraus, dass die Subdomain existiert. Für ihn bedeutet NOERROR Präsenz. Er verwirft np und wählt sp.
Er wendet sp=none an. Die gefälschte Rechnung wird zugestellt. Das veröffentlichte np=reject wurde nie herangezogen.

Sieben Schritte, kein Fehler, kein Anomalie-Log. Der Administrator hat np=reject in gutem Glauben veröffentlicht und hält seine nicht existierenden Subdomains für geschützt. Sie sind es nicht.

Die Beobachtung ist reproduzierbar. Folgendes liefert eine direkte Abfrage nach einem nicht existierenden Namen auf einer von Cloudflare signierten Zone:

$ dig +dnssec +norecurse randomabc123.cloudflare.com A @ns3.cloudflare.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
randomabc123.cloudflare.com. IN NSEC \000.randomabc123.cloudflare.com. RRSIG NSEC TYPE128

Der Status ist NOERROR. Das NSEC deckt ein minimales Intervall ab (\000.randomabc123...) und das Vorhandensein von Typ 128 (NXNAME) bestätigt das Compact Denial. Ein DMARC-Evaluator hinter einem klassischen Resolver sieht dieses NOERROR unverändert.

Auf einer Zone mit Compact Denial lässt die NOERROR-Antwort DMARC von np=reject auf sp=none zurückfallen und die gefälschte E-Mail kommt durch

Zum Vergleich eine signierte Zone, die korrekt antwortet:

$ dig +dnssec randomabc123.fbi.gov A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

Status NXDOMAIN, Abwesenheitsnachweis per NSEC3. Hier greift np normal. Dieselbe Protokollfamilie, gegensätzliches Verhalten. Der DNS-Anbieter macht den ganzen Unterschied.

Wer ist von diesem blinden Fleck wirklich betroffen?

Drei Bedingungen müssen gleichzeitig erfüllt sein, damit die Lücke greift. Fehlt eine, bleibt dein np gewahrt. Das verschweigen viele Artikel: Das Problem ist weder universell noch unvermeidlich.

Drei Bedingungen müssen zusammenkommen

Deine Richtlinie veröffentlicht ein np, das strenger ist als der Fallback sp. Sind np und sp identisch, ist nichts zu verlieren: Ob der Empfänger das eine oder das andere anwendet, das Ergebnis ist dasselbe.
Deine Zone ist DNSSEC-signiert und setzt Compact Denial oder "black lies" ein. Eine unsignierte Zone, oder eine signierte, die ein echtes NXDOMAIN zurückgibt, hat dieses Problem nicht.
Der DMARC-Evaluator des Empfängers verlässt sich auf den Antwortcode. Das ist das Standardverhalten nahezu aller Implementierungen: Sie lesen den Statuscode (NOERROR gegen NXDOMAIN), nicht den Pseudo-Typ NXNAME.

Die Nuance, die alle übersehen: np gegen sp

Der entscheidende Punkt: np wird nur ausgehebelt, wenn es strenger ist als sp. Solange der Empfänger auf sp zurückfällt, entscheidet der Wert von sp über das Schicksal der gefälschten E-Mail.

Veröffentlichte Richtlinie	Was `np` verspricht	Angewendet auf Compact-Denial-Zone	Exponiert?
`sp=none; np=reject`	Fake-Subdomains abweisen	`sp=none`: die Mail kommt durch	Ja, klaffende Lücke
`sp=quarantine; np=reject`	Abweisen	`sp=quarantine`: Spam statt Abweisung	Teilweise
`sp=reject; np=reject`	Abweisen	`sp=reject`: trotzdem Abweisung	Nein
`sp` fehlt, `p=reject`, `np=reject`	Abweisen	Fallback auf `p=reject`	Nein

Die unterste Zeile ist dein Ausweg. Ist sp (oder sein Fallback) bereits so streng wie np, hat der blinde Fleck keine Wirkung. Das ist die Grundlage des Fixes.

Die Wildcard-Falle

Compact Denial ist nicht der einzige Weg, np auszuhebeln. Ein DNS-Wildcard tut es auch, und ganz ohne DNSSEC. Enthält deine Zone *.captaindns.com, dann liefert jeder Name unter captaindns.com eine positive Antwort: Der Wildcard erzeugt für alle eine Existenz. Eine Subdomain, die du nie deklariert hast, "existiert" nun aus Sicht des DNS, also greift np nie und der Empfänger fällt auf sp zurück. Ein weiter A- oder AAAA-Wildcard hebt dein np genauso sicher auf wie eine Compact-Denial-Zone.

Auf Anbieterseite ergeben unsere eigenen dig-Tests, die du reproduzieren kannst, das folgende Bild. Mehrere der größten Managed-DNS-Dienste antworten auf den von ihnen signierten Zonen mit NOERROR statt NXDOMAIN:

DNS-Anbieter	Getestete signierte Domain	Antwort auf nicht existierenden Namen	`np` gewahrt?
Cloudflare	cloudflare.com	NOERROR + NSEC mit NXNAME (Typ 128)	Nein
NS1 (IBM)	ns1.com	NOERROR + NSEC mit NXNAME	Nein
AWS Route 53	login.gov	NOERROR + minimales NSEC, ohne NXNAME	Nein
Azure DNS	office.com, hhs.gov	NOERROR + minimales NSEC, ohne NXNAME	Nein
Google Cloud DNS	fbi.gov	NXDOMAIN (NSEC3)	Ja

Zwei Lehren. Erstens brechen zwei verschiedene Varianten np. Das strikte Compact Denial mit NXNAME-Markierung (Cloudflare, NS1) und die älteren "black lies", ein nacktes NOERROR ohne NXNAME (Route 53, Azure). Egal welche Variante: Der gemeinsame Nenner ist der Code, NOERROR statt NXDOMAIN. Das weitet den Umfang deutlich aus. Zweitens ist es kein Schicksal: Google Cloud DNS gibt ein klassisches NXDOMAIN zurück und lässt np funktionieren. Der Anbieter zählt.

Ein Wort der Ehrlichkeit zur Tragweite. Wir nennen keinen Prozentsatz: Die genaue Verbreitung der Compact-Denial-Zonen zu messen, würde einen globalen Scan verlangen, den wir nicht durchgeführt haben. Aber Cloudflare gehört zu den größten DNS-Anbietern der Welt, und Route 53 wie Azure DNS wiegen schwer in der Unternehmensinfrastruktur. Wenn vier Akteure dieses Kalibers auf ihren signierten Zonen NOERROR zurückgeben, ist ein großer Teil der real ausgerollten DNSSEC-Zonen betroffen. Für Oracle Cloud DNS und Dyn haben wir keine auswertbare signierte Zone beobachtet: Wir ordnen sie weder dem einen noch dem anderen Lager zu.

Entscheidungsbaum: Bin ich vom blinden np-Fleck auf DNSSEC betroffen, je nach Anbieter und meiner sp-Richtlinie

Wie prüfst du, ob dein np gewahrt bleibt?

Drei Prüfungen genügen, um zu wissen, ob dein np wirklich angewendet wird. Jede beantwortet eine der drei Bedingungen der Lücke. Rechne mit fünf Minuten.

Schritt 1: Ist deine Zone DNSSEC-signiert?

Fang mit dem Einfachsten an. Ist deine Zone nicht signiert, trifft dich der Compact-Denial-Fleck nicht (Achtung trotzdem auf die weiter oben beschriebene Wildcard-Falle). Prüfe das Vorhandensein von DNSKEY- und DS-Einträgen mit dem DNSSEC-Prüfer von CaptainDNS oder auf der Kommandozeile:

dig DNSKEY captaindns.com +short
dig DS captaindns.com +short

Eine signierte Zone gibt mindestens einen DNSKEY-Schlüssel zurück und, auf Elternseite, einen DS-Eintrag. Signierte Zone: weiter zu Schritt 2. Unsignierte Zone: Schritt 3 bleibt für den Wildcard-Fall nützlich.

Schritt 2: Gibt eine erfundene Subdomain `NXDOMAIN` oder `NOERROR` zurück?

Das ist der zentrale Test. Frage einen Namen ab, den du nie angelegt hast, und lies den Statuscode, nicht die Daten:

dig +dnssec existiert-nicht-9x7q.captaindns.com A

Suche die Zeile ;; ->>HEADER<<-. Zwei mögliche Ausgänge:

status: NXDOMAIN: perfekt, dein np greift normal. Du bist im Fall Google Cloud DNS.
status: NOERROR: Deine Zone verbirgt die Nichtexistenz hinter einem NOERROR. Dein np fällt auf sp zurück. Weiter zu Schritt 3, um die tatsächliche Exposition zu bemessen.

Teste dabei gleich über einen öffentlichen Resolver, denn das ist, was die Mailempfänger sehen. Unsere Versuche bestätigen, dass 8.8.8.8, 1.1.1.1 und 9.9.9.9 das NOERROR weiterreichen, ohne NXDOMAIN zu rekonstruieren. Da das CO-Flag nicht aktiviert ist, erhält der nachgelagerte DMARC-Evaluator tatsächlich ein NOERROR.

Schritt 3: Ist np strenger als sp?

Letzte Frage, die entscheidendste. Hol dir deinen Eintrag und vergleiche np mit sp (und mit dem Fallback p, falls sp fehlt):

dig TXT _dmarc.captaindns.com +short

Gleiche die Werte mit der Tabelle aus dem vorigen Abschnitt ab. Ist np strenger als der Fallback sp und hat Schritt 2 NOERROR ergeben, ist dein Schutz für nicht existierende Subdomains ausgehebelt. Um die vollständige Syntax zu lesen und einen fehlerhaften Tag zu erkennen, gib den Eintrag in den DMARC-Eintragsprüfer ein. Sind np und der Fallback schon auf demselben Niveau, atme auf: Der blinde Fleck kann dir nichts anhaben.

Wie sicherst du deine Subdomains schon jetzt ab?

Der Fix hängt nicht von einem künftigen Patch des DNS oder der IETF ab. Du rollst ihn heute aus, auf Konfigurationsseite, indem du deine Richtlinie unempfindlich dagegen machst, dass np ignoriert werden kann. Das Prinzip: np nie allein einen Schutz tragen lassen, den sp nicht sicherstellt.

Das Rezept: doppelt hält besser

Richte sp an np aus. Wenn du nicht existierende Subdomains abweisen willst, weise auch die nicht legitimen existierenden Subdomains ab und mach das zu deinem Fallback:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@captaindns.com"

Mit sp=reject ist es egal, ob der Empfänger die Subdomain für existierend hält oder nicht: In beiden Fällen weist er ab. Compact Denial läuft ins Leere. Das ist die einzige Konfiguration, die den blinden Fleck schließt, egal wie sich deine DNSSEC-Zone verhält. Ist deine Root-Domain noch nicht bereit für p=reject, kannst du p weicher lassen, aber halte sp und np auf demselben strengen Niveau.

Einträge auf den sendenden Subdomains veröffentlichen

sp=reject blockiert alles, was nicht ausdrücklich erlaubt ist. Deine legitim sendenden Subdomains (newsletter.captaindns.com, notifications.captaindns.com) müssen daher ihre eigene Authentifizierungskonfiguration und, idealerweise, ihren eigenen DMARC-Eintrag tragen. Kartiere zuerst deine Absender über die aggregierten rua-Berichte, veröffentliche dann für jeden einen eigenen Eintrag, bevor du sp verschärfst. Diese Bestandsaufnahme bewahrt dich auch davor, versehentlich einen internen Dienst abzuweisen.

Ein sauberer Eintrag mit stimmigen p, sp und np lässt sich mühelos erzeugen und validieren. Das DMARCbis-Migrationstool übernimmt deinen bestehenden Eintrag und bringt ihn auf den Standard, ohne die v=DMARC1-Abwärtskompatibilität zu brechen.

Die Wahl des DNS-Anbieters zählt

Das Verhalten beim Abwesenheitsnachweis ist bei den meisten Managed-Anbietern nicht konfigurierbar: Es wird vom Dienst vorgegeben. Wenn du verlangst, dass np empfängerseitig funktioniert, ohne von sp abzuhängen, wird das NXDOMAIN-Verhalten deines Anbieters zu einem vollwertigen Auswahlkriterium, genauso wie Latenz oder Preis. Das ist kein Grund, vor Cloudflare oder Route 53 zu fliehen, deren Vorteile real bleiben. Es ist ein Grund, ihre Antwort auf einen nicht existierenden Namen zu kennen und dein sp entsprechend zu konfigurieren. Solange sp an np ausgerichtet ist, hört der Anbieter auf, ein Problem zu sein.

Wo steht die IETF bei diesem Thema?

Bis heute ist keine Lösung beschlossen. Die Spannung zwischen dem np-Tag und Compact Denial of Existence wurde in der dmarc-Arbeitsgruppe der IETF angesprochen, hat aber noch zu keiner normativen Korrektur geführt, und die RFC 9989 behandelt die Frage nicht. Ein Grund mehr, auf Konfigurationsseite abzusichern, ohne zu warten.

Drei Ansätze kursieren, keiner ist entschieden:

Den Pseudo-Typ NXNAME lesen. Die DMARC-Bibliotheken könnten lernen, die NXNAME-Markierung (Typ 128) als NXDOMAIN zu interpretieren, was np für Zonen mit striktem Compact Denial wiederherstellen würde. Das würde die "black lies" ohne NXNAME außen vor lassen, wie die von Route 53 oder Azure.
Das CO-Flag ausrollen. Das Ökosystem könnte die Aktivierung des Compact-Answers-OK-Flags auf Resolver-Seite verallgemeinern, um NXDOMAIN vor dem DMARC-Evaluator zu rekonstruieren. Das setzt eine breite Koordination voraus, die sich kurzfristig nicht abzeichnet.
NODATA wieder aufnehmen. Eine künftige Revision des Standards könnte die Toleranz der RFC 9091 wiederherstellen und ein NODATA bei A, AAAA und MX erneut als Signal für Nichtexistenz akzeptieren.

Keiner dieser Ansätze hat einen Zeitplan. Rechne nicht mit einem schnellen Fix. Die gute Nachricht: Du brauchst keinen. sp an np auszurichten, hebelt den blinden Fleck schon heute aus, unabhängig davon, was die IETF entscheidet.

🎯 Aktionsplan: np auf einer DNSSEC-Zone absichern

Teste deine Zone. Frage einen nicht existierenden Namen ab: dig +dnssec erfunden-9x7q.captaindns.com A. Ein status: NOERROR signalisiert den blinden Fleck.
Vergleiche np und sp. Hol dir deinen _dmarc-Eintrag und prüfe, ob np strenger ist als der Fallback sp. Wenn ja, und Schritt 1 hat NOERROR ergeben, bist du exponiert.
Richte sp an np aus. Veröffentliche sp=reject; np=reject (oder das strenge Niveau, das du anpeilst), um den Schutz unabhängig vom DNS-Antwortcode zu machen.
Inventarisiere deine Absender. Kartiere die tatsächlich sendenden Subdomains über die rua-Berichte, bevor du sp verschärfst, um nichts Legitimes abzuweisen.
Veröffentliche eigene Einträge auf jeder legitim sendenden Subdomain.
Beseitige weite Wildcards (*.captaindns.com als A/AAAA), die jeden Namen "existieren" lassen und np aufheben, ob mit DNSSEC oder ohne.
Nimm das NXDOMAIN-Verhalten deines DNS-Anbieters in deine Kriterien auf, ohne es zum Grund für eine überstürzte Migration zu machen.

FAQ

Schützt der np-Tag meine nicht existierenden Subdomains wirklich?

Ja, aber unter einer Bedingung, die nicht immer erfüllt ist: Das DNS muss für nicht existierende Namen ein echtes NXDOMAIN zurückgeben. Ist deine Zone DNSSEC-signiert und setzt Compact Denial of Existence ein, gibt sie stattdessen NOERROR zurück. Der DMARC-Evaluator glaubt dann, die Subdomain existiere, verwirft np und wendet sp an. Ist sp freizügiger als np, wird der Schutz ohne jedes Signal ausgehebelt.

Wie erkenne ich, ob meine DNSSEC-Zone mit NOERROR oder NXDOMAIN antwortet?

Frage einen Namen ab, den du nie angelegt hast, und lies den Statuscode: dig +dnssec erfundener-name-9x7q.captaindns.com A. Suche die Zeile ;; ->>HEADER<<-. Ein status: NXDOMAIN heißt, np funktioniert. Ein status: NOERROR signalisiert, dass deine Zone die Nichtexistenz verbirgt und np auf sp zurückfällt.

Bricht Compact Denial of Existence auch SPF oder DKIM?

Nein. SPF und DKIM hängen nicht von der Erkennung der Nichtexistenz einer Subdomain ab. Compact Denial betrifft nur die DMARCbis-Logik, die zwischen sp und np wählt, je nachdem ob der Name existiert oder nicht. Deine SPF- und DKIM-Prüfungen sowie die p-Richtlinie deiner Root-Domain sind nicht betroffen.

Bin ich betroffen, wenn ich kein DNSSEC nutze?

In der Regel nein: Eine unsignierte Zone gibt für nicht existierende Namen ein klassisches NXDOMAIN zurück, und np greift normal. Eine Ausnahme: die Wildcards. Ein *.captaindns.com-Eintrag als A oder AAAA lässt jeden Namen aus Sicht des DNS "existieren", was np auch ohne DNSSEC aufhebt. Prüfe, dass du keinen weiten Wildcard hast.

Muss ich DNSSEC deaktivieren, damit np funktioniert?

Nein, auf keinen Fall. DNSSEC schützt die Integrität deiner DNS-Antworten, und es zu deaktivieren würde weit schwerere Risiken öffnen als der blinde Fleck von np. Der richtige Fix ist nicht, DNSSEC anzurühren, sondern sp in deinem DMARC-Eintrag an np auszurichten, damit der Schutz nicht mehr vom Antwortcode abhängt.

Welche Richtlinie sollte ich veröffentlichen, um trotz des blinden Flecks geschützt zu sein?

Mach sp so streng wie np. Zum Beispiel v=DMARC1; p=reject; sp=reject; np=reject. Mit sp=reject ist es egal, ob der Empfänger die Subdomain für existierend oder nicht existierend hält: In beiden Fällen weist er ab. Das ist die einzige Konfiguration, die den blinden Fleck schließt, egal wie sich deine DNSSEC-Zone verhält. Veröffentliche zuerst eigene Einträge auf deinen legitim sendenden Subdomains.

Beheben öffentliche Resolver wie 8.8.8.8 das Problem?

Nein. Unsere Tests bestätigen, dass 8.8.8.8, 1.1.1.1 und 9.9.9.9 das NOERROR einer Compact-Denial-Zone weiterreichen, ohne NXDOMAIN zu rekonstruieren. Das optionale CO-Flag (Compact Answers OK), das diese Rekonstruktion erlauben würde, ist standardmäßig nicht aktiviert. Der DMARC-Evaluator hinter diesen Resolvern erhält also tatsächlich ein NOERROR.

Ist Google Cloud DNS wirklich verschont?

Ja, laut unseren Tests. Eine Abfrage nach einem nicht existierenden Namen auf einer von Google Cloud DNS signierten Zone gibt ein klassisches status: NXDOMAIN zurück, mit Abwesenheitsnachweis per NSEC3. Der np-Tag greift also normal. Das ist das Gegenbeispiel, das zeigt: Das Problem ist nicht DNSSEC inhärent, sondern der Compact-Denial-Entscheidung mancher Anbieter.

Wird die IETF dieses Verhalten korrigieren?

Die Frage wurde in der dmarc-Arbeitsgruppe der IETF angesprochen, aber bis heute ist keine Lösung beschlossen und die RFC 9989 behandelt sie nicht. Drei Ansätze existieren (den Pseudo-Typ NXNAME lesen, das CO-Flag verallgemeinern, NODATA wieder aufnehmen), keiner hat einen Zeitplan. Rechne nicht mit einem schnellen Fix: Sichere jetzt auf Konfigurationsseite ab.

Ersetzt der np-Tag sp?

Nein, sie ergänzen sich. Der sp-Tag gilt für Subdomains, die in deinem DNS existieren, np für die, die nicht existieren. Die Fallback-Kette läuft von np über sp zu p. Gerade weil der Empfänger auf sp zurückfällt, wenn er die Nichtexistenz nicht bestätigen kann, erzeugt die Differenz zwischen den beiden Werten den blinden Fleck.

Glossar

NXDOMAIN: DNS-Antwortcode, der bedeutet, dass der abgefragte Name nicht in der Zone existiert. Das einzige Signal, das DMARCbis akzeptiert, um np auszulösen.
NODATA: Antwort mit NOERROR und leerem Datenabschnitt. Der Name existiert, aber nicht für den abgefragten Typ. Löst np nicht aus.
NOERROR: DNS-Statuscode, der das Ausbleiben eines Fehlers anzeigt. Verwendet sowohl für eine positive Antwort als auch, bei Compact Denial, zum Nachweis einer Nichtexistenz, was den DMARC-Evaluator täuscht.
Compact Denial of Existence: DNSSEC-Technik, die die Nichtexistenz eines Namens über ein einziges synthetisiertes NSEC und eine NOERROR-Antwort nachweist, um Signaturen und Bandbreite zu sparen.
NXNAME (Typ 128): Pseudo-Typ, der in einer Compact-Denial-Antwort markiert, dass die Abwesenheit echt ist (der Name existiert nicht) und kein bloßes NODATA.
Black lies: ältere Variante desselben Prinzips, ein NOERROR mit minimalem NSEC, aber ohne NXNAME-Markierung, verwendet unter anderem von AWS Route 53 und Azure DNS.
CO-Flag (Compact Answers OK): Option auf Resolver-Seite, die es erlaubt, ein NXDOMAIN aus einer Compact-Denial-Antwort zu rekonstruieren. In der Praxis selten aktiviert.
np-Tag: DMARCbis-Richtlinie für nicht existierende Subdomains. Fallback: sp, dann p.

Erzeuge in einer Minute einen sauberen Eintrag: Erstelle eine DMARC-Richtlinie mit stimmigen p, sp und np mithilfe des DMARC-Generators und validiere das Ergebnis vor der Veröffentlichung.