Lokalisierung von SIP-Servern via DNS

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.

Lokalisierung von SIP Servern

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 regsitriert 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. 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.

 
Auswahl des Transport Protokolls

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 muss 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-Rufnummern-Auflösung über ENUM, mit dem Flag “s” verwendet und stellen damit ein Verknüpfung 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 Diensterkennung 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 gestellt werden muss.