RFC3263 describes the DNS procedure and guidelines to be followed in order to locate SIP Servers.
From the abstract of RFC3263:
- The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform
- Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact.
- It also uses DNS to allow a server to send a response to a backup client if the primary client has failed.
The document here describes those DNS procedures in detail.
When it comes to implement the proposed guidelines from RFC3263 in order to locate SIP server, the specification doesn’t seem to cover enough all the possible situations, specially for SIPS URI, and that is why we should consider to change some points there.
The purpose of this post is, first to indicate which points of the proposed RFC3263 mechanisms could create problems when it comes to resolve the transport for SIPS URIs and how these points should be changed by applying some rules on the results of the DNS query. Second this post provides what is the minimum DNS configuration for SIP, that is the minimum required NAPTR, SRV and A records according to the RFC3263.
1. RFC3263 misconceptions when it comes to transport resolution
The proposed mechanism from the specification for the transport resolution, suggest to have NAPTR query first and if this doesn’t return any results to issue a SRV query. At this point the the specification fails to provide clear directions on how to choose the transport when the URI under question is a SIPS URI.
We should consider to change the way the transport resolution mechanism have to be done keeping in mind the RFC5630 “The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)” guidelines.
So as said before RFC3263 states that if the NATPR query returns no records, an SRV query should be performed and if that query returns any results that contains transports that the client can support, then the client can choose any of the results:
- A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server.
The “..use any transport protocol it desires which is supported by the server.” creates a confusion and problems when it comes to SIPS URIs. The SRV query results should be examined and some rules should be applied before we choose the transport.
Another point of conflict coming from RFC3263 for the transport resolution, is in the case where port is available in the URI. The specification states :
- if no transport protocol is specified, and the TARGET is not numeric, but an explicit port is provided, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI.
This should be “TLS for a SIPS URI”
2. SIPS URI clarifications from the RFC5630 “The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)”
RFC5630 purpose is to clarify the use of SIPS URI.
- The meaning and usage of the SIPS URI scheme and of Transport Layer Security (TLS) RFC5246 are underspecified in SIP RFC3261 and have been a source of confusion for implementers. This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol(SIP). It also makes normative changes to SIP (including both RFC3261 and RFC3608).
RFC5630 [3.1.3 – Using TLS with SIP Instead of SIPS] defines two uses of TLS, one with SIPS URI, and one with SIP URI. As it states SIPS URI should be treated as “TLS-only” requests, while using TLS with SIP URI should be treated as “best-effort TLS”.Taken from there, we should further enhance RFC3263 guidelines by taking into account RFC5630.SRV records of a DNS server should be clear of what they want to provide.
So if one would like to use the “best-effort TLS” approach this DNS SRV record should be included:
And if the client supports TLS, then TLS should be the chosen transport.
If the SIP server should follow the “TLS only” approach, then one of the following SRV records should be included (or both to support all possible queries) :
OR
And the client will have to go with the TLS transport.
Of course, a server could provide both and so to give the ability to the client even if using SIP URI to go with a TLS transport if available.
3. How the DNS NAPTR results should be treated
When it comes to the NAPTR lookup, RFC3263 proposed mechanism to resolve transport is sufficient and the guidelines for SIP and SIPS URIs are clear enough:
- If a SIPS URI is given, discard any service that do not contain “SIPS” as the protocol in the service field. That conforms with the RFC5630 that SIPS URI should be treated as “TLS only”
- If a SIP URI is given, the client should retain records with “SIPS” as the protocol, if the client supports TLS. Again this conforms to the RFC5630 for “best-effort TLS” - Results should be processed according to the order of each record and the first one should be picked up to set the transport - If the result contain “SIPS” as a service protocol, the transport should be set to TLS
- If the result contain “D2T” as a service protocol, the transport should be set to TCP
- If the result contain “D2U” as a service protocol, the transport should be set UDP
- The “SIPS” service should be the preferred if the client can support it.
4. How the DNS SRV results should be treated
If the NAPTR lookup returns no results, a DNS SRV query should be done.
Here we need to clarify and change how the DNS results should be treated for a given request when transport is to be discovered, given the fact that the client supports TCP, UDP and TLS.
The statement from RFC5623 that the client should “use any transport protocol it desires which is supported by the server” is not enough to make a clear decision for the transport and further process of the result should be done using some rules.
For example, a SIP Registrar may provide the following SRV record for SIPS URI:
If the client is to pick the TCP transport as is, then this will fail because the TCP connector wont be able to establish a connection with the TLS connector on the other side. In this example, the client should treat _sips._tcp result as “TLS only” and choose TLS as transport.
Since the DNS SRV records defined for a SIP server may vary from one application to the other, the client should collect all the results of a DNS SRV lookup, and then apply the following rules:
- Lookup for a SIP URI- SRV Record Results: [ _sip._tls, _sip._tcp, _sip._udp] => The _sip._tls should interpreted as “best-effort TLS” and the client should choose TLS as transport if available, otherwise ANY available transport
- SRV Record Results: [_sip._tcp, _sip._udp] => Client should choose ANY of the two results as long as they are available
- SRV Record Results: [_sip._tcp] => Client should choose TCP as transport
- SRV Record Results: [_sip._udp] => Client should choose UDP as transport
- Lookup for a SIPS URI- SRV Record Results: [_sips._tcp, any others] => Should be treated as “TLS only” approach and the client should set TLS as transport
- SRV Record Results: [_sips._tls, any others] => Should be treated as _sips._tcp, that is “TLS only” and the client should set TLS as transport
Of course if an SRV lookup doesn’t returns any result, the regular approach should be followed, that is to pick the default transport for the given URI.
- TLS for SIPS URI
- UDP for SIP URI OR
- TCP for SIP URI if UDP is not available
Should there be a preference between TCP and UDP?
5. DNS NAPTR required records
According to RFC3263 4.1, the minimum required NAPTR records a SIP proxy, redirect server, or registrar should have, if it comes to be resolved through a DNS lookup, are the following:
- example.com. IN NAPTR 50 50 “s” “SIPS+D2T” “” _sips._tcp.example.com.
- example.com. IN NAPTR 90 50 “s” “SIP+D2T” “” _sip._tcp.example.com
- example.com. IN NAPTR 100 50 “s” “SIP+D2U” “” sip._udp.example.com.
From RFC3263:
- If a SIP proxy, redirect server, or registrar is to be contacted through the lookup of NAPTR records, there MUST be at least three records – one with a “SIP+D2T” service field, one with a “SIP+D2U” service field, and one with a “SIPS+D2T” service field. The records with SIPS as the protocol in the service field SHOULD be preferred (i.e., have a lower value of the order field) above records with SIP as the protocol in the service field. A record with a “SIPS+D2U” service field SHOULD NOT be placed into the DNS, since it is not possible to use TLS over UDP.
Of course Domain, TTL, Priority, Preference, Port and FQDN of the the record should be set according to the application/needs.
6. DNS SRV required records
Accordingly, the minimum DNS SRV records that should be defined are:
So in the above example for SIP URIs and UDP or TCP transport, the request will be routed using port 5060 to the sipserver1.example.com. For secure SIPS URIs, the 5061 port should be used and the same server.
Of course Domain, TTL, Priority, Weight, Port and FQDN of the the record should be set according to the application/needs.
7. DNS A Records
Finally the DNS zone configuration should contain an A record for the domain:
That will be used to resolve the FQDN of servers to an IP Address.
8. A complete DNS Zone configuration file
Here is an example of a complete DNS Zone configuration for the example.com domain.
$TTL 1800
@ IN SOA ns1.example.com. root.example.com. (
2012030101 ; serial#
1800 ; refresh, seconds
1800 ; retry, seconds
1800 ; expire, seconds
1800 ) ; minimum TTL, seconds
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; DNS Servers for ‘example.com’
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; NS record for example.com
; server: sipserver1.example.com
;
example.com. IN NS sipserver1.example.com.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Call Routing for SIP domain ‘example.com’
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; NAPTR record for SIPS TCP example.com
; priority: 2 weight: 0
; protocol: “SIPS+D2T” regex: “” uri: _sips._tcp.example.com
;
example.com. IN NAPTR 2 0 “s” “SIPS+D2T” “” _sips._tcp.example.com.
; NAPTR record for SIP TCP example.com
; priority: 2 weight: 0
; protocol: “SIP+D2T” regex: “” uri: _sip._tcp.example.com
;
example.com. IN NAPTR 2 0 “s” “SIP+D2T” “” _sip._tcp.example.com.
; NAPTR record for SIP UDP example.com
; priority: 2 weight: 0
; protocol: “SIP+D2U” regex: “” uri: _sip._udp.example.com
;
example.com. IN NAPTR 2 0 “s” “SIP+D2U” “” _sip._udp.example.com.
; SRV record for domain SIP TCP example.com
; priority: 1 weight: 0 port: 5060 server: sipserver1.example.com
;
_sip._tcp.example.com. IN SRV 1 0 5060 sipserver1.example.com.
; SRV record for domain SIP UDP example.com
; priority: 1 weight: 0 port: 5060 server: sipserver1.example.com
;
_sip._udp.example.com. IN SRV 1 0 5060 sipserver1.example.com.
; SRV record for domain SIP TLS example.com
; priority: 1 weight: 0 port: 5061 server: sipserver1.example.com
;
_sip._tls.example.com. IN SRV 1 0 5061 sipserver1.example.com.
; SRV record for domain SIPS TCP example.com
; priority: 1 weight: 0 port: 5061 server: sipserver1.example.com
;
_sips._tcp.example.com. IN SRV 1 0 5061 sipserver1.example.com.
; SRV record for domain SIPS TLS example.com
; priority: 1 weight: 0 port: 5061 server: sipserver1.example.com
;
_sips._tls.example.com. IN SRV 1 0 5061 sipserver1.example.com.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; IP Addresses
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; A record for sipserver1.example.com
;
sipserver1.example.com. IN A 192.168.1.207
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
9. How to test DNS configurations
In order to test A records, a simple ping would be enough. If the command ping sipserver1.example.com would result some replies, then A record configuration is okTo test SRV records, for Linux use dig command and for Windows use nslookup.
- Linux example: dig _sips._tcp.example.com SRV should result the IP Address and port of the server for SIPS TLS
- Windows example: use nslookup, then set querytype=SRV and then type the SRV record you wish, for example _sips._tcp.example.com. Should result the IP Address and port for SIPS TLS
Also, in order to check NAPTR records again use Linux dig.
For Windows i am not aware of a program that could be used to check NAPTR records, as nslookup doesn’t support this type of records (tested on Windows XP and Windows 7)
Linux example: dig example.com NAPTR will result with the available NAPTR records on the DNS server
10. Links / Resources
