Die Reihenfolge der Namensauflösung unter Windows — hosts, DNS-Cache, LLMNR/mDNS und DoH

„Die Einstellungen sind dieselben, aber nur dieser PC erreicht den internen Server nicht.“ „Im Browser öffnet es sich, aber die Geschäftsanwendung scheitert an der Namensauflösung.“ „Ich habe es in hosts eingetragen, und es greift nicht.“

Bei solchen Störungen ist zuerst festzustellen, welcher Mechanismus für diesen Namen antwortet. Windows hat mehrere Pfade: Cache, hosts, DNS-Server, LLMNR, NetBIOS und mDNS, und manche Apps nutzen einen eigenen Pfad, der von Windows getrennt ist.

Dieser Artikel gibt zuerst das Gesamtbild, ordnet die Form eines Namens und die Unterschiede der Pfade und geht dann zum konkreten Eingrenzungsverfahren. Wer sofort untersuchen muss, springt aus der folgenden Tabelle zum passenden Abschnitt.

Voraussetzungen für diesen Artikel

Der Artikel zum Paketmitschnitt behandelt die Pakete, die über die Leitung gehen, und der Artikel zu Proxys behandelt, „wessen Proxyeinstellungen gelesen werden“. Dieser Artikel behandelt den Schritt davor: „woher die Ziel-IP-Adresse kam“, geordnet anhand der Primärquellen von Microsoft.

1. Zuerst das Fazit

Drei Punkte sind festzuhalten.

• Die Namensauflösung unter Windows läuft nicht immer eine einzige Reihe der Reihe nach ab. Cache und hosts kommen zuerst, aber bei einem Single-Label-Namen laufen DNS und LLMNR/NetBT standardmäßig parallel.³⁴
• Derselbe Name liefert andere Ergebnisse, wenn die Einstellungen des PCs und der Pfad der App differieren. Suffixe, VPN, die NRPT und den integrierten Resolver des Browsers getrennt denken.⁵⁶⁷
• In der Untersuchung den genutzten Pfad einschränken und die Ergebnisse vergleichen. Cache, DNS und Link-Local mit den Schaltern von Resolve-DnsName trennen, dann mit einem Einstellungsdiff gegen einen funktionierenden PC und mit einem Mitschnitt bestätigen.⁸

Die folgende Abbildung dient als Gesamtkarte.

flowchart TB
    accTitle: Namensauflösung ist eine Schichtung
    accDescr: Eine Anfrage zur Namensauflösung geht von der API der App zum DNS-Clientdienst; Cache und hosts werden zuerst geprüft, dann der DNS-Server, und nur bei Single-Label-Namen werden LLMNR und NetBIOS versucht (standardmäßig parallel zu DNS). Bei .local-Namen ist mDNS ein zusätzlicher Pfad neben dem konfigurierten DNS. Der Browser hat einen eigenen Resolver außerhalb dieser Reihe
    app["App (getaddrinfo)"] --> svc["DNS-Clientdienst"]
    svc --> cache["Cache (einschließlich hosts)"]
    cache -->|falls fehlend| dns["DNS-Server abfragen"]
    cache -->|"falls fehlend, Single-Label-Name (standardmäßig parallel zu DNS)"| ll["LLMNR / NetBIOS"]
    svc -->|".local-Name (zusätzlicher Pfad)"| mdns["mDNS"]
    browser["Browser"] -.->|eigener Resolver, DoH| ext["Separater Pfad"]

Zuerst wird der Cache geprüft; danach laufen DNS und, bei Single-Label-Namen, LLMNR und NetBIOS parallel. Der Browser hat einen eigenen Pfad.

Im Folgenden behandeln die Kapitel 3 bis 5 „welche Schicht antwortet“, Kapitel 6 „wie die Abfrage gesendet wird“ und die Kapitel 7 und 8 „wie sich das prüfen lässt“. DoH ist eine Funktion, die den Transport zum DNS-Server auf HTTPS umstellt; sie ersetzt nicht die Reihenfolge von hosts, Cache und NRPT.⁹

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (48 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. „Namensauflösung“ ist kein einzelner Vorgang

Die App erhält nur eine Adresse oder einen Fehler zurück

Wenn eine App mit einem Namen wie www.example.com verbindet, wird Winsocks getaddrinfo aufgerufen (die Unicode-Variante ist GetAddrInfoW). Für den Namensraum NS_DNS wandelt diese Funktion den Namen über DNS, die lokale Hosts-Datei und andere Mechanismen in eine Adresse. Antworten mehrere Namensraum-Anbieter, aggregiert sie die Antworten und gibt sie zurück.¹⁰

Mit anderen Worten: Am Ergebnis, das die App erhält, ist nicht zu erkennen, welche Schicht geantwortet hat.

Auch Dns.GetHostAddresses in .NET nutzt unter Windows getaddrinfo. Für einen in hosts eingetragenen Host gibt es diese Adresse zurück, ohne einen DNS-Server zu fragen. HttpClient läuft ebenfalls auf dieser Dns-Klasse, sodass eine .NET-App, die das Ziel direkt verbindet, die Reihenfolge der Windows-Namensauflösung übernimmt.¹¹

Über einen HTTP-Proxy ändert sich der Name, der aufgelöst wird. Lokal aufgelöst wird der Name des Proxys; der Zielname wird auf der Proxy-Seite aufgelöst. Dann spielen lokales hosts, Cache, Suffixe und NRPT bei der Auflösung des Ziels keine Rolle. Welche Proxyeinstellungen gelesen werden, behandelt der Artikel zu Proxys.

2.1 Der DNS-Clientdienst legt die Reihenfolge fest

Unter getaddrinfo arbeitet der DNS-Clientdienst (Dienstname Dnscache). Die Microsoft-Dokumentation beschreibt die grundlegende Reihenfolge so.³

1. Den Cache prüfen.
2. Die Hosts-Datei prüfen.
3. Den DNS-Server abfragen.

Weil der Inhalt von hosts beim Dienststart in den Cache geladen wird, fasst dieser Artikel die ersten beiden zusammen als Schicht 1, „Cache und hosts“.⁵

Danach verzweigt der Pfad je nach Name und Richtlinien.

Die standardmäßige „intelligente Multihomed-Namensauflösung“ sendet DNS-, LLMNR- und NetBT-Abfragen parallel an alle Netzwerke. Welche Antwort übernommen wird, entscheiden die Regeln in den Abschnitten 4.3 und 5.2.⁴

Deshalb sind „wann die Abfrage gesendet wird“ und „die Priorität der zurückkommenden Antworten“ zwei verschiedene Dinge. LLMNR oder NetBT in einem Mitschnitt zu sehen heißt für sich noch nicht „DNS ist gescheitert“. Die „drei Schichten“ in diesem Artikel sind eine Gliederung zur Erklärung; sie bedeuten nicht, dass die Schichten stets zeitlich nacheinander laufen.

2.2 Was außerhalb der Reihe steht

Besonders leicht zu verwechseln sind die folgenden beiden.

Dass Edge den integrierten Client nutzt, bedeutet für sich nicht, dass sich der DNS-Server ändert. Abschnitt 6.2 trennt das von der Einstellung Sicheres DNS, die einen anderen Anbieter wählt.

3. Schicht 1 — Cache und hosts

Was auf dieser Schicht zu klären ist: welche Antworten im PC liegen bleiben. Der Cache hält nicht nur korrekte Antworten, sondern auch veraltete und Antworten „der Name existiert nicht“.

3.1 hosts wird in den Cache geladen

Die Hosts-Datei liegt unter C:\Windows\System32\drivers\etc\hosts. Beim Start des DNS-Clientdienstes werden die Zuordnungen von Name zu IP-Adresse in den Resolvercache geladen. Auch über DNS-Abfragen gewonnene Einträge bleiben für ihre TTL (Time to Live) im selben Cache.⁵

ipconfig /displaydns zeigt sowohl die aus hosts geladenen Einträge als auch die durch kürzliche DNS-Abfragen gewonnenen.¹³ Auch im Microsoft-Beispiel gilt: steht contoso.com in hosts, gibt Resolve-DnsName contoso.com diese Adresse zurück und es fließt kein DNS-Verkehr.³

Wie das Fehlen von DNS-Paketen zu lesen ist

Löst man einen FQDN ohne DoH oder DoT auf, die Namensauflösung gelingt, und auf Port 53 geht keine Abfrage, antworten vermutlich Cache oder hosts. Zuerst sind jedoch die folgenden anderen Pfade auszuschließen.

Nicht allein wegen „auf Port 53 ist nichts“ auf „Cache“ schließen; auch die Pfade ansehen, die in Frage kommen. Eine einzige Testzeile in hosts auf einem Entwicklungsrechner kann eine Untersuchung in die Irre führen.

Das Bearbeiten von hosts erfordert Administratorrechte, und Sicherheitsprodukte können die Änderung erkennen. Ein Design, das den Betrieb einer Geschäftsanwendung von hosts abhängig macht, ist zu vermeiden.

3.2 Auch negative Antworten werden zwischengespeichert

„Nicht gefunden“ ist ebenfalls eine der Antworten, die in den Cache gehen. Der DNS-Client speichert negative Antworten ebenso wie positive.⁵

Zeigt ipconfig /displaydns für den Zielnamen „Name does not exist“, liegt eine negative Antwort des DNS-Servers auf dem Client. Das Microsoft-Verfahren weist an, sie mit ipconfig /flushdns zu verwerfen.¹⁴¹³

Die Haltezeit des negativen Caches ist MaxNegativeCacheTtl unter HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, der Standard ist 5 Sekunden.¹⁵ Deshalb kann ein PC noch einige Sekunden lang Fehler liefern, unmittelbar nachdem ein Eintrag in DNS ergänzt wurde.

3.3 TTL und „nur manche PCs sind veraltet“

Auch positive Antworten bleiben für ihre TTL. Ein PC, der den Namen vor der Änderung der Server-IP aufgelöst hat, nutzt die alte Antwort weiter, während ein PC, der ihn nach der Änderung erstmals auflöst, die neue erhält. Selbst mit demselben DNS-Server unterscheidet sich das Ergebnis, wenn der Zeitpunkt der Abfrage ein anderer ist.⁵

Clear-DnsClientCache verhält sich wie ipconfig /flushdns und löscht den gesamten Cacheinhalt einschließlich negativer Antworten.¹⁶ Mit Get-DnsClientCache lässt sich der Cache als Objekte holen und Eintragstyp sowie verbleibende TTL prüfen.¹⁷

# Ist ein bestimmter Name im Cache, und wie viele Sekunden TTL bleiben?
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# Inhalt von hosts und Cache gemeinsam prüfen
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# Cache verwerfen (einschließlich negativer Antworten)
Clear-DnsClientCache

Wird auf Schicht 1 eine Antwort gefunden, ist diese Abfrage entschieden, bevor sie den DNS-Server erreicht. Es bleibt jedoch die Möglichkeit, dass eine falsche Antwort ursprünglich vom DNS-Server gelernt wurde. Nicht beim Leeren stehen bleiben; auch die in Schritt 3 von Kapitel 8 neu geholte Antwort prüfen.

4. Schicht 2 — Abfrage des DNS-Servers

Hat Schicht 1 keine Antwort, geht die Auflösung zu DNS. Hier getrennt denken: welcher Name, an welchen Server, zu welchem Zeitpunkt.

4.1 Single-Label-Namen und Suffixe

Zuerst die Form des Namens prüfen, den die App übergeben hat.⁵

Ein Suffix ist der Domänenteil, der hinter einen kurzen Namen gesetzt wird. corp.example.com an app01 anzufügen macht den abgefragten Namen zu app01.corp.example.com.

Wenn eine Suchliste existiert

Suffixe aus der DNS-Suffixsuchliste werden von oben der Reihe nach angefügt, und der Name wird mit abschließendem Punkt gesendet. Sobald eine Suchliste konfiguriert ist, wird nur diese Liste verwendet. Primärsuffix, verbindungsspezifische Suffixe und Namensdevolution kommen nicht zum Einsatz.¹⁸

Wenn keine Suchliste existiert

Das primäre DNS-Suffix wird angefügt. Ist Namensdevolution aktiv, fällt nach jedem Fehlschlag die linkeste Bezeichnung weg und der Name wird erneut versucht; etwa von www.test.contoso.com zu www.contoso.com. Hat ein Adapter ein verbindungsspezifisches DNS-Suffix, wird auch das angefügt und gesendet.⁵

Deshalb expandiert dasselbe server01 anders in einer Umgebung, in der die Gruppenrichtlinie eine Suchliste verteilt, und in einer Umgebung, in der die Domänenmitgliedschaft ein Primärsuffix liefert.

Eine lange Liste verlängert auch die Wartezeit

Liegt das richtige Suffix weit hinten in der Liste, sammelt sich die Abfragezeit, bis es erreicht ist. Microsoft erklärt diese Verzögerung ebenfalls am Beispiel von sechs Suffixen. Um nur eine bestimmte Expansion zu versuchen, einen abschließenden Punkt anfügen, etwa internal.contoso.com..³

# Globale Einstellungen: Suchliste und Devolution
Get-DnsClientGlobalSetting

# Pro Schnittstelle: verbindungsspezifisches Suffix und Registrierungseinstellungen
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# DNS-Server pro Schnittstelle (IPv4 und IPv6)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSetting liefert die globalen Einstellungen wie Suchliste und ob und bis zu welcher Stufe Devolution aktiv ist; Get-DnsClient liefert die Einstellungen pro Schnittstelle.¹⁹²⁰

4.2 Die Reihenfolge mehrerer DNS-Server und Timeouts

Wenn „es nicht scheitert, aber mehrere Sekunden Wartezeit entstehen“, Neuübertragungen an einen nicht antwortenden DNS-Server verdächtigen. Für die auf einer NIC konfigurierten DNS-Server sieht der standardmäßige Neuübertragungszeitpunkt so aus.²¹

Das ist die Tabelle für den Fall ohne Antwort. Insbesondere die folgenden beiden nicht verwechseln.

Wenn „wir einen davon gestoppt haben, aber es wechselt nicht“, und ein Server mit alter Zone weiterläuft und negative Antworten liefert, geht die Auflösung nicht zum nächsten Server.²¹

Der vierte und spätere Server wird erst nach 4 Sekunden erreicht

Liegt der Server, der antworten kann, an vierter oder späterer Stelle in der Liste, vergehen nach der ersten Abfrage mindestens 4 Sekunden. Ist die Frist der App kürzer, scheitert sie bereits an der Namensauflösung. Um die Abfrage früher hinauszuschicken, müsste dieser Server unter die ersten drei rücken; die grundlegende Abhilfe ist jedoch, die unerreichbaren Server davor zu reparieren oder aus den Einstellungen zu nehmen. Auch den Timeout auf der App-Seite überprüfen.²¹

Auch im Microsoft-Beispiel braucht eine Konfiguration, in der nur einer von vier Servern erreichbar ist, etwa 4 Sekunden bis zum Abschluss. Die Dauer lässt sich mit Measure-Command messen, und dasselbe Dokument behandelt unter 1 Sekunde als akzeptabel.³

# Einen bestimmten Server direkt nur per DNS fragen und die Dauer in Millisekunden erhalten
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

Weil dieser Befehl den Server festlegt, misst er die Antwortzeit allein dieses Servers. Die Verzögerung, bis der vierte Listeneintrag erreicht ist, prüft man mit einer Abfrage ohne -Server oder mit einem Mitschnitt dieser Abfrage.

Der DNS-Client rückt schneller antwortende Server nach oben, merkt sich nicht antwortende Server und versucht sie periodisch erneut. Der Anfangstimeout wird außerdem anhand der bisherigen Leistung im Bereich 25 bis 1.000 Millisekunden angepasst. Die Tabelle oben ist das standardmäßige Gerüst; deshalb weichen Messungen davon ab.⁵

4.3 Mehrere NICs und „intelligente Multihomed-Namensauflösung“

Auf einem PC mit Kabel und WLAN oder einem PC, dem ein VPN-Adapter hinzukommt, nicht nur die Liste der DNS-Server prüfen, sondern auch die Abfrage über Netzwerke hinweg und die Auswahl der Antwort.

Neuübertragung an mehrere Adapter

Im Microsoft-Abfrageverfahren geht die Abfrage an den ersten DNS-Server des bevorzugten Adapters, mit 1 Sekunde Wartezeit. Kommt keine Antwort, geht sie an den ersten Server jedes Adapters, der noch in der Kandidatenmenge ist, mit 2 Sekunden Wartezeit, und danach an alle Server aller Adapter, mit Wartezeiten von 2, 4 und 8 Sekunden. Liefert ein Server eines Adapters eine negative Antwort, werden die übrigen Server dieses Adapters aus den Kandidaten genommen.⁵

Die Richtlinie, die parallele Abfragen steuert

Die Gruppenrichtlinie „Intelligente Multihomed-Namensauflösung deaktivieren“ steuert das folgende Verhalten.⁴

Weil die Richtlinie „deaktivieren“ heißt, gilt: die Richtlinie zu aktivieren deaktiviert die Optimierung.

Ein Beispiel, in dem VPN das Ergebnis ändert

Wird ein interner Name abgefragt, liefert das DNS auf der VPN-Seite die interne Adresse, und das DNS auf der Seite des Heimrouters kann ebenfalls eine andere positive Antwort liefern: eine öffentliche Adresse unter demselben Domänennamen wie intern, oder die Adresse einer Werbe-Seite, die einen nicht existierenden Namen ersetzt, zum Beispiel.

Bei zwei positiven Antworten entscheidet die Bindungsreihenfolge über die Übernahme. Unter aktuellem Windows bestimmt die Schnittstellenmetrik diese Priorität; je kleiner das von Get-NetIPInterface gezeigte InterfaceMetric, desto höher die Priorität. Unterschiede dieser Reihenfolge von PC zu PC werden Unterschiede im Ergebnis.²²

Liefert dagegen die Heimseite eine negative Antwort, fällt dieser Adapter aus den Kandidaten und die Antwort der VPN-Seite wird genutzt.⁵ VPN-Produkte verteilen die NRPT oder „Intelligente Multihomed-Namensauflösung deaktivieren“ gerade, um diese Unterschiede zu steuern.

4.4 NRPT — das Abfrageziel je Namensraum ändern

Die NRPT (Name Resolution Policy Table, Namensauflösungsrichtlinientabelle) ist eine Tabelle, die je Namensraum wie .corp.contoso.com festlegt, welche DNS-Server zu nutzen sind, sowie die Einstellungen für DirectAccess und DNSSEC. Profile von DirectAccess und Always On VPN schreiben Regeln hinein und erzeugen Verhalten wie „nur interne Namen an das interne DNS senden“.²³⁶

Get-DnsClientNrptPolicy -Effective zeigt die tatsächlich wirksamen Regeln.

# Die tatsächlich wirksamen NRPT-Regeln
Get-DnsClientNrptPolicy -Effective

# Nur die Regeln eines bestimmten Namensraums anzeigen. -Namespace filtert nur nach dem Namespace-Attribut; es gleicht nicht gegen einen Namen ab.
# 'app01.corp.example.com' zu übergeben liefert nicht die Suffixregel für '.corp.example.com'.
# Welche Regel auf einen Namen zutrifft, ermittelt man, indem man die Regeln auflistet und selbst abgleicht, wie in Schritt 4 von Kapitel 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

Die NRPT gilt nur für Apps, die die Windows-DNS-API nutzen. Apps mit eigener DNS-Implementierung umgehen diesen Pfad. Die VPNv2-CSP-Dokumentation nennt nslookup als Beispiel und verlangt Resolve-DnsName zur Prüfung der NRPT. Der integrierte Resolver des Browsers und DoH liegen ebenfalls außerhalb der Windows-DNS-API.⁶

5. Schicht 3 — Die Auswege für Single-Label-Namen: LLMNR, NetBIOS und danach mDNS

5.1 Worin sich die drei Protokolle unterscheiden

LLMNR und NetBIOS over TCP/IP (NetBT) sind alternative Mittel, um einen Single-Label-Namen wie app01 aufzulösen. Standardmäßig laufen sie parallel zu DNS, und eine Link-Local-Antwort kann übernommen werden, selbst wenn DNS eine positive Antwort liefert. Seriell nach einem DNS-Fehler werden sie nur, wenn die intelligente Multihomed-Namensauflösung deaktiviert ist.⁴

mDNS ist davon getrennt; es ist ein zusätzlicher Pfad für .local-Namen. Es ist kein Auffangnetz, das nach einem gescheiterten DNS-Auflösen eines Single-Label-Namens einspringt.²⁴

Auch bei .local die DNS-Prüfung nicht überspringen

.local wird nicht zu mDNS-exklusiv. Ist die Active-Directory-Domäne etwas wie corp.local, wird dieser Name weiterhin auch über die konfigurierten DNS-Server und die NRPT aufgelöst. RFC 6762 erlaubt ebenfalls das Nebeneinander mit Unicast-DNS. Bei der Untersuchung von .local-Namen auch die DNS- und VPN-Richtlinien prüfen.²⁴

NetBT hängt davon ab, ob WINS existiert, und vom Knotentyp

Ohne konfiguriertes WINS ist der Standard B-node; ist auch nur ein WINS-Server konfiguriert, ist der Standard H-node.²⁹ LLMNR- und NetBT-Broadcasts überschreiten keine Subnetze, Abfragen an WINS sind jedoch Unicast und können es daher.

nbtstat -c zeigt den NetBIOS-Namenscache, und nbtstat -R leert den Cache und lädt LMHOSTS neu.³¹

5.2 Welche Antwort Vorrang hat

Welche Antwort nach den parallelen Abfragen Vorrang hat, steuert ebenfalls die Richtlinie.⁴

In Heim- oder öffentlichen Netzen kann die Antwort eines nahegelegenen Geräts mit demselben Namen Vorrang vor DNS haben. Auch hier gilt, die Antwortpriorität getrennt davon zu lesen, ob die Abfragen seriell oder parallel sind.

5.3 Die Richtung von Microsoft: Ausrichtung auf mDNS

Im April 2022 hat Microsoft die Ausrichtung auf mDNS und den schrittweisen Rückbau von NetBIOS-Namensauflösung und LLMNR angekündigt.²⁷ Alte und unsichere Geräteerkennungsprotokolle wie Computer Browser sind ebenfalls als veraltet eingestuft.³² Entwürfe, die Single-Label-Namen mit Multicast oder Broadcast ergänzen, laufen aus.

Die Microsoft-Informationen zur LLMNR-Schwachstelle nennen als Umgehungen das Blockieren von TCP/UDP 5355 und das Aktivieren der Gruppenrichtlinie „Deaktivieren der Multicastnamensauflösung“. Sie halten außerdem fest, dass der Computer infolgedessen für andere Computer unsichtbar werden kann.²⁵ Das Aktivieren dieser Richtlinie deaktiviert LLMNR auf allen Adaptern des DNS-Clients.⁴

Die Entscheidung zur Deaktivierung selbst ist richtig, aber für den verschwindenden Pfad muss ein Ersatz in DNS bereitstehen. Für Geräte, die nicht in DNS registriert sind, A-Einträge registrieren oder die dynamische Registrierung über DHCP aktivieren und die Ziele auf FQDN umstellen. Geräte mit mDNS-Unterstützung können .local-Namen nutzen, aber die Reichweite ist auf den Bereich beschränkt, den Multicast durchdringt.

5.4 Der typische Fall „nur manche PCs kommen nicht durch“: Single-Label-Namen

Steht in einer Konfigurationsdatei oder Verknüpfung \\fileserver01 oder http://app01/, erzeugt derselbe Name die folgenden Unterschiede.

Was Resolve-DnsName app01 -LlmnrOnly sagt, ist „ob sich über LLMNR auflösen lässt“. Es sagt nicht, woher die im Alltag übernommene Antwort stammt. Der Vergleich mit dem Ergebnis ohne Schalter und Mitschnitte erfolgen in Schritt 5 von Kapitel 8.⁸

Die grundlegende Abhilfe sind FQDN und DNS-Registrierung

Ziele, die von Single-Label-Namen abhängen, auf FQDN umstellen und die Namensauflösung auf DNS bündeln.

SMB2 und später verbinden direkt auf TCP 445 und nutzen keine NetBIOS-Sitzungen.³³ Das ist jedoch eine Frage des Transports. Beim Auflösen des Namens in einem Ziel wie \\fileserver01\share können LLMNR oder NetBT zum Einsatz kommen. Den FQDN angeben, etwa \\fileserver01.corp.example.com\share, um die Abhängigkeit vom Single-Label-Pfad zu entfernen.

Auch bei FQDN bleiben einige Vorsichtshinweise. Ein FQDN ohne abschließenden Punkt wird zusätzlich mit Suffixen versucht, wenn die Richtlinie aktiv ist, die Suffixe an Namen mit mehreren Bezeichnungen anfügt. Ein auf .local endender Name kann mDNS neben DNS nutzen. Die Form, die den Namen unbedingt festlegt, ist der absolute Name mit abschließendem Punkt. Die Voraussetzung, in der Praxis „ein FQDN ist auf DNS festgelegt“ als wahr zu behandeln, ist, dass die genannte Richtlinie deaktiviert ist und der interne Domänenname nicht .local verwendet.

6. Der Transport zum DNS-Server — DoH ändert die Reihenfolge nicht

6.1 DoH unter Windows 11 / Windows Server 2022

Windows-DoH ist eine Funktion, die Abfragen an den DNS-Server über HTTPS sendet. Sie ist mit dem bestehenden hosts, Cache und der NRPT sowie mit Resolver-Angaben je Adapter und Profil integriert; sie ersetzt nicht die Reihenfolge der Kapitel 3 und 4.⁹

Der DNS-Client von Windows 11 unterstützt DoH, und neuere Versionen unterstützen auch DoT (DNS over TLS). Die Microsoft-Beschreibung nennt jedoch nicht, welche Versionen DoT unterstützen, sodass es nicht auf jeder in diesem Artikel vorausgesetzten Umgebung verfügbar sein muss. Das Folgende behandelt DoH.⁹

Zuerst die Liste bekannter DoH-Server prüfen

Sofern DDR nicht aktiviert ist, sind nur Server in der Liste bekannter DoH-Server nutzbar. Die Standardliste enthält Cloudflare, Google und Quad9 und lässt sich mit Get-DnsClientDohServerAddress prüfen. Für einen internen DNS-Server und Ähnliches eine DoH-Vorlage zusammen mit Fallback- und Auto-Upgrade-Einstellungen registrieren.¹³⁴

# Die Liste bekannter DoH-Server
Get-DnsClientDohServerAddress

# Den internen DNS-Server als DoH-Server registrieren (kein Klartext-Fallback, mit Auto-Upgrade)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

Die Registrierung ist auch mit netsh dnsclient add encryption möglich. Das globale netsh dnsclient set global doh=yes|no|auto ist eine von dem serverseitigen autoupgrade getrennte Einstellung.³⁵

auto allein verbietet nicht die Rückkehr zu Klartext. Ob bei Fehlschlag auf UDP zurückgefallen wird, entscheidet getrennt das serverseitige udpfallback bzw. -AllowFallbackToUdp in PowerShell. Um die Auflösung auf verschlüsselten Transport zu beschränken, auch den Fallback deaktivieren.³⁵

Ist DDR aktiv, gibt es auch einen dynamischen Entdeckungspfad

Auf Versionen mit DDR (Discovery of Designated Resolvers) kann ein im Klartext konfigurierter Resolver seine verschlüsselten DNS-Endpunkte bekanntgeben. Weil die Verbindung ohne Eintrag in der statischen Liste auf Verschlüsselung angehoben werden kann, gilt nicht „es steht nicht in der Liste, also ist es kein DoH“.³⁵

Damit DDR arbeitet, sind beide nötig: das globale netsh dnsclient set global ddr=yes und das adapterbezogene set interface <name> ddr=yes. Ob bei Fehlschlag der über DDR gewonnenen verschlüsselten Auflösung auf Klartext zurückgefallen wird, entscheidet ddrfallback, das standardmäßig deaktiviert ist.

In der Untersuchung neben der bekannten Liste netsh dnsclient show global und netsh dnsclient show state prüfen sowie die mit set interface gesetzten Werte auf Adaptern, die DNS-Server haben. Die in der Dokumentation definierten show-Unterbefehle sind encryption, global und state; einen adapterbezogenen Show-Unterbefehl gibt es nicht.³⁵

„Zulassen“, „Anfordern“ und die Rückkehr zu Klartext trennen

In der Einstellungen-App die DNS-Einstellungen auf manuell setzen; „Bevorzugte DNS-Verschlüsselung“ lässt sich nur wählen, wenn der bevorzugte DNS-Server in der bekannten Liste steht. Es gibt drei Optionen.¹

Die Gruppenrichtlinie „DNS über HTTPS (DoH)-Namensauflösung konfigurieren“ hat Zulassen, Verbieten und Anfordern. Bei Zulassen wird DoH genutzt, wenn zusätzlich zur Registrierung in der bekannten Liste Bedingungen wie Auto-Upgrade, die Verschlüsselungseinstellung des Adapters oder das globale doh=auto erfüllt sind. Bei „Anfordern“ scheitert die Namensauflösung selbst gegen Server ohne DoH-Unterstützung.¹³⁵

„DoH anfordern“ nicht auf domänenzugehörige PCs anwenden. Microsoft warnt ausdrücklich davor. Active Directory Domain Services hängt stark von DNS ab, und der mit Windows Server gelieferte DNS-Serverdienst unterstützt keine DoH-Abfragen.¹

Im Mitschnitt Einstellungen und tatsächlichen Verkehr getrennt lesen

Tatsächlich über DoH gesendete Abfragen liegen in TLS auf Port 443 statt auf UDP 53. Auch bei „DoH zulassen“ fließen Abfragen an Server außerhalb der bekannten Liste und Fallbacks nach einem Verschlüsselungsfehler im Klartext. Dass DoH konfiguriert ist, lässt den Verkehr auf Port 53 nicht verschwinden.

Sind keine DNS-Abfragen sichtbar, neben hosts und Cache auch DoH und DoT (Port 853) prüfen. Zum Mitschnitt siehe den Artikel zum Paketmitschnitt.

6.2 DoH im Browser ist vom Betriebssystem getrennt

Den integrierten DNS-Client von Edge und die Änderung des Abfrageziels über Sicheres DNS versteht man leichter, wenn man sie in zwei Stufen teilt.

Der integrierte Client wird über BuiltInDnsClientEnabled gesteuert, und DoH-Abfragen erfolgen stets durch den integrierten Resolver.⁷ Sicheres DNS ist auf von der Organisation verwalteten PCs standardmäßig deaktiviert und wird mit DnsOverHttpsMode (off / automatic / secure) und DnsOverHttpsTemplates konfiguriert.³⁶³⁷

Ein Edge, bei dem ein anderer Anbieter gewählt ist, kann externe Sites auflösen, aber Namen scheitern lassen, die nur das interne DNS kennt. Umgekehrt kann Edge allein Seiten noch öffnen, wenn das OS-DNS ungesund ist. Bleibt es beim aktuellen Anbieter, ändert sich das Abfrageziel nicht.

Die Schlussfolgerung: Erfolg im Browser und Erfolg der Geschäftsanwendung nicht als Beleg für denselben Pfad behandeln. Den OS-Pfad mit Resolve-DnsName oder ping prüfen.

7. Welchen Pfad nimmt die App?

Bevor die Werkzeuge für eine Untersuchung gewählt werden, den betrachteten Pfad angleichen.

Die wichtigsten Schalter von Resolve-DnsName, nach Untersuchungszweck geordnet, sind die folgenden.⁸

7.1 A und AAAA: IPv6 kommt zuerst zurück

Selbst wenn die Namensauflösung gelingt, kann die anschließende Adressauswahl die Verbindung langsam machen.

Der DNS-Client fragt sowohl A (IPv4) als auch AAAA (IPv6). Auch im Mitschnitt erscheinen beide Abfragen als Paar.³ Nach den Antworten wählen getaddrinfo und der verbindende Stapel die zu nutzende Adresse. Windows Vista und später verwenden die Präfixtabelle aus RFC 3484 und bevorzugen standardmäßig IPv6-Global-Unicast gegenüber IPv4.³⁸

Allerdings gilt: Eine AAAA-Antwort allein bedeutet nicht, dass stets eine IPv6-Verbindung versucht wird. Die Zielauswahl verwirft zuerst unbrauchbare Ziele, etwa solche ohne IPv6-Quelladresse oder Route, und ordnet dann die Kandidaten.³⁹

Das Problem entsteht in Umgebungen, in denen eine IPv6-Quelladresse und eine Route vorhanden zu sein scheinen, aber tatsächlich nicht funktionieren. Die Namensauflösung gelingt, doch Zeit geht an der Verbindung verloren. Ob IPv6 wirklich versucht wurde, bestätigt man nicht allein aus der DNS-Antwort, sondern aus Verbindungsprotokollen oder einem Mitschnitt.

Microsoft empfiehlt nicht, IPv6 zu deaktivieren, weil einige Windows-Komponenten dann nicht mehr arbeiten. Stattdessen beschreibt es, DisabledComponents auf 0x20 zu setzen, um IPv4 in der Präfixrichtlinie zu bevorzugen.³⁸ Den Fall, dass localhost nach ::1 auflöst und mit einer Untersuchung kollidiert, die 127.0.0.1 angenommen hat, behandelt auch der Artikel zum Paketmitschnitt.

8. Das Eingrenzungsverfahren — die Schichten von oben abschälen

Auf dem scheiternden PC der Reihe nach ausführen. Jeder Befehl existiert, um den Pfad einzuschränken, und sein Erfolg allein beweist nicht den im Alltag genommenen Pfad. Den Vergleich der Ergebnisse mit dem Mitschnitt am Ende kombinieren.

Schritt 1: Die Form des Namens prüfen

In einem Protokoll oder einer Konfigurationsdatei den Namen prüfen, den die App tatsächlich übergibt. Der Pfad ändert sich je nachdem, ob es ein Single-Label-Name ist, auf .local endet oder einen abschließenden Punkt hat. Bei einem kurzen Namen wie http://app01/ von der Ergänzung in Abschnitt 4.1 und den Unterschieden je PC in Abschnitt 5.4 ausgehen.

Schritt 2: Lässt sich allein aus Cache und hosts auflösen?

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnly beschränkt nur diese Abfrage auf den lokalen Cache. Wurde eine falsche Antwort vom DNS-Server gelernt, kommt nach dem Leeren derselbe Wert zurück. Dass sie im Cache lag, ist kein Beweis, dass der DNS-Server unbeteiligt ist.⁸

Schritt 3: Lässt sich allein über DNS auflösen?

# hosts ausschließen, kein LLMNR/NetBIOS senden und nur die konfigurierten DNS-Server abfragen
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

Hatte Schritt 2 keine Antwort und gelingt dieser Schritt lediglich, ist es meist ein gewöhnlicher Cache-Miss. Von einem Cache- oder hosts-Problem kann man nur sprechen, wenn Schritt 2 eine veraltete Antwort, eine falsche Antwort oder einen negativen Cacheeintrag zeigte.

Scheitert auch dieser Schritt, den Weg zum DNS-Server, die Serverseite und die clientseitigen Richtlinien untersuchen. Bevor es zu Schritt 4 geht, Folgendes prüfen.

• Get-DnsClientNrptPolicy -Effective: gibt es eine Regel, die den Namen an einen anderen DNS-Server lenkt?
• Get-DnsClientDohServerAddress und die DoH-Gruppenrichtlinie: steht „DoH anfordern“ gegen einen Server, der es nicht unterstützt?

Gibt es eine NRPT, ändern sich die Zielserver in Schritt 4. Ist „DoH anfordern“ die Ursache, scheitert nur die Namensauflösung, während Weg und Server gesund sind. Zuerst die Prüfungen in den Abschnitten 4.4 und 6.1 abschließen.

Schritt 4: Jeden Server direkt fragen

Die DNS-Server der verbundenen Adapter sammeln und, wenn eine NRPT-Regel auf den Zielnamen zutrifft, durch die Server dieser Regel ersetzen. Auch DNS-Server einbeziehen, die nur für IPv6 konfiguriert sind.

$name = 'app01.corp.example.com'
# Die DNS-Server der verbundenen Schnittstellen aus IPv4 und IPv6 sammeln.
# Server, die in den Einstellungen eines getrennten VPN oder virtuellen Switches liegen bleiben, gehören nicht zum aktuellen Auflösungspfad, daher ausschließen (Server, die nur für IPv6 konfiguriert sind, nicht übersehen)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# Die Server der NRPT-Regel, die auf diesen Namen zutrifft (von Always On VPN oder DirectAccess geschrieben), erscheinen nicht in den Adaptereinstellungen, daher aus der wirksamen Richtlinie wählen.
# Der Parameter -Namespace von Get-DnsClientNrptPolicy filtert nur nach dem Namespace-Attribut der Regel; er gleicht nicht gegen den Namen ab.
# Daher Any-Regel (.), Suffixregeln (führender Punkt; gelten für den Namensraum selbst und untergeordnete Domänen), FQDN-Regeln und Präfixregeln (der Hostnamenteil; Platzhalter wie web* sind zulässig) selbst abgleichen
# und die spezifischere (längere) Regel übernehmen. Die Any-Regel ist die kürzeste, daher wird sie nur gewählt, wenn keine andere Regel zutrifft
# Namespace ist eine Menge von Zeichenfolgen (angezeigt als Namespace : {.corp.example.com}), daher die Elemente jeder Regel zum Abgleich expandieren und nach der Länge des getroffenen Namensraums ordnen
# Bei einem absoluten Namen mit abschließendem Punkt (app01.corp.example.com.) den Punkt nur für den Abgleich entfernen. An Resolve-DnsName das ursprüngliche $name übergeben
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # Gibt die NRPT Server für diesen Namensraum vor, geht die Abfrage in Schritt 3 an diese Server. Die Server des Adapters liegen außerhalb des Pfads, daher ersetzen
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # Mehrere Einträge können je Antwort in anderer Reihenfolge kommen, daher vor dem Vergleich sortieren
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # Negative Antworten (Name existiert nicht), SERVFAIL und Timeouts landen hier. Den Grund behalten statt ihn zu verwerfen
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

Zuerst die zu vergleichenden Server aufreihen

Die NameServers und DirectAccessDnsServers der NRPT können in den DNS-Einstellungen des Adapters fehlen. Fragt Schritt 3 die Server der NRPT, untersucht Schritt 4 aber nur die Server des Adapters, werden unterschiedliche Pfade verglichen.

Die NRPT hat Regeltypen wie Suffix, FQDN, Präfix und Any (.), und spezifischere Regeln haben Vorrang.⁴⁰ -Namespace filtert nur nach dem Attribut der Regel; es gleicht nicht gegen den Hostnamen ab. Deshalb expandiert der Code oben die Namensräume der Regeln und gleicht sie gegen den Zielnamen ab.²³

Bei einem Split-DNS-VPN ist es normal, dass der Resolver der Heimseite eine negative Antwort auf einen internen Namen liefert und nur die NRPT-Seite eine positive. Werden auch Server außerhalb des Pfads verglichen, sie getrennt als „Kontrolle“ festhalten und nicht in die Beurteilung von Zonenabweichungen mischen. Timeouts gegen Server, die auf getrennten Adaptern liegen bleiben, sind ebenfalls von Verzögerungen auf dem aktuellen Auflösungspfad getrennt.

Als Nächstes die Ergebnisse auseinanderlesen

Unterscheiden sie sich auch als Mengen, Zoneninhalt und Seriennummern prüfen. Außerdem ist dies eine Messung mit durch -Server festgelegtem Ziel. Die durch die Listenposition verursachte Verzögerung „4 Sekunden, bis der vierte und spätere Server erreicht wird“ aus Abschnitt 4.2 prüft man in Schritt 3 oder in dessen Mitschnitt.

Schritt 5: Die Link-Local-Schicht prüfen

Resolve-DnsName -Name 'app01' -LlmnrOnly          # Nur LLMNR
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # Nur LLMNR oder NetBIOS (kein DNS)
nbtstat -c                                        # NetBIOS-Namenscache

Diese Prüfung gilt Single-Label-Namen. -NetbiosFallback fällt nur bei DNS-Fehlschlag auf NetBIOS zurück, daher ist es bei einem Namen, den DNS auflösen kann, keine NetBIOS-Prüfung.⁸

Die Ergebnisse so lesen.

Welches Protokoll geantwortet hat, unterscheidet man im Mitschnitt anhand von UDP 5355 (LLMNR) gegenüber UDP 137 (NetBT). Um den alltäglichen Auflösungspfad zu bestätigen, auch mit der Adresse vergleichen, die Resolve-DnsName ohne Schalter zurückgibt, und bei Abweichung die übernommene Antwort im Mitschnitt prüfen, weil standardmäßig auch DNS parallel abgefragt wird.

Schritt 6: Die Einstellungsdumps vergleichen

In einer Untersuchung „nur manche PCs“ dasselbe Skript auf einem funktionierenden und einem scheiternden PC ausführen und vergleichen.

# name-resolution-dump.ps1 -- mit Administratorrechten ausführen und die Ausgabedateien der beiden Maschinen nebeneinander vergleichen
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # Fehlende Punkte (etwa DoH unter Windows 10) als Fehler festhalten
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

Zu vergleichen sind die Reihenfolge der DNS-Server, die Suchliste, verbindungsspezifische Suffixe, die NRPT, DoH, Schnittstellenmetriken und Richtliniewerte.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient hält EnableMulticast für „Deaktivieren der Multicastnamensauflösung“, DisableSmartNameResolution für „Intelligente Multihomed-Namensauflösung deaktivieren“, die Suchliste, das Primärsuffix und so weiter.⁴ Den Diff gegen die bisher geordnete Arbeitsweise jeder Schicht halten.

Schritt 7: Mit einem Paketmitschnitt untermauern

Das Microsoft-Verfahren zur Datenerfassung startet netsh trace start capture=yes auf Client und Server, verwirft den Cache mit ipconfig /flushdns, reproduziert das Problem und stoppt mit netsh trace stop.⁴¹

In Wireshark mit dns.qry.name == "app01.corp.example.com" oder dns.qry.name contains "app01" filtern, um zu sehen, welcher Server nach was gefragt wurde und was zurückkam.

Blockiert die Firewall der sendenden Seite UDP 53, läuft Resolve-DnsName in den Timeout, und im Mitschnitt erscheint ebenfalls keine DNS-Abfrage. Nicht nur den Fall eingrenzen, in dem die Namensauflösung gelingt und kein Verkehr hinausgeht, sondern auch den, in dem sie scheitert und kein Verkehr hinausgeht.³

Über DNS hinaus 5355 für LLMNR, UDP 5353 für mDNS und UDP 137 für den NetBT-Namensdienst prüfen. DoH ist 443 und DoT ist 853. Wie man mitschneidet und Mitschnitte liest, ist im Artikel zum Paketmitschnitt gesammelt.

9. Entwurf auf der Seite der Geschäftsanwendung — gegen Namensauflösung robust machen

Damit Untersuchungen leichter werden, zählt, dass die App-Seite festhalten kann, „welcher Name, wonach aufgelöst, und wo es scheiterte“. Das Protokoll der App mit den Einstellungsdumps und Mitschnitten abzugleichen, die der IT-Betrieb sammelt, erleichtert die Entscheidung, wo in Kapitel 8 zu beginnen ist.

Ziele als FQDN führen und nicht von hosts abhängen

Die Vorgaben in Konfigurationsdateien, Verknüpfungen und UNC-Pfaden als FQDN führen. Das entfernt die Abhängigkeit von der Suffixergänzung von Single-Label-Namen und von LLMNR und NetBT. Die Vorsichtshinweise aus Abschnitt 5.4 bleiben jedoch: mDNS neben DNS für .local-Namen und die Richtlinie, die Suffixe an Namen ohne abschließenden Punkt anfügt.

hosts ist für eine vorübergehende Überschreibung in der Entwicklung praktisch, erfordert aber Administratorrechte und Handarbeit. Verteilung und Änderungshistorie sind schwer zu führen, und manche Resolver ziehen es gar nicht zu Rate (nslookup tut es nicht¹²). Ziele über Konfigurationsdateien umschalten.

Ergebnis, Dauer und Fehlergrund der Namensauflösung festhalten

Beim Start und ähnlichen Punkten die IPv4- und IPv6-Adressen und die Dauer für die wichtigsten Ziele festhalten. Weil Dns.GetHostAddresses dasselbe Ergebnis wie getaddrinfo liefert, lässt sich nachverfolgen, „auf welchem PC, seit wann, wonach es aufgelöst war“.¹¹

// Die Namensauflösungsergebnisse der wichtigsten Ziele beim Start festhalten (.NET 6 oder höher)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("Namensauflösung {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "Namensauflösung fehlgeschlagen {Host} Fehler {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

Fehler protokollieren und erneut werfen. Stillschweigend auf einen anderen Namen oder eine feste IP umzuschalten macht den tatsächlichen Pfad in einer Untersuchung unerkennbar. Mit Fehlercode und Dauer kann der IT-Betrieb entscheiden, wo in den Schritten 2 bis 4 zu beginnen ist.

Timeouts und IPv6-Antworten einplanen

Der DNS-Client verbraucht gegen nicht antwortende Server bis zu 10 Sekunden je abgefragtem Kandidaten.²¹ Erzeugt die Suffixsuche mehrere Kandidaten, kann die Gesamtdauer 10 Sekunden übersteigen.

Wird der Verbindungstimeout auf 2 oder 3 Sekunden zusammengedrückt, endet die Namensauflösung vor der Frist nicht in Konfigurationen wie einer, in der der antwortfähige Server an vierter oder späterer Stelle steht. Der zweite Server wird jedoch nach 1 Sekunde abgefragt und der dritte nach 2 Sekunden, sodass ein einzelner ausgefallener Server nicht unbedingt Scheitern bedeutet. Mit den Neuübertragungszeiten aus Abschnitt 4.2 entwerfen.

Außerdem bevorzugt Windows standardmäßig IPv6, wenn eine AAAA-Antwort zurückkommt und eine IPv6-Quelladresse und Route existieren.³⁸ Verbindungscode, der nur IPv4 annimmt, kann die Verbindung scheitern lassen, obwohl die Namensauflösung gelungen ist. Den Erfolg der Namensauflösung vom Erfolg der Verbindung trennen und beide Adressarten behandeln.

10. Zusammenfassung

Was in der Windows-Namensauflösung zuerst zu trennen ist: die Form des Namens, die Schicht, die die Antwort liefert, und der Pfad, den die App nimmt.

Cache und hosts antworten zuerst, und bei Single-Label-Namen laufen DNS und LLMNR/NetBT standardmäßig parallel. Bei .local kommt mDNS hinzu. Sobald die Auflösung zu DNS übergeht, ändern Suffixe, Neuübertragungszeiten, mehrere NICs und die NRPT das Ergebnis. DoH ist eine Funktion, die diesen Transport umstellt, und sie ist vom integrierten Resolver des Browsers getrennt zu betrachten.

Die Untersuchung schränkt den Pfad in der Reihenfolge -CacheOnly, dann -NoHostsFile -DnsOnly, dann -Server, dann -LlmnrOnly ein und bestätigt mit einem Einstellungsdiff und einem Mitschnitt. Was zählt, ist den negativen Cache, den Unterschied zwischen keiner Antwort und einer negativen Antwort und die clientseitigen Richtlinien nicht zu übersehen.

Wenn „nur dieser PC kommt nicht durch“, zuerst diese beiden Dinge prüfen.

In welcher Form wird der Name übergeben? Auf diesem PC, welcher Pfad antwortet?

Sind diese beiden geklärt, lässt sich eingrenzen, wo zu suchen ist.

Verwandte Artikel

• Paketmitschnitt unter Windows in der Praxis — pktmon, netsh trace und Wireshark wählen
• Unternehmensproxy und Windows-Apps — Proxyauflösung in WinINET, WinHTTP und .NET sortieren
• HttpClient nicht mit using umschließen ── HTTP-Kommunikation in C#-Geschäftsanwendungen (Erzeugungsmuster, Timeouts, Retries)
• Windows-Firewall und Business-Anwendungen — Eingehende Regeln über das Installationsprogramm registrieren
• Die Fallstricke von Netzlaufwerken und UNC-Pfaden ── Fileserver (Freigabeordner) in Business-Anwendungen richtig einsetzen
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Praktische PowerShell-Befehlssammlung — Kleine, oft genutzte Funktionen für den Alltag ausbauen

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt Ursachenuntersuchungen von Kommunikationsstörungen rund um die Namensauflösung wie „die Geschäftsanwendung erreicht den internen Server nur auf manchen PCs nicht“ und „im Browser öffnet es sich, aber die App scheitert an der Namensauflösung“, Design-Reviews, ob eine Geschäftsanwendung Umgebungsänderungen wie das Deaktivieren von LLMNR, DoH und VPN standhält, und die Umsetzung einer Kommunikationsschicht, die Namensauflösungsergebnisse und Timeouts festhält. Werden Einstellungsdumps eines funktionierenden und eines scheiternden PCs der Anfrage beigelegt, steht der Ausgangspunkt der Untersuchung schnell fest.

• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Windows-App-Entwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ich habe die Hosts-Datei geändert, aber die Änderung greift nicht. Warum?

Unter Windows wird der Inhalt der Hosts-Datei beim Start des DNS-Clientdienstes in den Cache geladen, und die Namensauflösung läuft in der Reihenfolge Cache, hosts, DNS-Server. Greift eine Änderung nicht, prüfen Sie zuerst den Eintrag für diesen Namen mit ipconfig /displaydns und verwerfen Sie eine alte Antwort mit ipconfig /flushdns. Als Nächstes stellen Sie in Frage, ob das verwendete Werkzeug überhaupt den Windows-Resolver durchläuft. nslookup nutzt den OS-Resolver nicht; es umgeht Cache, hosts und die NRPT und fragt den DNS-Server direkt, sodass nichts aus hosts in der Ausgabe erscheint. Das tatsächliche Auflösungsergebnis einschließlich hosts sehen Sie mit Resolve-DnsName oder ping. Greift es dann immer noch nicht, prüfen Sie, ob die App wie ein Browser einen eigenen Resolver oder DoH hat.

Die Site öffnet sich im Browser, aber nur die Geschäftsanwendung scheitert an der Namensauflösung.

Wahrscheinlich lösen Browser und App den Namen über unterschiedliche Pfade auf. Microsoft Edge spricht standardmäßig mit dem integrierten DNS-Client statt mit dem OS-DNS-Client zum DNS-Server, und ist unter Sicheres DNS (DoH) ein anderer Anbieter gewählt, fragt es einen externen Resolver. Dns.GetHostAddresses in .NET und ein HttpClient, der das Ziel direkt verbindet, gehen dagegen über die OS-getaddrinfo und unterliegen hosts, dem DNS-Cache, der NRPT und der DNS-Suffixsuchliste (bei Anforderungen über einen HTTP-Proxy wird der Zielname auf der Proxy-Seite aufgelöst). Liefern beide unterschiedliche Antworten, ist der schnellste Weg, mit Resolve-DnsName und einem Paketmitschnitt abzugleichen, welcher Pfad welchen DNS-Server nach was gefragt hat.

Die Einstellungen sollten identisch sein, und trotzdem erreichen nur manche PCs den internen Server nicht. Was soll ich vergleichen?

Vergleichen Sie die Form des Namens und die Schicht, auf der jeder PC seine Antwort erhält. Ein Single-Label-Name (ein Name ohne Punkt, etwa server01) wird mit der DNS-Suffixsuchliste des PCs oder dem verbindungsspezifischen Suffix ergänzt und an DNS geschickt und standardmäßig parallel auch an auf dasselbe Subnetz beschränkte Mechanismen wie LLMNR und NetBIOS-Broadcast (nacheinander nach einem DNS-Fehler werden sie nur versucht, wenn die Optimierung deaktiviert ist; ist WINS konfiguriert, nutzt NetBIOS Unicast und kann Subnetze überschreiten). Ein domänenzugehöriger PC kann den Namen auflösen, weil das Suffix ihn zum FQDN ergänzt, während ein PC im VPN oder in einem anderen Subnetz oder ein PC mit deaktiviertem LLMNR und NetBIOS denselben Namen nicht auflösen kann. Zuverlässig ist, die Ausgabe von Get-DnsClientServerAddress, Get-DnsClientGlobalSetting, Get-DnsClient und Get-DnsClientNrptPolicy -Effective auf einem funktionierenden und einem scheiternden PC zu sammeln und zu vergleichen. Die grundlegende Abhilfe besteht darin, die Ziele in Konfigurationsdateien und Verknüpfungen als FQDN zu führen.

Die Namensauflösung scheitert nicht; es dauert nur mehrere Sekunden, bis die Verbindung zustande kommt. Was verursacht das?

Hier zeigt sich der Timeout- und Wiederholungsmechanismus des DNS-Clients. Gegen einen DNS-Server, der nicht antwortet, überträgt Windows 1, 2, 4 und 8 Sekunden nach Start erneut und gibt nach 10 Sekunden auf. Auch bei mehreren konfigurierten DNS-Servern wartet Windows mindestens 4 Sekunden, bevor es den vierten oder späteren Server in der Liste abfragt, wenn genau der antwortet. Eine lange DNS-Suffixsuchliste stapelt ebenfalls Verzögerung, weil ein Single-Label-Name mit jedem Suffix der Reihe nach versucht wird. Messen Sie mit Measure-Command, wie lange Resolve-DnsName braucht, und legen Sie in Wireshark den Filter dns.qry.name, um zu sehen, welche Serverabfragen unbeantwortet bleiben.

Wir haben LLMNR und NetBIOS als Sicherheitsmaßnahme deaktiviert, und jetzt sind manche Geräte nicht mehr per Namen erreichbar.

Das ist eine erwartete Nebenwirkung. LLMNR und NetBIOS over TCP/IP sind sekundäre Mittel, um Single-Label-Namen von Geräten, die nicht in DNS registriert sind, im selben Subnetz aufzulösen; sie zu deaktivieren entfernt diesen Pfad. Microsoft selbst hat 2022 die Ausrichtung auf mDNS und den schrittweisen Rückbau von NetBIOS-Namensauflösung und LLMNR angekündigt, sodass die Entscheidung zur Deaktivierung selbst richtig ist. Die Abhilfe besteht darin, die Namensauflösung auf DNS zu bündeln: A-Einträge der Geräte im internen DNS registrieren oder die dynamische Registrierung über DHCP aktivieren und die Ziele von Apps und Freigaben auf FQDN umschreiben. Geräte mit mDNS-Unterstützung lassen sich über ihren .local-Namen auflösen, aber auch dieser Pfad reicht nur so weit, wie Multicast kommt.

Was geschieht mit der internen Namensauflösung, wenn ich DoH (DNS over HTTPS) unter Windows 11 aktiviere?

DoH ist eine Funktion, die den Transport auf HTTPS umstellt, wenn der DNS-Client die konfigurierten DNS-Server abfragt; die bestehende Reihenfolge von hosts, Cache und NRPT bleibt. Sofern DDR (Discovery of Designated Resolvers) nicht aktiviert ist, ist DoH nur nutzbar, wenn der Server in der Liste bekannter DoH-Server steht; soll ein interner DNS-Server genutzt werden, muss ein Administrator ihn mit Add-DnsClientDohServerAddress registrieren. Steht die Gruppenrichtlinie „DNS über HTTPS (DoH)-Namensauflösung konfigurieren“ auf „DoH anfordern“, scheitert die Namensauflösung selbst gegen Server ohne DoH-Unterstützung. Microsoft sagt ausdrücklich, diese Einstellung auf domänenzugehörigen PCs nicht zu aktivieren, weil der mit Windows Server gelieferte DNS-Serverdienst, von dem Active Directory abhängt, keine DoH-Abfragen unterstützt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.