Eine umgekehrte Suche gibt einen beanspruchten Hostnamen für eine IP-Adresse zurück. Vorwärts bestätigt Reverse DNS prüft dann, ob dieser Hostname wieder in die ursprüngliche Adresse aufgelöst wird. Der zweite Schritt fängt eine häufige Inkonsistenz auf, aber eine Übereinstimmung stellt nicht sicher, dass der Absender vertrauenswürdig oder berechtigt ist, die Absenderdomäne einer Nachricht zu verwenden.
Definieren Sie den Vergleich
Referenzen: RFC 1912 §2.1, RFC 3596 §2.1, RFC 4291 §2.2.
Nehmen Sie die beobachtete SMTP -Quelladresse als Startwert. Fragen Sie den PTR Datensatz ab. Fragen Sie für jeden zurückgegebenen Hostnamen den entsprechenden Weiterleitungsadresstyp ab: A für eine IPv4 Quelle und AAAA für eine IPv6 Quelle. Vergleichen Sie die Adresswerte mit einem IP-Parser für IPv6 , damit äquivalente Textformen gleich behandelt werden.
Für die Diagnose dieses Handbuchs bedeutet die Bestätigung, dass mindestens der Weiterleitungsadresssatz eines zurückgegebenen Hostnamens die ursprüngliche IP enthält. Behalten Sie die Ergebnisse pro Host sowie diese Zusammenfassung bei. Dies ist eine explizit definierte Diagnoseregel und kein Versprechen, dass jeder Empfänger die gleiche Auswahlrichtlinie implementiert oder jedes PTR Ergebnis überprüft.
Halten Sie Fehler deutlich voneinander fern
Referenzen: RFC 1035 §4.1.1, RFC 2181 §10.2.
Keine PTR -Antwort, ein Hostname ohne passende Adresse, ein DNS Timeout und ein Validierungsfehler sind unterschiedliche Ergebnisse. Eine Zeitüberschreitung kann nicht beweisen, dass der Datensatz fehlt. Eine IPv4 A-Übereinstimmung stellt keine Bestätigung für eine IPv6 Quelle dar. Behalten Sie Antwortcodes und Zeitpunkte bei, anstatt alle Ergebnisse in einem einzigen roten Abzeichen zusammenzufassen.
Hören Sie nicht bei der ersten Adresse auf, die für einen Hostnamen zurückgegeben wird. Ein Host kann mehrere Adressen haben und die ursprüngliche Adresse kann sich später im Satz befinden. Ein Dashboard sollte auch nicht stillschweigend mehrere PTR Namen verwerfen. Die zugrunde liegenden Ergebnisse werden benötigt, um genau zu erklären, was übereinstimmt.
Berechnen Sie einen synthetischen Testsatz
Fall A beginnt bei 192.0.2.25. PTR kehrt zurück smtp.example.com; Die A-Menge dieses Namens ist 192.0.2.24, 192.0.2.25. Das erwartete Ergebnis wird bestätigt, da die ursprüngliche Adresse Mitglied des Satzes ist. Gleichheit mit dem gesamten Set ist nicht erforderlich.
Fall B verwendet denselben PTR , aber der A-Satz enthält nur 192.0.2.24. Das erwartete Ergebnis stimmt nicht überein. Fall C erhält eine Zeitüberschreitung beim Forward-Lookup. Das erwartete Ergebnis ist ungelöst, keine Abweichung. Fall D beginnt um 2001:db8::25 und die AAAA-Antwort des Ziels lautet 2001:0db8:0000:0000:0000:0000:0000:0025. Das erwartete Ergebnis wird bestätigt, nachdem beide als IPv6 -Adressen normalisiert wurden.
Reproduzieren Sie diese Fälle mit einem Fixture-Resolver oder isolierten Zonen. Speichern Sie für jeden Fall die Quell-IP, PTR Antwort, die Weiterleitungsantwort, den Abfragetyp und das berechnete Mitgliedsergebnis. Eine einfache Implementierung analysiert jede Adresse und bewertet, ob sich die Quelle im zurückgegebenen Satz befindet, während DNS Fehler vor diesem Mitgliedschaftsschritt behandelt werden. Diese erwarteten Ergebnisse besagen nicht, dass ein Produktionsempfänger getestet wurde.
Beheben Sie die Nichtübereinstimmung auf der Eigentümerseite
Referenzen: RFC 1035 §3.5, RFC 8767 §4.
Wenn der PTR falsch ist, arbeiten Sie mit dem Reverse-Zone-Operator zusammen. Wenn die Weiterleitungsadresse falsch ist, arbeiten Sie mit dem autorisierenden DNS Betreiber des Hostnamens zusammen. Wenn bei der Autorität beide korrekt sind, bei einem Resolver jedoch nicht, untersuchen Sie die Zwischenspeicherung oder unterschiedliche Ansichten. Bewahren Sie Beweise für beide Richtungen gleichzeitig auf, damit eine sequentielle Änderung nicht fälschlicherweise als anhaltende Inkonsistenz diagnostiziert wird.
Testen Sie abschließend die tatsächliche SMTP Route und bewahren Sie alle Empfängerantworten auf. Die Weiterleitungsbestätigung ist eine Konsistenzeigenschaft von DNS Daten. Angreifer können den Abgleich von Vorwärts- und Rückwärtsdatensätzen durchführen, und ein legitimer Anbieter kann dennoch eine fehlerhafte Konfiguration haben. Nutzen Sie die Feststellung neben und nicht anstelle von Authentifizierungs- und Missbrauchskontrollen.
Halten Sie den Umfang der Beweise explizit
Die vier synthetischen Fälle können allein anhand der Adresszugehörigkeit und Normalisierung überprüft werden: bestätigt, nicht übereinstimmend, ungelöst und bestätigt. Die lokale Berechnung führt keine PTR oder Forward-Lookups durch, prüft keinen Empfänger und misst die Reputation nicht.