Netze, die sich von allein konfigurieren und in denen jedes Programm auf magische Weise erfährt, wo sich welcher Drucker versteckt, wie der Fileserver heißt und über welche Adresse der Router seine Weboberfläche anbietet: Dieses Versprechen löst Zeroconf ein, dank Avahi auch unter Linux.
Admins und Heimvernetzer haben Besseres zu tun, als ihre IP-Netzwerke mit Handarbeit und Hintergrundwissen manuell einzurichten. Penibel für passende Adressen sorgen, eigene Nameserver administrieren und ein Verzeichnis aller verfügbaren Ressourcen pflegen gehört nicht zu den interessanten und kreativen Aufgaben. Das Gesamtkonzept Zeroconf mit seinen Teilaufgaben IP-Adressierung, Namensauflösung und Service Discovery (Abbildung 1) erledigt das allein.
Abbildung 1: Das Zeroconf-Gesamtkonzept sorgt für praktische Automatismen auf drei Ebenen: Es vergibt automatisch IP-Adressen, implementiert eine dezentrale Namensauflösung und betreibt darüber Service-Discovery.
Den alten Wunsch nach automatischer Konfiguration von IP-Nummern, Netzmasken und Nameserver-Adressen erfüllt häufig ein DHCP-Server (Dynamic Host Configuration Protocol). Ihn muss der Admin allerdings verwalten. Es geht aber auch ohne zentralen DHCP-Server: IPv4LL [2] vergibt IP-Adressen aus dem privaten Bereich 169.254.0.0/16. Die Computer im Netz ziehen je eine zufällige IP und prüfen, ob diese Nummer noch frei ist. Wenn ja, dann weisen sie die Adresse der lokalen Netzwerkschnittstelle zu. Sollte es trotz aller Vorsicht später zu einem Streit über IPs kommen, löst ein simples, aber effektives Verfahren den Konflikt. Details erläutert der Kasten "IPv4LL".
Besonders nützlich ist IPv4LL in Ad-hoc-Netzwerken: einfach einstecken und loslegen, ohne Hilfe und Koordination eines Administrators. So lassen sich Endgeräte wie digitale Videorekorder, Drucker, Digitalkameras, Stereoanlagen oder auch Internet-Kühlschränke ohne menschlichen Eingriff vernetzen.
Neuere Mac-OS-X- und Windows-Versionen verwenden IPv4LL bereits, wenn auch teils in vereinfachter Form. Windows kennt die Technik unter dem veralteten Namen APIPA (Automatic Private IP Addressing). Das Zeroconf-Programm [4] von Anand Kumria rüstet Linux mit IPv4LL auf. Nach der Installation startet »zeroconf« automatisch für jede lokale Netzwerkschnittstelle und setzt zusätzlich zu manuellen oder per DHCP zugewiesenen IP-Adressen auch immer eine per IPv4LL. Das stellt sicher, dass der Rechner über mindestens eine gültige Adresse verfügt. Beim ausgehenden Datenverkehr entscheidet die Routingtabelle des Linux-Kerns, welche der lokalen Adressen er verwendet, und sorgt so für friedliche Koexistenz von IPv4LL und anderen Adressierungen.
Mit IP-Adressen allein klappt zwar die Kommunikation, ohne Namensvergabe mit DNS (Domain Name System) bleibt sie aber reichlich unkomfortabel. Das klassische DNS-Protokoll funktioniert nach dem Client-Server-Modell: Hierarchisch geordnete Server beantworten die Anfragen der Clientrechner. Ad-hoc-Netze ohne Admin brauchen dagegen einen Peer-to-Peer-Dienst, bei dem alle Computer in einem lokalen Netz den Namensraum gleichberechtigt und gemeinsam organisieren.
Apple hat zu diesem Zweck ein Protokoll namens Multicast-DNS (MDNS, [4]) entwickelt und die Spezifikation freigegeben. Es basiert auf klassischem DNS und stellt unter dem Domänen-Suffix ».local.« einen Raum bereit, in dem Rechner ihre Namen und IP-Adressen registrieren. Im lokalen Netz dient MDNS als unbürokratische Ergänzung des Internet-weiten, stark reglementierten DNS.
Anders als das klassische DNS, das auf Port 53 sendet, arbeitet MDNS auf Port 5353. Das hält beide sauber getrennt, MDNS-Server brauchen auch keine Root-Rechte. Der Aufbau von MDNS-Paketen gleicht den normalen DNS-Paketen aber so stark, dass sogar die bekannten Unix-DNS-Werkzeuge wie »dig« MDNS erzeugen und verarbeiten.
Während die Syntax eines Multicast-DNS-Pakets fast genau der in RFC 1035 definierten DNS-Spezifikation folgt, ist ihre Semantik modifiziert. Zum Beispiel nehmen die Query-Pakete mehrere Fragen auf (Abbildung 2a). Um Bandbreite zu sparen, gibt der Fragesteller auch gleich mögliche Antworten mit: Er sendet die ihm bekannten RRs (Resource Records, also DNS-Datensätze), die auf seine eigene Fragestellung passen. Diese Antworten braucht dann niemand mehr zu geben.
Abbildung 2a: MDNS-Query-Pakete, also Fragen nach DNS-Datensätzen (Resource Records, RRs), dürfen im Gegensatz zu DNS mehr als eine Frage enthalten.
Will ein Multicast-DNS-Rechner einen neuen Datensatz veröffentlichen, dann beginnt er gegebenenfalls mit einem Kollisions-Check. Der stellt sicher, dass nicht zwei Teilnehmer des Netzes sich widersprechende Datensätze registrieren. Der Rechner nutzt dazu eine MDNS-Query, in die er den zu registrierenden RR einbindet, und wartet, ob ein anderer Teilnehmer ablehnend reagiert. Hat er den Kollisionstest bestanden oder ihn für unnötig gehalten, dann gibt er seinen Dienst bekannt. Dazu sendet er unaufgefordert ein Antwortpaket (Abbildung 2b).
Abbildung 2b: Antwortpakete schickt MDNS auch ohne vorherige Frage. Damit publiziert ein Rechner seine Dienste im lokalen Netz.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
