Tailscale MagicDNS fonctionne, mais nslookup échoue sous macOS

Sur un Mac, ping résout un nom de machine tailnet tandis que nslookup renvoie un échec, et les deux commandes disent la vérité. Les applications résolvent via le résolveur système, que Tailscale configure par interface, tandis que nslookup et host lisent un fichier statique que MagicDNS ne touche jamais. Les deux chemins peuvent diverger sans qu’un seul paquet ne se perde. Déterminez quel chemin votre application en échec a emprunté avant de modifier un réglage DNS.

Deux chemins de résolution, deux réponses différentes

Le trafic des applications sous macOS passe par le résolveur système, et les entrées de résolveur limitées par interface décident quel serveur répond pour quel domaine. Tailscale y installe son entrée MagicDNS, c’est pourquoi Safari et ssh trouvent les noms tailnet. nslookup, host et dig lisent plutôt /etc/resolv.conf ou prennent un serveur sur la ligne de commande, et ce fichier nomme généralement encore le routeur ou un serveur de bureau. Un nom tailnet envoyé à ce fichier n’a aucune réponse faisant autorité qui l’attende, donc l’outil signale un échec tandis que le chemin système réussit.

Aucun des deux outils ne se comporte mal. Ils interrogent des serveurs différents, et un seul de ces serveurs connaît votre tailnet.

Testez le même nom via le chemin système

Utilisez l’appel de recherche du système comme premier test, puis comparez-le à une requête adressée directement au résolveur MagicDNS. Gardez l’orthographe identique dans les deux, y compris le domaine tailnet, car un nom court et un nom pleinement qualifié sont des questions différentes avec des réponses différentes.

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

Ces trois sorties répondent à trois questions : ce que le système renvoie, quels résolveurs sont configurés pour quels domaines et ce que MagicDNS lui-même sait. Un nom présent dans la deuxième et la troisième mais absent de la première indique une configuration locale et non le tailnet.

Une fois le nom résolu, testez le service

Une réponse DNS correcte prouve seulement qu’un nom correspond à une adresse. Le service derrière peut être arrêté, le port peut être filtré par une règle d’accès et un certificat peut nommer un hôte différent de celui que vous avez saisi.

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

Conservez le texte d’erreur d’origine, car un avertissement de certificat, un délai de connexion dépassé et un nom introuvable mènent chacun ailleurs. Changer les serveurs de noms répare le troisième et fait perdre un après-midi sur les deux premiers.

MagicDNS ne remplace pas le DNS de bureau

Un nom dans une zone de bureau n’est pas un nom d’appareil tailnet même lorsque le même client peut atteindre les deux. Quand la destination se trouve derrière un routeur de sous-réseau, le client a besoin d’un DNS fractionné pour cette zone pointant vers le résolveur interne, ce qui est un réglage différent de MagicDNS et documenté à côté de celui-ci.

Les domaines de recherche comptent aussi. Un nom court non qualifié reçoit chaque suffixe configuré ajouté dans l’ordre, si bien qu’un ordinateur portable qui vient de rejoindre un autre réseau peut résoudre via un suffixe obsolète. Vérifiez quel suffixe a été appliqué avant de déclarer la zone cassée.

Quand les deux chemins échouent, les faits du tailnet décident

Si la recherche système et la requête directe échouent toutes deux pour un appareil que vous croyez exister, le problème se situe en amont du résolveur du Mac.

Confirmez le nom de la machine et le domaine tailnet dans la console d’administration, confirmez que l’appareil est en ligne et approuvé, et confirmez que les réglages DNS du client n’ont pas été désactivés localement. Un appareil hors ligne conserve son nom et n’a simplement aucune adresse à renvoyer.

Choisissez ensuite selon les preuves. Un nom qui résout sur le chemin système et échoue dans nslookup est une différence de chemin d’outil ; un nom qui résout tandis que le service refuse est un problème d’accès ou de certificat ; un nom qui ne résout nulle part est un problème de tailnet ou de configuration DNS. Trois responsables, trois corrections, et la documentation MagicDNS couvre les spécificités macOS du premier cas.