Unter RFC 9989 §9.2, ein vorübergehendes DMARC Fehler bedeutet, dass bei der Auswertung ein Problem aufgetreten ist, das möglicherweise bei einem späteren Versuch behoben wird. Dies bedeutet nicht, dass die Domäne über keine Richtlinien verfügt oder dass die Authentifizierung legitimer E-Mails endgültig fehlgeschlagen ist.
Betrachten Sie das Ergebnis als Beginn einer Lösungsuntersuchung. Stellen Sie fest, welche erforderliche Suche fehlgeschlagen ist, ob die Daten in ihrer Autorität vorhanden sind und was das empfangende System daran gehindert hat, eine brauchbare Antwort zu erhalten.
Erfassen Sie die fehlgeschlagene Bewertung
Speichern Sie das vollständige vertrauenswürdige Ergebnis oder die zurückgegebene SMTP Antwort, die Uhrzeit, die Absenderdomäne und die Senderoute. Beachten Sie, zu welcher Authentifizierungsmethode der Fehler gehört. Ein Provisorium SPF oder DKIM Problem ist nicht automatisch dasselbe wie dmarc=temperror.
Behalten Sie den genauen Suchnamen und Datensatztyp bei, wenn Protokolle sie offenlegen. Eine Richtlinien- TXT Abfrage, eine SPF Abhängigkeit und a DKIM Selektor Die Suche kann verschiedene Namen und Autoritäten umfassen. Wenn Sie nur den Domänenstamm testen, kann die fehlgeschlagene Abhängigkeit möglicherweise übersehen werden.
Bewahren Sie ein kleines Beweispaket auf, bevor Sie Änderungen vornehmen. Wiederholte Abfragen können nach dem Vorfall erfolgreich sein, sodass eine spätere fehlerfreie Antwort den ursprünglichen Fehlerdatensatz nicht ersetzen kann.
Folgen Sie einem reaktionsbasierten Entscheidungspfad
Dies ist eine diagnostische Entscheidungstabelle, keine universelle Zuordnung vom DNS Status zu einer E-Mail-Disposition:
- Abfragebeobachtung: Relevante vollständige Antwort mit NOERROR; Was es feststellt: Diese Abfrage hat zu diesem Zeitpunkt verwendbare Daten zurückgegeben; Nächste Untersuchung: Vergleichen Sie es mit der früheren Beobachtung des Empfängers
- Abfragebeobachtung: Vollständige Antwort ohne Daten; Was festgestellt wird: Der angeforderte Datensatz wurde in diesem Antwortkontext nicht gefunden. Nächste Untersuchung: Überprüfen Sie den genauen Namen, die Autorität, die Aliase und die Entdeckung
- Abfragebeobachtung: NXDOMAIN ohne Alias-Komplikation; Was festgestellt wird: Der abgefragte Eigentümername existiert nicht; Nächste Untersuchung: Bestätigen Sie den Abfrageumfang und den anwendbaren Fallback
- Abfragebeobachtung: SERVFAIL ; Was festgestellt wird: Die Lösung wurde nicht erfolgreich abgeschlossen. Nächste Untersuchung: Überprüfen Sie die Autoritäts-, Delegations-, Validierungs- und Resolver-Protokolle
- Abfragebeobachtung: VERWEIGERT; Was es feststellt: Ein Server hat die Anfrage abgelehnt; Nächste Untersuchung: Überprüfen Sie die Abfragerichtlinie und die beabsichtigte Rolle des Servers
- Abfragebeobachtung: Timeout; Was es feststellt: Innerhalb der Grenzen des Versuchs ist keine brauchbare Antwort eingetroffen; Nächste Untersuchung: Überprüfen Sie Erreichbarkeit, Transport, Verlust und Serverzustand
DNS Antwortcodes werden definiert durch RFC 1035 §4.1.1; negative Antworten von RFC 2308 §2.1 Und RFC 2308 §2.2. Eine Abfrage für _dmarc.example.com betrifft diesen Eigentümernamen. Die negative Antwort allein beweist nicht, dass example.com nicht existiert. Folgen Sie Aliasketten, bevor Sie dem ursprünglich abgefragten Namen eine Abwesenheit zuordnen.
Vergleichen Sie autorisierende und rekursive Pfade
Identifizieren Sie zunächst die richtigen autorisierenden Server, einschließlich aller delegierten Subdomänen. Testen Sie den entsprechenden Namen bei jeder Behörde und vergleichen Sie die Antworten. Wenn die Behörden anderer Meinung sind, untersuchen Sie den Versorgungsstaat der Zone und die jüngsten Änderungen.
Überprüfen Sie dann den rekursiven Pfad, der vom betroffenen Empfangssystem verwendet wird, sofern Beweise verfügbar sind. Vergleichen Sie Abfragezeit, Status, Antwort und TTL. Der lokale Resolver eines Betreibers und ein Remote-Empfänger können unterschiedliche Cache- oder Validierungsstatus haben.
Das folgende fiktive Kurztranskript veranschaulicht den Vergleich:
14:02 UTC | rekursiver Resolver R | _dmarc.example.com TXT | SERVFAIL 14:04 UTC | Autorisierender Server A | gleicher Name/Typ | KEIN FEHLER, Richtlinie zurückgegeben um 14:04 UTC | Autorisierender Server B | gleicher Name/Typ | KEIN FEHLER, Richtlinie zurückgegeben um 14:09 UTC | Resolver R nach untersuchter Reparatur | gleicher Name/Typ | KEIN FEHLERDiese Beobachtungen schränken die Untersuchung auf den rekursiven oder intervenierenden Pfad ein. Sie beweisen die Ursache nicht ohne Protokolle und stellen nicht fest, was jeder Empfänger erlebt hat.
Beziehen Sie DNSSEC Validierung in die Untersuchung ein
Unter RFC 4035 §5.5, kann ein validierender Resolver fehlerhafte Daten zurückweisen DNSSEC Validierung, auch wenn eine direkte Abfrage an einen autorisierenden Server Text zurückgibt. Überprüfen Sie Delegierungs- und Validierungsnachweise, einschließlich Schlüssel- oder Signaturänderungen, mithilfe der unterstützten Tools und Protokolle des zuständigen DNS Teams.
Eine direkte Antwort einer Behörde gibt nicht selbst die Validierungsentscheidung des Empfängers wieder. Ebenso beweist ein SERVFAIL kein DNSSEC Problem; es kann mehrere Ursachen haben.
Reparieren Sie den festgestellten Validierungsfehler, falls vorhanden. Das Deaktivieren der Validierung zum Ausblenden des Symptoms ist kein Beweis dafür, dass der beabsichtigte sichere Lösungspfad wiederhergestellt wurde.
Testen Sie gegebenenfalls sowohl UDP als auch TCP
DNS -Transport kann Teil des Fehlers sein. Eine erfolgreiche kleine UDP-Abfrage stellt nicht sicher, dass eine größere Antwort, ein Wiederholungsversuch mit verkürzter Antwort oder TCP auf demselben Pfad funktioniert.
RFC 7766 RFC 7766 §5 erfordert allgemeine DNS -Implementierungen, um sowohl UDP als auch TCP zu unterstützen. Vergleichen Sie den relevanten Namen und Typ für jeden Transport, wenn Sie Erreichbarkeits- oder größenbezogene Fehler diagnostizieren. Überprüfen Sie die Kürzungsmarkierung und die Netzwerknachweise, anstatt davon auszugehen, dass jede Zeitüberschreitung dieselbe Ursache hat.
Ein Transporttest ist eine diagnostische Beobachtung. Es sollte nicht zu einem Workaround für die Produktion werden, der den vorgesehenen Resolver oder Validierungspfad umgeht, ohne dass ein überprüfter Entwurf vorliegt.
Halten Sie Abwesenheit und fehlgeschlagene Lösung getrennt
Unter RFC 2308 §5, negative Antworten können zwischengespeichert werden, ebenso positive Daten. Ein neu hinzugefügter Datensatz kann in einer rekursiven Ansicht so lange fehlen, bis der frühere negative Cache-Status abläuft. Das unterscheidet sich davon, dass ein autoritativer Server nicht erreichbar ist.
Ein Konfigurationsfehler kann auch bestehen bleiben, während der beobachtete Fehler weiterhin als vorübergehend eingestuft wird. „Vorübergehend“ beschreibt die Bewertungskategorie und ist kein Versprechen, dass durch Warten eine fehlerhafte Delegation oder Signatur repariert wird.
Verwenden der Leitfaden zu fehlenden Datensätzen für bestätigte Abwesenheit und den Publikationsworkflow um den tatsächlichen Namen und die Autorität zu überprüfen.
Überprüfen Sie die Wiederherstellung, bevor Sie die Richtlinie überdenken
Aktuell RFC 9989 §4.10.1 Überlässt die Behandlung von DNS Fehlern bei der Richtliniensuche dem Empfänger. Die Bewertungsanleitung in RFC 9989 §5.3.6 besagt, dass erforderliche DNS Abfragen, die aufgrund von DNS Fehlern nicht abgeschlossen wurden, keinen DMARC Bestanden oder -Fehler begründen und die Richtlinie zur Bewertung des Domänenbesitzers nicht auf dieses unvollständige Ergebnis angewendet werden kann. Die Handhabung des Empfängers kann dennoch unterschiedlich sein.
Durch Ändern von p wird eine nicht erreichbare erforderliche Suche nicht repariert. Stellen Sie zunächst die nutzbare Auflösung wieder her, testen Sie dann dieselbe Route erneut und überprüfen Sie die neuen methodenspezifischen Ergebnisse. Bewahren Sie jede Entscheidung zur Geschäftswiederherstellung als separate, zeitlich begrenzte Änderung auf.
In der endgültigen Aufzeichnung sollten die fehlgeschlagene Abhängigkeit, die festgestellte Ursache, die Reparatur und Empfängernachweise nach der Wiederherstellung aufgeführt sein. Dadurch lässt sich der nächste vorübergehende Ausfall leichter diagnostizieren, ohne eine funktionierende Politik reflexartig zu schwächen.
Bewahren Sie die Entscheidung und die Beweise getrennt auf
Für das fiktive Transkript 14:02–14:09 wird der Autoritätserfolg eingeschränkt, die fehlgeschlagene Komponente wird jedoch nicht identifiziert. Fordern Sie den tatsächlichen Resolver- oder Netzwerkbefund an, bevor Sie DNSSEC , Transport oder einen bestimmten Server als Ursache nennen. RFC 8767 §4 erlaubt die qualifizierte Verwendung veralteter Antworten; Frische allein ist keine universelle Ausfall- oder Wiederherstellungsuhr. Bei diesen Beobachtungen handelt es sich um erfundene Lehrmittel, nicht um durchgeführte Tests.