SIP and DNS - federation, failover, load balancing and more

SIP and DNS
Where do you want to go today?
© Copyright 2006-2014 Edvina AB, Sollentuna , Sweden. A l l r i g h t s reserved.
DNS ROCKS!

Executive summary
SIP use DNS for client-managed load
balancing and failover.
Not using DNS makes it hard to build
scalable, resilient SIP solutions.

Static and dynamic routing
• In SIP we use the request URI to find the
next hop
• If there’s a route set, the topmost URI in
the route set is used instead
• For responses, the via header marks the
path back
• For all of these DNS is used
RFC 3263

The DNS zone now includes SIP
yourcompany.se
Host names
Security credentials
E-mail addresses
URI: Web addresses
Unified Communication

SIP routing
• If there’s a predefined route, use it for initial transactions
• Outbound proxy, Path
• If there’s a dialog with a defined route set, use the route set until
it ends
• If there are no more static routes, look at the request URI and find
the next hop
• IP address (IPv4 and IPv6), DNS Host names , DNS domains

SIP URIs
sip:line2@192.168.40.25:5074
sip:jardar@sipguru.no
sip:conference.executive@sipguru.no;transport=tcp
sip:invalid@pluto.sipguro.no:5060
sip:session2@[2001:ab::1200]:5070

Locating SIP servers
”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.
• RFC 3263 - Jonathan Rosenberg
!
It also uses DNS to allow a server to send a response to a backup client if the primary client has
failed. This document describes those DNS procedures in detail.”

DNS role in routing
”The first is for proxy 1 to discover
the SIP server in domain B, in order to forward the call for joe@B.
The second is for proxy 2 to identify a backup for proxy 1 in the
event it fails after forwarding the request.”
RFC 3263 - Locating SIP servers
Proxy
1
Proxy
2
UA
Domain A Domain B

DNS role in routing
Proxy
1.2
Proxy
2.2
”If proxy 1 sends a
request to proxy 2.1 and the request fails, it
retries the request by sending it to proxy 2.2.”
RFC 3263 - Locating SIP servers
Proxy
1.1
Proxy
2.1
UA
Domain A Domain B

DNS - once per
transaction
• No less, no more
• CANCEL needs to be based on DNS for the
INVITE it cancels. It has to be sent to the very
same server.
• Primary target is ;maddr, secondary is the
hostname part of the URI
” It is important to note that DNS lookups can be used
multiple times throughout the processing of a call.”

Step by step
• 1. Domain or host?
• If the URI contains a transport protocol, it has to be used
• If the URI contains a port, it’s not a domain but a host name
• If the target is an IP address, use it
• 2. Domain
• Lookup NAPTR record to find service (protocol)
• NAPTR RFC 2915
• Use SRV records to find a list of hosts
• Lookup A and AAAA records for all hosts
UDP: SIP+D2U
TCP: SIP+D2T, SIPS+D2T
SCTP: DIP+D2S, SIPS+D2S

NAPTR example
Domain example.com NAPTR records
; order pref flags service regexp replacement!
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com.!
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com!
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.
Domain example.com SRV records for _sip._tcp
;; Priority Weight Port Target!
IN SRV 0 1 5060 server1.example.com.!
IN SRV 0 2 5060 server2.example.com.
This domain prefers SIP/TLS, then SIP/TCP and SIP/UDP.
For SIP/TCP, there are two servers load balancing, so that server 1 gets 1/3rd of the calls. First
NAPTR, then SRV query on the result of NAPTR.

DNS SRV record
details
!
_Service._Proto.Name [TTL] Class SRV Priority Weight Port Target host
example!
!
!
!
STUN records:!
_sip._udp.domain.tld. IN SRV 20 0 5060 mysipproxy.domain.tld.
Priority is used for failover,
weight for load balancing
_stun._udp.domain.tld. IN SRV 20 0 3478 mystunserver.domain.tld.
Priority and Weight is 0-65535 (16 bit values)

SRV load balancing
IN SRV 0 1 5060 server1.example.com.!
IN SRV 0 2 5060 server2.example.com.
• First summarize the combined weight of all
entries in one priority
• In this case, it’s 3. Now 1/3 of calls needs to
be sent to server1, and 2/3 to server 2.

SRV Failover
IN SRV 10 1 5060 server1.example.com!
IN SRV 20 1 5060 server2.example.com
• First try lowest priority
• Then work yourself up the chain at failure
• Stay there until it fails, then restart

Building a list
• For each host, build a list of addresses
• Assemble ALL address records for the host
• For dual stack clients both A and AAAA, for single stack
the address family used
• Try to connect to all addresses. RFC 2782 and
3263 does not specify order of connection
• RFC 2782 says that all addresses for a given
name should be tested before next host name is
used.

The chain ;; Priority Weight Port Target!
IN SRV 20 2 5060 server4.example.com
_sip._udp.sipguru.no
Priority 10 Priority 20
Server1 75% Server2 25% Server3 33% Server4 67%
A A
AAAA AAAA
A A
AAAA AAAA
The
hosts are not in the same
domain

Query for SRV records agave:~ olle$ dig @192.168.101.2 -t SRV _sip._udp.global.sm.edv
!
;; <<>> DiG 9.8.3-P1 <<>> @192.168.101.2 _sip._udp.global.sm.edv -t SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26290
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3
!
;; QUESTION SECTION:
;_sip._udp.global.sm.edv.
IN
SRV
!
;; ANSWER SECTION:
_sip._udp.global.sm.edv. 86400
IN
SRV
0 0 5060 sip1.global.sm.edv.
_sip._udp.global.sm.edv. 86400
IN
SRV
0 0 5060 sip2.global.sm.edv.
!
;; AUTHORITY SECTION:
sm.edv.
86400
IN
NS
ns.sm.edv.
!
;; ADDITIONAL SECTION:
sip1.global.sm.edv.
86400
IN
A
192.168.101.10
sip2.global.sm.edv.
86400
IN
A
192.168.101.11
ns.sm.edv.
86400
IN
A
192.168.101.2
!
;; Query time: 1 msec
;; SERVER: 192.168.101.2#53(192.168.101.2)
;; WHEN: Thu Sep 26 16:30:04 2013
;; MSG SIZE rcvd: 182

Rules from the RFC
• 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.

More rules
• If the NAPTR for one domain points to
another domain’s SRV record
• You still MUST have a SRV record for the
domain in the URI

If no NAPTR
• Query SRV records for EACH transport
the client supports
• Pick any protocol
• If there’s no SRV record, use TCP for SIPS
uri’s and UDP for SIP: uri’s.
• Try TCP for SIP: uri’s if the message is too
big for UDP

Hostname, not IP?
Query DNS for A and
AAAA records!

Ooops IPv6
• Use DNS to prioritize your connections
• If IPv6 is used only over tunnels, you might
want to have lower priority for IPv6
servers
• If IPv6 is native in your network, give IPv6
servers higher priority
• Avoid IPv4 NAT issues

The IPv6 preferred chain
IN SRV 10 3 5060 server1.sipguru.no.!
IN SRV 20 2 5060 server4.sipguru.no.
_sip._udp.sipguru.no
Priority 10 Priority 20
Server1 75% Server2 25% Server3 33% Server4 67%
AAAA AAAA
A A
AAAA AAAA
No IPv4 records!

Show how you want to
be connected.
• NAPTR tells the world how your domain
wants to be contacted - TLS, TCP, UDP
• SRV can be used to show address family
preference
• SRV is used to load balance incoming traffic
• SRV is used to provide failover on incoming
connections
DNS rocks!

Outbound proxy
• When using an outbound proxy, the client does
not do any DNS queries for URI’s, only to locate
the outbound proxy
• All initial requests are sent to the outbound
proxy, which will resolve the NAPTR, SRV and
HOST records and make a decision on how to
proceed with the request
• Using DNS to locate the outbound proxy gives
failover and load balancing.
• Outbound proxys usually record-route the dialog, to
stay in the dialog in future transactions

Failure processing
• If a server fails in sending a reply to the
sender’s address, it can do DNS lookup on
the domain in the topmost Via: header to
find other servers that may be able to
handle the reply
• This assumes that the via is a DNS name

Issues
• RFC 3263 (Locating SIP Servers) and RFC
2782 doesn’t agree
• RFC 3263 claims the client should look up
A or AAAA record - not and. This cause
issues with dual stack clients and servers.
• RFC 3263 does not specify how
connections should be made using the list
of IP addresses

Example
IN SRV 20 2 5060 server4.sipguru.no.
!
server1.sipguru.no. IN A 192.168.0.1!
server1.sipguru.no. IN A 192.168.0.2
server1.sipguru.no. IN AAAA 2001::1
server1.sipguru.no. IN AAAA 2001::2!
server2.sipguru.no. IN A 10.0.0.2!
server3.sipguru.no. IN AAAA 2001::3

Summary
• DNS enables federation
in SIP. You manage your
domain and how other
partys call your service.
• DNS is used for load
balancing between
servers
• DNS is used for failover,
to ensure that your SIP
service is always
reachable.
• DNS can be used to
locate internal servers,
like voicemail servers,
outbound proxys and
conference bridges.
SIP without DNS is broken.

EDVINA TRAINING CLASSES
• Kamailio from start
• SIP Protocol
• SIP Security
• Scalability
CUSTOM
INHOUSE
TRAININGS
• Update for existing
Kamailio, OpenSER
and SER users
• Introduces Kamailio
version 4
• New SIP standards
• SIP, Asterisk, Kamailio
and much more
• Done at your site,
customized for your
project
• Cost effective when
more than four
students
Find more details at http://edvina.net

SIP and DNS - federation, failover, load balancing and more

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à SIP and DNS - federation, failover, load balancing and more

Similaire à SIP and DNS - federation, failover, load balancing and more (20)

Plus de Olle E Johansson

Plus de Olle E Johansson (20)

Dernier

Dernier (20)

SIP and DNS - federation, failover, load balancing and more