Une recherche DNS peut échouer car la réponse ne correspond pas à l'échange UDP utilisable et le chemin de secours ne peut pas être exécuté. Grand Enregistrements TXT, DNSSEC le matériel et la composition de la réponse peuvent exposer ce problème. Ne supprimez pas une clé ou ne raccourcissez pas une stratégie simplement parce qu'un vérificateur ne signale aucun enregistrement ; Déterminez d’abord si le résolveur a obtenu une réponse complète.
Lire le signal de troncature
Références : RFC 1035 §4.1.1, RFC 7766 §5, RFC 6891 §6.2.3.
Le bit TC de l'en-tête DNS indique une troncature. Un client qui a besoin des données manquantes réessaye normalement en utilisant TCP. Les implémentations DNS modernes doivent prendre en charge TCP selon RFC 7766 ; DNS n'est pas un service uniquement UDP. EDNS permet à un demandeur d'annoncer une taille de charge utile UDP plus grande, mais cette annonce ne garantit pas que chaque réseau sur le chemin transportera le paquet.
La fragmentation IP, les pare-feu et les middlebox défectueux peuvent interférer avec des réponses UDP plus importantes. TCP peut être requis indépendamment du fait qu'une valeur TXT particulière apparaisse ou non petite dans un panneau Web. Mesurez la réponse et le chemin, pas seulement le nombre de caractères que vous avez collés.
Séparez les deux jambes du résolveur
Références : RFC 7766 §5, RFC 7208 §4.4.
Les échanges de stub à récursif et récursif à faisant autorité sont distincts. Un TCP réussi depuis votre ordinateur portable vers un résolveur public ne prouve pas que le résolveur du destinataire du courrier peut atteindre votre autorité sur TCP. De même, un test d'autorité directe ne reproduit pas tous les résolveurs de transfert utilisés par un récepteur.
Enregistrez le propriétaire de la requête, le type, le serveur, le transport, les options EDNS, la taille de la réponse, les indicateurs et le timing. Une réponse partielle tronquée ne doit pas être interprétée comme un ensemble complet de réponses sélectionnées. SPF politiques. SERVFAIL et timeout ne prouvent pas que le nom n'existe pas. Conservez l’erreur exacte avant de modifier les enregistrements d’application.
Reproduire un défaut de repli contrôlé
Dans un laboratoire DNS jetable, configurez une réponse suffisamment grande pour dépasser une taille de réponse UDP acceptée délibérément petite. Autorisez d’abord UDP et TCP. Demandez le même propriétaire et tapez et capturez les paquets ou une trace du résolveur. Les preuves attendues incluent une réponse UDP tronquée suivie d'une réponse TCP réussie lorsque le client effectue un repli.
Bloquez ensuite uniquement le chemin TCP du laboratoire à la limite choisie. Répétez la requête avec une entrée et un état de cache identiques contrôlés. Le résultat attendu est un échec de recherche complète à cette frontière malgré un échange UDP fonctionnel. Restaurez la règle immédiatement après le test. Il s'agit d'une spécification de laboratoire et non d'une autorisation de modifier la sécurité du réseau de production ; cette procédure basée sur le pare-feu n'a pas été exécutée pour cet article. L’expérience historique de fermeture de service ci-dessous est un test différent, plus restreint.
Avec une version BIND dig installée prenant en charge ces options, creuser @AUTH OWNER TXT +bufsize=512 +ignorer peut exposer la réponse UDP sans nouvelle tentative TCP automatique, tandis que creuser @AUTH OWNER TXT + tcp demande explicitement TCP. Remplacez les valeurs de laboratoire, inspectez l'aide de la version et conservez l'intégralité du résultat. Les commandes n'ont pas été exécutées ici dans cette revue. La capture de client personnalisé conservée ne valide pas le comportement de fouille.
Réparer les transports avant de repenser la politique
Références : RFC 7766 §5, RFC 7208 §3.2, RFC 7208 §3.3.
Confirmez que le service écoute sur les deux transports et que le chemin réseau autorisé autorise le trafic requis. Demandez à l’opérateur responsable d’examiner les modifications apportées au pare-feu ou à l’équilibrage de charge. Testez à nouveau la même réponse et capturez l'achèvement sur le chemin prévu.
Garder les réponses gérables de manière opérationnelle est utile, mais diviser une valeur TXT en chaînes dans un seul enregistrement ne réduit pas suffisamment la réponse DNS totale pour résoudre les erreurs de transport. Le fractionnement d’une stratégie SPF en plusieurs enregistrements de stratégie crée une violation distincte des normes. Résolvez le problème avec des preuves de transport, puis des résultats d'authentification représentatifs, et non avec une valeur de tableau de bord plus courte.
Preuves historiques conservées en laboratoire
La capture conservée est datée du 7 novembre 2026. Ce qui suit décrit cette observation historique limitée, et non une nouvelle exécution ou un test d' EmailAuth.ai .
Le service DNS isolé a délibérément émis TC avec une réponse UDP vide pour une réponse TXT volumineuse. La même question sur TCP a renvoyé la réponse complète avec TC clear et une longueur de câble supérieure à 512 octets. La fermeture des connexions TCP acceptées dans le service de test a provoqué l'échec du client. Aucun paramètre de pare-feu ou de réseau de production n'a été modifié. Ceci teste les échanges UDP et TCP réels sous troncature forcée ; il ne prétend pas tester le seuil de taille automatique d'un serveur DNS ou creuser sa propre implémentation de secours. Les étiquettes de capture sont large_udp_truncated ; large_tcp_complete; tcp_failure.json. Les coureurs retenus et les captures brutes sont inclus dans ce dossier de révision à titre de preuves historiques. Ils ont été inspectés et non réexécutés pour cet examen. Les résultats de production DNS , DNSSEC et SMTP n'ont pas encore été testés.