Die Verwendung des Session Initiation Protocols (SIP) baut an verschiedenen Stellen, ähnlich wie das Simple Mail Transfer Protocol (SMTP), auf DNS-Funktionalitäten auf. Im RFC 3263 sind einige dieser Anforderungen von Seiten des SIP an das DNS beschrieben. Das folgende stellt eine beispielhafte Zusammenfassung dieser Anforderungen dar.
Für die Lokalisierung von
Diensten innerhalb einer Domain (oder eines Hosts)
existieren sog. Service Records (SRV) im DNS. Ein SRV Record
ist vergleichbar dem MX-Record für die Mailzustellung.
Ein SRV-Record ist allerdings wesentlich allgemeiner
gehalten.
Über einen SRV-Record können für einen
spezifischen Dienst ein oder mehrere Server angegeben
werden. In der Regel werden diese Angaben auf Ebene der
Domain hinterlegt. Der Service wird dabei über den
Namen angesprochen unter dem er bei IANA registriert wurde.
Damit keine Verwechslung mit realen Namen möglich ist,
wird diesem sog. Servicenamen ein Unterstrich vorangestellt
(Wer den Servicenamen eines Dienstes wissen möchte
schaut am besten in der Datei /etc/services nach).
Das verwendete Transportprotokoll wird ebenfalls mit
vorangestelltem Unterstrich als Subdomain angehängt,
und damit wird eine Anfrage an das DNS mit Recordtyp SRV
durchgeführt.
Beispiel:
$ dig srv _sip._udp.iptel.org ; <<>> DiG 9.2.3 <<>> srv _sip._udp.iptel.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21628 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;_sip._udp.iptel.org. IN SRV ;; ANSWER SECTION: _sip._udp.iptel.org. 86400 IN SRV 0 0 5060 fox.iptel.org. ;; AUTHORITY SECTION: org. 159030 IN NS TLD2.ULTRADNS.NET. org. 159030 IN NS TLD1.ULTRADNS.NET. ;; ADDITIONAL SECTION: TLD1.ULTRADNS.NET. 159030 IN A 204.74.112.1 TLD2.ULTRADNS.NET. 159030 IN A 204.74.113.1 ;; Query time: 97 msec ;; SERVER: 10.14.33.67#53(10.14.33.67) ;; MSG SIZE rcvd: 152
Als Ergebnis erhält man einen oder mehrere SRV-Records die letztlich auf einen Host verweisen der den geforderten Dienst (hier SIP als UDP Dienst) unter dem angegebenen Port (hier 5060) anbieten.
In der Zone müssen entsprechende Records hinterlegt werden:
$ORIGIN example.com.
; Prio Weight Port Server
_sip._udp IN SRV 10 0 5060 server.example.com.
_sip._tcp IN SRV 10 0 5060 server.example.com.
_sip._udp IN SRV 20 0 5060 backup.ex.de.
_sip._tcp IN SRV 20 0 5060 backup.ex.de.
_sips._tcp IN SRV 10 0 5060 server.example.de.
Ein SIP-Client kann als
Transportprotokoll entweder UDP oder TCP verwenden.
Zusätzlich ist eine sichere Variante des Protokolls
(SIPS) über TLS und TCP definiert.
Der Client muß eine Möglichkeit haben
herauszufinden welche Protokolle von einem SIP Server
angeboten werden, damit er anschließend eine
entsprechende SRV-Anfrage durchführen kann. Für
diesen Zweck werden laut RFC3263 NAPTR-Records verwendet.
Diese werden hierbei, anders als bei der
e164-Rufnummernauflösung über
ENUM, mit dem Flag s
verwendet und stellen damit ein Mapping auf die oben
angegebenen SRV Records dar:
$ORIGIN example.com. ; order pref flags service regexp replacement @ IN NAPTR 10 50 "s" "SIP+D2T" "" _sips._tcp.example.com. IN NAPTR 20 50 "s" "SIP+D2U" "" _sip._udp.example.com. IN NAPTR 40 50 "s" "SIP+D2T" "" _sip._tcp.example.com.
Die Dienstekennung SIP+D2T bzw. SIP+D2U besagt, dass dieser Eintrag für den SIP Dienst, und dabei für ein "Domain zu TCP" bzw. "Domain zu UDP" Mapping verwendet wird. Die Flagge s kennzeichnet den Eintrag als "terminalen" Eintrag mit Verweis auf einen SRV Record. Dies bedeutet, dass im nächsten Schritt eine Anfrage an den angegebenen Service Record gestelllt werden muß.
Die sog. SRV-Records sind, insbesondere wenn man sich bereits mit MX-Records auskennt, trotz ihres merkwürdigen Aussehens recht einfach zu verstehen. Die Verwendung von NAPTR-Records ist allerdings sehr gewöhnungsbedürftig. Dies liegt unter anderem an den vielseitigen Verwendungsmöglichkeiten, der Verwendung von regulären Ausdrücken (in unserem Beispiel wurden wir glücklicherweise damit verschont) und den vielfältigen Einsatzmöglichkeiten und Bedeutung der Felder in dem Datensatz. Darüberhinaus sind die NAPTR-Records bisher nicht sonderlich weit verbreitet. All diese Dinge führen dazu, dass sich daran (an der Verbreitung) wohl auch in geraumer Zeit nichts ändern wird ;-).
Last modified: 24. Apr 2006 08:01