Navigation

Was ist WINS?

WINS steht für Windows Internet Name Service.

Vergleichbar zu dem Verfahren, das bei DNS verwendet wird, um IP-Adressen in leichter lesbarere Namen umzusetzen, stellt WINS eine Methode auf Windows-NT basierten Systemen dafür zur Verfügung.

Der Hauptunterschied zwischen WINS und DNS liegt darin, dass DNS eine hierarchische Anordnung zur Verfügung stellt (die Namen können in einer baumartigen Struktur angeordnet werden). WINS stellt einen "flachen" NameSpace zur Verfügung.

WINS unterscheidet sich vom Standard DNS in drei signifikanten Punkten:

1. WINS ist dynamisch. Wenn ein Microsoft-basierter Computer im Netzwerk hochgefahren wird, sendet er einen Broadcast an alle physikalisch an diesem Segment angeschlossenen Systeme. Dies ist ein dynamischer Prozess, bei dem Computer das Netzwerk betreten und wieder verlassen ohne dass eine Intervention notwendig ist. Bei DNS werden die IP-Mappings in einer Datenbank gehalten (üblicherweise eine Datei namens 'hosts'), doie jemand administrieren muss. DNS stellt Anfragen über einen Requestor namens BIND, während NetBIOS über Broadcasts oder gerichtete Datagramme an den WINS-Server anfragt.
2. Ein NetBIOS Name kann nicht ohne zusätzliche Software über DNS aufgelöst werden. Microsofts DNS-Server integriert sich in seinen WINS-Service, der der DNS sagt, dass er WINS als eine Art 'hosts'-Datei behandeln soll.
3. Bei NetBIOS müssen Namen im ganzen Netzwerk eindeutig sein, während bei DNS mehrfache Namen (sogar in der selben Domäne) zulässig sind.

NetBIOS Namen

Um WINS zu verstehen muss man NetBIOS und NetBT verstehen.

NetBIOS ist ein älterer "NameSpace" der von IBM Produkten unterstützt wird. Er hat seine Wurzeln im LAN Manager. NetBIOS verwendet Broadcast um sein Netzwerkinterface den restlichen im Netzwerk partizipierenden Systemen bekanntzugeben.

NetBIOS sollte nicht mit NetBEUI verwechselt werden. Ebenso wie TCP/IP ist NetBEUI ein Transportprotokoll. NetBIOS ist nur ein unterstützter NameSpace , der einn vorhandenes Transportprotokoll benutzt.

Die Definition dieses NameSpace sind 15 Zeichen. Zusätzlich verwendet NetBIOS ein 16. Zeichen, dass im hexadezimalen Format abgelegt wird. Dieses 16. Zeichen ist im Gegensatz zu den 15 vorher NICHT lesbar. Es wird verwendet um den Type der Ressource anzugeben.

Der NetBIOS Name eines Servers sieht z.B. so aus:

SERVER1          
^^^^^^^^^^^^^^^  ^
1------------15  16th char.

Dies gibt an, dass die Ressource \\SERVER1 heißt, und dass es sich um einen Domain Master Browser handelt (ersichtlich am 16. Zeichen '1B'), dem sogenannten NetBIOS-Suffix.

Es ist wichtig, zwischen den NetBIOS Namen und den Standard IP-Hostnamen zu unterscheiden. Ein NetBIOS Name kann Leerzeichen " " ebenso enthalten wie Unterstriche "_". Keines der beiden Zeichen wird von IP-Hostnamen unterstützt. Beachten Sie dies, wenn die Namen für Ihre Windows-basierten Systeme vergeben.

Beim Installieren von TCP/IP auf einer NT-Maschine prüft die Installationsroutine den NetBIOS Name, um zu sehen, ob er als IP-Hostname verwendet werden kann. Sollte er nicht konform sein, werden Unterstriche "_" durch einen Bindestrich "-" ersetzt und der NetBIOS Name wird ggf. bis zum ersten Leerzeichen " " übernommen. Der Rest wird weggelassen.

Auflösung von NetBIOS Namen

Der Client verwendet folgende Reihenfolge, wenn er einen Name auflösen muss:

• Er ermittelt, ob der Name länger als 15 Zeichen ist, oder einen Punkt "." enthält. Wenn ja befragt er den DNS

• Er prüft ob der Name bereits im NetBIOS Name Cache vorhanden ist.

• Er kontaktiert den WINS Server und versucht den Name darüber aufzulösen

• Er verwendet einen lokalen IP Broadcast im Subnetz

Wenn der LMHOST Lookup aktiviert ist, prüft er diese Datei

1. Er prüft die HOSTS-Datei
2. Er stellt eine Anfrage an den DNS-Server

Beachten Sie dazu auch die schematische Darstellung der Namensauflösung

Wenn ein MS Netzwerkclient einen NetBIOS Name auflösen will, sendet er einen Broadcast an das komplette Segment mit der Anfrage "Wer ist SERVER1?"

\\SERVER1 bemerkt, dass ein Client nach im fragt und sieht nach dem Domain Controller Service (um z.B. den User zu authentifizieren). Dann antwortet er "Ich bin \\SERVER1" und die Verbindung zwischen den beiden Systemen wird eingerichtet. (In Wirklichkeit ist das nur grob dargestellt. Detailliert müsste man sich hier mit SMB zusätzlich beschäftigen.)

Wie die "alten Hasen" mit Sicherheit bereits festgestellt haben, würde dieses Vorgehen der Registrierung und der gegenseitigen Nachfragen zu einem ständigen Broadcasten im Netzwerk führen. Tatsächlich ist es sogar noch schlimmer! Jede neue Sitzung beginnt mit einem Broadcast-Frame (der von jedem Computer des Segments verarbeitet werden muss). Außerdem gibt sich jedes System alle 15 Minuten im Netz bekannt, um die anderen wissen zu lassen, dass es noch da ist (dies dient Browser-Zwecken, die später dargestellt werden). Fügen Sie mehr als ein Protokoll hinzu und jedes System gibt sich über jedes Protokoll alle 15 Minuten bekannt!

Anmerkung: Dies gilt nur für die jeweiligen Netzwerksegmente, die über Switche oder Hubs zusammengeschlossen sind, da ein Broadcast nicht über einen Router geht!

NetBT (NBT)

NetBT steht für NetBIOS over TCP/IP (zuweilen auch als NBF -- NetBIOS Frames bezeichnet). Als Teil des modularen Protocol Stack der von MS implementiert ist und als NDIS (Network Driver Interface Specification) bezeichnet wird, teilt sich der Protocol Stack in unterschiedliche Schichten (layer) auf:

MS TCP/IP and NetBT Network Model:

Anfragen nach NetBIOS-basierten Ressourcen werden vom NetBT "service" bearbeitet und dann an den Protocol Stack weitergereicht, der sie dann über die Leitung schickt. Das NetBT Interface verbirgt die Spezifikationen des Protocol Stack vor der anfragenden Applikation.

Der NetBIOS Interface Service ermöglicht es, dass NetBIOS-basierte Kommunikation unabhängig vom Protocol Stack funktioniert. Applikationen müssen nur mit dem NetBIOS Support kommunizieren (auf dem Application & Presentation layer). Sie müssen sich selbst nicht um weitere Details des Protocol Stacks kümmern. NetBT verkapselt die NetBIOS Daten in ein Paket (NBF), das dann weitergereicht wird. Die 'Server' und 'Workstation' Dienste nutzen typischerweise NetBIOS.

Dies ermöglicht es MS-Netzwerk-orientierten Anwendungen in einer TCP/IP-Umgebung zu funktionieren und weiterhin die NetBIOS-Möglichkeiten zu nutzen.

Also bietet NetBT eine Möglichkeit, NetBIOS-Daten über Router hinweg zu senden. Wie löst nun aber eine Maschine einen Namen in einem entfernten (remote) Netzwerk zu einer IP-Adresse auf? Da, wie oben erwähnt, NetBIOS Auflösungen über Broadcasts ausgeführt werden, gehen sie nicht über Router!
Die Antwort auf dieses Dilemma heißt WINS. Die Aufgabe von WINS ist es, eine zentralen Punkt in einem gerouteten Netzwerk zu bieten,  der die NetBIOS Namen in IP-Adressen auflöst.

Auflösen von NetBIOS Namen in einem gerouteten Netzwerk

WINS ist ein Dienst, der auf einem NT Server läuft. Dieser sammelt die Informationen anderer Computer im Netzwerk (über den "NetBIOS name registration process") und deren zugehörige IP-Adressen und speichert sie in einer Datenbank. Diese Informationen werden dann an Computer ausgeliefert, die nach einem bestimmten Dienst bzw. System nachfragen. Dazu müssen verschiedene Prozesse klar sein, die dabei ablaufen: NetBIOS name registration, NetBIOS name renewal, NetBIOS name release, and zuletzt, NetBIOS name resolution.

NetBIOS name Registration Process

Nachdem wir nun wissen, wie NetBIOS Pakete in einer TCP/IP-Umgebung behandelt werden, können wir uns ansehen, wie ein System (das WINS verwendet) sich im Netzwerk registriert.

Zu diesem Zweck gehen wir von drei Systemen aus, die folgendermaßen konfiguriert sind:

Wenn SERVER bootet, initialisiert er seinen Protocol Stack. Teil dieses Initialisierungsprozesses ist die Registrierung beim definierten WINS Service (am 10.2.1.2). Um sich selbst zu registrieren sendet SERVER2 ein gerichtetes Datagramm an 10.2.1.2 über UDP Port 137 mit einer "name_registration_query" für den WINS Service am 10.2.1.2 um den Eintrag 'SERVER2' in seiner Datenbank zu registrieren.

Der WINS-Server trägt aber nicht einfach alles und jeden in seiner Datenbank ein (das würde sonst zu einem kompletten Chaos führen), sondern er führt ein paar Prüfungen vorher aus, bevor er den Name registriert.

Zunächst sieht er in seiner Datenbank nach, ob der Name bereits existiert. Wenn nicht, registriert er ihn in der Datenbank und der Prozess ist abgeschlossen.

Sollte er bereits einen gleichlautenden Eintrag haben, sendet der WINS Server eine Anforderung an den Eigentümer des geführten Eintrags. Wenn der WINS keine Antwort erhält, versucht er es drei Mal im Abstand von 500ms. Wenn das System mit dem geführten Eintrag antwortet, sendet der WINS eine negative_name_query Antwort an den anfragenden Client. Wenn der WINS keine Antwort von bisher geführten Eigentümer erhält, registriert er den Name des anfragenden Systems und sendet eine positive_name_registration_response.

Dies deckt zwei mögliche Szenarien ab:

1. Sie haben die Adresse von SERVER2 geändert (z.B. ihn in ein neues Subnetz eingefügt) und den Name mit der neuen IP-Adresse beim WINS neuregistriert.
2. Es gibt eine andere Maschine mit dem selben NetBIOS Name im Netzwerk (was nicht zulässig ist).

NetBIOS Name Renewal

Die Namen im WINS haben eine bestimmte "Time to live" (TTL) oder Renewal Interval. Ein Name muss erneuert werden, bevor dieses Intervall abläuft, ansonsten wird die Zuweisung des Name zur Adresse freigegeben. Es liegt in der Verantwortung des Client diesen name referesh request anzufordern. Windows NT Clients führen dies in der halben Zeit des Renewal Interval aus.

NetBIOS Name Release

NetBIOS Namen können explizit oder "silent" freigegeben werden. Explizit werden sie freigegeben, wenn der Rechner sauber herunterfährt. "Silent" tritt in der Regel auf, wenn das System steht oder aus anderen Gründen nach Ablauf des Renewal Intervall nicht mehr erreichbar ist, ohne sich sauber abgemeldet zu haben.

Bei der Freigabe des Namens wird dieser in der Datenbank als freigegeben gekennzeichnet. Die Informationen dazu werden dann nicht mehr zu den WINS-Partnern propagiert. Wenn es sich um eine explizite Freigabe gehandelt hat, macht sich der WINS-Server zum Eigentümer dieses Eintrags, wenn er es nicht sowieso bereits war.

Die Freigabe wird besonders behandelt, wenn diese bei der Freigabe eine andere Eigentümer-ID hat (d.h. der Client hat sich bei einem WINS registriert und bei einem anderen abgemeldet). In diesem Fall wird der Eintrag als extinct markiert. Dies geschieht um Inkonsistenzen zwischen dem Primary und dem Secondary WINS-Server zu vermeiden. Ansonsten könnte es sein, dass der Eintrag auf einem Server als aktiv und am anderen als freigegeben geführt wird, da der Eintrag nicht nochmal repliziert wird, da er bereits repliziert wurde. Das Setzen des "extinct"-Status führt zur Replikation und bringt die Datenbanken wieder "in sync".

NetBIOS Name Query and Resolution

Wenn in einer MS Netzwerkumgebung eine System eine Ressource im Netz lokalisieren muss (z.B. einen Domain Controller) sendet der Client einen Broadcast, um nach dieser zu suchen. Tatsächlich sendet es en Paket an alle an das selbe physikalische Segment verbundenen Systeme mit der Frage "Wo ist SERVER1?". Das Problem besteht darin, dass jedes Mal wenn ein Broadcast geschickt wird, wird an allen verbundenen und ins Netzwerk "horchenden" Systemen ein Software Interrupt ausgelöst, außerdem entsteht dadurch unnötiger Netzwerktraffic. Wie würden Sie das finden, wenn einer Ihrer Kollegen der einen Mitarbeiter namens Michael fnden will, zu allen anderen käme und fragen würde "Sind Sie Michael? Ich suche Michael!". Dies würde Sie nach einer kurzer Zeit sehr annerven! Sie würden bestimmt bald eine Liste anlegen um allen denen geben, die ständig bei Ihnen nachfragen, dass Sie sie in Zukunft nicht mehr belästigen.

Genau das ist die Funktion eines WINS!

In einer WINS-Umgebung wird eine Anfrage an den WINS-Server geschickt, wenn eine System ein anderes im Netzwerk sucht. Dies geschieht, indem ein UPD Paket an den Port 137 geschickt wird, das einen name_query_request enthält. Der WINS-Server erhält das Paket und sieht in seiner Datenbank nach, welche IP-Adresse dem entsprechenden NetBIOS-Name zugeordnet ist.

Wie passiert das also? In Wirklichkeit passiert eine ganze Dinge mehr, als nur eine simple Anfrage und eine kurze Antwort! Es ist eine Serie von Prozessen. Betrachten wir dazu unseren oben Beispielserver (SERVER2 10.1.1.2) der beim WINS-Server (NT-WINS 10.2.1.2) nach der IP-Adresse von SERVER1 (10.3.1.2) fragt.

Bevor wir damit anfangen, sollten noch ein paar Begriffe geklärt werden:

NetBIOS Name Cache Der NetBIOS Name Cache ist ein Speicherbereich, in dem MS Netzwerkprodukte NetBIOS Namen und ihre IP-Adressen zwischenspeichern, die bereits benutzt wurden. Standardmäßig werden solche Zuweisungen für eine Dauer von 600 Sekunden (10 Minuten) gehalten. Nach dieser Zeit erlischt der Eintrag, wenn er nicht neu benutzt wird. Sie können den Inhalt des NetBIOS Cache einsehen, indem Sie an der Eingabeaufforderung folgenden Befehl eingeben:

        nbtstat -c

Dieser Befehl wird in einem eigenen Artikel erklärt, in dem es um Troubleshooting und die dazu notwendigen Tools geht. Vielleicht sehen Sie auch eine Meldung wie "No names in cache", dies muss nichts Schlimmes bedeuten!

LMHOSTS file Ein LMHOSTS-file ist eine Datei, die MS Netzwerkprodukte benutzen Bei Windows NT4 liegt sie normalerweise im WINNT\SYSTEM32\drivers\etc-Verzeichnis. Sie ist vergleichbar zur /etc/hosts auf UNIX-Systemen. Es handelt sich um eine ASCII-Text-Datei die NetBIOS-Namen IP-Adressen zuweist. Diese würde auf der einen Seite unser Broadcast-Problem lösen und das Problem der gerouteten Umgebung umgehen, auf der anderen Seite aber schnell zu einem großen administrativen Aufwand werden, da diese Datei auf jedem Rechner einzeln aktualisiert werden muss! In unserem Fall könnte diese LMHOSTS so aussehen:

        10.1.1.2        SERVER2
        10.2.1.2        NT-WINS
        10.3.1.2        SERVER1
        

Auf der linken Seite steht die IP-Adresse und auf der rechten der zugeordnete NetBIOS Name. (Hier finden Sie eine ausführlichere Betrachtung zur LMHOSTS)

HOSTS file Wie bereits oben erwähnt, ist dies die entsprechende Unix-Datei. Prinzipiell ist sie vergleichbar zur LMHOSTS aufgebaut, dennoch gibt es ein paar Unterschiede NetBT Node Type Alle WINS Clients haben einen spezifischen "Node Type". Bei NT-Systemen finden Sie diesen in der Registry unter

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters

                 Key:         NodeType
                 Value Type:  REG_DWORD
                 Valid Range: 1, 2, 4, 8
                 Default:     8
        

Bei einer Windows 95 Maschine, liegt er in der Registry unter

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\MSTCP

                 Key:         NodeType
                 Value Type:  REG_DWORD
                 Valid Range: 1, 2, 4, 8
                 Default:     8

WINS Query Process

Zunächst schaut SERVER2 in seinem NetBIOS Name Cache nach, ob er die Adresse des Systems, mit dem er kommunizieren will, bereits kennt.

Da der Standard-Typ eines WINS Clients der h-node ist, wird in den weiteren Betrachtungen davon ausgegangen, dass dieser Typ verwendet wird (soweit nicht anders erwähnt).

Betrachten wir nun, wie SERVER2 beim NT-WINS nach der IP-Adresse von SERVER1 fragt:

Zunächst konsultiert SERVER2 seinen eigenen NetBIOS Name Cache, ob er die Information bereits hat. Wenn nicht muss er andere Quellen bemühen.

Davon ausgehend, dass er die Information nicht im Cache hat, ist der nächste Schritt, beim NT-WINS anzufragen, ob er die IP-Adresse von SERVER1 kennt. Dazu sendet er ein UDP-Paket an den Port 137 (name services) zum NT-WINS. Der der WINS-Dienst am NT-WINS auf den Port 137 hört, verarbeitet dieser das eingehende UPD-Paket, da es einen get_name_query request von SERVER2 enthält.

Auf dem NT-WINS sieht der WINS-Dienst in seiner Datenbank nach, ob er eine Zuweisung des NetBIOS-Namen zur IP-Adresse von SERVER1 hat und findet  für SERVER1 den Eintrag 10.3.1.2. Der WINS-Dienst antwortet mit einem Paket an SERVER2 das eine name_query_response und die IP-Adresse von SERVER1 enthält.

Nehmen wir kurz an, dass SERVER1 sich aus irgendeinem Grund nicht beim WINS-Dienst am NT-WINS registriert hat. Wie würde SERVER2 nun die IP-Adresse von SERVER1 finden? Nun, der WINS-Dienst  würde mit einem requested_name_does_not_exist antworten. Daraufhin sendet SERVER2 drei b-node-Broadcasts ins lokale Subnetz schicken,

Da sich SERVER1 nicht im selben Subnetz wie SERVER2 befindet, wird der lokale Broadcast kein Ergebnis zurückliefern. Was nun? Wir sind noch nicht am Ende! SERVER2 prüft nun ob er so konfiguriert ist, eine LMHOSTS zu verwenden. Wenn dies der Fall ist prüft er diese, ob eine entsprechende Namenszuweisung vorhanden ist.

Wenn es nun aber keinen Eintrag in der LMHOSTS gibt, oder wenn die LMHOSTS nicht vorhanden ist? Dann prüft SERVER2 seine TCP/IP-Konfiguration, ob er einen DNS-Server verwenden soll. Wenn alle oben genannten Methoden scheitern, setzt NT einen gethostbyname() Aufruf ab und befragt die lokale HOSTS-Datei. Sollte diese wiederum kein Ergebnis liefern, wendet sich SERVER2 an seinen eingetragenen DNS-Server indem er den selben gethostbyname() Aufruf absetzt.

Nun wird es etwas kompliziert, da, wie bereits erwähnt,  NetBIOS-Namen andere Zeichen zulassen als DNS. In unserem Fall trifft dies glücklicherweise nicht zu, aber zu diesem Sonderfall kommen wir noch.

Wenn SERVER2 bis zu diesem Zeitpunkt nicht in der Lage war, die IP-Adresse für SERVER1 aufzulösen, wird an den aufrufenden Prozess ein Fehler zurückgegeben.

Vielleicht haben Sie sich gewundert, das jedes Mal die etwas ausführliche Formulierung "WINS-Dienst am NT-WINS" verwendet wurde. Der Grund dafür ist, dass sogar der NT-WINS selbst so konfiguriert sein muss, seinen eigenen Dienst zu verwenden (d.h. er muss sich selbst als WINS-Server in der TCP/IP-Konfiguration eingetragen haben). Ohne diesen  Eintrag kann das system seinen eigenen WINS-Dienst nicht nach der Auflösung von NetBIOS-Namen befragen!

WINS Push-Pull Relationships

Vielleicht haben Sie bereits bemerkt, dass die TCP/IP-Konfiguration es nur erlaubt 2 WINS-Server einzutragen. Wer mit der UNIX-Welt vertraut ist, weiß, das dort mehrere DNS-Server in der /etc/resolv.conf eingetragen werden können.

In großen TCP/IP-Umgebungen kann es sinnvoll (und oft notwendig) sein mehr als zwei WINS-Server einzusetzen. Diese WINS-Server können dazu veranlasst werden, ihre Informationen über Subnetze, Domänen oder WANs auszutauschen. Dazu werden diese als Push-Pull-Partner definiert.

Über die "Replikationspartner" im WINS-Manager können die anderen WINS-Server Eingetragen werden.Da die WINS-Replikation ein komplexes Thema ist, soll hier nicht weiter darauf eingegangen werden.

WINS-Unterstützung: WINS Proxy Clients

Eine der Hauptbeschränkungen von WINS liegt darin, dass der Client in der Lage sein muss, den WINS-Server zu befragen. In einem nicht-gerouteten Netz stellt dies kein Problem dar (da Broadcasts verwendet werden können), aber in einem gerouteten Netz kann dies ein Problem sein.

Microsoft hat nun die Windows-Systeme (3.x, 9x und NT) in die Lage versetzt als sogenannter WINS Proxy zu agieren. Prinzipiell bedeutet dies, dass RFC1001-kompatible Systeme die einen WINS-Server nicht direkt befragen können, ihre NetBIOS-Anfragen an ein Proxy-System richten können, das diese Anfrage dann weiterleitet und die entsprechende Antwort zurückliefert.

Integration von WINS und DNS

Microsoft hat seinen eigenen DNS-Dienst in die Lage versetzt, den WINS nach Hostnamen zu befragen. Es gibt im DNS-Admin-Utility eine Stelle, an der auf einen WINS-Server verwiesen werden kann, der die Namensauflösung bereits ausführt. Dabei werden alle Großbuchstaben von NetBIOS-Namen in kleingeschriebene Hostnamen umgesetzt und der DNS-domain-name angefügt.