Résumé

  • George Michaelson raconte que son secours DNS n’existait qu’en théorie ; le redémarrage du « principal » a révélé qu’il s’agissait en réalité de l’unique instance.
  • DHCP et les annonces de routeur peuvent diffuser plusieurs adresses de résolveurs, mais cette liste ne prouve ni leur conservation par les clients, ni le basculement, ni l’identité des règles locales.
  • Une preuve légère doit relier le second service actif, ses dépendances, la configuration émise, l’état vu par les appareils, l’essai de panne et le retour arrière.

Le 9 septembre, George Michaelson a décrit sur le blog d’APNIC son usage de Pi-hole et d’AdGuard pour fournir un DNS interne à son domicile. Le billet n’est pas un avis d’incident concernant les services de production d’APNIC : il précise que les opinions appartiennent à l’auteur. Son intérêt tient à un constat sans grandiloquence. Michaelson croyait disposer d’un plan de secours. Ce plan n’avait jamais été mis en œuvre. Quand il a redémarré le service qu’il pensait être le résolveur principal, les appareils dépendants ont cessé de fonctionner. Le « principal » était le seul.

Cette panne ne documente ni durée, ni topologie complète, ni traces réseau, ni conséquence de sécurité. Elle documente mieux autre chose : le moment où une intention est confondue avec un état exécutable. Un schéma peut montrer deux résolveurs alors qu’un seul processus tourne. Un routeur peut afficher deux adresses alors que certains appareils n’en ont reçu qu’une. Deux adresses peuvent être enregistrées sans que la seconde soit jamais choisie. Et un secours peut répondre aux noms ordinaires tout en ignorant les règles de blocage ou de redirection qui justifiaient l’auto-hébergement.

La défaillance précédait l’interruption

L’interruption visible commence au redémarrage. Le défaut de résilience commence plus tôt, lorsque le secours reste une idée. Toute opération de maintenance est fondée sur une représentation de l’état courant. Si l’administrateur pense qu’une solution de remplacement éprouvée existe, arrêter un endpoint paraît être une action limitée. Si cette solution n’est pas déployée, la même action devient un test grandeur nature imposé aux utilisateurs.

Michaelson énumère lui-même les dépendances : les redémarrages du DNS interrompaient d’autres fonctions du domicile ; une modification du routeur pouvait couper le Wi-Fi ; une modification des paramètres DNS du routeur touchait DHCP. Ses trois questions portent donc sur les appareils dépendants, l’adoption réelle d’un service alternatif et la possibilité de restaurer la situation antérieure.

Compter les machines ne suffit pas. Deux processus sur le même hôte partagent sa panne. Deux petits serveurs sur la même alimentation partagent la coupure. Deux adresses annoncées par le même routeur partagent son erreur de configuration. Deux installations copiées depuis le même fichier fautif partagent une cause administrative. Dire « indépendants » impose de nommer le défaut qui ne doit pas les supprimer ensemble.

La configuration publiée n’est pas le comportement du client

Les RFC délimitent correctement la preuve. L’option 6 de DHCPv4, décrite par la RFC 2132, transporte une liste de serveurs DNS ordonnée par préférence. La RFC 3646 fournit pour DHCPv6 une liste d’une ou plusieurs adresses IPv6 de résolveurs récursifs. La RFC 8106 permet aux annonces de routeur IPv6 de distribuer des adresses RDNSS assorties d’une durée de validité ; une valeur nulle signifie qu’elles ne doivent plus être utilisées.

Ces mécanismes établissent ce que le routeur ou le service DHCP voulait diffuser à un instant donné. Ils n’établissent pas ce qu’un téléviseur, un téléphone, un ordinateur ou un capteur a conservé et choisi. La RFC 6419 relevait d’ailleurs le peu d’uniformité entre systèmes : listes par interface ou liste globale, premier ou dernier ensemble reçu, stratégies différentes de repli. Ce texte ancien ne décrit pas les appareils du foyer de Michaelson. Il suffit cependant à montrer qu’une capture d’écran du routeur n’est pas un inventaire des clients.

La RFC 9520 ajoute une frontière importante. Un résolveur peut recevoir plusieurs adresses de services récursifs et retenter une requête vers un autre serveur ou avec un autre transport. Mais ce droit technique n’est pas une garantie de délai ou de comportement pour chaque appareil. L’échec de résolution n’est constaté que lorsqu’aucun serveur disponible ne fournit de donnée utile. Entre l’annonce de deux adresses et la réponse utile vue par l’utilisateur, il reste donc un mécanisme à observer.

Une réponse n’est pas forcément la même politique

Pi-hole et AdGuard ne servaient pas seulement de relais neutres. Le billet mentionne des redirections de certains noms connus vers des adresses non enracinées. Lors d’un basculement, le second résolveur pourrait rendre Internet de nouveau accessible tout en appliquant une autre liste de blocage ou une autre réponse locale.

Rien dans la source ne permet d’appeler cela une faille de sécurité. Cela oblige seulement à mesurer deux résultats : la résolution continue-t-elle, et le comportement local attendu est-il préservé ? Un service disponible avec des règles divergentes est un succès partiel, pas une preuve complète de résilience.

Une preuve proportionnée au domicile

L’objection la plus solide est le coût. Le billet reconnaît que la plupart des foyers tolèrent une panne occasionnelle et n’ont pas besoin d’une architecture d’entreprise. Maintenir deux services, synchroniser les règles, séparer les dépendances et tester plusieurs appareils peut être excessif.

La réponse tient sur une note de maintenance. Indiquer les résolveurs A et B, leur hôte et leurs dépendances communes ; conserver les adresses et durées annoncées par DHCPv4, DHCPv6 ou RDNSS ; vérifier quelques appareils réellement différents ; retirer brièvement le résolveur préféré ; interroger un nom ordinaire et un nom soumis à une règle locale ; noter, lorsque c’est observable, le serveur utilisé et le délai de retour ; enfin restaurer l’ancien état.

Cet essai ne couvre ni tous les appareils ni toutes les pannes. Il clôt un cas limité et rend visibles les angles morts. Un projet devient un secours quand le service alternatif s’exécute. Il devient une résilience quand les clients peuvent l’employer. Il devient maintenable quand l’administrateur sait revenir à l’état précédent.

Sources