Eine Antwort auf einen fehlenden Datensatz kann den fehlenden Datensatz überdauern
Ein neues DKIM Selektor kann im autorisierenden DNS vorhanden sein, während ein rekursiver Resolver immer noch antwortet, als ob der Schlüssel fehlt. Eine mögliche Erklärung ist negatives Caching: Der Resolver hat zuvor erfahren, dass der Name oder der angeforderte Datensatztyp nicht verfügbar war, und hat diese Antwort beibehalten. Immer wieder das Gleiche speichern TXT Eintrag wird nicht jeden Cache darüber informieren, dass sich die Situation geändert hat.
Beweisen Sie zunächst, dass die beabsichtigte Aufzeichnung nun bei der richtigen Behörde vorliegt. Überprüfen Sie den vollständigen Besitzernamen, den angeforderten Typ und alle Alias-Ziele. Negatives Caching ist eine Hypothese, die nach Bestätigung der Veröffentlichung getestet werden muss, keine geeignete Erklärung dafür ein Rekord das in der falschen Zone erstellt wurde oder nicht von allen relevanten Behörden zugestellt wurde.
Identifizieren Sie, was die frühere Antwort verneinte
NXDOMAIN zeigt an, dass ein Name nicht existiert. NODATA beschreibt eine Antwort ohne relevante Datensätze des angeforderten Typs und keinen dedizierten DNS Antwortcode. Der übliche Header-Code ist NOERROR. Überprüfen Sie den Autoritätsabschnitt und die Alias-Verarbeitung, um dieses Ergebnis von einer Überweisung oder einer nicht abgeschlossenen Suche zu unterscheiden. Ein leerer Antwortabschnitt allein reicht nicht aus. RFC 2308 , Abschnitte 2.1–2.2.
Der Umfang zählt. Unter dem Cache-Modell von RFC 2308 ist ein Namensfehlereintrag mit Name und Klasse verknüpft; Ein No-Data-Eintrag enthält auch den angeforderten Typ. Wenn vor der negativen Antwort ein Alias steht, stellen Sie fest, welcher endgültige Name fehlt. Ein kundenseitiger Selektoralias kann auch dann vorhanden sein, wenn sein anbieterseitiges Ziel dies nicht tut. Dies erfordert die Untersuchung eines anderen Eigentümers als eines fehlenden Kundendatensatzes.
Behalten Sie das frühere Ergebnis bei, sofern verfügbar. Eine aktuelle positive Antwort kann den TTL- und Autoritätsabschnitt einer gestern erhaltenen negativen Antwort nicht rekonstruieren. Wenn keine frühere Erfassung vorliegt, sagen wir, dass negatives Caching mit den Beobachtungen übereinstimmt, aber nicht bewiesen ist.
Berechnen Sie die Lebensdauer anhand der richtigen SOA-Felder
Für eine verbindliche negative Antwort legt RFC 2308 fest SOA-Eintragist die TTL in dieser Antwort auf die kleinere TTL des SOA-Eintrags und sein MINIMUM-Feld. Die zwischengespeicherte negative Lebensdauer zählt dann herunter. Das Lesen von SOA.MINIMUM allein als universellen Negativ-Cache-Timer ist unvollständig. RFC 2308 , Abschnitte 3–5.
In einem fiktiven Beispiel beträgt die SOA-TTL der Zone 900 Sekunden und MINIMUM 3.600. Eine mit diesen Werten generierte negative Antwort hat eine anfängliche negative Lebensdauer von 900 Sekunden, nicht von 3.600. Wenn ein Resolver ihn um 12:00 Uhr erhielt und der neue Selektor um 12:03 Uhr veröffentlicht wurde, könnte sich der frühere negative Eintrag während des verbleibenden normalen Cache-Fensters immer noch auf diesen Resolver auswirken. Diese erfundenen Zeiten veranschaulichen die Berechnung, nicht einen beobachteten Vorfall.
Um 12:05 Uhr zeigt eine Stichprobe einer rekursiven Antwort möglicherweise eine reduzierte SOA-TTL. Behalten Sie bei, was tatsächlich gemeldet wird, anstatt diesen Wert durch die konfigurierten Felder einer neuen SOA-Abfrage zu ersetzen. Andere Caches haben möglicherweise zu unterschiedlichen Zeiten unterschiedliche Antworten erhalten, und die Resolver-Richtlinie kann das Caching einschränken. Eine einzelne Berechnung kann keine allgemeine Erholung um 12:15 Uhr belegen.
Verwechseln Sie Abwesenheits-Caching nicht mit Fehler-Caching
SERVFAIL und ein Timeout bestätigen nicht, dass der Datensatz fehlt. Sie beschreiben, dass es nicht gelingt, ein brauchbares Ergebnis zu erzielen. RFC 9520 aktualisiert die älteren Negativ-Caching-Regeln, indem es das Caching von Auflösungsfehlern erfordert, einschließlich DNSSEC Validierungsfehler; Die Dauer des Fehlercaches beträgt mindestens eine Sekunde und höchstens fünf Minuten. Dies ist unabhängig von der SOA-abgeleiteten NXDOMAIN / NODATA Berechnung. RFC 9520 , Abschnitte 3.2–3.4.
Wiederholte fehlgeschlagene Aktualisierungen können zu weiteren Fehler-Cache-Einträgen führen, sodass die Obergrenze keine Garantie für die Wiederherstellung nach einem Ausfall darstellt. Wenn eine Suche nach einer Reparatur SERVFAIL zurückgibt, bewahren Sie die Antwort auf und untersuchen Sie die Diagnose des Resolvers und die Upstream-Verfügbarkeit. Ersetzen Sie eine Authentifizierungsrichtlinie nicht, nur weil ein Lösungsfehler informell als fehlender Datensatz beschrieben wurde.
Bei Fehlern bei der Autoritätsaktualisierung kann das Serve-Stale-Verhalten auch die Zeitachse verkomplizieren, einschließlich veralteter negativer Daten. Notieren Sie, ob der betroffene Resolver so konfiguriert ist, dass veraltete Antworten bereitgestellt werden, wenn diese Informationen verfügbar sind. Leiten Sie die Konfiguration nicht aus einer einzelnen Ausgabezeile ab. RFC 8767 , Abschnitte 4 und 10.
Veröffentlichen Sie neue Namen, bevor sie zu Abhängigkeiten werden
Bereiten Sie für eine geplante Selektorrotation den neuen öffentlichen Datensatz vor, bevor Sie den Signaturdienst auf dessen Verwendung umstellen. Überprüfen Sie den genauen Besitzer und jedes Ziel bei den zuständigen Betreibern. Vermeiden Sie es, einen nicht erstellten Produktionsnamen wiederholt so zu prüfen, als wäre ein Erfolg zu erwarten. Solche Abfragen können vor der Veröffentlichung negative Cache-Einträge erstellen.
Wenn eine Preflight-Abfrage erforderlich ist, behalten Sie deren Zeit und Antwort bei. Beziehen Sie Überlegungen zu negativen Caches in den Startplan ein, anstatt einen unangenehmen Preflight-Fehler zu verbergen. Eine niedrigere TTL für den zukünftigen TXT Datensatz verkürzt nicht rückwirkend eine bereits an anderer Stelle zwischengespeicherte Abwesenheitsantwort. Ebenso löscht das Leeren des Laptops eines Administrators nicht den Resolver eines E-Mail-Anbieters.
Erstellen Sie einen begrenzten Wiederherstellungsdatensatz
Das vorgeschlagene Arbeitsblatt enthält eine Zeile für jeden Endpunkt und jede Beobachtung: UTC-Zeit, genaue Frage, Antwortcode, relevante Antwort oder Alias, SOA-Eigentümer und zurückgegebene TTL sowie Autorität oder Rekursionsrolle. Vergleichen Sie aktuelle maßgebliche Ergebnisse mit dem betroffenen rekursiven Pfad und einem separat identifizierten Vergleichslöser. Bewahren Sie die vollständigen Antworten auf und wiederholen Sie sie in angemessenen dokumentierten Abständen.
Wenn der Behörde die Aufzeichnung fehlt, korrigieren Sie die Veröffentlichung. Wenn die Autorität korrekt ist und ein erfasster negativer Eintrag das rekursive Ergebnis erklärt, verfolgen Sie diesen spezifischen Cache-Pfad. Wenn SERVFAIL , Verweise oder inkonsistente Berechtigungen angezeigt werden, untersuchen Sie stattdessen diese Zweige. Überprüfen Sie abschließend eine kontrollierte Nachricht mit dem neuen Selektor. Dieser Artikel enthält nur fiktive Arithmetik und einen vorgeschlagenen Arbeitsablauf. Die ursprünglichen Resolver-Vergleiche und die Ergebnisse der empfangenen Nachrichten stehen noch aus, sodass das operative Beweistor des Katalogs noch offen ist.