Seite 5: Namenssuche

Inhaltsverzeichnis

Den Namen Suchen

Die Namen nur mit netsh aufzulösen wird auf die Dauer langweilig. Damit möglichst viele Programme sie benutzen können, hat Microsoft PNRP in den DNS-Resolver des Betriebssystems integriert: Wenn ein Programm beim System nach der Adresse zu einem Namen in der Domain pnrp.net nachfragt, löst Windows ihn nicht über DNS auf, sondern per PNRP. Davon profitieren natürlich nur die Programme, die DNS-Namen nicht selbst auflösen, sondern die Dienste des Betriebssystems nutzen. Anwendungen mit eigener Resolver- Bibliothek wie nslookup oder Opera haben daher nichts von PNRP. Ein Gateway, das DNS-Anfragen für die Domain pnrp.net selbst im PNRP auflöst und die Antwort per DNS zurückliefert, betreibt Microsoft nicht. Bei der Umwandlung einer P2P-ID in einen DNS-Namen (DNS Encoding) werden aus Authority und Classifier zwei DNS-Labels, also durch Punkte getrennte Bestandteile eines Domain-Names. Eine P2P-ID wird von links nach rechts aufgelöst (erst Authority, dann Classifier). Da bei DNS-Namen die Auflösung jedoch von rechts nach links läuft, werden Authority und Classifier vertauscht. Weil der PNRP-Classifier Unicode-Zeichen enthalten kann, wird er gemäß Punycode umgewandelt. Falls die Punycode-Umwandlung nicht nötig ist, wird ein p vorangestellt und "-p" angehängt. Sollte das Authority-Label mit einer Ziffer beginnen (was die DNS-Regeln verbieten), kommt auch ein p davor. Für ungesicherte P2P-IDs gibt es dann eine platzsparende Kürzung: Sofern der Classifier nicht mit Punycode bearbeitet wurde, fallen das Authority-Label p0 und die Dreingaben am Classifier-Label wieder weg.

Aus der P2P-ID 0.mypnrpname entsteht so der DNS-Name mypnrpname.pnrp.net (oder pmypnrpname-p.p0.pnrp.net), aus 0.MyPNRPName wird mittels Punycode für die Großbuchstaben yame-4kahaobt.p0. pnrp.net. Diese Umrechnung erledigt der Befehl show convertedname im peer-Kontext von netsh in beiden Richtungen.

Leuchtfeuer

Um zu zeigen, wie eine native PNRP-Anwendung funktioniert, stellen wir das Beispielprogramm Beacon (englisch für Leuchtfeuer) zur Verfügung. Es nimmt beliebig viele Schlagwörter entgegen und generiert daraus P2PIDs, die es in der globalen Wolke registriert. Im Hintergrund sucht Beacon nach denselben PNRP-Namen, um Gleichgesinnte in der IPv6-Einsamkeit zu finden. Dabei sendet es bei jeder Anfrage eine Liste der schon bekannten PNRP-Knoten für das Schlagwort mit, sodass immer neue Knoten gefunden werden. Diese präsentiert das Programm gruppiert in einer minimalen grafischen Oberfläche. Auf Klick auf ein Stichwort zeigt Beacon zu dem Knoten weitere Details wie IPv6-Adressen, Rechnername, Betriebssystem und Anzahl der Prozessoren. Diese Informationen werden in der Extended Payload übertragen.

Wer Beacon selbst kompilieren oder mit den PNRP-Funktionen herumspielen möchte, benötigt Visual Studio 2008 (auch in der kostenlosen Express-Edition) und das .NET Framework 3.5 SP1, da erst diese Kombination PNRP vollständig unterstützt.

Wie die neue "Easy Connect"-Funktion der Remote- Hilfe in Windows 7 funktioniert, zeigt netsh: Wenn man mit cloud show names vor und nach der Hilfeanforderung die registrierten P2P-IDs vergleicht, entdeckt man in der globalen Wolke eine neue. Sie ist nicht signiert (Authority 0) und der Name besteht nur aus hexadezimalen Ziffern. Auf dem PC des Helfers berechnet Windows aus dem Remote-Hilfe-Passwort diese Zahl, löst die P2P-IP per PNRP auf und stellt die Verbindung per IPv6 her – an allen störenden IPv4-NAT-Routern vorbei. Beim Einrichten einer HomeGroup sieht man dagegen eine zusätzliche gesicherte P2P-ID in der Link-lokalen Wolke. Der Rest der Zauberei steckt in anderen Protokollen, die nicht Gegenstand dieses Artikels sind. Microsoft stellt sich PNRP auch als Alternative zu DynDNS vor. Das heißt dann Windows Internet Computer Name (WICN) und läuft über den "PNRP-Computernamenveröffentlichungs-Dienst", den ebenfalls netsh steuert. Mit

peer set machinename publish=start

veranlasst man ihn, eine P2P-ID bis zum nächsten Neustart zu registrieren. Soll er das immer automatisch tun, setzt man dem Befehl noch autopublish=enable hinzu. Allerdings ist die dazu automatisch erzeugte P2P-ID eine gesicherte mit leerem Friendly Name, besteht also nur aus 64 hexadezimalen Ziffern und einem Punkt. Um von anderswo auf den PC zuzugreifen, taugt das nicht, da kann man sich auch gleich die IPv6-Adresse merken. Deshalb ist es möglich, die veröffentlichte P2P-ID mit dem Parameter name= zu setzen. Am einfachsten ist das mit einer unsignierten ID. Die Windows-Kommandozeile

netsh p2p pnrp peer set machinename name="0.mypnrpname" publish=start
autopublish=enable

richtet die selbst gewählte ID "mypnrpname" dauerhaft ein. In den Tests in der c’t-Redaktion funktionierte PNRP in der Link-lokalen Wolke sehr gut. Die Auflösung einer selbst registrierten P2P-ID über die globale Wolke mit der IPv6- Verbindung über Microsofts Teredo-Tunnel schlug dagegen oft fehl. Die Wolken-Statistik cloud show statistics zeigte zwar sowohl für den registrierenden als auch für den anfragenden Rechner sinnvolle Werte an. Doch offenbar zerfällt die globale Wolke manchmal in mehrere Teile. Vielleicht liegt das ja an der geringen Zahl von Nutzern, die jedoch spätestens mit der Verbreitung von Windows 7 steigen dürfte.