Un routeur domestique peut-il résoudre un DNS fractionné pour IPv4 et IPv6 ?
Oui, si le routeur ou le résolveur délégué fournit les réponses A et AAAA prévues aux réseaux clients appropriés et que les clients utilisent effectivement ce résolveur pour les deux familles.
La compatibilité devient une véritable question lorsque les noms d’hôte internes doivent être résolus vers des adresses IPv4 et IPv6 privées, tandis que les clients publics reçoivent des réponses publiques. Commencez par un chemin ou un compte temporaire, conservez l’état fonctionnel précédent et évaluez la conception selon la charge de travail d’origine plutôt que sur la base d’un test de connexion ponctuel.
Distinguer l’architecture prise en charge de celle qui présente des risques
La branche prise en charge fournit des réponses A et AAAA spécifiques au client à partir d’une même politique faisant autorité. La branche concurrente correspond aux clients IPv6 qui contournent le résolveur local ou reçoivent une adresse globale ou ULA inaccessible. Notez les versions, identités, adresses, chemins de montage, autorisations et l’état observable actuel avant de modifier l’une ou l’autre branche.
Les vues DNS fractionnées pertinentes définissent la première limite de compatibilité. Utilisez-les pour limiter votre affirmation, puis vérifiez le même comportement sur ce serveur domestique précis au lieu de considérer qu’une fonctionnalité documentée prouve que toute la conception fonctionne.
Écrivez la règle de décision avant le test : la réussite doit permettre à chaque réseau de recevoir la famille d’adresses prévue et d’atteindre le même service avec certificat, sans hairpinning public ; l’échec inclut un enregistrement AAAA qui divulgue une adresse publique ou obsolète, des clients qui utilisent un DNS externe chiffré, ou un routage IPv6 et une politique de pare-feu qui ne correspondent pas à la réponse. Cela empêche de prendre une connexion partielle ou une sortie de commande réussie pour une compatibilité de bout en bout.
Reproduire exactement le chemin de stockage et de réseau
Utilisez un seul élément discriminant contrôlé : interrogez les enregistrements A et AAAA depuis chaque VLAN, inspectez le résolveur réellement utilisé, puis connectez-vous via les deux familles avec le repli public désactivé pendant le test. Gardez constants le client, la charge de travail, le jeu de fichiers, le compte et le calendrier afin que le composant modifié soit la seule explication plausible.
Utilisez les règles d’adresses dnsmasq pour choisir la seconde observation importante pour ce chemin. Capturez les deux côtés de la transaction : résolveur ou route, protocole négocié, identité du processus, état de sortie, latence, octets transférés et tout événement de récupération.
Répétez le test après l’événement du cycle de vie indiqué dans le titre : recréation, reconnexion, remontage, redémarrage, basculement ou changement de client. Une conception qui ne fonctionne que tant que d’anciens sockets, caches ou identifiants restent actifs n’a pas réussi le test.
dig A app.home @router
dig AAAA app.home @router
curl -4 https://app.home
curl -6 https://app.homeInterpréter les résultats de durabilité, de délai d’expiration et de récupération
RÉUSSITE : chaque réseau reçoit la famille d’adresses prévue et atteint le même service avec certificat, sans hairpinning public. Enregistrez les versions exactes et la topologie qui ont produit cet état, car la conclusion s’applique à ces conditions et non à toutes les implémentations du protocole.
ÉCHEC : l’enregistrement AAAA divulgue une adresse publique ou obsolète, les clients utilisent un DNS externe chiffré, ou le routage IPv6 et la politique de pare-feu ne correspondent pas à la réponse. Vérifiez les dépendances partagées telles que le DNS, la MTU, l’identité, l’état du pare-feu, la latence du stockage et les sessions mises en cache avant d’attribuer la responsabilité à l’une ou l’autre branche principale.
EXCEPTION : supprimez la surcharge AAAA incorrecte, restaurez un jeu de réponses accessibles et corrigez la publication du résolveur ainsi que le routage IPv6 avant de le réactiver. N’élargissez pas les privilèges, ne supprimez pas les données sources, n’affaiblissez pas la sécurité du transport et ne remplacez pas le stockage fonctionnel tant qu’une observation reproductible n’a pas identifié la limite défaillante.
Ne conserver la conception qu’après une vérification adaptée à la restauration
Appliquez uniquement l’action correspondant à la branche observée, puis relancez la charge de travail d’origine. Ne conservez la conception que lorsque chaque réseau reçoit la famille d’adresses prévue et atteint le même service avec certificat, sans hairpinning public, pendant deux cycles de vie pertinents et sous la charge simultanée attendue.
Utilisez le DNS split-horizon pour vérifier le workflow dépendant le plus proche. Son comportement en matière d’accès, de temps de réponse et de récupération doit rester inchangé pendant l’activation de la nouvelle conception.
Arrêtez-vous et revenez à l’état enregistré si l’enregistrement AAAA divulgue une adresse publique ou obsolète, si les clients utilisent un DNS externe chiffré, ou si le routage IPv6 et la politique de pare-feu ne correspondent pas à la réponse. Transmettez les horodatages, les versions exactes, les preuves liées aux routes ou aux montages et la reproduction la plus réduite possible au lieu d’ajouter une nouvelle solution de contournement.
Comparez le résultat aux règles de pare-feu IPv6 afin que le risque ne soit pas simplement déplacé vers une autre couche réseau, d’identité, de sauvegarde ou de stockage.
Pour un DNS split-horizon double pile, la réponse qualifiée est donc le jugement initial, et non un oui inconditionnel. L’état observable de réussite constitue la ligne d’acceptation ; l’état d’échec constitue la ligne de retour arrière.
FAQ
Un enregistrement A peut-il fonctionner alors que l’enregistrement AAAA fait échouer l’application ?
Oui. De nombreux clients privilégient IPv6, de sorte qu’un chemin AAAA défaillant peut échouer avant que l’IPv4 ne soit essayée.
Le DNS sécurisé du navigateur ignorera-t-il le routeur ?
C’est possible. Confirmez le résolveur effectif du client et définissez une politique pour le DNS chiffré sur les appareils gérés.
Le réseau IPv6 interne doit-il utiliser des adresses ULA ou globales ?
Les deux peuvent fonctionner lorsque le routage, le DNS, le pare-feu et les noms des certificats sont cohérents ; testez le chemin réel du client.
Produits recommandés
Assistance et conseils
Plus à lire
Une galerie auto-hébergée peut-elle préserver l’association des Live Photos Apple ?
Une décision conditionnelle concernant un serveur personnel pour l’association des Live Photos Apple, avec des tests contrôlés, l’interprétation des résultats, une procédure de retour...
Pouvez-vous importer Google Takeout et les sauvegardes de téléphone dans une seule photothèque ?
Une décision conditionnelle concernant un serveur domestique pour l’importation groupée de photos, avec des tests contrôlés, l’interprétation des résultats, un retour en arrière et...
Immich peut-il utiliser une bibliothèque externe sans prendre possession des fichiers ?
Une décision conditionnelle pour serveur personnel concernant la propriété des bibliothèques externes d’Immich, avec des tests contrôlés, l’interprétation des résultats, un retour en arrière...
