Session Initiation Protocol (SIP): Locating SIP Servers
Extracted elements (29)
Domain administrators are RECOMMENDED to assign different weight values to SRV records with equal priority (e.g., 1000 and 1001 rather than both 1000), making deterministic ordering easier for stateless proxies without requiring algorithmic tie-breaking.
SRV-backed domain names are recommended for Contact and Record-Route headers (e.g., sip:server23.provider.com) instead of numeric IP addresses, so that backup SRV records with higher priority values can provide failover if the primary element fails.
UDP is the default transport for SIP URIs with numeric targets or explicit ports because UDP was the only mandatory transport in RFC 2543 and is thus the only one guaranteed to be interoperable as a baseline.
Stateless proxies that perform DNS lookups remain vulnerable to delivering retransmissions to different servers if DNS TTLs expire mid-transaction and entries change. Network implementors should avoid stateless proxies with DNS access if this failure mode is critical.
This document changes RFC 2543 behavior for SRV fallback: when no NAPTR records are found, the client now queries SRV independently per supported transport protocol rather than merging priority values across all transport SRV records and selecting the overall most preferred.
This document changes RFC 2543 behavior: when a TARGET has an explicit port (even port 5060), A or AAAA records are now used rather than SRV records. Previously, SRV records were used for explicit port 5060.
A CANCEL for a particular SIP request MUST be sent to the same SIP server that the original SIP request was delivered to.
A client MUST discard NAPTR service fields that identify transport protocols not supported by the client. Only service fields with 'D2X' values for supported transports are retained.
A client resolving a SIPS URI MUST discard any NAPTR service fields that do not contain 'SIPS' as the protocol. A client resolving a SIP URI SHOULD retain SIPS records if TLS is supported.
A record with a 'SIPS+D2U' service field SHOULD NOT be placed in the DNS, since it is not possible to use TLS over UDP.
A stateless proxy MUST define a deterministic ordering for SRV records of equal priority, using any algorithm such as alphabetical or ASCII-compatible encoding sort.
DNS lookup procedures MUST be performed exactly once per transaction. Once a SIP server has been successfully contacted, all retransmissions of the request and ACK for non-2xx responses to INVITE MUST be sent to the same host.
For backwards compatibility with RFC 2543, a domain MUST maintain SRV records for the domain of the original query, even if the NAPTR replacement field points to a different domain.
For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. The same applies to SRV query and target domain names.
If a SIP proxy, redirect server, or registrar is contacted via NAPTR, there MUST be at least three NAPTR records: one with 'SIP+D2T', one with 'SIP+D2U', and one with 'SIPS+D2T'. SIPS records SHOULD be preferred (lower order field value).
If a stateless proxy does not successfully contact the first server in the list, it SHOULD act as a stateful proxy for that transaction to ensure retransmissions go to the same server.
If no transport protocol or port is specified and TARGET is not numeric, the client SHOULD perform a NAPTR query for the domain in the URI to discover available transport protocols.
If the TARGET was not a numeric IP address but an explicit port is present in the URI, the client performs an A or AAAA lookup and SHOULD try each IP address in order, trying the next if the current attempt fails.
If the URI specifies a transport protocol in the transport parameter, that transport protocol SHOULD be used. If no transport is specified but TARGET is a numeric IP address, the client SHOULD use UDP for a SIP URI and TCP for a SIPS URI.
On failure (503 response, transport failure, or timer B/F expiry), the client SHOULD create a new request identical to the previous but with a different Via branch ID (new SIP transaction), and send it to the next element in the RFC 2782 list.
When a server receives a response failure and the Via header's sent-by field contains 'TLS' as transport, the server MUST use TLS over TCP to send the response.
NAPTR service fields for SIP use the form 'SIP+D2X' and 'SIPS+D2X', where D2U maps to UDP, D2T to TCP, and D2S to SCTP. These records map a domain to the SRV record for a specific transport protocol.
Server fallback for response delivery uses the Via header's sent-by field: if it contains a numeric IP, send directly; if a domain with port, perform A/AAAA lookup; if a domain without port, perform SRV query using '_sips' or '_sip' service identifier based on the Via transport value.
TARGET is defined as the value of the maddr parameter of the URI if present, otherwise the host value of the hostport component of the URI. It identifies the domain to be contacted for DNS resolution.
IANA maintains a registry of NAPTR service field values to SIP transport protocol mappings. New entries require publication of a standards-track RFC. Initial values: SIP+D2T=TCP, SIPS+D2T=TCP, SIP+D2U=UDP, SIP+D2S=SCTP.
An attacker who can modify DNS NAPTR records could cause a client to use a non-secure transport even when TLS is available and preferred, constituting a bid-down attack. The SIPS URI scheme partially mitigates this: a sips URI always requires TLS regardless of DNS records.
Clients that frequently contact the same domain SHOULD cache whether NAPTR records contain SIPS entries. If such records were previously present but disappear in later queries, this indicates a potential attack, and the client SHOULD generate an alert and MAY reject the request.
Proxies performing NAPTR queries could deliberately ignore SIPS entries to downgrade security for all users relying on them. Unlike DNS tampering (which requires wire interception), proxy compromise requires a break-in and is considered a less likely but harder-to-prevent threat.
Client DNS resolution follows: (1) check URI transport parameter; (2) if numeric IP or explicit port, use A/AAAA; (3) if no port/transport, perform NAPTR query; (4) use NAPTR-derived SRV records; (5) if no NAPTR, try SRV per supported transport; (6) if no SRV, fall back to A/AAAA. Failure triggers retry to the next element in the ordered list.