J'ai ajouté un deuxième serveur DNS à la maison et cela a résolu des problèmes qui n'avaient rien à voir avec Internet

Pour le meilleur ou pour le pire, les pannes DNS ressemblent à un problème Internet. Je veux dire, si le site Web ne se charge pas, il s'agit en quelque sorte d'un problème avec votre connexion Internet, mais pas de la même manière que lorsque votre FAI tombe en panne, par exemple. Avec les échecs DNS, tout le reste pourrait être parfait, mais les sites Web auront du mal.

J'ai finalement compris quel était mon problème : le véritable point faible était le serveur DNS que j'avais délibérément placé en plein milieu de mon réseau. Je pensais que je faisais la bonne chose, mais je ne pouvais pas me tromper davantage.

Le DNS était impliqué dans bien plus de choses sur mon réseau domestique que je ne le pensais

Les noms locaux doivent encore être résolus

Le problème avec le DNS, et c'est une chose à laquelle beaucoup d'entre nous n'y pensent pas vraiment, c'est qu'il n'entre pas en jeu uniquement lorsque nous essayons d'accéder à quelque chose sur Internet. C'était le cas pour moi aussi, et ce que je ne savais pas à l'époque, c'est que toute cette situation m'enverrait dans une joyeuse quête de dépannage réseau.

J'utilise également des noms d'hôte pour les appareils et les services de mon réseau local, et ces noms doivent encore être traduits en adresses IP pour que mon PC sache quoi faire de ce trafic. Ainsi, mon NAS pourrait être assis là, se sentant bien, Ethernet pourrait fonctionner correctement, et pourtant essayer de l'atteindre par nom d'hôte donnerait l'impression qu'il est hors ligne. C'était ennuyeux, et au début, j'ai blâmé mon FAI, puis mon NAS ou la connexion à celui-ci. Mais il y avait une distinction importante.

Étant donné que je pouvais accéder au service directement via son adresse IP, mais qu'elle avait disparu lorsque j'ai essayé d'utiliser son nom, le chemin réseau était probablement correct (ce qui a pris un peu de temps à comprendre). Cependant, la résolution du nom était le problème.

Et comme j'avais chargé un résolveur DNS local de répondre à ces requêtes, des problèmes avec ce serveur pourraient se répercuter sur n'importe quel appareil qui y était connecté. Tout est devenu assez ambigu, mais au final, c’est parce qu’ils dépendaient tous de la même infrastructure que j’ai complètement sous-estimé.

J'avais accidentellement construit un point de défaillance unique

Mon routeur pourrait fonctionner correctement alors que le DNS était mort

Ce résolveur DNS que j'ai configuré pour moi-même a été mis en place dans le but d'avoir plus de contrôle sur mon réseau. Compte tenu de mes divers problèmes avec mon FAI, j’ai tendance à préférer avoir plus de contrôle sur les choses plutôt que de ne rien faire. Malheureusement, dans mes tendances de contrôle, j'ai également fait dépendre chaque appareil de ce réseau de la disponibilité d'une seule machine.

Tant que le résolveur était opérationnel, tout allait bien. Mais si quelque chose tournait mal, mon routeur pourrait toujours acheminer le trafic et mon Internet pourrait fonctionner, mais tout ce qui nécessitait une recherche DNS était en ruine.

Les symptômes de ce problème (probablement assez spécialisé, j'imagine) sont assez ambigus. Le principal problème était le chargement lent ou le refus de chargement de diverses applications, sites et services locaux. Le redémarrage de l'appareil n'aiderait pas, de la même manière que le redémarrage d'un routeur n'aiderait pas toujours, car le problème sous-jacent était toujours là.

Le deuxième serveur n'attend pas nécessairement son tour

« Principal » et « sauvegarde » sont des étiquettes pratiques, et non une règle universelle

À ce stade, l’ajout d’un deuxième serveur DNS commençait à sembler un choix évident. Si le premier résolveur me laissait tomber, le second passerait simplement à la vitesse supérieure et prendrait le relais, n'est-ce pas ?

Théoriquement.

Nommer ces éléments « primaire » et « secondaire » donne l'impression que l'un d'eux fait tout le travail et que le second reste assis, ne faisant rien jusqu'à ce que cela soit nécessaire, mais les clients ne gèrent pas tous aussi bien plusieurs serveurs DNS. Par exemple, Windows peut passer à un autre serveur DNS configuré lorsque le premier ne répond pas. Il peut également changer quel résolveur est le « principal » en fonction de la réactivité.

Cela se résume donc au fait que ce deuxième serveur DNS n’était pas vraiment secondaire ; c'était plutôt adjacent, ce qui causait quelques problèmes. Il devait connaître les mêmes noms d’hôtes locaux et fournir le même type de réponses que le premier.

Vous pouvez prouver le problème sans deviner

Tester les noms et adresses séparément

Tout cela était frustrant, je ne vais pas mentir, mais un test assez simple m'a donné les réponses dont j'avais besoin. L'objectif était de séparer la connectivité de base de la résolution de noms.

Comme mentionné ci-dessus, si un service local répondait lorsque j'ai entré son adresse IP mais ne se chargeait pas en fonction du nom d'hôte, c'est un signe assez fort que vous pourriez être confronté à ce problème. Une fois que j'ai compris cela, j'ai pu interroger directement le DNS et voir si le résolveur renvoyait réellement une réponse.

Sous Windows, tout ce dont vous avez besoin, ce sont des outils comme nslookup et Resolve-DnsName. Vous pouvez diriger la requête vers un serveur DNS spécifique, ce qui vous permet de tester indépendamment votre résolveur d'origine et le nouveau, puis de comparer les enregistrements locaux. Une fois que les deux résolveurs répondent correctement, mettez le premier hors ligne et répétez une recherche normale. Tout va bien ? Cela vous indique que votre deuxième serveur assure réellement la redondance.

Mon deuxième serveur DNS devait être véritablement indépendant

Deux adresses IP ne servent à rien si une seule panne tue les deux

Il y a encore un piège ici, bien sûr. En effet, même si vous disposez de deux adresses de serveur DNS, vous n'avez peut-être toujours pas de redondance intégrée.

Tant que les deux résolveurs se trouvent sur le même appareil, leur sort est lié audit appareil. Dites que vous le redémarrez ou qu'il tombe en panne… les deux résolveurs aussi. Cela rend le concept un peu inutile, car vous n'avez pas la sécurité intégrée que vous essayiez de mettre en place en premier lieu.

Pour moi, la solution était que le deuxième résolveur devait vivre ailleurs, avec sa propre adresse IP, avec les mêmes enregistrements locaux.

Les échecs ont commencé à avoir un sens une fois que j'ai changé d'état d'esprit

Honnêtement, comprendre que le DNS n'est pas nécessairement simplement une question de « chargement ou non du site Web » a changé la donne. Mon résolveur DNS local est devenu un élément essentiel de mon réseau, et je l'ai toujours sous-estimé et ne l'ai pas traité comme un point de défaillance important. Rapide à blâmer à peu près tout le reste, j'ai passé plus de temps à résoudre ce problème que nécessaire.