Comment vérifier si le DNS est à l’origine des échecs de connexion à Home Assistant

Le DNS est fortement suspect lorsque Home Assistant peut atteindre un service par adresse IP, mais échoue par nom d’hôte, lorsque les erreurs mentionnent explicitement la résolution de noms ou des délais d’attente DNS, ou lorsque le même nom d’hôte se comporte différemment depuis différents réseaux. Un simple message générique « échec de la connexion » ne suffit pas à le confirmer.

Testez le DNS depuis la machine et le chemin réseau qui échouent réellement. Le fait qu’un ordinateur portable résolve correctement un nom d’hôte ne prouve pas que l’hôte Home Assistant, le conteneur, l’application mobile ou le résolveur local obtient la même réponse.

Commencez par le nom d’hôte exact indiqué dans l’erreur

Lisez le journal Home Assistant ou l’erreur de l’application Companion et notez le nom d’hôte exact, pas seulement le nom de l’intégration. Un refus de connexion, une erreur TLS, un délai d’attente et un échec de recherche DNS relèvent de couches différentes.

Les recommandations actuelles de Home Assistant en matière de connexion indiquent que les routeurs, le DNS, le DHCP, les appareils injoignables et les services indisponibles sont des causes courantes d’erreurs de connexion. La formulation du journal devrait vous aider à déterminer quelle piste tester ensuite.

Si l’erreur indique déjà « nom ou service inconnu », « échec temporaire de la résolution de noms » ou un délai d’attente DNS, passez directement aux tests du résolveur. Si elle indique « connexion refusée », le DNS a peut-être déjà fonctionné et le service distant ou le port est alors plus probablement en cause.

Effectuez les tests DNS depuis le chemin Home Assistant concerné

Utilisez dig ou nslookup depuis l’hôte Home Assistant, le conteneur ou un autre système utilisant le même résolveur. Comparez les adresses renvoyées avec celles que le nom d’hôte est censé représenter.

Le guide de dépannage de Companion recommande d’utiliser dig et nslookup lorsque Home Assistant signale un délai d’attente lors de la recherche d’un nom d’hôte. Une recherche échouant depuis la machine concernée constitue un indice bien plus solide qu’une recherche réussie depuis un autre client.

Répétez le test plusieurs fois si l’échec est intermittent. Un résolveur qui réussit une fois, puis expire toutes les dix requêtes, peut tout de même rendre les intégrations peu fiables.

Comparez l’accessibilité par nom d’hôte et par adresse IP directe

Lorsque cela est sûr et pertinent pour le service, testez la destination avec son adresse IP connue. Si le chemin par IP fonctionne de manière répétée alors que celui par nom d’hôte échoue, les éléments disponibles orientent vers le DNS ou vers un routage propre au nom d’hôte.

Ne considérez toutefois pas cela comme une preuve absolue pour les services HTTPS ou utilisant des hôtes virtuels. Les certificats TLS, les reverse proxies et les en-têtes Host peuvent exiger le nom d’hôte même lorsque l’adresse IP sous-jacente est accessible.

Le guide ZimaSpace consacré aux échecs DNS intermittents dans les applications auto-hébergées approfondit ce test en distinguant la latence du résolveur, les réponses obsolètes, le DNS fractionné et les chemins de résolution propres aux conteneurs.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez les réponses A et AAAA

Un nom d’hôte peut être correctement résolu tout en sélectionnant une famille d’adresses inutilisable. Par exemple, un enregistrement AAAA peut exister alors que le routage IPv6 est défaillant, ce qui entraîne de longues attentes avant le basculement vers IPv4.

Les diagnostics DNS de Home Assistant signalent explicitement les défaillances du serveur DNS et la gestion incorrecte des requêtes A et AAAA. Sous Home Assistant OS, ces mêmes diagnostics indiquent l’état du résolveur et les options de DNS de secours.

Comparez séparément les résultats A et AAAA, puis testez la connectivité avec la famille d’adresses renvoyée. Ne désactivez pas globalement IPv6 simplement parce qu’un nom d’hôte pose problème ; identifiez d’abord le chemin défaillant.

Comparez les DNS internes et externes lorsque l’échec dépend de l’emplacement

Si un nom d’hôte Home Assistant fonctionne en données mobiles, mais pas sur le Wi-Fi domestique, ou fonctionne à l’intérieur du réseau local, mais pas à distance, comparez la réponse DNS depuis ces deux emplacements. Le DNS fractionné peut volontairement renvoyer une adresse privée à l’intérieur et une adresse publique ou de tunnel à l’extérieur.

Vérifiez les redirections DNS du routeur, les réécritures Pi-hole ou AdGuard, les noms mDNS, les domaines de recherche locaux, les enregistrements DNS publics et les caches obsolètes. Un enregistrement public correct ne peut pas corriger une redirection interne erronée, et un enregistrement LAN correct ne peut pas rendre une adresse privée accessible depuis Internet.

Modifiez une seule variable de résolution à la fois. Un résolveur public temporaire peut être utile pour diagnostiquer les noms publics, mais configurer en dur un DNS public ne résout pas le problème lorsque le nom d’hôte est censé pointer vers un service local privé.

FAQ

Si Home Assistant fonctionne par IP, mais pas par nom d’hôte, le DNS est-il forcément en cause ?

C’est un indice fort, mais pas une preuve absolue. Les certificats HTTPS, les reverse proxies, les hôtes virtuels et les règles de routage peuvent se comporter différemment lorsque vous contournez le nom d’hôte. Confirmez à la fois la réponse DNS et le chemin applicatif.

Dois-je configurer définitivement Home Assistant sur 8.8.8.8 ou 1.1.1.1 ?

Pas automatiquement. Les résolveurs publics sont utiles pour tester des noms publics, mais ils ne peuvent pas résoudre les enregistrements DNS fractionnés privés, sauf si ces enregistrements sont volontairement publiés ailleurs. Corrigez le résolveur qui doit faire autorité pour le nom défaillant.