Wird die Namensreservierung und -auflösung ausschließlich per Broadcast durchgeführt, kann man Rechner, die hinter Routern liegen, nicht erreichen. Broadcasts verbleiben in den Subnetzen, in denen sie ausgesendet wurden.
Der einfachste Weg, die Namensauflösung über Subnetzgrenzen hinweg zu realisieren, geht über eine statische Tabelle. Unter Windows heißt diese Datei LMHOSTS. Sie liegt abhängig von der Windowsversion in unterschiedlichen Verzeichnissen und lässt sich am einfachsten mit der Suchfunktion des Explorers finden. Diese Datei ist ähnlich aufgebaut wie die Datei /etc/hosts unter Unix. Ein Beispieleintrag ist der folgende:
192.168.1.5 samba
Die Einträge in der LMHOSTS können durch den Zusatz #PRE ergänzt werden. Dieser Zusatz legt fest, in welcher Reihenfolge die Namensauflösung vorgenommen wird. Ist kein #PRE vorhanden, so wird zunächst eine konventionelle Namensauflösung per Broadcast versucht. Erst, wenn diese fehlschlägt, wird in der LMHOSTS nachgeschaut. Ist der Zusatz vorhanden, so wird ohne Namensauflösung direkt der Wert in der LMHOSTS verwendet.
Die zweite Möglichkeit, das Problem zu lösen, ist eine zentrale Datei LMHOSTS. Dazu gibt den WINS-Server. Ein solcher Server ist nicht mehr als ein Rechner, bei dem sich jede Applikation im Netz mit ihren Namen anmeldet. Die IP-Adresse dieses Servers muss jedem Rechner mitgeteilt werden. Bei Windows geschieht dies in den Eigenschaften des TCP/IP Protokolls im Reiter WINS-Adresse. Setzt man DHCP-Server ein, kann man ebenfalls den WINS-Server festlegen. Samba bekommt die Adresse mit dem Parameter wins server = <ip-adresse> im Abschnitt [global] der smb.conf mitgeteilt. Sobald ein Client seinen WINS-Server per IP-Adresse kennt, ist es völlig gleichgültig, ob sich dieser im gleichen Subnetz befindet oder nicht.
Die Namensreservierung erfolgt nicht mehr per Broadcast, sondern mit einem ganz normalen gerichteten UDP-Paket an den WINS-Server. Gerichtete Pakete werden selbstverständlich ganz normal an den WINS-Server weitergeleitet. Dieser sieht in seiner Tabelle nach, ob der Name bereits reserviert ist. Ist das nicht der Fall, so wird er spontan eine Bestätigung der Reservierung zurückschicken. Diese Reservierung gilt nun für eine bestimmte Zeit und muss rechtzeitig erneuert werden.
Ist der Name bereits reserviert, wird der WINS-Server den bisherigen Besitzer befragen, ob er den Namen noch benötigt. Bekommt er keine Antwort, wird er dem neuen Besitzer ebenfalls eine Bestätigung schicken. Möchte der alte Besitzer den Namen noch verwenden, so wird der Anfragende eine Ablehnung der Reservierung erhalten. Diese Nachfrage ist notwendig, um einem abgestürzten Rechner das spontane Booten zu ermöglichen, da bei einem Absturz keine Freigabe der Namensreservierung erfolgen kann.
Samba kann ganz normal als WINS-Server konfiguriert werden, indem der Parameter wins support = yes gesetzt wird. Ist diese Parameter gesetzt, kann Samba nach einem Neustart bei allen Clients und allen sonstigen Servern als WINS-Server eingetragen werden. Werden diese dann neu gestartet, melden sie sich beim WINS Server an.
Wenn nun ein Rechner mit Samba als WINS Server konfiguriert ist, und sich die anderen Rechner dort anmelden, werden diese in der Datei /var/lock/samba/wins.dat abgelegt. Der nmbd pflegt diese Datei dynamisch, je nach Reservierungen und Abmeldungen. Die Datei wins.dat wird in regelmäßigen Abständen geschrieben. Wenn es notwendig sein sollte, den wirklich aktuellen Stand unabhängig von diesem Zeitintervall zu erhalten, so kann man dem nmbd das HUP-Signal senden. Außerdem wird die wins.dat beim Beenden des nmbd geschrieben.
Diese Datenbank wird auf Festplatte gehalten, damit die Daten einen Neustart von Samba überleben. Jeder Rechner, der einen Namen für sich reserviert hat, hat diese Reservierung für einen bestimmten Zeitraum ausgesprochen. Wenn Samba jetzt neu gestartet werden sollte, und dadurch die Datenbank verloren ginge, wäre der gesamte NetBIOS-Namensraum nicht mehr verfügbar. Außerdem kann ein WINS Server die angeschlossenen Clients weder von sich aus finden, noch sie darum bitten, sich erneut zu registrieren. Daher ist die WINS Datenbank über Neustarts von Samba hinaus zu erhalten.
WINS hat gegenüber der broadcastbasierten Namensreservierung einige Vorteile. Namensreservierung per Broadcast erfolgt durch Wartezeiten. Es wird die Reservierung angekündigt, es wird gewartet, die Reservierung wird erneut angekündigt, und es wird wieder gewartet. Dieses Spiel wiederholt sich mehrfach, bis der Rechner sicher sein kann, dass ein eventueller Vorbesitzer des Namens genug Zeit hatte, sich zu beklagen. Beim Einsatz von WINS entfallen diese Wartezeiten, da hier ein einziger Rechner sämtliche reservierte Namen registriert und in seiner Tabelle nachschauen kann. Daher ist die Reservierung per NetBIOS deutlich schneller, und auch weniger netzbelastend. Selbst wenn man also nur ein einziges Subnetz hat, sollte man zur Reduzierung der Netzlast den Einsatz eines WINS-Servers in Erwägung ziehen.
Zusätzlich sei hier angemerkt, dass es netzwerkweit nur einen einzigen WINS-Server geben darf. Selbst wenn es unterschiedliche Arbeitsgruppen oder Domänen gibt, darf es nicht mehr als einen WINS-Server geben. Setzt man mehrere ein, hat man getrennte Namensräume. Rechner im einen Namensraum können mit Rechnern, die an einem anderen WINS-Server angeschlossen sind, nicht kommunizieren. Es kann trotzdem zu Kollisionen kommen, da Windowsrechner bestimmte Namen unabhängig von WINS-Einstellungen ausschließlich per Broadcast reservieren. Unter Windows NT kann man mehrere WINS-Server einsetzen, die sich gegenseitig abstimmen. Diese WINS-Server treten gegenüber den Clients als ein einziger Server auf, unabhängig von ihrer Anzahl.
Die Abfrage eines WINS Servers durch nmblookup erfolgt beispielhaft folgendermaßen:
nmblookup -R -U 192.168.1.5 samba
Hiermit wird der WINS Server, der auf dem Rechner 192.168.1.5 liegt, nach dem Namen samba befragt.
Samba kennt zwei zusätzliche Funktionen, die es im Zusammenhang mit WINS interessant machen. Einerseits kann Samba als WINS Proxy eingerichtet werden, indem wins proxy = yes gesetzt wird. Ist diese Einstellung aktiv, dann wird Samba sämtliche Reservierungen und Anfragen, die es aus dem lokalen Netz per Broadcast erhält, an den mit wins server = konfigurierten WINS Server weiterleiten. Damit kann man einen Samba-Server in ein Subnetz stellen. Sämtliche Rechner in diesem Netz werden nun beim WINS angemeldet, und nutzen diesen auch. Dies ist auch dann der Fall, wenn sie entweder selbst keinen WINS Server ansprechen können oder nicht dafür konfiguriert sind. Man sollte jedoch in jedem Fall eine echte Konfiguration des WINS Servers auf dem Client vorziehen. Ein WINS Proxy kann nur eine Lösung Behelfslösung sein, da man sich damit auf einen weiteren Rechner verlässt.
Unter Windows kann man statische Einträge im WINS vornehmen. Dies geht so direkt unter Samba nicht. Man muss hierzu den Parameter dns proxy = yes auf dem WINS Server setzen. Empfängt der WINS Server nun eine Anfrage, die er nicht aus seiner Datenbank beantworten kann, wird er eine ganz normale Unix-Hostnamenanfrage machen. Typischerweise wird er in der /etc/hosts nachschauen und danach dann das DNS anhand der Konfiguration in der Datei /etc/resolv.conf befragen. Damit ist es durch einen Eintrag auf dem WINS Server möglich, den gesamten DNS-Namensraum auch in der NetBIOS-Namenswelt zur Verfügung zu stellen.