The Cable Guy - November 2006
Link-Local Multicast Name Resolution
Von The Cable Guy
Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie unter http://www.microsoft.com/germany/technet/community/columns/cableguy/cgarch.mspx.
Link-local Multicast Name Resolution (LLMNR) ist ein neues Protokoll, über das eine zusätzliche Möglichkeit zur Auflösung der Hostnamen von Computern im gleichen Netzwerk zur Verfügung steht. Es ist besonders dann sehr nützlich, wenn es keinen DNS-Server gibt. LLMNR tauscht Request- und Reply-Nachrichten aus und löst so Hostnamen in IPv6- oder IPv4-Adressen auf. In diesem Artikel beschreiben wir die Implementierung von LLMNR unter Microsoft® Windows Vista™ und Windows Server® Code Name "Longhorn".
Anmerkung: Dieser Artikel geht davon aus, dass Sie sich mit IPv4, IPv6, DNS und DNS-Clients und -Servern auskennen.
Auf dieser Seite
 | Einleitung |
| Aufbau der LLMNR-Nachrichten |
| Der Startvorgang des Hosts und die Namensauflösung |
| Zusätzliche Informationen |
Einleitung
LLMNR wird im Internet-Draft mit dem Titel "Link-local Multicast Name Resolution (LLMNR)" (draft-ietf-dnsext-mdns-47.txt) beschrieben. Es ermöglicht IPv6- und IPv4-Hosts, die Hostnamen von Computern im gleichen Netzwerk ohne einen DNS-Server oder einen DNS-Client aufzulösen.
IPv4-Hosts können IPv4-Adressen über NetBT (NetBIOS over TCP/IP) auflösen. Hierzu senden Sie NetBIOS-Name Query Request-Nachrichten per Broadcast an das lokale Subnetz. Der Knoten, der den entsprechenden Namen verwendet, sendet eine NetBIOS-Name Query Response-Nachricht per Unicast zurück an den anfragenden Computer. NetBT funktioniert jedoch nur mit IPv4 - nicht mit IPv6. Außerdem haben Administratoren die Möglichkeit, NetBT in Umgebungen mit DNS zu deaktivieren. Wenn dies der Fall ist und keine DNS-Server verfügbar sind, dann muss die Namensauflösung über die Hosts-Datei durchgeführt werden.
LLMNR unterstützt die Hostnamensauflösung in Netzwerken, in denen es keinen DNS-Server gibt. Hierbei kann es sich zum Beispiel um ein ad-hoc IEEE 802.11-WLAN handeln, das von einigen mobilen Computern für einen befristeten Zeitraum eingerichtet wurde.
LLMNR-Nachrichten nutzen ein Format, das dem von DNS-Nachrichten entspricht (RFC 1035). Es verwendet jedoch einen anderen Port als DNS. LLMNR-Name Query Request-Nachrichten werden unter Windows Vista an UDP-Port 5355 gesendet. LLMNR-Name Query Response-Nachrichten werden über UDP-Port 5355 gesendet. Der LLMNR-Cache ist vom DNS-Cache getrennt.
Anmerkung: Der LLMNR-Internet-Draft zeigt auch auf, wie LLMNR-Nachrichten über TCP versendet werden können. Solche TCP-basierten LLMNR-Nachrichten werden jedoch unter Windows Vista nicht unterstützt.
Bei LLMNR-Nachrichten, die über IPv6 übertragen werden, sendet der abfragende Host eine LLMNR-Name Query Request-Nachricht an die lokale IPv6-Multicastadresse FF02::1:3. Bei LLMNR-Nachrichten, die über IPv4 übertragen werden, sendet der abfragende Host eine LLMNR-Name Query Request-Nachricht an die Multicastadresse 224.0.0.252. In beiden Fällen wird verhindert, dass ein Multicast-fähiger Router die Anfrage außerhalb des lokalen Subnetzes weiterleitet.
Alle IPv6-basierten LLMNR-Hosts überwachen die IPv6 Multicastadresse FF02::1:3, und die entsprechenden Ethernet-Netzwerkadapter reagieren auf Ethernet-Frames mit der Multicast-Zieladresse 33-33-00-01-00-03. Alle IPv4-basierten LLMNR-Hosts überwachen die Multicastadresse 224.0.0.252, und die entsprechenden Ethernet-Netzwerkadapter reagieren auf Ethernet-Frames mit der Multicast-Zieladresse 01-00-5E-00-00-FC.
Ein typischer Nachrichtenaustausch setzt sich bei LLMNR aus einer Multicast-Abfrage und - wenn ein Host im Subnetz den abgefragten Hostnamen nutzt - einer Unicast-Antwort zusammen. Windows Vista-basierte LLMNR-Hosts senden keine Antworten auf Unicast-Abfragen.
Im Gegensatz zu DNS-Servern kümmern sich LLMNR-Hosts nur um Abfragen für den eigenen Hostnamen - und nicht für einen Teil des DNS-Namespace, der sich möglicherweise unter dem abgefragten Namen befindet (es gibt also keine Zonen im herkömmlichen Sinn - die "Zone" besteht bei LLMNR nur aus dem Hostnamen des Hosts). Ein LLMNR-Knoten, der den Namen test.office.example.com nutzt, ist also für andere Namen, die auf office.example.com enden, nicht zuständig.
Aufbau der LLMNR-Nachrichten
Wie oben beschrieben nutzt LLMNR das gleiche Format wie DNS für seine Nachrichten. In Abbildung 1 ist dieses Format zu sehen.
Abbildung 1: Das LLMNR-Nachrichtenformat
Wie bei DNS-Nachrichten nutzt LLMNR einen 12-Byte-Header und mehrere Abschnitte mit Anfrage-Einträgen, Antwort-Einträgen, Authority-Einträgen und zusätzlichen Einträgen.
Abbildung 2 zeigt den Aufbau des LLMNR-Headers.
Abbildung 2: Der LLMNR-Header
Genau wie bei DNS-Nachrichten wird auch bei LLMNR eine zwei Byte lange Transaktions-ID verwendet. Über diese ID werden die Anfragen den Antworten zugeordnet. Es gibt ein zwei Byte großes Feld für Flags und Indikatoren (diese werden weiter unten beschrieben) und zwei Byte große Felder, über die festgelegt wird, wie viele der einzelnen Einträge in der Nachricht enthalten sind.
Die Maximalgröße für eine LLMNR-Nachricht beträgt entweder 65.527 Byte (entspricht der Maximalgröße für UDP-Nachrichten unter IPv6) oder 65.507 Byte (Maximalgröße für UDP-Nachrichten unter IPv4). LLMNR-Nachrichten, die über die MTU des Segmentes hinausgehen, werden vom sendenden Host fragmentiert.
In Abbildung 3 sehen Sie den Aufbau des zwei Byte großen Feldes für Flags und Indikatoren im LLMNR-Header.
Abbildung 3: Flags und Indikatoren im LLMNR-Header
In den zwei Bytes sind die folgenden Flags definiert:
| • | QR-Flag: Wie bei DNS zeigt das Query/Response-Flag, ob es sich um eine Anfrage (QR=0) oder eine Antwort (QR=1) handelt. |
| • | Opcode: Wie bei DNS zeigt der vier Bit lange Operation-Code (Opcode), um was für eine Art von Abfrage es sich handelt. Der Opcode ist für Anfragen und Antworten 0. |
| • | C-Flag: Das Conflict-Flag zeigt Namenskonflikte an. Wenn ein Name im Subnetz eindeutig sein sollte, setzt der antwortende Host das Flag auf 0. Wenn der anfragende Host schon mehrere Antworten auf seine Anfrage erhält, setzt er das Flag auf 1. Anfragen, in denen das Flag 1 ist, werden nicht beantwortet. Die Hosts, die den angefragten Namen nutzen, können so jedoch erkennen, dass ihr Name nicht eindeutig ist. |
| • | TC-Flag: Wie bei DNS wird das Truncation-Flag dann in Antworten gesetzt, wenn die Nachricht aufgeteilt wurde (weil der Datenteil die Maximalgröße für Pakete im Subnetz übersteigt). Wenn der anfragende Host eine Nachricht mit TC-Flag 1 erhält, kann er eine neue TCP-basierte Anfrage an die Unicastadresse des antwortenden Hosts senden. Da LLMNR-Nachrichten eine große Maximalgröße haben können, setzt Windows Vista das TC-Flag nicht. |
| • | T-Flag: Das Tentative-Flag wird auf 1 gesetzt, wenn der antwortende Host den Namen verwendet, aber nicht feststellen konnte, ob der Name eindeutig ist. |
| • | RCODE-Field: Wie bei DNS zeigt das vier Bit lange Return Code-Feld, ob die Antwort erfolgreich war. Bei LLMNR wird das Feld von dem anfragenden und dem antwortenden Host auf 0 gesetzt. Im Gegensatz zu DNS-Servern antworten LLMNR-Hosts, die nicht autorisiert enden für einen Namen sind, nicht mit RCODE 3. Sie senden ganz einfach gar keine Antwort. |
LLMNR-Nachrichten, die über IPv6 gesendet werden, nutzen den folgenden IPv6-Header:
| • | Destination Address-Feld: FF02::1:3 |
| • | Source Address-Feld: Lokale Multicast- oder Unicastadresse der sendenden Schnittstelle. |
| • | Hop Limit-Feld: 1 |
LLMNR-Nachrichten, die über IPv4 gesendet werden, nutzen den folgenden IPv4-Header:
| • | Destination Address-Feld: 224.0.0.252 |
| • | Source Address-Feld: IPv4-Unicastadresse der sendenden Schnittstelle. |
| • | TTL-Feld: 1 |
Bei LLMNR-Anfragen nutzen Windows Vista-basierte Clients den Zielport 5355. Der Quellport wird dynamisch festgelegt. Bei LLMNR-Antworten nutzen Windows Vista-basierte Clients den dynamisch festgelegten Port als Zielport und den Quellport 5355.
Der Startvorgang des Hosts und die Namensauflösung
Wenn ein Host unter Windows Vista startet, prüft er, ob sein Hostname eindeutig ist. Hierzu sendet er LLMNR-Name Query Request-Nachrichten mit seinem Hostnamen (ohne Suffix).
Ein Computer mit dem Namen client1 und dem primären DNS-Suffix wcoast.example.com ist in Bezug auf LLMNR also zum Beispiel für den Hostnamen client1, jedoch nicht für client1.wcoast.example.com autorisierend. Wenn es eine Antwort gibt, bei der das C-Flag auf 0 gesetzt ist, dann besteht ein Namenskonflikt. Der LLMNR-Host bemerkt diesen Konflikt und antwortet nicht auf Anfragen für seinen Hostnamen. Er sendet jedoch alle 15 Minuten eine neue Anfrage für seinen Hostnamen. So kann er feststellen, wann sich der Computer mit dem in Konflikt stehenden Hostnamen nicht mehr im Subnetz befindet. Wenn dies der Fall ist, beginnt der Host auf Anfragen zu seinem Hostnamen zu antworten.
Um Anfragen in der Form hostname.local zu vereinfachen, konvertiert Windows Vista hostname.local in hostname und versucht diesen Namen über LLMNR aufzulösen. Ein Windows Vista-basierter Computer ist nicht autorisierend für den Namen computername.local (der Computername ist nicht das Gleiche wie der Hostname!).
Wenn ein Hostname aufgelöst werden muss, versucht ein Computer unter Windows Vista dies über IPv6 und IPv4 (die Standardeinstellung). Hierbei geht er folgendermaßen vor:
1. | Er führt eine normale DNS-Namensauflösung durch. Hierzu kombiniert er den Hostnamen mit dem primären DNS-Suffix des Computers und sendet eine DNS Name Query Request-Nachricht an seinen DNS-Server. |
2. | Wenn die DNS-Namensauflösung fehlschlägt (zum Beispiel, da der DNS-Server RCODE=3 zurückgibt), sendet er bis zu zwei Multicast-LLMNR-Name Query Request-Nachrichten über IPv6 und IPv4. |
3. | Wenn die LLMNR-Namensauflösung fehlschlägt und NetBT aktiviert ist, sendet er bis zu drei NetBIOS Name Query Request-Nachrichten per Broadcast. |
Wenn der aufzulösende Namen kein einzelner Name (oder ein Name im Format hostname.local) ist, dann werden LLMNR und NetBT nicht verwendet. LLMNR wird jedoch auch dann eingesetzt, wenn kein DNS-Server konfiguriert wurde.
LLMNR-Hosts im gleichen Subnetz, die eine LLMNR-Name Query Request-Nachricht erhalten, prüfen, ob sie autorisierend für den angefragten Namen sind. Wenn dies der Fall ist, erstellt und sendet der Host eine LLMNR-Name Query Response-Nachricht per Unicast. Diese Nachricht enthält die original Anfrage und die Antwort (eine oder mehrere IP-Adressen). Der antwortende Host gibt nur die IP-Adressen an, über die er für den anfragenden Host erreichbar ist (zum Beispiel die Adressen, die der Schnittstelle zugewiesen sind, über die die Anfrage erhalten wurde).
Zusätzliche Informationen
Weitere Informationen zu den Erweiterungen in Bezug auf TCP/IP unter Windows Vista finden Sie unter:
| • | |
| • | Microsoft IPv6-Website (engl.) |
| • |