Fragen Sie, wer die Antwort erstellt hat
Zwei DNS Suchvorgänge können unterschiedlich sein, ohne dass eines der beiden Tools beschädigt wird. Man kann einen autoritativen Server nach den aktuellen Daten der Zone fragen; Ein anderer fragt möglicherweise einen rekursiven Resolver, der eine frühere Antwort enthält. Eine nützliche Authentifizierungsuntersuchung zeichnet auf, welcher Pfad zu jeder Beobachtung geführt hat, anstatt ein grünes Häkchen von einer Suchseite als endgültigen Status der Domäne zu behandeln.
Ein autoritativer Server antwortet aus den von ihm bedienten Zonen. Ein rekursiver Resolver arbeitet im Auftrag eines Clients, indem er andere Server konsultiert oder zwischengespeicherte Informationen wiederverwendet. Ein Stub-Resolver übergibt Fragen im Allgemeinen an einen rekursiven Dienst. Dieselbe Software kann mehr als eine Rolle übernehmen. Identifizieren Sie daher die Rolle dieser bestimmten Reaktion, anstatt sich auf einen Produktnamen zu verlassen. RFC 1034 , Abschnitte 4.3.1 und 5.3.1.
Diese Unterscheidung ist wichtig, wenn eine neu veröffentlichte DKIM Selektor wird in den Tools des DNS Hosts angezeigt, bleibt aber für einen Prüfer nicht verfügbar. Die Behörde kann feststellen, was ein Server derzeit bedient; Das rekursive Ergebnis hilft zu erklären, was ein Empfangspfad sehen kann. Keine Beobachtung steht stellvertretend für die andere.
Richten Sie die Delegation ein, bevor Sie einen Endpunkt auswählen
Beginnen Sie mit dem genauen Besitzer und Typ, der in der Nachricht oder Serviceanweisung angegeben ist. Folgen Sie der Delegation in die Zone, die für diesen Eigentümer verantwortlich ist. Eine untergeordnete Zone kann andere autorisierende Server haben als die übergeordnete, und ein Anbieteralias kann wieder in eine andere Zone führen. Der auf einem alten Ticket angezeigte DNS Host ist möglicherweise nicht mehr der delegierte Host. RFC 1034 , Abschnitte 4.2.1–4.2.2.
Bereiten Sie eine Liste maßgeblicher Servernamen und ihrer Adressen vor und fragen Sie dann die relevanten Server direkt ab. Behalten Sie bei, welche Adresse kontaktiert wurde. Wenn verschiedene Behörden unterschiedliche Datensätze zurückgeben, untersuchen Sie zunächst das DNS Veröffentlichungs- oder Zonenbereitstellungsproblem. Ein Resolver kann legitimerweise auf jede verfügbare Autorität stoßen; Die Auswahl des Servers mit der gewünschten Antwort löst die Inkonsistenz nicht.
Eine Ablaufverfolgung kann dabei helfen, den Delegationspfad zu untersuchen, es handelt sich dabei jedoch um eine separate Beobachtung. Der zwischengespeicherte Pfad, die Weiterleitungskonfiguration, das Quellnetzwerk usw. eines Empfängers werden nicht reproduziert DNSSEC Validierungsverhalten. Kennzeichnen Sie einen Trace als Trace, anstatt ihn als Abfrageverlauf des E-Mail-Anbieters darzustellen.
Interpretieren Sie Flaggen mit ihren Grenzen
Das AA-Flag identifiziert eine autorisierende Antwort in der DNS Antwort. RD zeichnet auf, dass eine Rekursion angefordert wurde; RA kündigt die Verfügbarkeit von Rekursionen an. RD und RA beweisen nicht, dass der Server eine neue Suche nach dieser Antwort durchgeführt hat. Ein rekursiver Server kann eine Anfrage aus dem Cache erfüllen. RFC 1035 , Abschnitt 4.1.1.
Fordern Sie für eine direkte Autoritätsprüfung keine Rekursion an und überprüfen Sie die tatsächliche Antwort. Eine Antwort ohne AA, eine Empfehlung, VERWEIGERT oder eine Zeitüberschreitung erfordert Interpretation; Die Serveradresse allein macht nicht jede Antwort maßgebend. Wenn Aliase auftreten, sorgen Sie dafür, dass jeder Besitzer und jedes Ziel sichtbar ist und identifizieren Sie, welche Zone die endgültigen Daten liefert. Die Autorität über den Alias-Eigentümer begründet nicht automatisch die Autorität über sein Ziel.
Behalten Sie die vollständigen Frage-, Antwort- und Autoritätsabschnitte bei. Ein Befehl, der nur TXT Zeichenfolgen ausgibt, verbirgt den Kontext, der zur Unterscheidung zwischen alten zwischengespeicherten Daten, einem Verweis, einem Alias und einer Abwesenheitsantwort erforderlich ist. Eine kurze Ausgabe eignet sich zum schnellen Auslesen, nachdem der vollständige Diagnosedatensatz gespeichert wurde.
Vergleichen Sie ein fiktives Paar von Resolver-Beobachtungen
Stellen Sie sich einen fiktiven Selektor vor blue._domainkey.example.com. Um 10:00 UTC geben zwei relevante autorisierende Server den neu vorgesehenen Public-Key-Datensatz zurück. Um 10:02 Uhr gibt Resolver A einen älteren Schlüssel mit verbleibenden 420 Sekunden zurück, während Resolver B den neuen Schlüssel zurückgibt. Diese Zeiten, Ergebnisse und TTLs wurden erfunden, um die Argumentation zu veranschaulichen. Es wurden keine Netzwerkmessungen durchgeführt.
Dieses Muster stimmt mit verschiedenen Cache-Verläufen überein, aber die Beobachtung allein beweist nicht die Ursache. Stellen Sie sicher, dass alle Fragen denselben Namen, denselben Typ und dieselbe Klasse verwendeten, dass die Serverendpunkte aufgezeichnet wurden und dass keine geteilte Ansicht oder Weiterleitungsrichtlinie die Antwort geändert hat. Wenn Resolver A später von einer inkonsistenten Autorität aktualisiert wird, kann einfaches Warten das Problem möglicherweise nicht lösen.
In der vorgeschlagenen Vorfallnotiz würde es heißen: „Die befragten Behörden sind sich über den neuen Schlüssel einig; Resolver A gibt immer noch den alten Schlüssel zurück; Ergebnis des Empfängers ist noch nicht beobachtet.“ Es würde nicht heißen, dass jeder Empfänger aktualisiert wurde oder dass die Authentifizierung nun erfolgreich ist. Behalten Sie die Verfügbarkeit des älteren öffentlichen Schlüssels und den Signaturübergang des Absenders im Rahmen eines koordinierten Rotationsplans bei, anstatt Datensätze zu löschen, damit ein Suchbildschirm aufgeräumt aussieht.
Trennen Sie Datenprobleme von Erreichbarkeitsproblemen
Ein rekursives SERVFAIL stellt dies nicht fest ein Rekord fehlt. Eine Behörde ist möglicherweise nicht erreichbar, eine Delegation schlägt möglicherweise fehl oder DNSSEC Validierung verhindert möglicherweise, dass der Resolver die Antwort akzeptiert. Eine direkte Antwort von einem Server schränkt die Untersuchung ein, beweist jedoch nicht, dass alle Abhängigkeiten für den rekursiven Resolver fehlerfrei sind.
Auch der Transport ist wichtig. DNS erfordert TCP-Unterstützung und eine abgeschnittene UDP-Antwort kann einen TCP-Wiederholungsversuch erfordern. Vergleichen Sie einen Vorschlag dig @AUTH_IP blue._domainkey.example.com . TXT +norecurse mit der gleichen Abfrage mit +tcp wenn es um den Transport geht. Ändern Sie nicht die Firewall- oder Sicherheitseinstellungen, nur um den Test erfolgreich durchzuführen. Lassen Sie den diagnostizierten Pfad vom zuständigen Bediener überprüfen. RFC 7766 , Abschnitte 5–6.
Machen Sie den Vergleich reproduzierbar
Verwenden Sie eine Arbeitsblattzeile pro Abfrage: UTC-Zeitstempel, Operatorstandort, Serverendpunkt, Rekursionsauswahl, Eigentümer, Typ, Klasse, Antwortcode, Flags, Datensätze, TTLs und Transport. Wiederholen Sie ausgewählte Beobachtungen in einem dokumentierten Intervall und bewahren Sie die früheren Zeilen auf. DNS Caches entwickeln sich weiter, sodass durch das Überschreiben des ersten Ergebnisses nützliche Timing-Beweise entfernt werden.
Beenden Sie den Vorgang mit einer kontrollierten Nachricht über den betroffenen Absender und behalten Sie die Identitäten und Ergebnisse des vertrauenswürdigen Empfängers bei. DNS Vergleich kann eine Abhängigkeit erklären; Es kann weder die Platzierung im Posteingang noch die interne Suche eines bestimmten Empfängers nachweisen. Dieser Artikel liefert einen vorgeschlagenen Arbeitsablauf und einen fiktiven Vergleich. Originale, mit Zeitstempel versehene, autorisierende und rekursive Antworten sind weiterhin erforderlich, bevor das Katalogbeweistor geschlossen werden kann.