Der SPF Der PTR-Mechanismus ist eine veraltete Möglichkeit, einen verbindenden Host durch Validierung zu autorisieren Reverse DNS. Aktuelle SPF Leitlinien besagen, dass es nicht veröffentlicht werden sollte, da es langsam, in einigen Fällen von DNS-Fehlern unzuverlässig und betrieblich aufwändig ist. Es bleibt Teil des Protokolls und konforme Gutachter müssen es unterstützen.
Diese Unterscheidung ist wichtig: entmutigt bedeutet nicht, dass sie allgemein ignoriert oder automatisch ungültig wird. Wenn Sie es entfernen, ohne die Absender zu identifizieren, die davon abhängig sind, kann dies die tatsächlichen Authentifizierungsergebnisse verändern. RFC 7208 Abschnitt 5.5 gibt entsprechende Hinweise.
Verstehen Sie die zu ersetzende Berechtigung
Konzeptionell beginnt ptr mit einer umgekehrten Suche nach der Verbindungsadresse. Anschließend werden die zurückgegebenen Namen vorwärts aufgelöst, um zu überprüfen, ob sie auf die Verbindungsadresse verweisen. Ein validierter Name muss mit der Zieldomäne übereinstimmen oder innerhalb der Domänengrenze liegen, damit der Mechanismus übereinstimmt.
Dies ist mehr als nur die Überprüfung, ob ein Hostname eine bekannte Zeichenfolge enthält. Ein Name wie relay.example.com befindet sich in example.com ; relay.notexample.com ist nicht. Eine umgekehrte Antwort allein reicht ebenfalls nicht aus: Vorwärtsvalidierung ist wichtig.
Reverse DNS wird oft vom Adresseigentümer verwaltet und nicht von der Organisation, SPF bearbeitet. Dadurch entsteht eine zusätzliche administrative Abhängigkeit, wenn die Richtlinie auf Hostnamen unterhalb einer ausgewählten Domäne angewiesen ist.
Gehen Sie ein synthetisches Legacy-Beispiel
Angenommen, example.com veröffentlicht v=spf1 ptr:example.com -all. Eine Verbindung kommt von 192.0.2.55 an. Die umgekehrte Antwort lautet outbound.example.com und die A-Antwort dieses Namens enthält 192.0.2.55 . In dieser vereinfachten Vorrichtung befindet sich der validierte Name in example.com , sodass ptr übereinstimmt.
Wenn die Weiterleitungsadresse stattdessen 192.0.2.99 lautet, wird der Rückwärtsname nicht für die Verbindungsadresse validiert. Wenn kein anderer validierter Name qualifiziert ist, stimmt ptr nicht überein und die Richtlinie erreicht -all . Ebenso ist ein validierter Name außerhalb der Zieldomäne nicht allein deshalb qualifiziert, weil er ähnlich aussieht.
Hierbei handelt es sich um erwartete Protokollergebnisse für synthetische Eingaben, nicht um Beobachtungen aus einer Produktionsdomäne. Bei der echten Auswertung gelten auch die Such- und Verarbeitungsgrenzen, einschließlich der Grenzen für die Rückwärts- und Vorwärtsarbeit.
Verwechseln Sie nicht zwei Reverse-DNS-Entscheidungen
Das Entfernen des PTR-Mechanismus aus SPF bedeutet nicht, dass der PTR Eintrag des Servers gelöscht wird. Reverse DNS kann unabhängig von SPF weiterhin für SMTP Vorgänge, Empfängeranforderungen und Reputationsprüfungen relevant sein. Ein Host kann über entsprechendes Reverse DNS verfügen, während seine SPF Richtlinie IP4, IP6 oder eine dokumentierte Anbietereinbindung verwendet.
Halten Sie die Migration eng begrenzt. Ersetzen Sie den Autorisierungsmechanismus und behalten Sie andere funktionierende DNS Einstellungen bei, es sei denn, eine separate, gerechtfertigte Änderung erfordert dies.
Wählen Sie einen Ersatz aus beobachteten Absendern
Für dedizierten, stabilen ausgehenden Datenverkehr unter Ihrer Kontrolle machen explizite IP4- und IP6-Berechtigungen die beabsichtigten Adressen sichtbar. Verwenden Sie für einen Dienst mit verwalteter, sich ändernder Infrastruktur die dokumentierte SPF Konfiguration, anstatt eine Anbieter-Hostnamenregel neu zu erstellen.
Der ein Mechanismus kann sinnvoll sein, wenn ein speziell kontrollierter Hostname die Sendeadressen definieren soll. Es ist kein automatischer bester Ersatz für ptr: Es ändert das Berechtigungsmodell und erstellt eine eigene Forward-DNS-Abhängigkeit.
Erstellen Sie eine Bestandsaufnahme der Adressen, die derzeit über PTR laufen, und erhalten Sie Eigentumsnachweise. Berücksichtigen Sie Failover, IPv6 und seltenen Datenverkehr. Sammeln Sie nicht ein paar aktuelle Adressen und behaupten Sie, Sie hätten den vollständigen Berechtigungssatz eingerichtet.
Migrieren Sie, ohne die Unsicherheit zu verbergen
Erstellen Sie eine vorgeschlagene Richtlinie, die die verifizierten legitimen Routen autorisiert. Bewerten Sie die alten und neuen Richtlinien für diesen Satz und für nicht autorisierte Kontrollen. Prüfen Sie, ob ein neuer Zuschuss umfassender ist als der alte und ob unbekannte Absender weiterhin ungeklärt sind.
Behalten Sie den vorherigen Datensatz bei und definieren Sie Rollback-Bedingungen, die an legitime Workflow-Fehler gebunden sind. Veröffentlichen Sie über die normale Änderungskontrolle, überprüfen Sie DNS Antworten und überprüfen Sie die vom Vertreter empfangenen Nachrichten. Wenn ein legitimer Absender fehlschlägt, bestätigen Sie seine Identität und seinen Besitz, bevor Sie die Berechtigung hinzufügen.
Der praktische Imbiss
ptr als SPF -Autorisierungsmechanismus unter Verwendung von Beweisen über echte Absender außer Betrieb nehmen. Behalten Sie das notwendige Reverse- DNS bei und ersetzen Sie versteckte Hostnamen-Abhängigkeiten durch ein explizites, wartbares Berechtigungsmodell.
Notieren Sie die nächste Entscheidung
Bewahren Sie für die synthetische Legacy-Quelle die umgekehrte Antwort, die vorwärts gerichtete Antwort, den validierten Namen und den Zielgrenzenvergleich separat auf. Vergleichen Sie dann den vorgeschlagenen Ersatz mit bekannten, Failover- und seltenen Quellen sowie einer nicht autorisierten Kontrolle. Wenn der Besitz eines Absenders unbekannt bleibt, notieren Sie diese Lücke, anstatt sie stillschweigend zu vergrößern CIDR. Bei dieser Überprüfung wurden keine PTR Abfragen oder Migrationen durchgeführt.