Die Verwendung des Session Initiation Protocols (SIP) baut an verschiedenen Stellen, ähnlich wie das Simple Mail Transfer Protocol (SMTP), auf DNS-Funktionalitäten auf. In den RFCs 7984 und 8553 sind einige dieser Anforderungen von Seiten des SIP an das DNS beschrieben.
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 E-Mail Zustellung. 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.
Beispiel:
$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.
Beispiel:
$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 "Terminal" Eintrag mit Verweis auf einen SRV Record. Dies bedeutet, dass im nächsten Schritt eine Anfrage an den angegebenen Service Record gestellt werden muss.