Un enregistrement TXT n’est pas une seule chaîne. La RFC 1035 le stocke comme une suite de chaînes de caractères d’au plus 255 octets, qu’un résolveur recolle sans rien entre elles. C’est pourquoi une clé DKIM de 2048 bits doit être livrée au fichier de zone en plusieurs morceaux entre guillemets, et pourquoi la couper au mauvais endroit — ou recoller les morceaux avec un espace — casse la signature du courrier d’une façon pénible à diagnostiquer. Cet outil coupe sur des frontières d’octets, jamais au milieu d’un caractère, et met en forme pour BIND ou pour une API DNS.
Fonctionnalités
Découpe sur des frontières de 255 octets, en comptant des octets et non des caractères
Ne coupe jamais un caractère multi-octet ni une paire de substitution
Formats BIND sur une ligne, entre parenthèses, chaînes seules ou tableau JSON
Nombre d’octets par morceau, pour voir quelles chaînes sont pleines
Alerte sur les espaces parasites, les guillemets déjà présents et les enregistrements de plus de 512 octets
Recolle les chaînes issues d’un fichier de zone ou d’une réponse dig
Exemples de clé DKIM 2048 bits, de SPF long et de jeton de vérification
Comment utiliser Diviseur d’enregistrement TXT
Collez la valeur TXT complète : les guillemets sont ajoutés pour vous
Indiquez le nom de l’enregistrement et le TTL pour une ligne de zone complète
Choisissez le format attendu par votre hébergeur DNS
Copiez l’enregistrement, ou passez à l’onglet de recollage
default._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIja…" "…QIDAQAB"
Deux chaînes entre guillemets que le résolveur concatène sans rien entre elles.
Erreurs courantes et dépannage
L’hébergeur DNS refuse l’enregistrement, jugé trop long. — Il applique la limite de 255 octets à une seule chaîne. Collez la version découpée, chaque morceau entre guillemets séparément.
La vérification DKIM échoue après le découpage. — Presque toujours un espace entre les morceaux. Les résolveurs concatènent sans rien, tout espace ajouté fait donc partie de la clé.
La valeur contient déjà des guillemets. — Collez la valeur brute. Les guillemets sont ajoutés à la mise en forme, et une valeur déjà entre guillemets finit doublement encadrée.
Les morceaux font moins de 255 caractères. — La limite est de 255 octets, pas de caractères. Tout caractère non ASCII occupe deux à quatre octets, un morceau peut donc être plein avec moins de caractères.
Foire aux questions
Pourquoi un enregistrement TXT est-il limité à 255 caractères ?
Chaque chaîne d’un enregistrement TXT porte un octet de longueur, ce qui la borne à 255 octets. L’enregistrement complet peut en contenir plusieurs, la vraie limite est donc la taille du message DNS.
Comment un résolveur recolle-t-il les chaînes TXT ?
Il les concatène dans l’ordre sans aucun séparateur. C’est ce comportement qu’exploitent DKIM, SPF et les jetons de vérification, d’où l’indifférence au point de coupure.
Où faut-il couper une clé DKIM ?
N’importe où, tant que chaque morceau ne dépasse pas 255 octets. Pour le vérificateur la clé est une seule chaîne Base64 une fois recollée, couper au milieu du Base64 ne pose donc aucun problème.
Quelle taille peut atteindre l’enregistrement TXT complet ?
En pratique quelques kilooctets, mais les réponses au-delà de 512 octets exigent EDNS ou une reprise en TCP. Certains résolveurs s’en accommodent mal.
Faut-il découper un enregistrement SPF de la même façon ?
Seulement si une chaîne dépasse 255 octets, ce qui arrive avec beaucoup d’inclusions. Notez que SPF a en plus sa propre limite de dix requêtes DNS.