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”.
|
IPv4LL |
|---|
|
Die Adressvergabe mit IPv4LL (IPv4 Link-Local Addresses, [2]) bedient sich bei ARP (Address Resolution Protocol), um für ein Netzwerkinterface automatisch eine freie IP-Adresse zu finden. Die IANA (Internet Assigned Numbers Authority) sieht hierfür den Adressbereich 169.254.0.0/16 vor. Will ein Computer eine IPv4LL-Adresse konfigurieren, wählt er eine zufällige IP-Adresse zwischen 169.254.1.0 und 169.254.254.255. Die ersten 256 und die letzten 256 Adressen hat die IANA für zukünftige Anwendungen reserviert. Der Standard verlangt, dass der Zufallszahlengenerator auch rechnerspezifische Informationen berücksichtigt, zum Beispiel die MAC-Adresse des Netzwerkinterface. Das senkt die Wahrscheinlichkeit, dass zwei Maschinen die gleiche Nummer ziehen. Erst fragen, dann sendenBevor ein Rechner seine IP-Adresse als Absender in IP- oder ARP-Paketen verwendet, muss er prüfen, ob sie wirklich frei ist. Der Test ist immer dann fällig, wenn Linux das Netzwerkinterface aktiviert. Das passiert beim Einschalten oder Rebooten des Computers, beim Aufwachen aus dem Sleep-Modus, aber auch beim Einstecken eines Ethernet-Kabels oder beim Eintritt in ein WLAN. Das IPv4LL-RFC verbietet ausdrücklich periodische Prüfungen, da sie Netzwerkressourcen verschwenden. Vielmehr hat ein Rechner eventuelle Konflikte passiv zu erkennen und darauf zu reagieren. Aktive KonfliktvermeidungFür den aktiven Konflikttest sieht IPv4LL so genannte ARP-Probes vor. In diesen Paketen setzt der Sender die Quell-IP auf 0.0.0.0 und verwendet als Empfänger die zu überprüfende Adresse. Ist der Rechner bereit für die Konfliktprüfung, wartet er zunächst ein bis zwei Sekunden und sendet dann drei ARP-Probes im zufälligen Zeitabstand von ein bis zwei Sekunden. Empfängt der Rechner zwischen Testbeginn und zwei Sekunden nach Ende ein ARP-Paket, das als Absender-IP die zu überprüfende IP-Adresse trägt, dann hat er einen Konflikt aufgedeckt. Die Prozedur beginnt von vorn mit einer anderen zufälligen IP. Empfängt der Computer eine fremde ARP-Probe, die als Empfänger-IP die zu testende IP enthält, muss er ebenfalls auf eine neue Test-IP wechseln. Das passiert eventuell, wenn zwei oder mehr Rechner gleichzeitig die gleiche Link-Local-Adresse probieren. Um ARP-Stürme und damit eine Überlastung des lokalen Netzwerks zu vermeiden, wenn es zu mehreren aufeinander folgenden Konflikten kommt, reduziert jeder Rechner nach zehn Fehlversuchen die Geschwindigkeit, mit der er neue Adressen wählt. Er beschränkt sich dann auf maximal eine Prüfung pro Minute. Die neue Adresse bekannt gebenKonnte er keinen Konflikt feststellen, hat der Rechner die IP-Adresse erfolgreich für sich beansprucht und muss dies bekannt geben. Er sendet dazu zwei ARP-Announcements im Abstand von zwei Sekunden. Hier setzt er als Absender- und als Empfänger-IP die neu ausgewählte Adresse ein. Empfängt der Rechner nach diesem Announcement ein fremdes ARP-Paket, dessen Empfänger-IP die eigene Adresse enthält, hat er passiv einen Adressenkonflikt bemerkt. Er kann dann auf neue IP-Adresse wechseln oder seine bisherige Nummer verteidigen. Letzteres ist zu empfehlen, wenn der Rechner noch TCP-Verbindungen offen hat. Er reagiert darauf mit einem weiteren ARP-Announcement. Gab es in den letzten Sekunden schon einen Adressenkonflikt, muss der Rechner auf eine neue IP-Adresse wechseln, um eine Endlosschleife zu vermeiden. (Andreas Krennmair) |
Einfach loslegen
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.
Namensfragen
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.
Rundruf
Der Name deutet es schon an: MDNS verwendet IP-Multicasting (ein Sender, viele Empfänger, [5]), um jedes Paket gleichzeitig an alle relevanten Computer im lokalen Netz zuzustellen. Klassisches Unicast-DNS sendet jedes Paket dagegen nur einem Adressaten. Zusammen mit intelligentem Cacheing minimiert Multicasting den zusätzlichen Verkehr.
MDNS verwendet die spezielle Multicast-Gruppe 224.0.0.251. Router geben deren Verkehr nicht weiter. Das stellt sicher, dass MDNS-Informationen nicht den Weg ins Internet finden. Dort könnten wieder Namenskollisionen auftreten und ein Sicherheitsrisiko wäre es obendrein, wie der Kasten “Sicherheit von MDNS” erklärt. Außerdem vereinfacht die lokale Multicast-Gruppe die Implementierung: Bei Internet-weitem Multicast (Mbone, Multicast-Backbone) wäre die Hilfe von IGMP (Internet Group Management Protocol) nötig. MDNS braucht diese Infrastruktur nicht, die Funktionen von Ethernet genügen (Multicast-MAC-Adressraum).
|
Sicherheit von MDNS |
|---|
|
Ähnlich wie DHCP ist MDNS ausschließlich für lokale Netzwerke gedacht und explizit nicht fürs Internet. Es besitzt keinerlei Sicherheitsvorkehrungen, alle MDNS-Teilnehmer müssen sich gegenseitig vertrauen. Sie verwalten den Namensraum ».local.« gemeinsam und kooperativ. Erweist sich eine Station als Störenfried oder dringen Angreifer ins lokale Netz ein, ist es für sie einfach, MDNS zu missbrauchen. Sie könnten bereits registrierte Dienste durch eigene unter dem gleichen Namen ersetzen und so etwa den Druckverkehr auf einen Server im Internet umlenken. Auch die bloße Kenntnis der internen Infrastruktur ist schon gefährlich. Um das Risiko zu vermindern, sendet Avahi auf Netzwerkschnittstellen, die ins Internet führen könnten, keinen MDNS-Verkehr. Trotzdem ist es zu empfehlen, zentrale Firewalls so zu konfigurieren, dass sie den UDP-Port 5353 in beiden Richtungen sperren. Die Avahi-Entwickler arbeiten daran, die vom klassischen DNS bekannte DNSSEC-Technik auch für MDNS zu implementieren. Die erlaubt es, MDNS-Verkehr, der nicht mit einem vorgegebenen kryptographischen Schlüssel kodiert ist, zu ignorieren. Somit können nur Computer, die diesen Key kennen, an der ».local.«-Domain teilnehmen. Leider widerspricht dies der Zeroconf-Idee, weil es nötig ist, vorab für jeden Teilnehmer im Netz den Schlüssel zu konfigurieren. |
MDNS-Responder
Auf jedem MDNS-fähigen Rechner läuft ein Hintergrundprozess, der MDNS-Responder. Er abonniert die MDNS-Multicast-Gruppe und reagiert auf Anfragen von anderen Netzwerkrechnern, gibt eigene DNS-Datensätze bekannt und verwaltet den MDNS-Cache.
Unter dem Namen DNS-SD (DNS Service Discovery, [6]) hat Apple eine weitere Technik entwickelt, die besonders gut zusammen mit MDNS harmoniert, jedoch auch mit klassischem DNS arbeitet. Mit DNS-SD fahnden die Rechner nach Dienste-Angeboten im Netz. Sie benutzen die DNS-Hierarchie, um Services anhand eines Namens aufzulösen, zu listen und bekannt zu geben.
DNS-SD begnügt sich mit bereits standardisierten und erprobten DNS-Datentypen, etwa SRV, TXT und PTR. Dadurch ist es ohne weitere Änderungen mit dem klassischen DNS-Server ebenso wie mit MDNS einsetzbar.
Dienste aufspüren
DNS-SD beantwortet zum Beispiel folgenden Wunsch eines Programms: Gib mir eine Liste aller Drucker, die das Unix-Druckprotokoll unterstützen und unter ».local.« registriert sind. Bei MDNS antworten darauf alle lokalen MDNS/DNS-SD-fähigen Drucker mit ihren Kontaktdaten, also IP-Adresse, Portnummer sowie beliebigen zusätzlichen Informationen, etwa dem angebotenen Papierformat. Die Clients dürfen nach beliebigen Dienstetypen suchen. Damit verhält sich MDNS/DNS-SD wie eine generische, für anwendungsspezifische Erweiterungen offene Variante der Windows-Funktion Netzwerkumgebung.
Dienstetypen tragen in DNS-SD kurze Kennungen, etwa »_http._tcp«. Jeder Typ besteht aus zwei Wörtern, die beide mit einem Unterstrich beginnen und durch einen Punkt getrennt sind. Das zweite Wort lautet »_tcp« oder »_udp«, je nach Netzwerkprotokoll. Bei der Anfrage ergänzt der Client noch die Domäne, er fragt also nach »_http._tcp.local.«. Jede Anwendung wählt das erste Wort im Dienstetyp selbst (Tabelle 1). Eine detaillierte Liste von bekannten DNS-SD-Dienstetypen ist auf [7] zu finden.
|
Tabelle 1: |
|
|---|---|
|
Dienstetyp |
Einsatzbereich |
|
_http._tcp |
Webseiten, etwa eine Benutzer-Homepage oder die |
|
_ftp._tcp |
FTP-Angebote zum Austausch von Dateien |
|
_distcc._tcp |
Vom verteilten Compilersystem »distcc« verwendeter |
|
_presence._tcp |
Nutzt Apples I-Chat für ein Instant-Messaging-System im |
|
_sip._tcp |
SIP-Telefonie zum einfachen Auffinden von |
|
_ssh._tcp |
SSH-Dienste |
|
_daap._tcp |
Protokoll für Apple I-Tunes (Musik übertragen) |
Namensfrage, die erste
DNS-SD-Dienste erhalten neben ihrem Typ stets einen eindeutigen Namen, der die jeweilige Instanz eines Dienstes innerhalb des Netzes beschreibt. Ein »_ftp._tcp«-Service könnte “Lennarts Dateien” heißen.
Jedem Dienst kann der Anbieter beliebige Meta-Informationen mitgeben. Es hat sich etwa bei HTTP (Dienstetyp »_http._tcp«) eingebürgert, in den Metadaten einen Pfad zu spezifizieren. Laufen mehrere Webdienste auf demselben Server, dann unterschieden sie sich in diesem Pfad. Ein DNS-SD-fähiger Webbrowser setzt aus den Informationen eine vollständige URL zusammen. Apple bezeichneten die drei Techniken IPv4LL, MDNS und DNS-SD zusammen griffig als Apple Bonjour (ehemals Rendezvous, [8]). Eine gleichnamige Implementierung liefert Apple bei Mac OSÂ X gleich mit, inzwischen gibt es auch eine Windows-Version zum Download.
Guten Tag
Unter Linux stehen gleich mehrere Implementierungen von MDNS/DNS-SD zur Verfügung (Tabelle 2). Am weitesten verbreitet sind bisher HOWL [9] und Apple Bonjour. HOWL basiert auf einer alten Fassung von Apple Bonjour, die unter der APSL steht (Apple Public Source License). Diese kontrovers diskutierte Lizenz geht zwar in die Richtung von freier Software, enthält jedoch einige Haken. So ist etwa das Debian-Projekt zu dem Schluss gekommen, dass die Lizenz gegen die Debian Free Software Guidelines verstößt. Folgerichtig hat Debian HOWL wieder aus seinen Archiven entfernt [11].
|
Tabelle 2: |
|
|---|---|
|
Programm |
Beschreibung |
|
Avahi |
Freie (LGPL) MDNS/DNS-SD-Software [10] |
|
Bonjour |
Das MDNS/DNS-SD-Paket von Apple unter der umstrittenen |
|
HOWL |
Auf Bonjour basierende MDNS/DNS-SD-Implementierung, teils unter |
|
JMDNS |
In Java implementiertes MDNS/DNS-SD [13] |
|
MDNSD |
Embeddable Multicast DNS Daemon, Teilumsetzung von MDNS/DNS-SD |
|
MDNS-Scan |
Simples Werkzeug, das alle im Netzwerk vorhandenen Dienste |
|
NSS-MDNS |
Plugin für den Name Service Switch (NSS) der Glibc; |
|
Pyzeroconf |
Python-Implementierung von MDNS/DNS-SD [16] |
|
TMDNS |
Tiny/Trivial Multicast DNS Responder (unvollständiges |
|
ZCIP |
Unvollständiges IPv4LL [17] |
|
Zeroconf |
Auf ZCIP basierende, aber vollständigere Implementierung |
Andere Distributionen haben ähnliche Vorbehalte, etwa Ubuntu und Red Hat Enterprise Linux. Eine breite Unterstützung von DNS-SD durch die Linux-Gemeinde ist daher mit HOWL oder Bonjour unwahrscheinlich.
Völlig frei von APSL-Code ist Avahi [10], ein vom Autor dieses Artikels maßgeblich mitentwickelter MDNS-Responder. Avahi steht unter der recht liberalen LGPL-Lizenz. Es handelt sich nicht nur um eine MDNS/DNS-SD-Implementierung für Desktop-Computer, sondern um ein ganzes Rahmenwerk, um MDNS/DNS-SD in eigene Projekte einzusetzen, etwa in Druckern und anderen Appliances. Avahi kann einige Dinge mehr als Bonjour, andere Tricks jedoch fehlen noch. Zu den Ersteren gehört MDNS-Reflection, also das Weiterleiten von MDNS-Verkehr zwischen mehreren Subnetzen. Zu den Lücken zählt DNS-Update, also das Registrieren von lokalen Diensten mit normalem DNS.
Avahi: Ganz auf Linux zugeschnitten
Im Gegensatz zu Bonjour ist Avahi auf die Fähigkeiten von Linux zugeschnitten. Unter anderem setzt es die Netlink-Schnittstelle von Linux ein, um auf Änderungen in der lokalen Netzwerkkonfiguration zu reagieren. Es kommuniziert mit anderen Prozessen über den Desktop-Nachrichtenbus Dbus und gibt damit lokal angebotene Dienste bekannt oder sucht nach solchen. Avahi liefert auch Adapter für KDE/Qt-Programme sowie für Gnome-Software. Zudem gibt es eine vollständige Avahi-Bibliothek für Mono/C# (siehe auch Tabelle 3).
|
Tabelle 3: |
|
|---|---|
|
Komponente |
Aufgabe |
|
avahi-core |
Diese Bibliothek implementiert den MDNS-Stack. Es ist |
|
avahi-daemon |
Unix-Daemon. Nutzt »avahi-core« und stellt dessen |
|
avahi-client |
Diese Library implementiert die Client-Seite für |
|
avahi-common |
Bibliothek mit Hilfsfunktionen für |
|
avahi-dnsconfd |
Unix-Daemon, der Informationen über Unicast-DNS-Server aus |
|
avahi-compat-howl |
Kompatibilitätsbibliothek, die die |
|
avahi-compat-libdns_sd |
Kompatibilitätsbibliothek, die die |
|
avahi-sharp |
Modul für Mono/C#, das eine objektorientierte |
|
kdnssd-avahi |
Dieses KDE-Modul setzt die KDNSSD-Schnittstelle von KDE auf |
Das KDE-Projekt hat seine DNS-SD-Abstraktionsschnittstelle KDNSSD [19] bereits auf Avahi portiert. So ist es jetzt möglich, alle DNS-SD-fähigen KDE-Programme mit Avahi einzusetzen. Unter anderem kann der Benutzer mit Hilfe des Dateimanagers Konqueror im Netzwerk nach Diensten wie etwa Dateifreigaben (FTP, WebDAV) suchen.
Auch Gnome plant für Version 2.14 die bisherige HOWL-Unterstützung durch Avahi zu ersetzen. Einige Gnome-Programme (etwa Vino, Rhythmbox, Video-LAN oder Gnomemeeting) sind bereits portiert, einige andere jedoch stehen noch aus. Siehe dazu auch die Hitliste von Avahi-Programmen in diesem Heft ab Seite 90.
Hemmnisse
Noch hinkt die DNS-SD-Integration in Linux-Applikationen ihren Gegenstücken unter Mac OSÂ X hinterher. Für eine umfassende Unterstützung sind sowohl Client- als auch Server-Programme anzupassen. Zurzeit fehlt dies zum Beispiel beim Druckserver Cups oder bei den FTP-Servern. Hinderlich wirkt sich auch aus, dass unter Linux drei inkompatible Programmierschnittstellen konkurrieren (Bonjour, HOWL und Avahi, siehe Tabelle 2). Mehrere MDNS-Responder können aber nicht gleichzeitig auf einem Rechner laufen, da sie alle den gleichen UDP-Port 5353 belegen.
Avahi 0.6 enthält neben der nativen Programmierschnittstelle auch eine (noch unvollständige) Unterstützung für die beide Konkurrenz-APIs von Bonjour und HOWL. Diese Kompatibilitätsbibliotheken sind dazu gedacht, existierende Programme schnell auf Avahi zu portieren. Es ist aber nicht zu empfehlen, neue Software mit ihnen zu programmieren: Sie gehen sehr verschwenderisch mit Ressourcen um. Das Avahi-Projekt hofft, diese Adapter nur für eine kurze Übergangszeit zu benötigen, und sieht darin ausdrücklich keine Dauerlösung. Abbildung 3 zeigt den modularen Aufbau von Avahi. Die Bedeutung der einzelnen Komponenten nennt Tabelle 3.
Abbildung 3: Der Avahi-Daemon nutzt die Bibliotheken Common und Core für MDNS und DNS-SD. Über Dbus kommuniziert er mit Avahi-fähigen Clients (gelb). Diese binden die Avahi-Client-Bibliothek direkt ein oder verwenden eine Kompatibilitätsbibliothek (grün). Gestrichelte Linien markieren externe Komponenten.
Avahi installieren
Eine sinnvolle Minimalinstallation von Avahi 0.6.3 benötigt die Bibliotheken Expat, Libdaemon und Dbus (0.34 oder aktueller). Die Unterstützung für Python, Mono, Qt 3, Qt 4 und Glib ist per Configure-Option abschaltbar, etwa »./configure –disable-qt4«. Anschließend folgt »make && make install«.
Aus Sicherheitsgründen läuft Avahi nicht als Root, sondern mit verminderten Privilegien als Benutzer »avahi« und gleichnamige Gruppe. Die gilt es, als Nächstes einzurichten, etwa auf Debian per »addgroup –system avahi« und »adduser –system –no-create-home –ingroup avahi avahi«. Passend zur Distribution ist noch ein Init-Skript zu aktivieren, das den Avahi-Daemon bei jedem Systemstart automatisch lädt. Unter Debian ist dies per »update-rc.d avahi-daemon defaults 25 15« schnell erledigt.
Nach seinem ersten Aufruf registriert Avahi den lokalen Rechnernamen unter der MDNS-Domäne ».local.« im Netz. Der Dig-Aufruf »dig -p 5353 @224.0.0.251 ecstasy.local« bestätigt dies (Listing 1, Zeile 12) für einen Rechner namens »ecstasy«. Als Portnummer setzt der Aufruf 5353 (Option »-p«) und als DNS-Server die Multicast-Gruppe 224.0.0.251 (Option »@«). Dig zeigt die Antwort mit einem Adresseneintrag (Typ »IN A«), der auf die lokale IP-Adresse 192.168.50.4 verweist.
|
Listing 1: |
|---|
01 ; <<>> DiG 9.3.1 <<>> -p 5353 @224.0.0.251 ecstasy.local 02 ; (1 server found) 03 ;; global options: printcmd 04 ;; Got answer: 05 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59476 06 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 07 08 ;; QUESTION SECTION: 09 ;ecstasy.local. IN A 10 11 ;; ANSWER SECTION: 12 ecstasy.local. 10 IN A 192.168.50.4 13 14 ;; Query time: 28 msec 15 ;; SERVER: 192.168.50.4#5353(224.0.0.251) 16 ;; WHEN: Mon Sep 26 23:26:43 2005 17 ;; MSG SIZE rcvd: 47 |
Bequemer als mit Dig gelingt der DNS-SD-Scan mit dem Werkzeug »avahi-browse«. Der Aufruf »avahi-browse -a« listet alle verfügbaren Dienste im lokalen Netz. Listing 2 zeigt, wie das im Heimnetz des Autors aussieht. Wer lieber mit grafischen Oberflächen arbeitet, greift zu »avahi-discover« (Abbildung 4).
|
Listing 2: |
|---|
01 + eth0 IPv4 WebDAV on ecstasy Secure WebDAV File Share local 02 + eth0 IPv4 Remote Desktop on ecstasy VNC Remote Access local 03 + eth0 IPv4 WebDAV on ecstasy WebDAV File Share local 04 + eth0 IPv4 Remote Terminal on curacao SSH Remote Terminal local 05 + eth0 IPv4 Remote Terminal on ecstasy SSH Remote Terminal local 06 + eth0 IPv4 Remote Terminal on cocaine SSH Remote Terminal local 07 + eth0 IPv4 FTP Repository on ecstasy FTP File Transfer local 08 + eth0 IPv4 Debian FTP FTP File Transfer local 09 + eth0 IPv4 FTP Repository on cocaine FTP File Transfer local 10 + eth0 IPv4 curacao Web Site local 11 + eth0 IPv4 Lennart's Blog Web Site local 12 + eth0 IPv4 ecstasy Web Site local 13 + eth0 IPv4 MLDonkey on cocaine Web Site local 14 + eth0 IPv4 cocaine Web Site local 15 + eth0 IPv4 Printers on cocaine Web Site local 16 + eth0 IPv4 SFTP Repository on cocaine SFTP File Transfer local 17 + eth0 IPv4 distcc@curacao Distributed Compiler local 18 + eth0 IPv4 distcc@cocaine Distributed Compiler local 19 + eth0 IPv4 curacao [00:0c:76:xxxxxxxx] Workstation local 20 + eth0 IPv4 ecstasy [00:0e:a6:xxxxxxxx] Workstation local 21 + eth0 IPv4 cocaine [00:a0:c9:xxxxxxxx] Workstation local |
Abbildung 4: Avahi-Discovery zeigt die MDNS-Antworten als Baum. Am unteren Rand listet es den DNS-SD-Servicetyp für den ausgewählten Eintrag zusammen mit weiteren Daten.
Noch lange nicht jede Software ist darauf vorbereitet, ihre Netzwerkdienste selbsttätig per DNS-SD zu registrieren. Avahi enthält ein Feature, das SD für solche Dienste nachrüstet. Es genügt, im Verzeichnis »/etc/avahi/services« eine XML-Datei mit der Endung ».service« zu hinterlegen. Dieses File enthält Informationen über den Dienst. Listing 3 zeigt ein kommentiertes Beispiel für einen SSH-Dienst »ssh.service«.
|
Listing 3: |
|---|
01 <?xml version="1.0" standalone='no'?> 02 <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> 03 <service-group> 04 <name replace-wildcards="yes">Remote Terminal on %h</name> 05 <service> 06 <type>_ssh._tcp</type> 07 <port>22</port> 08 </service> 09 </service-group> |
Nachdem der Benutzer eine Service-Datei angelegt hat, genügt es, ein Hangup-Signal (Sighup) an »avahi-daemon« zu schicken, um ihn dazu zu bringen, das Dienste-Verzeichnis neu einzulesen: »killall -HUP avahi-daemon«. Ein Aufruf von »avahi-browse -a« sollte den neuen Dienst nun anzeigen.
DHCP-Ersatz
Die neue IP-Version 6 enthält eine Technik für die automatische Konfiguration von IP-Adressen, die ohne DHCP auskommt. Leider fehlt ihr eine Möglichkeit, auch die Adresse eines klassischen DNS-Servers wie mit IPv4-DHCP automatisch zu konfigurieren. MDNS schafft Abhilfe, wenn der Administrator Informationen über den zu verwendenden DNS-Server in der ».local.«-Domäne speichert. MDNS-fähige Clients fragen diese Informationen ab und passen ihre lokale DNS-Konfiguration an.
Avahi liefert für dieses Szenario das Programm »avahi-dnsconfd« mit. Der Daemon kontaktiert einen lokal laufenden »avahi-daemon« und nutzt ihn, um nach DNS-Servern Ausschau zu halten. Findet er einen, führt er ein Skript aus, das zum Beispiel die Datei »/etc/resolv.conf« anpasst. Unter Debian hängt »update-rc.d avahi-dnsconfd defaults 26 14« den Daemon in die Init-Startfolge.
Namensfrage, die zweite
Für eine vollständige Zeroconf-Umgebung fehlt neben dem IPv4LL-Werkzeug »zeroconf« und dem MDNS-Responder Avahi noch eine dritte Software. Damit alle Programme die MDNS-Rechnernamen verstehen (»ecstasy.local.« für den Computer des Autors), braucht Linux ein dazu passendes NSS-Modul (Name Service Switch, Abbildung 1). Für MDNS bietet sich »nss-mdns« [12] an. Es ergänzt die Standard-C-Bibliothek um die neue Variante der Namensauflösung.
Auch ohne lokalen MDNS-Responder kann »nss-mdns« MDNS-Anfragen stellen. Findet es zur Laufzeit jedoch Avahi vor, nutzt es dessen Cache, um den Netzwerkverkehr zu reduzieren. Die Software hängt von keinen externen Bibliotheken ab und ist mit »configure && make && make install« schnell aufgespielt. Um das Modul zu aktivieren, ergänzt der Admin in »/etc/nsswitch.conf« den Hosts-Eintrag um das Modul »mdns4«:
hosts: files dns mdns4
Ein kleiner Test mit »getent hosts ecstasy.local« bestätigt, dass die Namensauflösung nun korrekt funktioniert:
192.168.50.4 ecstasy.local
Auch andere Programme von Firefox bis Ping sollten nun mit ».local«-Domänennamen umgehen können.
Benutzerfreundlich
Mit den drei Programmen »zeroconf«, Avahi und »nss-mdns« gelingt es, ein komplettes freies Zeroconf-System aufzusetzen, das mit den Möglichkeiten von Mac OSÂ X und Windows gleichzieht. DNS-SD verbessert die Benutzerfreundlichkeit lokaler Netzwerkdienste. Es setzt auf kluge Autokonfiguration statt umständliche Dienstesuche. (fjl)
|
Der Autor |
|---|
|
Lennart Poettering studiert in Hamburg Informatik und entwickelt maßgeblich die freie MDNS/DNS-SD-Implementierung Avahi. |
