Warum MagicDNS Geräte auflöst, aber keine Büro-Hostnamen

MagicDNS gibt jedem Gerät in einem Tailnet einen Namen, der aus seinem Maschinennamen und der DNS-Domäne des Tailnets abgeleitet ist. Dieser Name wird von Tailscale erzeugt und entlang des Resolverpfads von Tailscale beantwortet. Ein Büro-Hostname wie files.office.example gehört zu einer Zone, die Tailscale nie geschrieben hat, deshalb kann das Umbenennen eines Geräts ihn nicht erzeugen. Die beiden Namensräume bestehen nebeneinander; sie haben einfach verschiedene Eigentümer.

Dieser Mechanismus steckt hinter einer sehr häufigen Meldung: Der Tailscale-Host antwortet, und der Dateiserver liefert weiterhin einen Auflösungsfehler.

Zwei Namensräume, zwei Eigentümer

Ein Gerätename wird aus dem eigenen Hostnamen der Maschine erzeugt, Kollisionen löst Tailscale auf, und das Ergebnis lebt unter der Tailnet-Domäne. Eine Bürozone wird von demjenigen gepflegt, der den Büro-Resolver betreibt, wobei Einträge von einem Administrator oder durch dynamische Registrierung angelegt werden. Kurze Namen verbergen den Unterschied: files kann eine Suchsuffix-Erweiterung sein, die vom Büro-DNS beantwortet wird, ein Tailnet-Gerät oder gar nichts. Die Abfrage des vollständigen Namens zeigt, welches System tatsächlich geantwortet hat.

Das Ändern des Maschinennamens des Subnetz-Routers bewirkt nichts für die Bürozone. Es benennt ein Tailscale-Gerät um und lässt den Eintrag auf dem Büroserver unberührt, weshalb Umbenennen und erneuter Versuch nie zusammenfinden.

Richten Sie die Bürozone auf ihren Resolver

Das geteilte DNS von Tailscale sendet Abfragen für ausgewählte Domänen an einen von Ihnen angegebenen Namensserver, und alles andere folgt der übrigen Richtlinie. Fügen Sie die Domäne hinzu, die der Büro-Resolver tatsächlich bedient, nicht das Suchsuffix, das Sie zufällig eingeben. Ein Suchsuffix teilt dem Client mit, was anzuhängen ist; es teilt dem Resolver nicht mit, wo er nachsehen soll. Diese beiden Einstellungen sehen in einer Konsole ähnlich aus und verhalten sich völlig unterschiedlich.

Ein eingeschränkter Namensserver muss für die ihm zugeordnete Domäne autoritativ sein, sonst ist die Antwort eine Weiterleitung statt einer Adresse.

Erreichbarkeit kommt vor der Auflösung

Der Client muss diesen Namensserver auch erreichen. Für einen Resolver in einem privaten LAN muss die Subnetzroute angekündigt und akzeptiert werden, die Zugriffsrichtlinie muss die Abfrage erlauben, und es muss einen Rückweg geben. Eine korrekte DNS-Adresse in der Administrationskonsole beweist nur, dass die Konfiguration gespeichert wurde. Wenn Pakete den Resolver nicht erreichen, ist das Symptom eine Zeitüberschreitung, die anders aussieht als eine autoritative Antwort, dass kein solcher Eintrag existiert.

Dieser Unterschied ist diagnostisch. Eine Zeitüberschreitung deutet auf Routing oder Richtlinie hin, während eine sofortige negative Antwort auf den Eintrag oder die Zone deutet. Lesen Sie, welche Sie erhalten, bevor Sie eine DNS-Einstellung ändern.

Trennen Sie den Namensfehler vom Dienstfehler

Wenn die Ressource unter ihrer privaten Adresse, aber nicht unter dem Hostnamen antwortet, bleibt die Untersuchung beim DNS. Wenn keines von beiden funktioniert, beheben Sie zuerst Routing oder Dienst, denn ein Name, der zu einer unerreichbaren Adresse auflöst, ist kein Fortschritt. Fragen Sie den vollständigen Namen ab und notieren Sie, welcher Server geantwortet hat. Unter macOS nehmen einige Kommandozeilenwerkzeuge einen anderen Weg als gewöhnliche Anwendungen, sodass ein Terminal mit dig und ein Browser sich über denselben Namen uneinig sein können.

Wiederholen Sie den Test mit ausgewähltem Exit-Node, wenn das der normale Modus für das Gerät ist. Die DNS-Behandlung von Exit-Nodes unterscheidet sich von der Konfiguration ohne Exit-Node, und Tests in nur einem Modus können den Fehler verfehlen, den Benutzer tatsächlich sehen.

Notieren Sie die Zone, die Resolveradresse und die Route, die die Abfrage trägt. Diese drei erklären die meisten MagicDNS-Überraschungen ohne eine weitere Runde des Umbenennens.