Le DNS fractionné peut-il résoudre un problème d’application auto-hébergée qui ne fonctionne qu’à l’intérieur de votre domicile ?

Oui, le DNS fractionné peut résoudre une défaillance interne uniquement lorsque le nom d'hôte public doit résoudre une adresse locale différente à la maison.

Une application auto-hébergée peut fonctionner avec les données mobiles car le DNS public pointe vers l'adresse WAN domestique, tandis que les appareils à l'intérieur du LAN échouent parce que le routeur ne peut pas faire un hairpin de cette connexion via la règle NAT publique. Le DNS fractionné évite cette boucle en renvoyant l'adresse locale du reverse-proxy ou de l'application aux clients domestiques, mais il ne réussit que lorsque le même nom d'hôte, certificat, route proxy et URL de base de l'application restent valides sur les deux chemins.

Vérifiez d'abord que le nom public fonctionne depuis l'extérieur

Testez l'URL exacte de l'application depuis les données mobiles ou un autre réseau externe. Confirmez la résolution DNS, TLS, le routage du reverse-proxy, la connexion, les redirections et la fonction de l'application qui échoue actuellement à l'intérieur de la maison.

Tailscale décrit le DNS fractionné comme un moyen de fournir aux clients des réponses DNS différentes selon le contexte plutôt que de forcer les utilisateurs internes et externes à passer par une route identique.

Si l'application échoue également à l'extérieur, le DNS fractionné n'est pas la première réparation à effectuer. Corrigez le DNS public, le tunnel ou le transfert de port, le routage proxy, TLS ou la configuration de l'application avant de créer une seconde réponse qui pourrait masquer la faute initiale.

Vérifiez si la défaillance interne est due au Hairpin NAT

Depuis un client domestique, interrogez le nom d'hôte public et enregistrez l'adresse retournée. Si elle résout à l'IP publique domestique, vérifiez si le routeur supporte le NAT loopback ou hairpin NAT pour ce service redirigé.

Un fil de dépannage Level1Techs recommande une substitution DNS locale qui pointe le domaine vers l'adresse du serveur interne lorsque le hairpin NAT est peu fiable.

Comparez l'échec du nom public avec l'accès direct à l'adresse locale du reverse-proxy. Si l'accès local direct atteint le proxy ou l'application prévue, tandis que l'IP publique échoue uniquement de l'intérieur, le DNS fractionné est une solution adaptée.

Dirigez la réponse interne vers le même point d'entrée logique

Créez un enregistrement DNS interne pour le nom d'hôte public existant, mais pointez-le vers l'adresse LAN du reverse proxy ou du point d'entrée local contrôlé. Évitez de pointer directement vers un backend lorsque les utilisateurs externes passent normalement par le proxy.

Une comparaison du DNS fractionné explique que les clients locaux peuvent résoudre le même domaine vers une adresse interne privée tandis que les clients externes continuent de recevoir l'adresse publique.

Conserver les deux chemins sur le même proxy préserve le routage basé sur le nom d'hôte, la politique d'accès, les en-têtes et les certificats. Contourner le proxy pour les clients domestiques peut charger la page mais casser l'authentification, les callbacks, WebSockets ou les contrôles de sécurité qui existent uniquement au niveau du proxy.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez que chaque client requis utilise le résolveur interne

Vérifiez le serveur DNS utilisé par les téléphones, ordinateurs portables, téléviseurs, conteneurs et clients VPN qui doivent recevoir la réponse interne. Le DNS sécurisé du navigateur, le DNS privé mobile, un résolveur VPN ou un serveur DNS public codé en dur peuvent contourner le résolveur domestique.

Les conseils d'auto-hébergement sur le DNS fractionné avertissent que les pannes surviennent souvent lorsque le VPN ou le client continue d'utiliser le mauvais contexte de résolveur malgré la présence sur le réseau interne.

Interrogez directement le serveur DNS interne, puis comparez cette réponse avec la recherche normale du client. Si le serveur retourne l'adresse locale mais pas le client, corrigez la distribution DHCP DNS, le DNS chiffré, la politique VPN ou les substitutions client avant de modifier à nouveau l'enregistrement.

Conservez le même nom d'hôte pour TLS et les callbacks d'application

Accédez à l'application via son domaine normal après activation de l'enregistrement interne. Ne le remplacez pas par un favori vers l'IP privée, car les certificats HTTPS et les routes du reverse-proxy sont généralement liés au nom d'hôte.

Le chemin interne doit également préserver l'URL de base publique de l'application, l'URI de redirection OAuth, l'adresse webhook et les en-têtes transférés. Le DNS fractionné modifie l'adresse de destination, pas le nom d'hôte que le navigateur ou le fournisseur doit utiliser.

Si l'application redirige vers l'IP publique, génère un nom d'hôte interne ou rejette l'en-tête host, corrigez les paramètres du proxy et de l'URL de l'application. Le DNS seul ne peut pas réparer un service configuré avec des identités incohérentes.

Conservez le DNS fractionné uniquement lorsque les deux chemins restent prévisibles

Testez depuis le Wi-Fi domestique, le Wi-Fi invité, le VPN, les données mobiles et un appareil utilisant le DNS privé. Confirmez que chaque client reçoit l'adresse prévue et atteint la même identité d'application.

Le guide ZimaSpace expliquant pourquoi un cloud privé fonctionne sur un seul réseau fournit le symptôme inverse et aide à vérifier que les deux vues DNS restent intentionnellement différentes.

Le DNS fractionné est la bonne solution lorsqu'il supprime une boucle publique cassée tout en préservant le même domaine, certificat TLS, route proxy et comportement de l'application. Utilisez plutôt le hairpin NAT lorsque le routeur le gère de manière fiable et que maintenir deux vues DNS ajouterait plus de risques que de valeur.