Diviseur d’enregistrement TXT DNS
Découpez une longue valeur TXT en chaînes de 255 octets, prêtes pour le fichier de zone.
Le diviseur d’enregistrement TXT fonctionne entièrement dans votre navigateur. Clés et jetons sont découpés sur votre appareil.
Générer un enregistrement DKIM
À propos de Diviseur d’enregistrement TXT
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
Exemple
Entrée
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A… (392 bytes)
Sortie
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.
Outils associés
Tous les outils ArrayKit