Een DNS editor die een limiet van 255 tekens meldt, betekent niet noodzakelijkerwijs uw SPF beleid moet meerdere records worden. Het DNS TXT formaat staat meerdere tekenreeksen binnen één bronrecord toe. SPF behandelt de inhoud ervan als één continue waarde. De operationele uitdaging is om de beoogde tekst te behouden en tegelijkertijd het beleid en de DNS reacties beheersbaar te houden.
Scheid drie verschillende limieten
Ten eerste is een individuele TXT -tekenreeks beperkt tot 255 octetten. SPF inhoud is ASCII, dus de gewone tekens beslaan elk één octet. Een enkele TXT record kan meer dan één dergelijke tekenreeks bevatten. RFC 7208 sectie 3.3 staat deze weergave expliciet toe.
Ten tweede heeft het DNS antwoord een grootte. Het bevat namen, metagegevens van records en andere TXT records die worden geretourneerd onder de naam van de eigenaar, niet alleen SPF -tekst. In paragraaf 3.4 wordt aanbevolen SPF DNS antwoorden klein genoeg te houden voor de verwerking van oudere UDP-taken van 512 octet. Dit is een compatibiliteitsaanbeveling, geen universeel maximum van 512 tekens voor SPF . Moderne DNS transportmogelijkheden elimineren niet elk probleem met de oplosser, firewall of truncatie.
Ten derde kent SPF evaluatie beperkte middelen. Het splitsen van tekst in tekenreeksen vermindert de geneste include-verwerking of de limiet van tien opzoektermen niet. Een kort beleid kan die evaluatielimiet overschrijden; een langere lijst met expliciete adressen mogelijk niet. Beoordeel de syntaxis, DNS transport en evaluatiekosten onafhankelijk.
Bewaar bewust ruimtes
SPF voegt tekenreeksen samen zonder spaties in te voegen. In een zonebestandsweergave, "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" produceert het beoogde continue beleid omdat de eerste string eindigt met een spatie. Als u die spatie verwijdert, worden de twee aangrenzende mechanismen samengevoegd tot ongeldige tekst.
De bovenstaande documentatie-only adressen zijn illustratief. Het zijn geen geautoriseerde waarden voor uw domein. De aanhalingstekens zijn de syntaxis van de zonebestandpresentatie; of u ze in een gehoste DNS editor invoert, hangt af van de gedocumenteerde interface van die provider. Sommige editors splitsen lange waarden automatisch, terwijl andere afzonderlijke tekenreeksvelden weergeven. Controleer het weergegeven antwoord in plaats van aan te nemen dat de weergave van de redacteur overeenkomt met het draadformaat.
Maak geen tweede TXT bronrecord aan v=spf1 om de rest vast te houden. Meerdere geselecteerd SPF records produceren permerror. Omgekeerd mag u geen niet-gerelateerde TXT -verificatierecords verwijderen, omdat een diagnostisch hulpprogramma verschillende TXT antwoorden weergeeft.
Inspecteer de gepubliceerde waarde
Leg het gezaghebbende TXT antwoord vast en identificeer welke tekenreeksen bij elk bronrecord horen. Reconstrueer de SPF waarde door alleen de tekenreeksen binnen één record samen te voegen. Controleer spaties bij elke gesplitste grens en zorg ervoor dat er één versiemarkering, geldige mechanismen en de beoogde eindverklaring aanwezig is.
Test vervolgens recursieve DNS reacties van de netwerken die er toe doen. Als een antwoord wordt afgekapt of de resolutie mislukt, onderzoek dan DNS transport en de providerconfiguratie in plaats van willekeurige mechanismen te verwijderen. DNSSEC en de bredere antwoordset kan de responsgrootte beïnvloeden; een eenvoudige tekentelling is geen test op volledige pakketgrootte.
Geef de voorkeur aan een opschoning van het beleid boven een slimme verpakking
Een groeiend beleid duidt vaak op een opeenstapeling van diensten. Controleer verouderde mechanismen, onnodig brede mechanismen en dubbele autorisaties voordat de complexiteit toeneemt. Behoud indien nodig de huidige, door de provider beheerde mechanismen, in plaats van de huidige IP-adressen uitsluitend te kopiëren om het record in te korten of opnieuw vorm te geven. Handmatig afgeplatte adressen kunnen verouderd raken als providers van infrastructuur veranderen.
Voor een beleid dat nog steeds meerdere tekenreeksen nodig heeft, slaat u de bedoelde, niet-gesplitste tekst op naast de gepubliceerde weergave. Dat geeft toekomstige beheerders een stabiel vergelijkingsdoel. Een onschuldige herindeling van de editor mag niet worden verward met een semantische beleidswijziging.
Controleer het voor de lezer gerichte resultaat
Na een goedgekeurde wijziging test u representatieve bronnen en een ongeëvenaarde bron met een normbewuste evaluator, en inspecteert u vervolgens de daadwerkelijke resultaten van vertrouwde ontvangers. Registreer de gereconstrueerde waarde, responsobservaties en evaluatieresultaten. Sluit het probleem wanneer zowel DNS weergave als het autorisatiegedrag correct zijn, en niet alleen wanneer de editor de opslag accepteert.
Reconstrueer een vraagantwoord
Het volgende is een synthetische diagnostische oefening, geen zoekopdracht die we hebben uitgevoerd of een record publiceren. Vervang de werkelijke naam van SPF eigenaar en een geverifieerde autoriteit naamserver voordat u deze alleen-lezen opdrachten gebruikt. Deze sjablonen gebruiken gereserveerde voorbeeldnamen.
dig @ ns1.example.net example.com TXT +geenalles +antwoord dig example.com TXT +geenalles +antwoordHet eerste commando vraagt de opgegeven gezaghebbende server; de tweede gebruikt de oplosser die op die machine is geconfigureerd. Een antwoord van één recursieve oplosser bewijst niet dat elke ontvanger dezelfde gegevens ziet. Indien nodig kunt u expliciet een andere bekende solver opvragen met @server-address.
Synthetisch antwoord:
example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "Gereconstrueerde waarde:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -allZonder de volgspatie in de eerste string wordt de grens 192.0.2.10ip4: 198.51.100.20 . De redacteur accepteert de TXT gegevens misschien, maar dat maakt het SPF beleid niet geldig. Twee afzonderlijke antwoordrecords die elk met v=spf1 beginnen, zijn daarentegen een probleem met meerdere beleidsregels en geen oplossing voor het splitsen van tekenreeksen.
Sla de opgevraagde server, de naam van de eigenaar, het tijdstempel en het antwoord op. Reconstrueer één record tegelijk, vergelijk het met het beoogde niet-gesplitste beleid en evalueer vervolgens de autorisatie van de afzender afzonderlijk. De opdrachten inspecteren DNS representatie; ze voeren geen volledige SPF evaluatie uit. Zien RFC 7208 Sectie 3.3 voor aaneenschakeling en Sectie 4.6.4 voor evaluatielimieten.