De lengtefout van een DNS formulier kan verwijzen naar verschillende limieten. Een lange TXT waarde, een enkel naamlabel en een volledige DNS naam worden niet op dezelfde manier gemeten. Inkorten van een DKIM sleutel of een splitsen SPF beleid in afzonderlijke records kan een invoerprobleem veranderen in een authenticatiefout.
Bepaal welk object te lang is
Referenties: RFC 1035 §2.3.4, RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 2181 §11.
RFC 1035 beperkt een DNS label tot 63 octetten en de volledige draadformaatnaam tot 255 octetten, inclusief de lengtevelden en het afsluitende rootlabel. Interpunctie bij presentaties en Unicode-invoer kunnen deze metingen verdoezelen. Tel het gecodeerde DNS formulier, niet alleen wat een browsertekstvak weergeeft. Pas de tekenregels voor de hostnaam niet blindelings toe op servicelabels die onderstrepingstekens bevatten.
TXT RDATA bestaat uit één of meer tekenreeksen, elk met een lengte van één octet en dus maximaal 255 octetten. Dat is geen algemene limiet van 255 tekens voor het geheel TXT record. Een provider kan een langere record ondersteunen door er meerdere strings in op te slaan, afhankelijk van DNS bericht- en servicelimieten.
Tekenreeksen splitsen zonder beleid te splitsen
Referenties: RFC 7208 §3.3, RFC 7208 §4.5, RFC 6376 §3.6.2.1, RFC 6376 §3.6.2.2.
Voor SPF worden tekenreeksen binnen één TXT -record aaneengeschakeld zonder extra spaties. Behoud de vereiste spaties op de gesplitste grens. Het armatuur "v=spf1 ip4:192.0.2.10" " -all" reconstrueert één beleid. Twee afzonderlijke TXT bronrecords aan elk begin v=spf1 zijn geen ondersteunde manier om het uit te breiden; SPF selecteert meerdere beleidsregels en retourneert een permanente fout.
Ook de beoogde waarde DKIM sleutelgegevens moet behouden blijven. Gebruik de gedocumenteerde lange-TXT-invoermethode van de provider, en niet handmatige afkapping. Splits niet lang keuzeschakelaar label door een punt in te voegen: dat verandert de DNS naam die door de verificateur wordt opgevraagd, tenzij de feitelijke selectorconfiguratie consistent wordt gewijzigd.
Voer grensgerichte armaturen uit
Referenties: RFC 1035 §2.3.4, RFC 1035 §3.3.
Maak tekenreeksen van exact 255 ASCII a octetten en 256 ASCII a octetten. Eén enkele DNS tekenreeks kan de eerste coderen, maar niet de tweede. Een record met twee strings van elk 128 octetten is een andere, geldige stringstructuur met in totaal 256 data-octetten. Deze markeringen zijn geen authenticatiebeleid.
Vergelijk voor namen een ASCII-label van 63 octet met een label van 64 octet en test vervolgens onafhankelijk de volledige draadnaamlengte. Bewaar de validatiefout voor elke afgewezen aanvraag. Publiceer er een in een aparte testzone SPF record met twee tekenreeksen, en vervolgens de opzettelijk ongeldige variant met twee beleidsrecords. Leg gezaghebbende RR-grenzen vast voor en na de gecorrigeerde publicatie van één record. De verwachte toepassingsresultaten zijn verwerking van één beleid versus verwerking van meerdere beleidsregels permerror.
Deze armaturen specificeren grensgedrag. Een lokale coderingstest kan lengtes aantonen, maar kan niet bewijzen dat een DNS provider een formulier accepteert, een livezone de beoogde RRset publiceert of een ontvanger een bericht authenticeert. Deze uitvoeringsresultaten moeten afzonderlijk worden vastgelegd.
Controleer de resulterende draadgegevens
Referenties: RFC 7208 §3.3, RFC 6376 §3.6.2.2.
Vraag de exacte eigenaar en het type op bij alle actieve autoriteiten. Gebruik een DNS parser die elke bronrecord en de bijbehorende tekenreekslijst bewaart. Reconstrueer waarden volgens het verbruikende protocol in plaats van elke uitvoerregel samen te voegen. Vergelijk vervolgens een relevant recursief antwoord en test de mailstroom.
Als het formulier nog steeds geldige gegevens afwijst, leg dan de exacte fout vast en raadpleeg de huidige providerspecifieke limiet. Voeg geen brede SPF autorisatie toe, verzwak een sleutel of creëer geen ander beleid als tijdelijke oplossing. De juiste oplossing behoudt zowel de bedoelde bytes als de DNS structuur.
Parser en RRset-bewijs uitgevoerd
De bewaarde historische opname van 7 november 2026, geïnspecteerd maar niet opnieuw uitgevoerd voor deze beoordeling, vermeldt dat de dnspython-parser een label van 63 octet en een draadnaam van 255 octet accepteerde, en de overeenkomstige gevallen van 64 en 256 octet verwierp met lengte-uitzonderingen. Werkelijke UDP-autoriteitsregistraties tonen de before-status als twee afzonderlijke SPF TXT records, en vervolgens de gecorrigeerde status als één TXT record met twee geordende tekenreeksen. Een loopback-forwarder retourneerde dezelfde grenzen. Dit is een lokaal gecontroleerde publicatie, geen wijziging in het providerpanel. SPF permerror voor het geval met twee beleidsregels blijft een door de bron gedefinieerd verwacht resultaat omdat er geen SPF evaluator is uitgevoerd. Het bewijs van de grens en het vastleggen van gegevens mag niet worden aangezien voor bewijs van live levering.
Houd de reikwijdte van het bewijs expliciet
De gearchiveerde parser en DNS opnamen blijven ongewijzigd behouden. Deze beoordeling controleert de geregistreerde resultaten en berekent afzonderlijk de bytegrenzen lokaal; het herhaalt geen UDP-publicatie, voert geen SPF evaluator uit of test een providerformulier. Het SPF resultaat met twee records is een normatieve verwachting en geen vastgelegde authenticatie-uitvoering.