Ohne DNS und DHCP kein VoIP

12.09.2007 von Richard Hyatt
Backup, unterbrechungsfreie Stromversorgung und ein hochsicherer Server-Raum – alles probate Mittel, um Netzwerk und VoIP-Infrastruktur zu schützen. Doch ohne zuverlässige und einfach zu verwaltende Grunddienste wie DHCP und DNS kommt erst gar keine Verbindung zustande.

Nachdem Voice over IP eine Zeitlang das Hype-Thema schlechthin war, ist es mittlerweile ruhiger um das Telefonieren per Datenpaket geworden. Das heißt aber nicht, dass die Kunden das Interesse an VoIP verloren hätten. Mittlerweile sind eine ganze Reihe von Herstellern am Markt aktiv, die Systeme für alle Unternehmensgrößen anbieten: von der Drei-Platz Lösung, die ohne zentralen Server auskommt, bis zur Enterpriselösung für multinationale Konzerne.

Sprache und Daten zu kombinieren wird im Endeffekt der größte Gewinn von VoIP sein. Mit VoIP kann man sein Telefon zu einem sehr leistungsfähigen und intelligenten Bestandteil der Bürokommunikation machen, damit sind Funktionen möglich, die mit einem herkömmlichen, analogen Telefon niemals realisierbar wären.

Wie auch immer die Implementation aussieht, fest steht: wer sich ausschließlich auf VoIP für die Sprachkommunikation verlässt, muss dafür Sorge tragen, dass der Dienst eine mindestens ebenso hohe Verfügbarkeit hat, wie herkömmliche Telefonie. Dass die Infrastruktur, also Switche und Router, redundant ausgelegt sind, versteht sich in so einem Fall von selbst. Auch der Server mit der eigentlichen IP-Telefonanlage wird meist durch entsprechende Maßnahmen gesichert. An eine weitere Grundvoraussetzung für reibungsloses VoIP denken allerdings die wenigsten – den DHCP- und DNS-Dienst.

IP-Adresse = Telefonnummer

VoIP-Telefone sind wie jedes IP-basierte Gerät auf eine IP-Adresse angewiesen, um überhaupt mit dem Netzwerk kommunizieren zu können. In der Regel erledigen das einer oder mehrere DHCP-Server in den Netzwerksegmenten. DHCP erlaubt das zentrale Verteilen und Verwalten von IP-Adressen im Netzwerk sowie zu einem großen Teil auch die Konfiguration von Hosts durch das Verschicken von Optionslisten und Config-Dateien.

Gesucht - gefunden: Ein DHCP-Client erhält IP-Adresse und andere Konfigurationsparameter vom DHCP-Server.
Erweitertes DHCP: Ein VoIP-Phone benötigt noch zusätzliche Konfigurationsdaten, um telefonieren zu können.

VoIP-Telefone benötigen komplexere Konfigurationen als ein PC, der in der Regel mit IP-Adresse, Netzmaske und Gateway auskommt. So werden Daten wie der nächste SIP-Proxy und der zuständige TFTP-Server per DHCP verteilt, Informationen, ohne die viele VoIP-Geräte nicht funktionsfähig sind. Ohne DHCP müssten alle Infos „fest“ also, manuell vorgegeben werden, eine Aufgabe, die in größeren Netzwerken unmöglich und schon in kleineren Netzen bei jeder Änderung extrem aufwändig ist.

DHCP kurz erklärt

Jedes netzwerkfähige Gerät mit einem DHCP-Client kann Anfragen an einen DHCP-Server senden. Welche Daten zurück geliefert werden, bestimmen Client und Server gleichermaßen. Am Server müssen die Parameter konfiguriert sein, der Client einen entsprechenden Eintrag in seiner Konfiguration benötigen. Der Ablauf ist in der RFC 2131 festgelegt und standardisiert. Er beinhaltet mehrere Schritte, die über das Netzwerkprotokoll UDP abgewickelt werden.

Der Client schickt zuerst eine Discover-Nachricht aus, um den nächsten verfügbaren DHCP-Server im lokalen Netzwerksegment zu finden. DHCP-Broadcasts werden von Routern nicht weitergeleitet, es sei denn man verwendet einen DHCP-Relay-Agent. Der kennt andere DHCP-Server und schickt Anfragen weiter, wenn er glaubt, dass sie in einem anderen Segment besser aufgehoben sind. Im Discover-Paket enthalten ist die MAC-Adresse des Clients, die ihn gegenüber dem DHCP-Server eindeutig identifiziert.

Antworten von mehreren DHCP-Servern

Gibt es mehr als einen DHCP-Server, können mehrere Antworten auf die Discover-Nachricht zurückkommen. Deren Inhalt kann der Server vom anfragenden Netzwerkgerät abhängig machen, zum Beispiel von dessen Hersteller oder von gerätespezifischen Infos.

Das VoIP-Gerät akzeptiert entweder die erste gültige Antwort auf seine Discover-Nachricht oder wählt in Abhängigkeit des Inhalts aus, zum Beispiel weil die Lease-Time für die IP-Adresse bei dieser Nachricht am längsten ist, der Client beim Server also weniger häufig um eine Verlängerung der Lease-Zeit bitten muss. Hat sich der Client für eine Discover-Antwort entschieden, fordert er beim Server die gewählte IP-Adresse, weitere Daten sowie die erste Verlängerung der Lease-Zeit an.

Bevor der Client sein Netzwerkinterface mit der zugewiesenen Adresse konfiguriert, sollte er noch prüfen, ob er als einziger im Netz diese Adresse beansprucht. Ein Administrator könnte versehentlich die gleiche IP-Adresse manuell zugewiesen und vergessen haben. In der Regel schickt der Client dazu einen ARP-Request mit der neu zugeteilten IP-Adresse aus und „horcht“ ob es eine Antwort mit der gleichen IP- aber einer anderen MAC-Adresse gibt.

DHCP-Optionen

Weitere Parameter werden durch so genannte DHCP-Options zugewiesen. Das ist besonders für VoIP-Geräte interessant, da diese oft eine erheblich komplexere Konfiguration vom DHCP-Server erwarten, als ein Arbeitsrechner. Sie müssen auch Informationen wie die Adresse des SIP-Proxies wissen, über den der Rufaufbau läuft, oder sie benötigen einen gültigen TFTP-Server, von dem sie beim Start eine Konfig-Datei oder ihr komplettes Boot-Image ziehen können.

Class "bluecat-voip-device" {
Match if option vendor-class-identifier = "bluecat.voip.device";
#Teilnehmer fordert die Werte bestimmter Konfigurationsparameter an
#1 = Angabe der Subnetzmaske des Teilnehmers
#3 = Angabe einer Liste der IP-Adressen der Router im Subnetz
#28 = Angabe der Übertragungsadresse des Subnetzes
#43 = Angabe der herstellerspezifischen Informationen
#54 = Angabe des DHCP-Server-Identifiers für DHCPOFFER/DHCPREQUEST
#60 = Angabe des Klassen-Identifiers des Herstellers
#67 = Angabe des Namens der Bootdatei
#120 = Angabe des SIP-Servers
#150 = Angabe der TFTP-Serveradresse
option dhcp-parameter-request-list 1, 3, 28, 43, 54, 58, 59, 60, 67, 120, 150;
option vendor-encapsulated-options "bluecat.voip.device.opt";
option bootfile-name "BLUECAT.BOOT";
option option-120 172.18.210.3;
option option-150 172.18.210.3;
}

Um so wichtiger also, dass der DHCP-Server stabil und allzeit verfügbar bereit steht. Leider sind ausgewachsene Redundanzfunktionen kein Bestandteil der häufig genutzten Netzwerkbetriebssysteme. Es gibt zwar Workarounds wie die Adressen in anschließende Bereiche aufzuteilen und sie von jeweils einem DHCP-Server versorgen zu lassen. Doch man vergeudet dabei die Hälfte der nutzbaren Adressen und wenn man Reservierungen benötigt, also manuell fest mit einer MAC-Adresse gekoppelten IP, ist die Methode ebenfalls nicht geeignet. Bei Microsoft Betriebssystemen ist in der Regel ein Cluster die einzige sichere Lösung für redundantes DHCP.

DNS und VoIP

Der Umgang mit Telefonnummern und Domänennamen ist ein weiterer Stolperstein auf dem Weg zur reibungslosen VoIP-Implementation. Geht es nur um Computer ist die Sache klar: ein DNS-Server setzt normal-verständliche Domänennamen wie www.beispiel.de in eine IP-Adresse um. DNS ist in fast allen Firmen, mit Ausnahmen von sehr kleinen Netzen, Grundvoraussetzung für den Datenaustausch.

Und selbst wenn es sich nicht lohnt, einen eigenen DNS-Server zu betreiben: sobald es einen Router für den Internetzugang gibt, ist auch DNS im Spiel. Der Router agiert entweder selbst als DNS-Server oder leitet Anfragen an den DNS-Server des Internet-Service-Providers weiter.

Im Fall von VoIP kommt eine weitere Komponente ins Spiel. Nicht Domänennamen sondern Telefonnummern sollen in eine IP-Adresse und einen passenden Dienst übersetzt werden. Durch eine Technologie namens ENUM kann sich nämlich hinter einer international standardisierten Telefonnummer (E.164) auch ein anderer Dienst verbergen: ein analoges Telefon, ein Handy, eine Mail-Adresse oder sogar eine Webseite.

Das Anrufziel per ENUM

Die Entscheidung darüber, wo ein Anruf im Endeffekt ankommt, hängt von Parametern ab, die im dazugehörigen DNS-Eintrag in Form von „Naming Authority Pointer Records“ (NAPTR) hinterlegt sind. Damit lassen sich Dienste definieren, zuordnen und priorisieren. Die Applikation, von der die Kontaktanfrage, zum Beispiel ein Anruf, ausgeht, sucht sich unter der angegebenen ENUM-Nummer die richtige Zieladresse und den passenden Dienst.

E164: Der DNS-Request liefert beim Rufaufbau auch gleich den richtigen SIP-Proxy mit, über den der Teilnehmer erreichbar ist.

ENUM, im RFC 3761 definiert, führt das Telefonnetz mit dem IP basierten Internet zusammen. Weil es sich, im Gegensatz zu den Telefonnummern, die der ITU unterstehen, um eine Internet-Ressource handelt, ist eine Top-Level Domain dafür vorgesehen: e164. ENUM-Mappings sind letztendlich nichts anderes als DNS-Einträge, auch wenn das Format gewöhnungsbedürftig ist. Die Umsetzung einer Telefonnummer in die korrespondierende ENUM-Domain läuft nach einem einfachen Muster ab:

Diensteauswahl

Der Vorgang läuft in den meisten ENUM-fähigen Clients automatisch ab, der Benutzer gibt nur die gewünschte Telefonnummer ein. Das Ergebnis ist ein vollständiger Domainname („Fully Qualified Domain Name“ = FQDN) der wie jeder andere Domainname verwendet werden kann. Die Unterscheidung, welcher Dienst unter diesem Domainnamen wartet, erledigen die Naming Authority Pointer Records.

Wählt der Benutzer die Nummer eines VoIP-Telefons, wird durch ENUM zunächst über das DNS-System die Nummer bis zum NAPTR-Eintrag aufgelöst. Für jede Domain können mehrere NAPTR-Einträge gesetzt werden, für jede Kommunikationsadresse eine. Die Auswertung dieser Resource Records ergibt einen oder mehrere Uniform Resource Identifier (URI), unter dem der gewünschte Service der angegebenen Domain bzw. Telefonnummer angesprochen werden kann.

NAPTR-Records liefern diese zusätzlichen Informationen auf sehr flexible Art und Weise. Es gibt Präferenzen, welcher Dienst in der Regel verwendet werden sollte, durch mehrere NAPTR-Records gleicher Priorität zu einem Namen, lässt sich sogar eine Art Lastverteilung erreichen. Der NAPTR-Record-Typ kann damit als eine Erweiterung des klassischen A-Records oder auch SRV-Records eines DNS-Eintrags angesehen werden.

Die Struktur von NAPTR-Records hingegen ist komplex. So wird auf eine Anfrage kein Domänenname zurück geliefert, sondern ein regulärer Ausdruck (regular expression), den man als erstes zerlegen muss. Ein regulärer Ausdruck ist eine Zeichenkette, die der Beschreibung von Mengen beziehungsweise Untermengen von Zeichenketten mit Hilfe bestimmter syntaktischer Regeln dient.

Letztendlich geht es darum, den Uniform Ressource Identifier (URI) aus dem regulären Ausdruck zu extrahieren. Ein URI besteht aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource dient. URIs werden zur Bezeichnung von Ressourcen wie Webseiten, Aufruf von Webservices aber auch E-Mail-Empfängern eingesetzt.

DNS und DHCP sind zentrale Komponenten von VoIP

Der korrekte Umgang mit ENUM, NAPTR und den dahinter verborgenen Diensten ist Aufgabe des DNS-Servers. Bei den mit dem Betriebssystem gelieferten Versionen ist dazu in der Regel keine gesonderte Konfigurationshilfe vorgesehen.

Administratoren müssen die fehlerträchtige Verwaltung von ENUM und NAPTR Einträgen mit Bordmitteln vornehmen, wenn sie überhaupt möglich sind. ENUM erfordert in jedem Fall mehr Aufwand bei der DNS-Verwaltung auf Seiten des Administrators, als bei einem reinen Daten-Netzwerk. Dazu gehört das Mappen von E.164 Nummern zu Fully Qualified Domain Names und die Verwaltung von NAPTR Ressource Records.

Zur Umsetzung der URI in einen korrekten, vom Benutzer angeforderten Dienst erfolgt eine potenziell komplexe - und damit fehlerträchtige - Ersetzung per regulärem Ausdruck. Spezialisierte Appliances bieten dafür einfache Tools und Wizards, die dem Administrator viel Arbeit abnehmen und die den Umgang mit ENUM-Zonen und NAPTR Datensätzen vereinfachen. (mha)

Richard Hyatt, CTO und Mitgründer von BlueCat Networks

In seiner Rolle als Chief Technology Officer bei BlueCat ist Richard Hyatt der technologische Visionär des Unternehmens und zeichnet für die Produktentwicklung und die Führung der verschiedenen Teams verantwortlich. Hyatt verfügt über ein umfangreiches Know-how und Expertenwissen in verschiedenen Programmiersprachen und dem Design von komplexen Systemen, Anwendungen und Betriebssystemen im Hinblick auf die Umsetzung in den integrierten Netzwerklösungen von BlueCat. Im Jahr 2000 wurde er von Ernst & Young zum Entrepreneur of the Year Award nominiert.

((Kasten))

ENUM Rufnummern in Deutschland und Österreich

Bevor die eigene Rufnummer als ENUM-Domain nutzbar ist, muss sie wie eine reguläre Domain registriert werden. In Deutschland wird die Rufnummerngasse +49 von der DENIC verwaltet, in Österreich ist ENUM.at für die Rufnummerngasse +43 zuständig. Die Organisationen vergeben die ENUM-Domänen aber nicht direkt, sondern über Mitgliedsprovider und Telefongesellschaften. Voraussetzungen für die Registrierung sind:

Die in Deutschland zur Verfügung stehenden Rufnummerngassen sind:

In Österreich sind folgende Rufnummernbereiche für die Nutzung mit ENUM vorgesehen: