Kurze interne Namen scheitern am VPN: das Suffix, das Sie nie sehen
Ein kurzer Name funktioniert nur, weil ein Suchsuffix ihn vervollständigt. Vergleichen Sie den vollständigen und den kurzen Namen, um eine Suffixlücke von einem Resolverfehler zu unterscheiden.
Der kurze Name funktionierte im Büro und scheitert am VPN, während der vollständige Name einwandfrei aufgelöst wird. Nichts ist kaputt. Ein nackter Name wie intranet ist kein vollständiger Name; der Client hängt ein Suffix aus seiner Suchliste an und fragt danach. Liefert das VPN-Profil dieses Suffix nicht, hört die vertraute Kurzform auf zu existieren.
Das ist der ganze Mythos. DNS ging nicht kaputt, die Suchrichtlinie änderte sich.
Ein nackter Name ist kein Name
Wenn Sie eine einzelne Bezeichnung eingeben, muss der Resolver entscheiden, wonach er fragt. Er versucht den Namen so, wie er angegeben wurde, und hängt dann Einträge aus der Suchliste einen nach dem anderen an, bis etwas antwortet. Unter Linux steuert resolv.conf diese Reihenfolge mit den Einstellungen search und ndots. Unter Windows leisten die Suffixliste und die Namensauflösungsrichtlinie dasselbe. Entfernen Sie das Suffix, und der Resolver hat nichts anzuhängen.
Ein funktionierender kurzer Name ist daher ein Beleg für eine Richtlinie, nicht für einen gesunden DNS-Server.
Was die Suffixliste und die Resolveradresse jeweils tun
Diese beiden werden ständig verwechselt. Die Resolveradresse sagt, wen man fragen soll; die Suffixliste sagt, nach welchem Namen gefragt wird. Ein VPN kann Ihnen einen privaten Resolver ohne Suffix geben oder ein Suffix mit dem falschen Resolver. Nur einer dieser Fehler sieht wie ein DNS-Ausfall aus.
Prüfen Sie beides getrennt, denn die Reparatur des falschen kostet ein Supportfenster.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Drei Symptome, drei verschiedene Zuständige.
Testen Sie zuerst den vollständigen Namen
Fragen Sie nach dem dokumentierten vollqualifizierten Namen des Administrators, nicht nach einer Vermutung. Ein funktionierender FQDN beweist, dass der Resolver erreichbar ist und der Eintrag existiert, was mit einer Abfrage die Hälfte der möglichen Ursachen ausschließt. Verwenden Sie ein Werkzeug, das zeigt, welcher Server geantwortet hat, damit Sie kein zwischengespeichertes Ergebnis lesen.
Halten Sie den Test privat. Interne Varianten an einen öffentlichen Resolver zu senden gibt Namen preis und prüft eine Richtlinie, die niemand beabsichtigt hat.
Wohin die Korrektur gehört
Korrigieren Sie das zuständige Profil oder das Managementsystem, das es erzeugt. Eine manuelle Änderung an der lokalen Resolverkonfiguration verschwindet meist beim erneuten Verbinden oder gilt für jedes Netzwerk, dem das Gerät beitritt, was schlimmer ist.
Untersuchen Sie unter Windows die wirksame Richtlinie statt des Kontrollkästchens, an das Sie sich erinnern. Get-DnsClientNrptPolicy zeigt die tatsächlich geltenden Namensauflösungsregeln.
Unter macOS gibt scutil --dns die Resolverkonfiguration pro bereichsbezogener Schnittstelle aus, einschließlich der Suchdomänen, die das VPN übertragen hat.
Lesen Sie unter Linux die Zeile search in /etc/resolv.conf, prüfen Sie aber, ob ein VPN-Client sie umgeschrieben hat. Wenn die Datei verwaltet wird, bearbeiten Sie die Quelle der Wahrheit statt der gerenderten Datei. Eine veraltete Zeile search aus einem früheren Netzwerk ist eine häufige Ursache.
Was Sie beim Profil aufbewahren sollten
Bewahren Sie den korrigierten vollständigen Namen, die Suffixliste und die Resolveradresse neben dem Clientprofil auf. Die nächste Person, die meldet, dass die intranet-Seite nicht erreichbar ist, kann drei bekannte Werte vergleichen, statt bei einer leeren Seite zu beginnen.
Und wenn nur die Kurzform scheitert, schreiben Sie das ins Ticket. Dieser Satz spart dem Resolver-Team einen Nachmittag.