De SPF ptr-mekanisme er en ældre måde at autorisere en forbindende vært gennem valideret omvendt DNS. Den nuværende SPF vejledning siger, at den ikke bør offentliggøres, fordi den er langsom, upålidelig i nogle tilfælde af DNS-fejl og driftsmæssigt byrdefuld. Det forbliver en del af protokollen, og kompatible evaluatorer skal understøtte det.
Den skelnen er vigtig: afskrækket betyder ikke universelt ignoreret eller automatisk ugyldig. Hvis du fjerner det uden at identificere de afsendere, der er afhængige af det, kan det ændre reelle autentificeringsresultater. RFC 7208 afsnit 5.5 giver den relevante vejledning.
Forstå den tilladelse, der erstattes
Begrebsmæssigt begynder ptr med et omvendt opslag for forbindelsesadressen. Den videresender derefter returnerede navne for at validere, at de peger tilbage til forbindelsesadressen. Et valideret navn skal matche måldomænet eller sidde inden for dets domænegrænse, for at mekanismen kan matche.
Dette er mere end at kontrollere, om et værtsnavn indeholder en velkendt streng. Et navn såsom relay.example.com er inden for example.com ; relay.notexample.com er ikke. Et omvendt svar alene er heller ikke tilstrækkeligt: fremadrettet validering er vigtig.
Omvendt DNS administreres ofte af adresseejeren i stedet for af organisationen, der redigerer SPF . Det skaber en yderligere administrativ afhængighed, når politikken er afhængig af værtsnavne under et valgt domæne.
Gå et syntetisk arv eksempel
Antag, example.com udgiver v=spf1 ptr:example.com -all. Der kommer en forbindelse fra 192.0.2.55 . Dets omvendte svar er outbound.example.com , og det navns A-svar inkluderer 192.0.2.55 . I denne forenklede opstilling er det validerede navn inden for example.com , så ptr matcher.
Hvis den videresende adresse i stedet er 192.0.2.99 , er det omvendte navn ikke valideret for den forbindende adresse. Hvis intet andet valideret navn er kvalificeret, matcher ptr ikke, og politikken når -all . På samme måde er et valideret navn uden for måldomænet ikke kvalificeret, blot fordi det ligner.
Disse er forventede protokolresultater for syntetiske input, ikke observationer fra et produktionsdomæne. Reel evaluering anvender også opslags- og behandlingsgrænserne, herunder grænser for tilbage- og fremadrettet arbejde.
Forveksle ikke to omvendte DNS-beslutninger
Fjernelse af ptr-mekanismen fra SPF betyder ikke sletning af serverens PTR record. Omvendt DNS kan stadig være relevant for SMTP operationer, modtagerkrav og omdømmetjek uafhængigt af SPF . En vært kan have passende omvendt DNS mens dens SPF -politik bruger ip4, ip6 eller en dokumenteret udbyder.
Hold migreringen snævert. Udskift godkendelsesmekanismen og behold andre fungerende DNS -indstillinger, medmindre en separat, berettiget ændring kræver dem.
Vælg en erstatning blandt observerede afsendere
For dedikeret stabil udgang under din kontrol, gør eksplicitte ip4- og ip6-tilladelser de tilsigtede adresser synlige. For en tjeneste med administreret skiftende infrastruktur skal du bruge dens dokumenterede SPF konfiguration i stedet for at rekonstruere en regel for udbyderens værtsnavn.
De en mekanisme kan være passende, når et specifikt kontrolleret værtsnavn er beregnet til at definere afsenderadresserne. Det er ikke en automatisk bedste erstatning for ptr: det ændrer tilladelsesmodellen og skaber sin egen forward-DNS-afhængighed.
Opbyg en fortegnelse over adresser, der i øjeblikket passerer gennem ptr, og indhent ejerskabsbeviser. Inkluder failover, IPv6 og sjælden trafik. Saml ikke et par nyere adresser og hæv, at du har etableret det komplette tilladelsessæt.
Migrer uden at skjule usikkerhed
Opret en foreslået politik, der godkender de verificerede legitime ruter. Evaluer de gamle og nye politikker for det sæt og for uautoriserede kontroller. Tjek, om en ny bevilling er bredere end den gamle, og om ukendte afsendere forbliver uafklarede.
Bevar den tidligere registrering og definer rollback-betingelser knyttet til legitime workflowfejl. Udgiv gennem normal ændringskontrol, inspicér DNS svar og verificer repræsentative modtagne beskeder. Hvis en legitim afsender mislykkes, skal du bekræfte dens identitet og ejerskab, før du tilføjer tilladelse.
Den praktiske takeaway
Træk ptr tilbage som en SPF godkendelsesmekanisme ved hjælp af beviser om rigtige afsendere. Bevar nødvendig omvendt DNS , og erstat skjulte værtsnavnsafhængigheder med en eksplicit, vedligeholdelig tilladelsesmodel.
Optag den næste beslutning
For den syntetiske ældre kilde skal du beholde omvendt svar, fremadrettet svar, valideret navn og sammenligning af målgrænsen separat. Sammenlign derefter den foreslåede udskiftning med kendte, failover og sjældne kilder plus en uautoriseret kontrol. Hvis én afsenderes ejerskab forbliver ukendt, skal du registrere dette hul i stedet for lydløst at udvide a CIDR. Denne gennemgang udførte ingen PTR forespørgsler eller migrering.