An Éminence Grise – the DNS

In marriage we need to find a way how to make common decisions. In my case we decided that my wife will make those routine, unimportant decisions as what to cook for a dinner, how will spend a weekend or holidays or what to do with the money we have. My responsibility is to take the key, long-term decisions which will have the major influence on our well-being. So I decide what soccer team is our favorite for the next season, brand of a BBQ grill and what is our relationship towards EU.

In the IMS network there are many key network functions which take the decisions about routing, charging, applied services etc. But should I choose one which would allow me to manage the whole network, I’d go for DNS. Without DNS there would be no IMS. And don’t get me wrong. This is not only about the usage of IP protocol and symbolic address translation. DNS is responsible also for other vital mechanisms as routing, load-sharing, resiliency, service discovery and zero-configuration, provisioning, mobile number portability, timezone support, etc.

DNS is defined in many documents the most important for us are IETF RFC 1034, RFC 1035, RFC 3646 and mainly in RFC 3263 and RFC 7984 and GSMA IR.67.

Let’s take a look on routing in the IMS network.

Routing in IMS

Routing in IMS

 

We can start with the registration. Well, the DNS is used also during the ePC attach procedure. But we don’t discuses particular access networks here. (The Protocol Configuration Options – PCO response will contain the IPv4/IPv6 address of the P-CSCF anyway).  In the IMS the P-CSCF will take the Request-URI header of the SIP REGISTER message and based on the DNS response will identify the I-CSCF.

 

And it’s not just about the registration. As you probably know, the routing in SIP is done either based on a top most Route header, or if there is no Route header the routing is done based on the Request-URI, which contains the address of the final recipient.

SIP INVITE Routing – Originating part

And every time before a network element can pass the message to a next hop, it has to discover what type of transport will be used (UDP, TCP, TLS, SCTP), what port to use and what numeric IP (IPv4/IPv6). This procedure we call SIP Server Locating. Sometimes the information is already present in the message headers (e.g. routing of responses), sometimes we can use some defaults and in all other cases we use the DNS.

As an example we mentioned the SIP REGISTER message on P-CSCF, because in this case we do the SIP routing based on the domain name, which user is registering to. That means we can’t use any defaults and we have to trigger the DNS.

SIP + DNS

However, as mentioned, it applies in general to all the SIP routing.

The SIP Server discovery is done in 3 steps to discover the Transport, Port and IP. That also corresponds to 3 DNS queries NAPTR, SRV and A/AAA.

Nameserver

Firstly we send the NAPTR request in order to find the right name server (as the I-CSCF can be in a different network).

Domain Name System (query)
 Flags: 0x0100 Standard query
 0... .... .... .... = Response: Message is a query
 .000 0... .... .... = Opcode: Standard query (0)
 .... ..0. .... .... = Truncated: Message is not truncated
 .... ...1 .... .... = Recursion desired: Do query recursively
 .... .... .0.. .... = Z: reserved (0)
 .... .... ...0 .... = Non-authenticated data: Unacceptable
 Questions: 1
 Answer RRs: 0
 Authority RRs: 0
 Additional RRs: 0
 Queries
 operator.com: type NAPTR, class IN
 Name:operator.com
 Type: NAPTR (Naming authority pointer)
 Class: IN (0x0001)
Domain Name System (response)
Flags: 0x8580 Standard query response, No error
 1... .... .... .... = Response: Message is a response
 .000 0... .... .... = Opcode: Standard query (0)
 .... .1.. .... .... = Authoritative: Server is an authority for domain
 .... ..0. .... .... = Truncated: Message is not truncated
 .... ...1 .... .... = Recursion desired: Do query recursively
 .... .... 1... .... = Recursion available: Server can do recursive queries
 .... .... .0.. .... = Z: reserved (0)
 .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
 .... .... ...0 .... = Non-authenticated data: Unacceptable
 .... .... .... 0000 = Reply code: No error (0)
 Questions: 1
 Answer RRs: 0
 Authority RRs: 1
 Additional RRs: 0
 Queries
operator.com: type NAPTR, class IN
 Name: operator.com
 Type: NAPTR (Naming authority pointer)
 Class: IN (0x0001)
 Authoritative nameservers
operator.com: type SOA, class IN, mname dns_01.operator.com
 Name: operator.com
 Type: SOA (Start of zone of authority)
 Class: IN (0x0001)
 Time to live: 15 minutes
 Data length: 68
 Primary name server: dns_01.operator.com
 Responsible authority's mailbox: devnull
 Serial Number: 167
 Refresh Interval: 10800 (3 hours)
 Retry Interval: 3600 (1 hour)
 Expire limit: 2419200 (28 days)
 Minimum TTL: 900 (15 minutes)

Transport discovery

To find out what type of transport to use, there are several rules to follow:

If the target (R-URI or the top most Route header) is a numeric IP, we use UDP transport layer.

sip:2233445566@10.0.0.1

If no transport is specified, but port is specified, we also use UDP.

sip:context123@scscf1.ims.operator.com:5070

Otherwise we can specify the transport directly.

sip:context123@scscf1.ims.operator.com;transport=tcp

For sips we always use TLS.

If none of the rules specified above applies, then we have to use DNS to resolve the address.

;        order pref flags service      regexp  replacement
IN NAPTR 10    50   "s"   "SIPS+D2T"   ""      _sips._tcp.icscf.ims.operator.com.
IN NAPTR 20    50   "s"   "SIP+D2T"    ""      _sip._tcp.icscf.ims.operator.com.
IN NAPTR 100   50   "s"   "SIP+D2U"    ""      _sip._udp.t.ims.operator.com.

The third column defines, what will be the order/priority. The row with the lowest value has the highest priority. In case when more rows have the same priority, then we loadshare using preference/weights in the fourth column. The flag “s” then tells to us, that the next step is the DNS SRV request. Again, for more details, please refer to RFC.

 

Port Discovery

It is even easier. If the port is specified, simply us it.

sip: context123@scscf1.ims.operator.com:5070

If the target is a numeric IP address, we use default ports for given transport layers.

sip:2233445566@10.0.0.1;transport=tls    => port 5061
sip:2233445566@10.0.0.1;transport=tcp    => port 5060
sip:2233445566@10.0.0.1;transport=udp    => port 5060

Otherwise we send an SRV request to DNS.

 ;;          Priority Weight Port   Target
       IN SRV  0        1      5060   icscf1.ims.operator.com
       IN SRV  0        2      5060   icscf2.ims.operator.com

A full DNS SRV request/response would look like:

Domain Name System (query)
Flags: 0x0100 Standard query
Queries
 _sip._udp.operator.com: type SRV, class IN
 Name: _sip._udp.operator.com
 Type: SRV (Service location)
 Class: IN (0x0001)
Domain Name System (response)
Flags: 0x8580 Standard query response, No error
Queries
 _sip._udp.operator.com: type SRV, class IN
 Name: _sip._udp.operator.com
 Type: SRV (Service location)
 Class: IN (0x0001)
 Answers
 _sip._udp.operator.com: type SRV, class IN, priority 10, weight 100, port 5060, target icscf1.ims.operator.com
 _sip._udp.operator.com: type SRV, class IN, priority 20, weight 100, port 5060, target icscf2.ims.operator.com
Authoritative nameservers
 operator.com: type NS, class IN, ns dns_01.operator.com Name: operator.com Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 8 hours Data length: 11 Name Server: dns_01.operator.com
Additional records
 icscf1.ims.operator.com: type A, class IN, addr 10.0.1.2 Name: icscf1.ims.operator.com
 icscf2.ims.operator.com: type A, class IN, addr 10.0.2.2 Name: icscf2.ims.operator.com

Note that the SRV can already contain A/AAA records.

IP Discovery

To discover an exact IP address is just a piece of cake. Either the numeric IP is present, then we will use it.

sip:2233445566@10.0.0.1

Or, if the SRV request was already done, use the returned IP address if present. If it wasn’t present, perform A query based on that result.

icscf1.ims.operator.com

If we haven’t done SRV request, then do A query using the SIP URI domain name. Use the numeric IP in the order returned by DNS.

icscf1.ims.operator.com 1800 IN A 10.10.1.1
icscf2.ims.operator.com 1800 IN A 10.20.1.1
DNS flow

DNS flow

 

On the first picture of routing in IMS above we have a simplified network with two sites. One is responsible for instance for the customers physically located in the west of a country (e.g. Vancouver) and the other one for those in the east (Montreal). If the DNS will do a loadsharing/loadbalancing, the SIP REGISTER message from Vancouver can end up in the IMS core (S/I-CSCF) in Montreal.

Also the DNS is typically responsible for an AS selection because the iFCs usually contain only generic FQDNs of application servers.

DNS + registration

DNS + registration

 

ENUM

During the session establishment we then use the DNS to find the proper routing based on the ENUM response.

Queries
2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net: type NAPTR, class IN
 Name: 2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net
 Type: NAPTR (Naming authority pointer)
 Class: IN (0x0001)
 Answers
2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net: type NAPTR, class IN, order 100, preference 10, flags u
 Name: 2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net
 Type: NAPTR (Naming authority pointer)
 Class: IN (0x0001)
 Time to live: 10 seconds
 Data length: 85
 Order: 100
 Preference: 10
 Flags length: 1
 Flags: "u"
 Service length: 7
 Service: "E2U+SIP"
 Regex length: 69
 Regex: "!^.*$!sip:+123456789012@ims.mnc000.mcc000.3gppnetwork.org;user=phone!"
 Replacement length: 1
 Replacement: <Root>

The DNS Resolver will support the following service-field values:

    • “E2U+sip” as defined in RFC 3824
    • “E2U+pstn:tel” as defined in RFC 4769
    • “E2U+pstn:sip” as defined in RFC 4769
  • REGEXP – Contains a substitution expression that is applied to the original string held by the AS in order to construct the next domain name to lookup.
  • REPLACEMENT – A 1 octet length field followed by the next NAME to query for NAPTR, SRV, or address records depending on the value of the flags field. If replacement is used this must be a fully qualified domain-name.

The ENUM request can be send by both S-CSCF or AS. The ENUM is as a database indicating the presence in the IMS and for Mobile Number Portability (MNP).

ENUM based Routing

As we can see a correctly working DNS is a must for a 4G network. When we look at the 5G the DNS will become even more critical component. The next generation should be about devices – IoT if you want. Think about all those devices. Some researches show that there will be about 50 billion connected devices in 2020. All these devices will need to use some services. How to do the service discovery when the device itself is supposed to be ‘plug&play’? Sure, the answer is DNS.

Other related posts:

12 thoughts on “An Éminence Grise – the DNS

  1. Pingback: Summer & IMS | Real Time Communication

  2. Pingback: Much Ado about Registration | Real Time Communication

  3. Pingback: How to read tcpdump – Registration | Real Time Communication

  4. Pingback: Sh Interface – What Is It Good for? | Real Time Communication

  5. Pingback: Presence – from the other site | Real Time Communication

  6. Pingback: Third party registration | Real Time Communication

  7. Pingback: VoLTE in IMS | Real Time Communication

  8. Pingback: ePDG and IPSec | Real Time Communication

  9. Pingback: How to read Initial Filter Criteria | Real Time Communication

  10. Pingback: SIP Illustrated 3: Routing and IMS Registration | Real Time Communication

  11. Pingback: SIP Illustrated 4: SIP Session | Real Time Communication

  12. Pingback: NEWS: Number Portability & ENUM | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s