SPF udfladning er en måde at erstatte nogle DNS-afhængige godkendelser med eksplicitte adresseområder. Det kan gøre en evaluering mindre afhængig af indlejrede opslag. Det kan også lade dig bevare en kopi af en andens skiftende netværk. En nyttig beslutning sammenligner derfor den foreslåede registrering og den proces, der vil holde den korrekt.
Etabler den faktiske begrænsning
Start med det nøjagtige konvolutdomæne, der bruges af den berørte applikation, ikke blot virksomhedens webstedsdomæne. Saml den nuværende post, dens afhængigheder og repræsentanter for afsendelsesadresser. Kør en standardbevidst evaluering med disse input og behold sporet. En etiket, der siger "for mange opslag" er ikke nok til at beslutte, hvad der skal erstattes.
RFC 7208 afsnit 4.6.4 begrænser evaluerede DNS-afhængige termer globalt på tværs af rekursion. Eksplicitte ip4- og ip6-mekanismer er uden for dette tidsbudget. Dette er den potentielle opslagsfordel; det er ikke et løfte om, at hver fladtrykt post er lille, korrekt eller hurtig.
Fjern først autorisationer, hvis virksomhedsejere bekræfter, at de er forældede. Tjek, om en særskilt applikation kan bruge et passende konfigureret konvolutunderdomæne. Hverken oprydning eller segmentering bør udføres blindt: Angiv de berørte meddelelser, og bekræft, at udbyderen understøtter den foreslåede identitet. Brug afsenderens opgørelse at forbinde en rekord adgang til en rigtig tjeneste.
Sammenlign betydning, ikke kun adresselister
Under RFC 7208 §5.2, en include er en evaluering af en anden politik, ikke en tekstfil med netværk, der skal kopieres. Kvalifikationer, rækkefølge, indlejrede inkluderer, omdirigering og makroer kan påvirke resultatet. En konverter skal bevare den tilsigtede autorisation for de understøttede input eller udtrykkeligt erklære, hvad den ikke kan repræsentere. Afvis en konvertering, der blot samler hver IP-lignende værdi fra et træ.
Spørg for hver foreslået udskiftning, hvilken upstream-politik den repræsenterer, hvilke input der blev testet, om IPv6 er dækket, og hvordan ændringer detekteres. Gem den originale afhængigheds- og udbyderdokumentation ved siden af det genererede output. Undgå at udvide tilstødende netværk til et større område blot for at forkorte teksten, medmindre hele området er uafhængigt godkendt.
Gør vedligeholdelsesomkostningerne synlige
Dette er en illustrativ beslutning, ikke en testet implementering. En faktureringsafsender refererer til en udbyderpolitik, der i øjeblikket godkender to områder. En fladtrykt kopi indeholder disse områder. I morgen tilføjer udbyderen en tredje. Den oprindelige afhængighed kan afsløre den nye autorisation gennem DNS ; kopien vil ikke indeholde den, før en vellykket opdatering udgiver en opdatering. Det omvendte problem opstår, når udbyderen trækker et interval tilbage, men kopien beholder det.
Tildel nogen at eje friskhed, mislykkede opdateringer, uventede store ændringer og nødgendannelse. Bed om en advarsel, når genereringsprocessen stopper, i stedet for kun når den offentliggjorte post er syntaktisk gyldig. En gyldig forældet post kan stadig være den forkerte post.
Test en kandidat før udskiftning
Bevar den tidligere rekord og lav en eksplicit før-og-efter-forskel. Test kendte afsendere, en uautoriseret adresse, hver relevant IP-familie og det endelige ikke-matchende resultat. Undersøg det faktiske TXT svar, inklusive dets størrelse og strenggrænser. RFC 7208 §3.3 og RFC 7208 §3.4 forklare, hvorfor opdeling af en TXT værdi i tegnstrenge ikke fjerner behovet for at administrere det overordnede DNS svar.
Brug en kontrolleret afsendelsestest efter godkendt offentliggørelse. Registrer det modtagende systems godkendelsesresultat og den konvolutidentitet, det evaluerede. Sæt ikke lighedstegn mellem en SPF forbedring med DMARC justering eller garanteret indbakkeplacering.
Vælg en driftsmodel, du kan opretholde
Bevar den afhængighedsbaserede politik, når dens evaluering er acceptabel, og dens løbende ejerskab er tydeligere. Overvej kun at udflade med demonstreret semantisk dækning, en pålidelig opdateringsmekanisme, alarmering og en exitplan. Et mindre opslagstal er nyttigt bevis, men ikke hele acceptbeslutningen. For vedligeholdelse efter adoption, fortsæt med gammel fladt SPF.
Optag den næste beslutning
For en hypotetisk konvertering skal du angive understøttede upstream-konstruktioner, kildesnapshot-tid, testede identiteter/IP'er, forventede terminalresultater og hvem der registrerer tilføjede eller tilbagetrukne områder. Hvis en makroafhængig autorisation ikke kan repræsenteres for de tilsigtede input, er kandidaten ikke klar, blot fordi dens opslagstal er mindre. Ingen konvertering, DNS ændring eller afsendelsestest blev udført for denne artikel.