En DNS editor, der rapporterer en grænse på 255 tegn, betyder ikke nødvendigvis din SPF politik skal blive til flere poster. DNS TXT formatet tillader flere tegnstrenge i én ressourcepost. SPF behandler deres indhold som én kontinuerlig værdi. Den operationelle udfordring er at bevare den tilsigtede tekst og samtidig holde politikken og dens DNS svar håndterbare.
Adskil tre forskellige grænser
For det første er en individuel TXT -tegnstreng begrænset til 255 oktetter. SPF indholdet er ASCII, så dets almindelige tegn optager hver en oktet. En enkelt TXT post kan indeholde mere end én sådan streng. RFC 7208 afsnit 3.3 tillader udtrykkeligt denne repræsentation.
For det andet har DNS svaret en størrelse. Det inkluderer navne, rekordmetadata og andre TXT poster, der returneres til det pågældende ejernavn, ikke kun SPF tekst. Afsnit 3.4 anbefaler at holde SPF DNS svar små nok til ældre 512-oktet UDP-håndtering. Dette er en kompatibilitetsanbefaling, ikke et universelt maksimum på 512 tegn for SPF . Moderne DNS -transportmuligheder eliminerer ikke alle resolver-, firewall- eller trunkeringsproblemer.
For det tredje har SPF evaluering ressourcegrænser. Opdeling af tekst i strenge reducerer ikke indlejret inkluderingsbehandling eller grænsen på ti opslagsårsager. En kort politik kan overskride denne evalueringsgrænse; en længere liste over eksplicitte adresser må ikke. Vurder syntaks, DNS transport og evalueringsomkostninger uafhængigt.
Bevar rum bevidst
SPF sammenkæder strenge uden at indsætte mellemrum. I en zonefil repræsentation, "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" producerer den tilsigtede kontinuerlige politik, fordi den første streng slutter med et mellemrum. Fjernelse af dette mellemrum forbinder de to tilstødende mekanismer til ugyldig tekst.
Ovenstående adresser kun til dokumentation er illustrative. De er ikke autoriserede værdier for dit domæne. Anførselstegnene er syntaks for præsentation af zonefil; om du indtaster dem i en hostet DNS editor afhænger af den pågældende udbyders dokumenterede grænseflade. Nogle redaktører opdeler lange værdier automatisk, mens andre viser separate strengfelter. Bekræft det serverede svar i stedet for at antage, at editorens skærm matcher trådformatet.
Opret ikke en anden TXT -ressourcepost, der begynder v=spf1 at holde resten. Flere valgt SPF optager producere permerror. Omvendt skal du ikke slette urelaterede TXT -bekræftelsesposter, fordi et diagnoseværktøj viser flere TXT svar.
Undersøg den offentliggjorte værdi
Indfang det autoritative TXT svar og identificer, hvilke strenge der hører til hver ressourcepost. Rekonstruer SPF værdien ved kun at sammenkæde strengene i dens ene post. Tjek mellemrum ved hver opdelt grænse og sørg for, at der er én versionsmarkør, gyldige mekanismer og den tilsigtede endelige erklæring.
Test derefter rekursive DNS svar fra de netværk, der betyder noget. Hvis et svar afkortes, eller løsningen mislykkes, skal du undersøge DNS transport og udbyderkonfiguration i stedet for at slette vilkårlige mekanismer. DNSSEC og det bredere svarsæt kan påvirke svarstørrelsen; et simpelt tegnantal er ikke en test i fuld pakkestørrelse.
Foretrækker politikoprydning frem for smart pakning
En voksende politik signalerer ofte akkumulerede tjenester. Gennemgang forældet omfatter unødvendigt brede mekanismer og duplikerede godkendelser, før kompleksiteten øges. Behold de nuværende udbyderstyrede mekanismer, når det er relevant i stedet for at kopiere deres nuværende IP-adresser udelukkende for at forkorte eller omforme posten. Manuelt fladtrykte adresser kan blive forældede, når udbydere ændrer infrastruktur.
For en politik, der stadig har brug for flere strenge, skal du gemme den tilsigtede uopdelte tekst sammen med den offentliggjorte repræsentation. Det giver fremtidige administratorer et stabilt sammenligningsmål. En harmløs editor-reformatering bør ikke forveksles med en semantisk politikændring.
Bekræft det læservendte resultat
Efter en godkendt ændring, test repræsentative kilder og en uovertruffen kilde med en standardbevidst evaluator, inspicer derefter faktiske betroede modtagerresultater. Registrer den rekonstruerede værdi, responsobservationer og evalueringsresultater. Luk problemet, når både DNS repræsentation og godkendelsesadfærd er korrekt, ikke kun når redaktøren accepterer lagringen.
Rekonstruer et forespørgselssvar
Det følgende er en syntetisk diagnostisk øvelse, ikke en forespørgsel, vi kørte eller en rekord at udgive. Erstat det faktiske SPF ejernavn og en verificeret autoritativ navneserver før du bruger disse skrivebeskyttede kommandoer. Disse skabeloner bruger reserverede eksempelnavne.
dig @ ns1.example.net example.com TXT +noall +answer dig example.com TXT +noall +svarDen første kommando spørger den angivne autoritative server; den anden bruger den resolver, der er konfigureret på den pågældende maskine. Et svar fra en rekursiv resolver beviser ikke, at alle modtagere ser de samme data. Hvis det er nødvendigt, forespørg en anden kendt resolver eksplicit med @server-adresse.
Syntetisk svar:
example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "Rekonstrueret værdi:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -allUden det efterfølgende mellemrum i den første streng bliver grænsen 192.0.2.10ip4: 198.51.100.20 . Redaktøren accepterer muligvis TXT dataene, men det gør ikke SPF politikken gyldig. Derimod er to separate svarposter, der hver starter v=spf1 et problem med flere politikker, ikke en strengopdelingsløsning.
Gem den forespurgte server, ejernavn, tidsstempel og svar. Rekonstruer én post ad gangen, sammenlign den med den tilsigtede uopdelte politik, og evaluer derefter afsenderautorisation separat. Kommandoerne inspicerer DNS repræsentation; de kører ikke en komplet SPF evaluering. Se RFC 7208 Afsnit 3.3 til sammenkædning og Afsnit 4.6.4 for evalueringsgrænser.