Pourquoi MagicDNS résout les appareils mais pas les noms d’hôte du bureau

MagicDNS attribue à chaque appareil d’un tailnet un nom dérivé du nom de sa machine et du domaine DNS du tailnet. Ce nom est créé par Tailscale et il y est répondu le long du chemin du résolveur de Tailscale. Un nom d’hôte de bureau comme files.office.example appartient à une zone que Tailscale n’a jamais écrite, donc renommer un appareil ne peut pas le créer. Les deux espaces de noms coexistent ; ils ont simplement des propriétaires différents.

Ce mécanisme se cache derrière un rapport très courant : l’hôte Tailscale répond, et le serveur de fichiers renvoie toujours une erreur de résolution.

Deux espaces de noms, deux propriétaires

Le nom d’un appareil est généré à partir du nom d’hôte de la machine elle-même, les collisions sont résolues par Tailscale, et le résultat vit sous le domaine du tailnet. La zone de bureau est entretenue par celui qui exploite le résolveur du bureau, avec des enregistrements créés par un administrateur ou par enregistrement dynamique. Les noms courts masquent la différence : files peut être une extension de suffixe de recherche à laquelle répond le DNS du bureau, un appareil du tailnet, ou rien du tout. Interroger le nom complet montre quel système a réellement répondu.

Changer le nom de machine du routeur de sous-réseau ne fait rien pour la zone du bureau. Cela renomme un appareil Tailscale et laisse l’enregistrement du serveur du bureau intact, c’est pourquoi renommer puis réessayer ne converge jamais.

Dirigez la zone du bureau vers son résolveur

Le DNS scindé de Tailscale envoie les requêtes pour les domaines choisis vers un serveur de noms que vous spécifiez, et tout le reste suit la politique restante. Ajoutez le domaine que le résolveur du bureau dessert réellement, pas le suffixe de recherche que vous tapez par hasard. Un suffixe de recherche indique au client quoi ajouter ; il n’indique pas au résolveur où chercher. Ces deux réglages se ressemblent dans une console et se comportent complètement différemment.

Un serveur de noms restreint doit être autoritaire pour le domaine qui lui est associé, sinon la réponse sera un renvoi plutôt qu’une adresse.

La joignabilité vient avant la résolution

Le client doit aussi atteindre ce serveur de noms. Pour un résolveur sur un LAN privé, la route du sous-réseau doit être annoncée et acceptée, la politique d’accès doit autoriser la requête, et un chemin de retour doit exister. Une adresse DNS correcte dans la console d’administration prouve seulement que la configuration a été enregistrée. Si les paquets ne peuvent pas atteindre le résolveur, le symptôme est un dépassement de délai, qui se distingue d’une réponse autoritaire indiquant qu’un tel enregistrement n’existe pas.

Cette différence est diagnostique. Un dépassement de délai pointe vers le routage ou la politique, tandis qu’une réponse négative immédiate pointe vers l’enregistrement ou la zone. Lisez laquelle vous obtenez avant de modifier un réglage DNS.

Séparez la défaillance du nom de la défaillance du service

Si la ressource répond à son adresse privée mais pas par nom d’hôte, l’enquête reste sur le DNS. Si aucune des deux ne fonctionne, corrigez d’abord le routage ou le service, car un nom qui résout vers une adresse injoignable n’est pas un progrès. Interrogez le nom complet et notez quel serveur a répondu. Sur macOS certains outils en ligne de commande suivent un chemin différent des applications ordinaires, donc un terminal dig et un navigateur peuvent être en désaccord sur le même nom.

Répétez le test avec un nœud de sortie sélectionné si c’est le mode normal de l’appareil. La gestion DNS du nœud de sortie diffère de la configuration sans nœud de sortie, et tester dans un seul mode peut manquer la défaillance que les utilisateurs voient réellement.

Notez la zone, l’adresse du résolveur et la route qui transporte la requête. Ces trois éléments expliquent la plupart des surprises de MagicDNS sans un autre cycle de renommage.