Die Existenz gehört zur Domäne, nicht zu einem Datensatztyp
Das np-Tag liefert a DMARC Bewertungsrichtlinie für nicht vorhandene Subdomains gemäß der geltenden erkannten Richtlinie. Es ist nur dann nützlich, wenn die Existenzentscheidung fundiert ist. "NEIN Ein Rekord, „kein DMARC TXT Eintrag„“ und „die Autorendomäne existiert nicht“ sind unterschiedliche Aussagen. Wenn man sie als Synonyme behandelt, kann dies die falsche Richtlinie auf eine echte Domäne anwenden oder einen Lösungsfehler hinter einer falsch negativen Antwort verbergen.
RFC 9989 Abschnitt 4.7 unterscheidet np von sp. Ersteres befasst sich mit nicht vorhandenen Subdomains; Letzteres richtet sich an bestehende Subdomains. Beides ersetzt nicht die Bestimmung, welcher Richtliniendatensatz gilt. Die eigene gültige Richtlinie der Autorendomäne hat Priorität und ihr p-Tag wird für diese Domäne verwendet. Die Berechnung der übergeordneten Richtlinie erfolgt später, wenn die Autorendomäne über keine eigene anwendbare Richtlinie verfügt.
Geben Sie das übergeordnete Element an und halten Sie die Beispiele fiktiv
Verwenden Sie north.example als erfunden Organisationsbereich mit dieser Richtlinie: v=DMARC1;p=none; sp=quarantine; np=reject; psd=n. Gehen Sie davon aus, dass in allen folgenden Fällen eine ansonsten gültige Nachricht verwendet wird, deren Authentifizierung keinen ausgerichteten Pass ergibt. Hierbei handelt es sich um dokumentarische Aufzeichnungen mit manuell abgeleiteten Ergebnissen, nicht um DNS Beobachtungen, Zustellversuche oder Aussagen über die Aufzeichnungen einer Organisation.
Legen Sie für live.north.example einen Adressdatensatz und keine eigene DMARC Richtlinie fest. Die Entdeckung erreicht die übergeordnete Grenze und die Existenz wird etabliert. Die angeforderte Bewertung stammt von sp=quarantine. Das p=none des übergeordneten Elements ersetzt nicht die spezifischere Voreinstellung „existierende Subdomäne“. Behalten Sie das ausgewählte Tag im Ergebnis bei, damit ein Prüfer erkennen kann, warum die Quarantäne ausgewählt wurde.
Legen Sie für empty.north.example eine fest MX Eintrag aber kein A-Rekord. Die maßgebliche NOERROR/ NODATA Antwort einer A-Abfrage ist mit diesem vorhandenen Namen kompatibel. Ohne eigene DMARC Richtlinie gilt weiterhin sp=quarantine . In diesem Fall wird bewusst ein fehlender Datensatztyp von einer fehlenden Domäne getrennt; Ein Prüfer, der es als nichtexistent einstuft, nur weil er nur nach A fragt, würde die erwartete Entscheidung nicht treffen.
Interpretieren Sie NXDOMAIN mit dem richtigen Namen
Legen Sie für gone.north.example eine autorisierende NXDOMAIN Antwort für die Autorendomäne selbst fest, ohne Alias-Kette und ohne eigene Richtlinie. Die ausgewählte übergeordnete Richtlinie verwendet np=reject. RFC 9989 Anhang A.4 erklärt, dass für die Existenz DMARC kein bestimmter E-Mail-bezogener Datensatztyp erforderlich ist. Seine Definition folgt DNS Existenz und nicht der engeren Vorstellung von SMTP eines auflösbaren Ziels.
Eine NXDOMAIN Antwort für _dmarc.live.north.example würde den abgefragten untergeordneten Namen ablehnen und nicht beweisen, dass live.north.example nicht vorhanden ist. Die Richtung der Schlussfolgerung ist wichtig. RFC 8020 erklärt, dass ein abgelehnter Name auch keine Nachkommen hat; Es heißt nicht, dass die Verleugnung eines Kindes seine Eltern auslöscht. Durch die Aliasverarbeitung kann sich der abgelehnte Name auch von der ursprünglichen Frage unterscheiden. Behalten Sie daher den tatsächlichen Namen bei, dessen Existenz abgelehnt wurde.
Ein leerer Nichtterminal ist ein weiterer nützlicher Grenzfall: Ein Knoten kann in der DNS Hierarchie existieren, weil er Nachkommen hat, auch wenn er keine eigenen Datensätze hat. Reduzieren Sie diese strukturelle Existenz nicht in NXDOMAIN . Der Vorrichtungsdesigner sollte den Baum angeben und nicht nur eine praktische Textbeschriftung, die an eine leere Antwort angehängt wird.
Untersuchen Sie NODATA und Auflösungsfehler separat
NODATA ist kein unabhängiger DNS Antwortcode. RFC 2308 Abschnitt 2.2 beschreibt eine negative Antwortklassifizierung, die einen Antwortkontext erfordert. Einem Verweis kann ein leerer Antwortabschnitt beigefügt sein, und Aliase können sich darauf auswirken, welcher Name und Typ tatsächlich aufgelöst wurde. Speichern Sie die Frage, den Antwortcode, die Alias-Kette und die Autoritätsinformationen, bevor Sie eine Schlussfolgerung ziehen.
SERVFAIL , Timeout und eine unvollständige Antwort sind kein Beweis für die Nichtexistenz. RFC 1035 Abschnitt 4.1.1 unterscheidet Serverfehler von Namensfehlern. Im fiktiven Fall broken.north.example “ lässt SERVFAIL die Existenz ungelöst; es wählt np nicht selbst aus. RFC 9989 Abschnitt 4.10.1 überlässt die Behandlung von DNS-Fehlern dem Ermessen des Empfängers, einschließlich einer möglichen vorübergehenden Verzögerung. Ein Bewerter muss diesen ungelösten Zustand beibehalten, anstatt eine normale negative Suche zu beanspruchen.
Wenden Sie Richtlinienpriorität und -fallback bewusst an
Geben Sie nun own.north.example ein gültiges v=DMARC1; p=none -Richtlinie mit ihrem genauen _dmarc Namen. Der eigene p-Wert liefert die Bewertung; Die NP- und SP-Einstellungen des Elternteils ersetzen es nicht. Hierbei handelt es sich um eine Richtlinienerkennungsregel und nicht um eine Ausnahme, die für freizügige untergeordnete Domänen erfunden wurde. Für die vorhandene untergeordnete Konfiguration sind weiterhin ein autorisierter Eigentümer und eine begründete Sicherheitsüberprüfung erforderlich.
Wenn np im ausgewählten übergeordneten Datensatz nicht vorhanden ist, ist der Standardwert gemäß Abschnitt 4.7 sp, wenn sp vorhanden ist, andernfalls p. Für das übergeordnete Beispiel führt das Entfernen von np dazu, dass die Bewertung der nicht vorhandenen Subdomäne unter Quarantäne gestellt wird. Durch das Entfernen von np und sp bleibt nichts übrig. Dieser Fallback verdient einen separaten Test, da eine Verknüpfung, die direkt von fehlendem np zu p springt, den dokumentierten sp-Standard ignorieren würde.
Der Testmodus und die Handhabung des Empfängers bleiben zusätzliche Ebenen. Wenn der anwendbare Datensatz t=y, leiten Sie zuerst die ausgewählte Richtlinie ab und wenden Sie dann ihre Testsemantik an. Eine angeforderte Ablehnungsbewertung ist auch keine Garantie für eine endgültige Ablehnung: Die Empfängeranalyse und die Interoperabilitätsanforderungen in RFC 9989 bleiben relevant. Die diesem Artikel beigefügte Tabelle erfasst die Richtlinienauswahl und nicht die beobachtete Posteingangsplatzierung.
Bewahren Sie ein Beweispaket anstelle einer grünen Plakette auf
Der genaue Auftrag lautet: Vergleichen Sie bestehende, NODATA und NXDOMAIN -Fälle und leiten Sie die ausgewählte Richtlinie ab. Der fiktive Vergleich unterstützt die Überprüfung der erwarteten Logik, schließt jedoch nicht das ursprüngliche Tor zur operativen Evidenz. Es wurden keine Live-Anfragen, kontrollierten Autoritätsereignisse oder Empfängerergebnisse erfasst. Die aktuelle Errat-Überprüfung ist auch ungelöst, nachdem unzugängliche Endpunkte gestoppt wurden.
Bei einer genehmigten Nachverfolgung sollten die genaue Autorendomäne, der anwendbare Richtliniendatensatz, der Existenznachweis, der Fallback-Pfad, die Empfängerversion und die daraus resultierende Bewertung gespeichert werden. Halten Sie die Überprüfung des DNS-Engineerings vom Besitz der E-Mail-Richtlinien getrennt. Produktionsanwendbarkeit, fachliche Prüfung, Sichtabnahme und Veröffentlichungsgenehmigung stehen noch aus. Eine zuverlässige np-Erklärung macht Unsicherheit genau dort sichtbar, wo ein unvorsichtiges Werkzeug sie verbergen könnte.