Når to SPF brikker viser forskjellige oppslagstall, ikke velg det mer betryggende tallet. Fastslå hva hvert verktøy målte. En kan vise DNS-avhengige termer på en evaluert bane, en annen kan utvide en policygraf, og en tredje kan vise nettverksspørringer. Disse utgangene kan svare på forskjellige spørsmål selv når de inspiserer det samme domenet.
Spør hva telleren betyr
RFC 7208 avsnitt 4.6.4 begrenser evaluerte DNS-avhengige termer på tvers av rekursjon. Det er ikke bare tellingen av alle TXT strenger, hver DNS pakke eller antall inkluderer synlig skrevet på toppnivået. Bufrede svar gir ikke et større logisk terminbudsjett.
Skill andre begrensninger også. Spesifikasjonen tar for seg ugyldige oppslag og mekanismespesifikke grenser i tillegg til hovedtaket for evaluert termin. Et verktøy kan presentere én kombinert advarsel mens et annet eksponerer hver kategori. Lagre den nøyaktige advarselsteksten og dokumentasjonen i stedet for å anta at hver rød etikett betyr det samme.
Gi begge verktøyene samme feste
Registrer det evaluerte domenet, tilkoblings-IP, avsenderidentitet, HELO der det er relevant, løservisning og spørretid. Hvis verktøyet bare godtar et domene, finn ut om antallet er et statisk estimat, en worst-case-analyse eller en bestemt syntetisk bane. En kun domeneskanning tilsvarer ikke automatisk å evaluere en reell tilkobling.
For policyer som bruker makroer, kan de manglende identitetsinndataene ha direkte betydning. Sammenlign IPv4 og IPv6 tilfeller separat når begge oppstår. Ta vare på DNS svarene eller en reproduserbar kontrollert armatur, slik at et senere leverandørskifte ikke gjør en antatt verktøysammenligning til en sammenligning av forskjellige policyer.
Gå et lite illustrerende eksempel
Vurder en syntetisk policy:
v=spf1 ip4:192.0.2.10 include:_spf.vendor.example -all
Under RFC 7208 §4.6.2 og RFC 7208 §5.6, for 192.0.2.10 kan den eksplisitte adressen matche før inkluderingen blir evaluert. For en annen adresse kan evaluering nå inkluderingen og dens nestede avhengigheter. Et grafutvidelsesverktøy kan vise den grenen selv når banen til den første meldingen aldri når den. De forskjellige tallene trenger forklaring, ikke en automatisk dom om at begge verktøyene er defekte.
Gjør inkludere-målet eksplisitt for å sammenligne numeriske tellinger. I denne syntetiske armaturen, _spf.vendor.example har nøyaktig én SPF TXT post, v=spf1 ip4:192.0.2.20 -all. Anta vellykket DNS henting, gyldig syntaks, ingen ekstra avhengigheter og vanlig POST FRA evaluering for overordnet domene.
- Inngang 192.0.2.10 : foreldrenes første ip4-mekanisme samsvarer. Den faktiske banen evaluerer 0 DNS-avhengige termer og besøker aldri include.
- Inndata 192.0.2.20 : foreldrenes ip4 stemmer ikke overens. Inkluderingen blir evaluert, dens mål-ip4 matcher, og forelderen returnerer bestått. Den faktiske banen evaluerer 1 DNS-avhengig term, inkludert.
- Input 192.0.2.30 : Inkluderingsmålet når -all og returnerer mislykkes, så inkluderingen stemmer ikke overens. Forelderen når sitt eget -all og returnerer mislykkes. Den faktiske banen evaluerer fortsatt 1 DNS-avhengig term, i samsvar med RFC 7208 §5.2.
Et statisk grafantall av DNS-avhengige termer er 1 for hele denne armaturen, uavhengig av hvilken tilkobling som er valgt. Den første TXT -hentingen av den overordnede policyen er nødvendig, men er ikke i seg selv en av de evaluerte termene som telles mot denne grensen. Dermed kan en visning på 0 for den første inngangen og 1 for den utvidede grafen begge forklares. Dette er analytiske forventede resultater, ikke utførte målinger eller nettverkspakketellinger.
Tenk deg nå at den inkluderte policyen endres mellom de to skanningene. En ny skanning kan legitimt avsløre et annet avhengighetstre. Lagre tidsstempler og faktiske svar før du eskalerer uenigheten. Et skjermbilde uten innganger er et svakt bevis.
Sammenlign spor ved første divergens
Lag en side ved side liste over de evaluerte termene. Finn det første stedet verktøyene er uenige: postvalg, en tidlig match, rekursjon, en DNS feil, en makroutvidelse eller en tellekonvensjon. Sjekk om den ene stopper ved en feil mens den andre fortsetter for diagnostiske formål. En diagnostisk utvidelse kan være nyttig uten å representere en gyldig gjennomført evaluering.
Hvis et verktøy ser ut til å være i strid med standarden, produsere en minimal syntetisk armatur og forventet oppførsel med en seksjonsreferanse. Send det til verktøyets vedlikeholder gjennom din vanlige støtteprosess, og unngå konfidensielle produksjonsdata der en armatur vil gjøre det. Ikke endre produksjonen bare for å få inkonsekvente dashbord til å stemme overens.
Ta en avgjørelse fra de løste bevisene
En gyldig kort vei for én avsender etablerer ikke helse for hver avsender. Test representative legitime innganger og en input som ikke samsvarer, og inspiser avhengighetene som kan endres senere. Omvendt er ikke en stor statisk graf i seg selv et bevis på at hver melding overskrider grensen for evaluert tidsperiode.
Registrer hvilken måling som støtter beslutningen din, eventuelle uløste verktøybegrensninger og den forventede effekten av en foreslått endring. Bruk mekanismebestilling først etter å ha forstått disse veiene. Hvis du ikke kan forene en følgeavvik, behold gjeldende bevis og søk en implementeringsspesifikk gjennomgang i stedet for å presentere en uforklarlig telling som sikkerhet.
Skriv avgjørelsen skriftlig
For den gitte to-record-armaturen, behold overordnet og underordnet tekst, inndataadresse, telledefinisjon og forventet bestått/ikke bestått. 0/1/1-verdiene er analytiske evaluerte termintellinger, ikke målte DNS pakker eller uavhengig verktøykjøring. Hvis et verktøy rapporterer en annen mengde, merk det før du sammenligner. Et avvik i en feilhåndteringsbane trenger sin egen fixtur i stedet for ekstrapolering fra disse vellykkede oppslagene.