De SPF ptr-mechanisme is een oudere manier om een verbindende host te autoriseren via gevalideerd omgekeerde DNS. De huidige SPF richtlijnen zeggen dat het niet mag worden gepubliceerd omdat het traag is, onbetrouwbaar in sommige gevallen van DNS-fouten en operationeel belastend. Het blijft onderdeel van het protocol en conforme beoordelaars moeten het ondersteunen.
Dat onderscheid is van belang: ontmoedigd betekent niet universeel genegeerd of automatisch ongeldig. Als u het verwijdert zonder de afzenders te identificeren die ervan afhankelijk zijn, kan dit de echte authenticatieresultaten veranderen. RFC 7208 sectie 5.5 zorgt voor de relevante begeleiding.
Begrijp de toestemming die wordt vervangen
Conceptueel gezien begint ptr met een omgekeerde zoekopdracht naar het verbindingsadres. Vervolgens worden de geretourneerde namen doorgestuurd om te valideren dat ze terugverwijzen naar het verbindingsadres. Een gevalideerde naam moet overeenkomen met het doeldomein of binnen de domeingrens liggen voordat het mechanisme overeenkomt.
Dit is meer dan controleren of een hostnaam een bekende string bevat. Een naam zoals relay.example.com bevindt zich binnen example.com ; relay.notexample.com is dat niet. Alleen een omgekeerd antwoord is ook onvoldoende: voorwaartse validatie is van belang.
Reverse DNS wordt vaak beheerd door de adreseigenaar en niet door de organisatie die SPF bewerkt. Dat creëert een extra administratieve afhankelijkheid wanneer het beleid afhankelijk is van hostnamen onder een gekozen domein.
Geef een synthetisch nalatenschapsvoorbeeld
Stel example.com publiceert v=spf1 ptr:example.com -all. Er komt een verbinding binnen vanaf 192.0.2.55 . Het omgekeerde antwoord is outbound.example.com , en het A-antwoord van die naam bevat 192.0.2.55 . In dit vereenvoudigde armatuur bevindt de gevalideerde naam zich binnen example.com , dus ptr komt overeen.
Als het doorstuuradres in plaats daarvan 192.0.2.99 is, wordt de omgekeerde naam niet gevalideerd voor het verbindende adres. Als er geen andere gevalideerde naam in aanmerking komt, komt ptr niet overeen en bereikt het beleid -all . Op dezelfde manier komt een gevalideerde naam buiten het doeldomein niet in aanmerking alleen omdat deze er hetzelfde uitziet.
Dit zijn verwachte protocolresultaten voor synthetische input, geen observaties vanuit een productiedomein. Bij echte evaluatie worden ook de opzoek- en verwerkingslimieten toegepast, inclusief grenzen voor achteruit en voorwaarts werk.
Verwar twee reverse-DNS-beslissingen niet
Het verwijderen van het ptr-mechanisme uit SPF betekent niet dat het PTR record van de server wordt verwijderd. Reverse DNS kan nog steeds relevant zijn voor SMTP bewerkingen, ontvangervereisten en reputatiecontroles, onafhankelijk van SPF . Een host kan de juiste reverse DNS hebben, terwijl het SPF -beleid gebruikmaakt van ip4, ip6 of een gedocumenteerde provider.
Houd de migratie beperkt. Vervang het autorisatiemechanisme en behoud andere werkende DNS instellingen, tenzij een afzonderlijke, gerechtvaardigde wijziging deze vereist.
Kies een vervanger uit de geobserveerde afzenders
Voor specifiek stabiel uitgaand verkeer onder uw controle maken expliciete IP4- en IP6-machtigingen de beoogde adressen zichtbaar. Voor een service met beheerde veranderende infrastructuur gebruikt u de gedocumenteerde SPF configuratie in plaats van een hostnaamregel van een provider te reconstrueren.
De een mechanisme kan geschikt zijn wanneer een specifiek gecontroleerde hostnaam bedoeld is om de verzendadressen te definiëren. Het is niet automatisch de beste vervanging voor ptr: het verandert het toestemmingsmodel en creëert een eigen forward-DNS-afhankelijkheid.
Bouw een inventaris op van de adressen die momenteel via ptr passeren en verkrijg bewijs van eigendom. Inclusief failover, IPv6 en onregelmatig verkeer. Verzamel niet een paar recente adressen en claim dat u de volledige machtigingenset heeft ingesteld.
Migreer zonder onzekerheid te verbergen
Maak een voorgesteld beleid dat de geverifieerde legitieme routes autoriseert. Evalueer het oude en nieuwe beleid voor die set en voor ongeautoriseerde controles. Controleer of een nieuwe subsidie breder is dan de oude en of onbekende afzenders onopgelost blijven.
Bewaar het eerdere record en definieer terugdraaivoorwaarden die verband houden met legitieme workflowfouten. Publiceer via normaal wijzigingsbeheer, inspecteer DNS antwoorden en verifieer door vertegenwoordigers ontvangen berichten. Als een legitieme afzender faalt, bevestig dan de identiteit en het eigendom ervan voordat u toestemming toevoegt.
De praktische afhaalmaaltijd
PTR buiten gebruik stellen als SPF autorisatiemechanisme op basis van bewijsmateriaal over echte afzenders. Behoud de noodzakelijke reverse DNS en vervang verborgen hostnaamafhankelijkheden door een expliciet, onderhoudbaar toestemmingsmodel.
Noteer de volgende beslissing
Voor de synthetische oudere bron moet u het omgekeerde antwoord, het voorwaartse antwoord, de gevalideerde naam en de doelgrensvergelijking afzonderlijk behouden. Vergelijk vervolgens de voorgestelde vervanging met bekende, failover- en niet-frequente bronnen plus een ongeautoriseerde controle. Als het eigendom van een afzender onbekend blijft, leg dan dat gat vast in plaats van het stilzwijgend groter te maken CIDR. Bij deze beoordeling zijn geen PTR query's of migratie uitgevoerd.