GSMA

Official Document IR.67 DNS Guidelines for Service Providers and GRX and IPX Providers

DNS Guidelines for Service Providers and GRX and IPX

Providers
Version 23.0
02/02/2024

Security Classification: Non-Confidential

Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is subject to
copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be
disclosed or in any other way made available, in whole or in part, to persons other than those permitted under the security classification without
the prior written approval of the Association.

Copyright Notice
Copyright © 2024 GSM Association

Disclaimer
The GSMA makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and
hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained
in this document may be subject to change without prior notice.

Compliance Notice
The information contain herein is in full compliance with the GSMA Antitrust Compliance Policy.

This Permanent Reference Document has been developed and is maintained by GSMA in accordance with the provisions set out in GSMA AA.34
- Policy and Procedures for Official Documents.

V0.1 Page 1 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Table of Contents
1 Introduction 5
1.1 Overview 5
1.2 Scope 5
1.3 Document Cross-References 5
2 DNS As Used on the GRX/IPX 8
2.1 Introduction 8
2.2 Architecture 8
2.3 Domains 16
2.3.1 Introduction 16
2.3.2 General 16
2.3.3 Domain names used on the GRX/IPX DNS 16
2.3.4 Domain names used on the Internet DNS (and owned by GSMA) 30
2.3.5 Domain names used on the GRX/IPX DNS for UNI 37
2.4 Non-service specific hostnames and domains 37
2.5 Host names for the evolved packet Core (EPC) 38
2.6 Host names for the IP Multimedia Subsystem (IMS) 38
3 General DNS Configuration for Service Providers 38
3.1 Introduction 38
3.2 DNS Server Hardware 38
3.3 DNS Server Software 38
3.4 DNS Server naming 39
3.5 Domain Caching 39
3.6 Reverse Mapping 39
3.7 Use of DNS Interrogation Modes 39
3.8 Use of the GRX/IPX Root DNS Server 40
3.9 Provisioning of Service Provider's DNS servers 41
3.10 Resource Records 41
3.11 Support for IPv4 and IPv6 41
4 DNS Aspects for Standardised Services 42
4.1 Introduction 42
4.2 General Packet Radio Service (GPRS) 42
4.2.1 Introduction 42
4.2.2 APN resolution in PDP Context activation 42
4.2.3 Inter-SGSN handovers for active PDP Contexts 44
4.3 Multi-media Messaging Service (MMS) 46
4.3.1 Introduction 46
4.3.2 MM delivery based on MSISDN for the Direct Interconnect model 46
4.3.3 MM delivery based on MSISDN for the Indirect Interconnect model 48
4.3.4 MM delivery based on NAI/e-mail address 49
4.4 WLAN Inter-working 49
4.4.1 Introduction 49
4.5 IP Multi-media Sub-system (IMS) 50
4.5.1 Introduction 50

V0.1 Page 2 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

4.5.2 SIP server configuration 51

4.5.3 Domain Names used 53
4.6 Generic Authentication Architecture (GAA) 53
4.6.1 Introduction 53
4.7 Generic Access Network (GAN) 53
4.7.1 Introduction 53
4.8 Secure User Plane Location (SUPL) 54
4.8.1 Introduction 54
4.9 Enhanced Packet Core (EPC) 54
4.9.1 Introduction 54
4.10 IMS Centralised Services (ICS) 54
4.10.1 Introduction 54
4.11 Access Network Discovery Support Function (ANDSF) 54
4.11.1 Introduction 54
4.12 Mobile Broadcast Services (BCAST) 54
4.12.1 Introduction 54
4.13 The XCAP Root URI on Ut Interface for MMTEL/IMS profile for Voice and
SMS (XCAP) 55
4.13.1 Introduction 55
4.14 RCS - Rich Communication Suite 55
4.14.1 Introduction 55
4.15 Evolved Packet Data Gateway (ePDG) 55
4.15.1 Introduction 55
4.16 Network element self-configuration 56
4.16.1 Introduction 56
4.17 EPC and GPRS coexistence 56
4.17.1 Introduction 56
4.18 MBMS Service Announcement Bootstrapping 56
4.18.1 Introduction 56
4.19 5G Core (5GC) 56
4.19.1 Introduction 56
4.19.2 Usage of DNS in Peer SEPP FQDN(s) discovery 56
4.19.3 Domain Names used 58
4.19.4 Use of DNS servers in peer SEPP IP address discovery 58
4.19.5 Handling Non-MNO SEPPs 60
4.20 Stand-alone NPN (SNPN) 60
4.20.1 Introduction 60
5 Processes and Procedures relating to DNS 60
5.1 Introduction 60
5.2 Existing domains/sub-domains on the GRX/IPX network and their
Allocation 60
5.3 Procedures relating to new domain names on the GRX/IPX network 61
5.4 GSMA Root DNS service and its access 62
5.4.1 GSMA Root DNS Service 62
5.4.2 Access to GSMA Root DNS Service 62

V0.1 Page 3 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

5.5 Delegation of sub-domains of “pub.3gppnetwork.org” 63

Annex A Sample BIND DNS Configuration for GPRS 64
A.1 Introduction 64
A.2 The "named.conf" file 64
A.2.1 The "named.conf" file for a PLMN Primary Nameserver 64
A.2.2 The "named.conf" file for a PLMN Secondary Nameserver 65
A.3 Zone Configuration Files 65
A.3.1 The "gprs.hint" file 65
A.4 The "0.0.127.in-addr.arpa" file 65
A.4.1 PLMN zone files 66
A.4.2 The "hosts" file 66
A.4.3 The "168.192.in-addr.arpa" file 67
Annex B Forms for transfer of sub-domain of “pub.3gppnetwork.org” 69
B.1 Request form 69
B.2 Letter of Authorization Template 70
Annex C Document Management 73
C.1 Document History 73
Other Information 81

V0.1 Page 4 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

1 Introduction

1.1 Overview
Inter Service Provider IP communications are starting to evolve to support services other
than GPRS Roaming. Many, if not all, of these services rely upon DNS. Therefore, it is of
utmost importance for the interworking and stability of such services that Service Providers
have all the necessary information to hand to ease configuration of their DNS servers upon
which such services rely.

This document is intended to provide guidelines and technical information for those who
need to set up and/or maintain DNS servers for inter Service Provider services. This
document is not intended to provide a general education on DNS. Thus, a reasonable level
of technical competence in DNS, and DNS server configuration is assumed throughout this
document.

1.2 Scope
This GSMA official document provides recommendations on DNS to facilitate successful
interworking of inter-Service Provider services. In particular, guidelines for general and
service specific configuration of DNS servers, GSMA processes and procedures relating to
formats, usage of domain names and sub-domain names, and updates to the GRX/IPX
Root DNS Server.

Particular attention is given to DNS servers connected to the private, inter-Service Provider
backbone network known as the "GRX" or "IPX", as described in GSMA PRD IR.34 [12].

Out of the scope of this document are vendor specific implementation/architecture options
and configuration of DNS servers used on the Internet (e.g. those DNS servers attached to
the Internet for web site hosting). The only exception to this is the guidelines for sub
domains used for any standardised services that specifically use the Internet i.e. those that
use the "pub.3gppnetwork.org" domain name.

Note that ENUM is out-of-scope of this document and is addressed in [56].

1.3 Document Cross-References

Document
Ref Title
Number
1 IETF RFC 1034 "Domain Names - Concepts and Facilities"
2 IETF RFC 1035 "Domain Names - Implementation and Specification"

3 Void No more used in current version of the document

4 Void No more used in current version of the document

5 Void No more used in current version of the document

IETF RFC 3403 "Dynamic Delegation Discovery System (DDDS) Part Three: The
6
Domain Name System (DNS) Database"
IETF RFC 3404 "Dynamic Delegation Discovery System (DDDS) Part Four: The
7
Uniform Resource Identifiers (URI)"

V0.1 Page 5 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Document
Ref Title
Number
3GPP TS 23.003 "Numbering, addressing and identification", Version 8.0.0 or
8
higher
9 GSMA PRD IR.52 "MMS Interworking Guidelines"
10 GSMA PRD IR.61 "WLAN Roaming Guidelines"
11 GSMA PRD IR.65 "IMS Roaming and Interworking Guidelines"
12 GSMA PRD IR.34 "Inter-Service Provider IP Backbone Guidelines"
13 IETF RFC 2821 "Simple Mail Transfer Protocol"
14 IETF RFC 2822 "Internet Message Format"
3GPP TS 23.140 "Multimedia Messaging Service (MMS); Functional description;
15
Stage 2", version 6.7.0 or higher
16 Void No more used in current version of the document
17 IETF RFC 3263 "Session Initiation Protocol (SIP): Locating SIP Servers"
18 IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
3GPP TS 33.220 "Generic Authentication Architecture (GAA); Generic
19
bootstrapping architecture", version 6.9.0 or higher
3GPP TS 43.318 "Generic Access to the A/Gb interface; Stage 2", version 6.6.0 or
20
higher
3GPP TS 44.318 "Generic Access (GA) to the A/Gb interface; Mobile GA interface
21
layer 3 specification", version 6.5.0 or higher
3GPP TS 23.236 "Intra Domain Connection of RAN Nodes to Multiple CN Nodes",
22
version 6.3.0 or higher
3GPP TS 23.060 "General Packet Radio Service (GPRS); Service description;
23
Stage 2", version 6.14.0 or higher
24 IETF RFC 3824 "Using E.164 numbers with the Session Initiation Protocol (SIP)"
25 Void No more used in current version of the document
3GPP TS 29.060 "General Packet Radio Service (GPRS); GPRS Tunnelling
26
Protocol (GTP) across the Gn and Gp interface"
OMA "Secure User Plane Location Architecture; Approved Version 1.0
27 OMA-AD-SUPL-V1_0-2 – 15 June 2007"
0070615-A
3GPP TS 23.401 "General Packet Radio Service (GPRS) enhancements for
28 Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
access"
29 3GPP TS 23.402 "Architecture enhancements for non-3GPP accesses"
30 3GPP TS 23.292 "IP Multimedia System (IMS) centralized services; Stage 2"
31 Void No more used in current version of the document

32 Void No more used in current version of the document

33 Void No more used in current version of the document

V0.1 Page 6 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Document
Ref Title
Number
34 Void No more used in current version of the document

3GPP TS 24.229 "IP Multimedia Call Control Protocol based on Session Initiation
35 Protocol (SIP) and Session Description Protocol (SDP); Stage 3",
version 7.13.0 or higher.
ITU-T Recommendation "The international identification plan for mobile terminals and
36
E.212 mobile users"
ITU-T Recommendation "The international public telecommunication numbering plan"
37
E.164
38 IETF RFC 3261 "SIP: Session Initiation Protocol"
39 GSMA PRD IR.33 "GPRS Roaming Guidelines"
OMA OMA-TS- "Service Guide for Mobile Broadcast Services"
40 BCAST_Service_Guide-
V1_1-20100111-D
41 Void No more used in current version of the document
GSMA PRD IR.40 "Guidelines for IP Addressing and AS Numbering for GRX/IPX
42
Network Infrastructure and User Terminals"

43 Void No more used in current version of the document

IETF RFC 4825 "The Extensible Markup Language (XML) Configuration Access
44
Protocol (XCAP)"

3GPP TS24.623 "Extensible Markup Language (XML) Configuration Access

45 Protocol (XCAP over the Ut interface for Manipulating
Supplementary Services)"
46 GSMA PRD IR.92 "IMS Profile for Voice and SMS"

47 Void No more used in current version of the document

GSMA PRD RCC.07 Rich Communication Suite - Advanced Communications Services

48
and Client Specification
GSMA PRD IR.21 GSM Association Roaming Database, Structure and Updating
49
Procedures
3GPP TS 32.501 Telecommunication management; Self-configuration of network
50
elements; Concepts and requirements
3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and
51 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Overall description; Stage 2

52 GSMA PRD IR.88 LTE and EPC Roaming Guidelines

3GPP TS 26.346 Multimedia Broadcast/Multicast Service (MBMS); Protocols and

53
codecs

54 Void No more used in current version of the document

3GPP TS 24.379 Mission Critical Push To Talk (MCPTT) call control;

55
Protocol specification

V0.1 Page 7 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Document
Ref Title
Number
56 GSMA NG.105 ENUM Guidelines for Service Providers and IPX Providers

57 3GPP TS 23.501 System architecture for the 5G System (5GS); Stage 2

58 GSMA PRD NG.102 IMS Profile for Converged IP Communications

3GPP TS 23.003 Technical Specification Group Core Network and Terminals;

59
Numbering, addressing and identification

60 GSMA PRD NG.113 5GS Roaming Guidelines

61 GSMA PRD FS.34 Key Management for 4G and 5G inter-PMN Security

62 3GPP TS 29.573 Interconnection; Stage 3

2 DNS As Used on the GRX/IPX

2.1 Introduction
The Domain Name System is critical to such services as GPRS roaming, inter-PLMN MMS
delivery and IMS inter-working. DNS is defined in many IETF RFC documents; the most
notable ones are IETF RFC 1034 [1] and IETF RFC 1035 [2].

2.2 Architecture
The DNS on the inter-PLMN IP backbone network (known as the "GRX/IPX") is completely
separate from the DNS on the Internet. This is purposely done to add an extra layer of
security to the GRX/IPX network, and the nodes within it. The GRX/IPX Root DNS Servers
that network operators see are known as "Secondary" Root DNS Servers (Formerly known
as “Slave” Root DNS Server) and are commonly provisioned by that Service Provider's
GRX/IPX. However, these Secondary Root DNS Servers can be provisioned by operators
themselves if they so wish.

Each Secondary Root DNS Server is synchronised with a "Primary" Root DNS Server
(Formerly known as “Master” Root DNS Server). This process of synchronisation is known
as a "Zone Transfer" and ensures that the data is the same in all GRX/IPX Service
Providers' and Operators' Secondary Root DNS Servers. The following diagram depicts this:

V0.1 Page 8 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Primary
Zone
File

Primary
Zone Root
Zone
Transfers Transfers
Zone
Seconda Seconda Seconda Transfers Seconda
ry ry ry ry
GRX MNO GRX MNO
1 2 2 3

Queries /
Responses

Local
DNS
MNO
1

: Backbone Architecture

The data in the Primary Root DNS Server is known as the Primary Zone File. The
population of the data that goes into the Primary Zone File has a number of sources, mainly
Operators, GRX/IPX Providers and GRX/IPX Providers acting on behalf of Operators. It is
also policed and validated by the Primary Root DNS Server providers (under authority from
GSMA) to ensure such things as correct sub domain allocation and usage etc. The following
diagram depicts this:

V0.1 Page 9 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

GRX /
IPX
Operator Provider
s NS
Problem / Info Policin
Queries g
Problem /
Operatio Queries
nal Primary Root DNS
Support Server
Primary Zone
File

Zone
Zone
Transfers
Transfers
Seconda Zone Seconda
Seconda ry Seconda Transfers ry
ry Root & ry Root &
GRX MNO GRX MNO
Provid 2 Provid 3

Queries /
Responses

Local
DNS
MNO
1

: Overall Process Architecture

Finally, the following shows the architecture and the typical signalling involved in resolving
hostnames to IP addresses or vice versa. The numbered steps below in the diagram
correspond to the numbered message flows:

V0.1 Page 10 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

GRX 1
or
MNO 1

Secondary Root
DNS

2 GRX 1 / 2
3 or
MNO 2

4 Authoritative DNS

Local
MNO 1 Caching 5
DNS
1
6
Resolve
r

: Resolver Architecture

1. The Resolver (for example an SGSN trying to find out the IP address of a GGSN)
sends a query for the hostname (for example an APN) for which it wants the IP
address, to its local caching DNS server.
2. The local caching DNS server checks to see if it has the answer to the query in its
cache. If it does it answers immediately (with message 6). Otherwise, it forwards the
query on to the Root DNS server. The Root DNS server may reside in the Service
Provider 1's network or it may reside in the GRX/IPX provider's network (GRX1). The
address(es) of the Root DNS server may either be statically configured or be found by
using Host Anycasting (see below).
3. The Root DNS server returns a referral to the DNS server which is authoritative for the
queried domain name of the hostname (for example returns the authoritative server
for "mnc015.mcc234.gprs").
4. The local caching DNS server caches the response for a specified amount of time
(specified by the root DNS server) and then re sends the query but to the authoritative
DNS server as specified by the Root DNS server. The authoritative DNS server may
reside in the same GRX/IPX provider's network (GRX1), another GRX/IPX provider's
network (GRX2) or the network of the destination Mobile Network Operator (Service
Provider 2). (Indeed, it may even reside in the requesting Service Provider's network!)

V0.1 Page 11 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

5. The Authoritative DNS server responds to the query with the address of the hostname
(or responds with a hostname, if a reverse lookup is being performed) to the Local
Caching server in the requesting network (Service Provider 1).
6. The Local Caching Server caches the response for a specified amount of time
(specified by the authoritative server) and forwards it on to the Resolver.

NOTE 1: The above shows only a typical message flow for the DNS resolving on the
GRX/IPX. It may take extra queries when an MNO has Multiple levels of
authoritative DNS servers (see example below and section 3.1). Please
refer to section 4 for more detailed information for each service.

NOTE 2: In clause 7.11.21 (Section 17) of GSMA PRD IR.21 [49] provides for MNOs
to directly exchange the IP addresses and DNS names of their authoritative
DNS servers. This gives the option for an MNO who has received such
information from another MNO to configure directly into their local caching
servers the authoritative DNS servers IP addresses for the corresponding
DNS names.
When this option is used, and a query matching a configured DNS name is
received, the interaction with the Root DNS server specified in steps 2-4
above is bypassed. Instead the query is sent directly to the other operators
authoritative DNS server, after which steps 5 and 6 follow. However, if the
local caching DNS server has cached the answer to the query, the answer
is sent directly as specified in step 2.

Instead of having a single Authoritative DNS, an Operator may choose to split the DNS into
several levels of DNS for example a First Level DNS which may be authoritative for some of
the domain names “owned” by the MNO, and one or more Second Level Authoritative
DNSes, which may be authoritative for different “subdomainnames”, where for example a
Second Level DNS may be outsourced to 3rd party service provider for a particular service.

V0.1 Page 12 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

GRX 1
or
MNO 1

Secondary Root
DNS

2 GRX 1 / 2
3 or
MNO 2

4 1st Level
Authoritative DNS
Local
MNO 1 Caching 5
DNS
1
8
6
Resolve
r
GRX 1 / 2
7 or
2nd LevelMNO 2
Authoritative DNS
or

: Resolver Architecture with multiple levels of Authoritative DNS

1. Same as step 1 in the example above

2. Same as step 2 in the example above

3. Same as step 3 in the example above
4. Same as step 4 in the example above
5. The First Level Authoritative DNS server may be authoritative for the queried domain
name, in which case it responds to the query with the address of the hostname (or
responds with a hostname, if a reverse lookup is being performed) to the Local
Caching server in the requesting network (Service Provider 1). In this case the
following step process continues with step 8.
Alternatively for certain “subdomain names”, a second level DNS may be authoritative.
In this case The First Level Authoritative DNS server returns a referral to the Second
Level DNS server which is authoritative for the queried domain name of the hostname
(for example returns the authoritative server for
"<subdomainname>.mnc015.mcc234.gprs")

V0.1 Page 13 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

6. The local caching DNS server caches the response for a specified amount of time
(specified by the First Level Authoritative DNS server) and then re - sends the query
to the Second Level Authoritative DNS server as specified by the First Level
Authoritative DNS server. The 2nd Level Authoritative DNS server may reside in the
same GRX/IPX provider's network (GRX1), another GRX/IPX provider's network
(GRX2), the network of the destination Mobile Network Operator (Service Provider 2),
or in a 3rd Party Service Providers Network.
7. The Second Level Authoritative DNS server may respond to the query with the address
of the hostname (or responds with a hostname, if a reverse lookup is being performed)
to the Local Caching server in the requesting network (Service Provider 1).
8. The Local Caching Server caches the response for a specified amount of time
(specified by the authoritative server) and forwards it on to the Resolver.

NOTE 3: It is recommended that no more than two Levels of Authoritative DNS (that
is First Level and Second Level) are provisioned in a resolution "chain".

NOTE 4: In case the option to directly configure the IP address of another operators
DNS server is used as discussed in NOTE 2 above, only IP addresses of
First Level Authoritative DNS Server should be configured.

Some IPX services are offered on different network segments (VLANs) that are application
aware and that may not provide end-to-end IP connectivity, i.e. as shown in Fig 4 below,
MNO2 can either be an On-net MNO or an Off-net via IPX2. The DNS architecture is
required to take this into account. (See GSMA PRD IR.34 [12]). A resolver architecture
where the DNS service is “fronted” with a DNS cache/forwarder is required.

V0.1 Page 14 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

IPX 1
Service Aware
IPX 1 Root /
Secondary DNS

3
4

5 MNO 2
IPX Caching /
Proxy DNS MNO 2
6
Authoritative DNS

2 7
3
4
IPX 2
Local Caching
MNO 1 DNS Service Aware

1 IPX 2 Proxy DNS

8

Resolve
r

Service aware network resolver architecture

1. The Resolver sends a query, to its local caching DNS server for the hostname for
which it wants the IP address.
2. The local caching DNS server checks to see if it has the answer to the query in its
cache. If it does, it answers immediately (with message 8). Otherwise, it forwards the
query on to the IPX proxy/DNS
3. Based on the requested domain, the IPX DNS/Cache, either sends the query to the
root DNS (in case MNO2 is on-net) or to the next IPX provider proxy (if MNO2 is off-
net) to resolve the query.
4. The secondary root DNS returns the authoritative DNS for the requested domain in
MNO 2 or (message 4-bis) the IPX 2 proxy returns the query response.
5. (Case of on-net only:) The IPX proxy/cache sends the query to the authoritative DNS
in MNO 2 network.

V0.1 Page 15 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

6. (Case of on-net only:) The authoritative DNS in MNO 2 returns the response to the
query.
7. The IPX proxy/cache returns the response to the query to the cache in MNO 1 network.
8. The response is returned from the local cache to the resolver.

2.3 Domains

2.3.1 Introduction
The following sub-sections detail the domain names that can and cannot be used on the
GRX/IPX network.

In addition to this, the 3GPP have designated a specific sub domain for usage on the
Internet's DNS to enable user equipment to locate a specific server on the Internet
(terminals cannot see the GRX/IPX therefore a whole new sub domain had to be
introduced). For more information on which domains used by 3GPP are intended for which
network, see 3GPP TS 23.003 [8], Annex D.

2.3.2 General
Unlike the DNS on the Internet, the DNS on the GRX/IPX network is currently much "flatter".
That is, there are not so many domains (and sub-domains of thereof), supported and
provisioned in the GRX/IPX Root DNS Server. This inherently means that all domain names
used by Service Providers and GRX/IPX Providers in any service that utilises the GRX/IPX
network are limited to just the domain names detailed in 2.3.3 below. No other domain
name formats are currently supported on the GRX/IPX network! This effectively means
a limitation of domain names of ".gprs" and ".3gppnetwork.org" at the higher level, and
limited beneath to sub-domains of a format based on ITU-T Recommendation E.212 [36]
number ranges.

For the ".gprs" domain name, so called "human friendly" sub-domains are also allowed, as
specified in 3GPP TS 23.003 [8], section 9. This consists of simply an FQDN reserved in the
Internet domain name space e.g. serviceprovider.fi, serviceprovider.co.uk. However, such
sub-domains of ".gprs" are not generally used in the GRX/IPX network and it is
recommended not to use these as they can negatively affect GPRS/3G PS roaming. See
section 2.3.3 below for more details.

More information on processes and procedures relating to domain names can be found in
section 5.

2.3.3 Domain names used on the GRX/IPX DNS

The following provides a summary of the domain names that are used by Service Providers
on private IP inter-connects and on the GRX/IPX network. These domain names are only
resolvable by network equipment and not by end users. That is, they are exclusively used
on the Network-Network Interface (NNI) and not on the User-Network Interface (UNI).

Additional domain names that are resolvable on the GRX/IPX network's DNS may be added
in the future. See section 5 for more details.

V0.1 Page 16 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

For more details about each domain name and/or sub-domain name, refer to the referenced
documents.

V0.1 Page 17 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

Each Service Provider
is allowed to use only
sub-domains
consisting of MNC(s)
Service Provider domains of the form:
Used in GPRS for the and MCC(s) that are
<Network_Label>.mnc<MNC>.mcc<MCC>.gprs
Operator ID in APNs. allocated to them by
See section 4.2 and ITU-T and their local
Where <Network Label> is the Network Label part of national numbering Domain needs to be
also 3GPP TS 23.003
the Access Pont Name (APN) as defined in 3GPP TS authority. resolvable by at least
[8], section 9, for more
23.003 [8], section 9, and <MNC> and <MCC> are all GPRS/PS roaming
information.
the MNC and MCC of the Service Provider partners.
For Support of 2G/3G Service Providers
represented in decimal (base 10) form, with any 2
and EPC coexistence, should avoid using
digit MNC padded out to 3 digits by inserting a zero
see also section 4.17 Network Labels
("0") on the beginning e.g. 15 becomes 015.
consisting of any of the
.gprs
below defined
sub-domains, in order
to avoid clashes.

rac<RAC>.lac<LAC>.mnc<MNC>.mcc<MCC>.gprs Used in inter-SGSN Domains need to be

handovers (i.e. Routing Each Service Provider resolvable by at least
Area Updates) by the is allowed to use only all SGSNs to which a
Where <RAC> and <LAC> are the Routing Area new SGSN (possibly in sub-domains UE can hand over
Code and Location Area Code (respectively) a new PLMN) to route consisting of MNC(s) (which may be in
represented in hexadecimal (base 16) form, and to the old SGSN and MCC(s) that are other networks, if
<MNC> and <MCC> are the MNC and MCC of the (possibly in the old allocated to them by inter network
Service Provider represented in decimal (base 10) PLMN). See section ITU-T and their local GPRS/PS handovers
form, with any 2 digit MNC padded out to 3 digits by 4.2 and also 3GPP TS national numbering are supported in a
inserting a zero ("0") on the beginning e.g. 15 23.003 [8], Annex C.1, authority. Service Provider's
becomes 015. for more information. network).

V0.1 Page 18 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

Used in Routing Area
Updates by the new
nri<NRI>.rac<RAC>.lac<LAC>.mnc<MNC>.mcc<MC SGSN (possibly in a
C>.gprs new PLMN) to route to
the old SGSN (possibly
in the old PLMN),
Where <NRI>, <RAC> and <LAC> are the Network where Intra Domain
Resource Identifier, Routing Area Code and Location Connection of RAN
Area Code (respectively) represented in hexadecimal Nodes to Multiple CN
(base 16) form, and <MNC> and <MCC> are the Nodes (also known as
MNC and MCC of the Service Provider represented "RAN flex" – see 3GPP
in decimal (base 10) form, with any 2 digit MNC TS 23.236 [22]) is
padded out to 3 digits by inserting a zero ("0") on the applied. See section
beginning e.g. 15 becomes 015. 4.2 and also 3GPP TS
23.003 [8], Annex C.1,
for more information.

rnc<RNC>.mnc<MNC>.mcc<MCC>.gprs Used in SRNS

relocation to route to
the target RNC in the
Where <RNC> is the RNC ID represented in new SGSN (possibly in
hexadecimal (base 16) form, and <MNC> and a new PLMN). See
<MCC> are the MNC and MCC of the Service section 4.2 and also
Provider represented in decimal (base 10) form, with 3GPP TS 23.003 [8],
any 2 digit MNC padded out to 3 digits by inserting a Annex C.3, for more
zero ("0") on the beginning e.g. 15 becomes 015. information.

mms.mnc<MNC>.mcc<MCC>.gprs Domain needs to be

Used in MMS for the
resolvable by at least
domain name part of
all directly connected
Where <MNC> and <MCC> are the MNC and MCC the FQDN for MMSCs.
MMS interworking
of the Service Provider represented in decimal (base See section 4.3 and
partners/Service
10) form, with any 2 digit MNC padded out to 3 digits also 3GPP TS 23.140
Providers and directly

V0.1 Page 19 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

by inserting a zero ("0") on the beginning e.g. 15 [15], section 8.4.5.1, connected MMS Hub
becomes 015. for more information. Providers.
The domain name(s)
used must be owned
by that Service
Provider on the
Used as an alternative
<Internet_assigned_domain_name>.gprs Internet. If the domain
Operator ID in APNs
name(s) expire on the Domain needs to be
(also known as
Internet, they also resolvable by at least
Where <Internet_assigned_domain_name> is a "Human Readable
expire on the all GPRS/PS roaming
domain name reserved by the Service Provider on APNs"). See 3GPP TS
GRX/IPX. Care should partners.
the Internet. An example is "example.com.gprs" 23.003 [8], section 9,
be taken to ensure
for more details.
there is no clash with
the other sub-domains
for ".gprs" as defined
above.
Used in IMS in SIP Each Service Provider Domain needs to be
ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org addressing; is allowed to use only resolvable by at least
specifically, in the sub domains all SIP/IMS based
Private and Public consisting of MNC(s)
Where <MNC> and <MCC> are the MNC and MCC service inter working
Identities used in SIP and MCC(s) that are
of the Service Provider represented in decimal (base partners/Service
registration. See allocated to them by
10) form, with any 2 digit MNC padded out to 3 digits Providers, as well as
section 4.5 and 3GPP ITU T and their local
by inserting a zero ("0") on the beginning e.g. 15 roaming partners
.3gppnetwork.org TS 23.003 [8], section national numbering
becomes 015. where a visited P-
13, for more authority. CSCF is used.
information.
rcs.mnc<MNC>.mcc<MCC>.3gppnetwork.org Used in SIP Sub domains within
addressing to a MNO- the Service Provider's
As above. The differentiator “rcs” is used to enable provided IMS core domain (i.e. As above
differentiation between IMS cores providing MMTEL providing only RCS mnc<MNC>.mcc<MC
and RCS services in the dual registration case (see services. C>) are documented in

V0.1 Page 20 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

GSMA PRD NG.102 [578]). In this case, the IMS 3GPP TS 23.003 [8]. It
core providing RCS services is hosted by the MNO. is recommended that
<provider>.rcs.mnc<MNC>.mcc<MCC>.3gppnetwork Service Providers do
.org not use other sub
domains that are not
specified in 3GPP,
The <provider> identifies a non-MNO 3rd party entity OMA or in this PRD as
providing RCS services on behalf of a single MNO Used in SIP
this could potentially
identified by MCC/MNC. Used to identify the IMS addressing to a hosted
cause a clash of sub As above
core providing RCS services in the dual registration IMS core providing
domain usage in the
case (see GSMA PRD NG.102 [578]) where the only RCS services.
future.
hosted IMS solution is provided with MNO consent
(i.e. using the 3rd party’s terms and conditions, but
using standard MCC/MNC based domain for
provisioning).
<provider>.rcs.3gppnetwork.org

In this case, the <provider> is a domain name

reserved by a 3rd party RCS provider on the Internet. Used in SIP
It identifies Used to identify the IMS core providing addressing to a hosted
As above
RCS services in the dual registration case (see IMS core providing
GSMA PRD NG.102 [587]) where the hosted IMS only RCS services.
solution is provided without MNO consent (i.e. using
the 3rd party’s terms and conditions and a
proprietary domain for provisioning).
Used in WLAN Since this is a realm,
wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org
inter-working for NAI not a domain name, it
realms. See section does not necessarily
Where <MNC> and <MCC> are the MNC and MCC 4.4 and 3GPP TS have to be resolvable
of the Service Provider represented in decimal (base 23.003 [8], section 14, by external entities.
10) form, with any 2 digit MNC padded out to 3 digits for more information. The only time this is

V0.1 Page 21 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

by inserting a zero ("0") on the beginning e.g. 15 used in DNS is when
becomes 015. Diameter is used and
the next hop is
determined by DNS
rather than a look up
table.
Since this is a realm,
Used in the Generic not a domain name, it
gan.mnc<MNC>.mcc<MCC>.3gppnetwork.org Access Network for does not necessarily
Full Authentication NAI have to be resolvable
realms and Fast by external entities.
Where <MNC> and <MCC> are the MNC and MCC Re-authentication NAI The only time this is
of the Service Provider represented in decimal (base realms. See section used in DNS is when
10) form, with any 2 digit MNC padded out to 3 digits 4.7 and 3GPP TS Diameter is used and
by inserting a zero ("0") on the beginning e.g. 15 23.003 [8], section the next hop is
becomes 015. 17.2, for more determined by DNS
information. rather than a look up
table.
Used in the Enhanced
Packet Core (EPC)
architecture (previously
epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org known as Service
Architecture Evolution Domain and
Where <MNC> and <MCC> are the MNC and MCC – SAE) for NAIs and sub-domains need to
of the Service Provider represented in decimal (base FQDNs of EPC related be resolvable by
10) form, with any 2 digit MNC padded out to 3 digits nodes. See section 4.9 EPC/SAE roaming
by inserting a zero ("0") on the beginning e.g. 15 and 3GPP TS 23.003 partners.
becomes 015. [8], section 19, for
more information.
For support of EPC
and 2G/3G

V0.1 Page 22 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

coexistence see also
section 4.17

5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org Used in the 5G Core Domain and

(5GC) architecture for sub-domains need to
NAIs and FQDNs of be resolvable by 5GC
Where <MNC> and <MCC> are the MNC and MCC 5GC related nodes. roaming partners.
of the Service Provider represented in decimal (base See section 4.19 and
10) form, with any 2-digit MNC padded out to 3 digits 3GPP TS 23.003 [8],
by inserting a zero ("0") on the beginning e.g. 15 section 28, for more
becomes 015. information.

ics.mnc<MNC>.mcc<MCC>.3gppnetwork.org Used in the IMS Domain should only

Centralised Services be resolvable for CS
feature in SIP roaming partners
Where <MNC> and <MCC> are the MNC and MCC addressing. See where an MSC
of the Service Provider represented in decimal (base section 4.10 and 3GPP (Server) enhanced
10) form, with any 2 digit MNC padded out to 3 digits TS 23.003 [8], section for ICS is allowed to
by inserting a zero ("0") on the beginning e.g. 15 20, for more be used in that visited
becomes 015. information. partner's network.
Used by Service
Each Service Provider
node.mnc<MNC>.mcc<MCC>.3gppnetwork.org Providers to provide
is allowed to use only Domain needs to be
FQDNs to non-service
sub-domains resolvable by at least
specific nodes/hosts
Where <MNC> and <MCC> are the MNC and MCC consisting of MNC(s) all
e.g. DNS/ENUM
of the Service Provider represented in decimal (base and MCC(s) that are roaming/interworking
servers, routers,
10) form, with any 2 digit MNC padded out to 3 digits allocated to them by partners for the
firewalls etc. See
by inserting a zero ("0") on the beginning e.g. 15 ITU-T and their local services used by this
section 2.4 of this
becomes 015. national numbering domain name.
document for more
authority.
information.

oam.mnc<MNC>.mcc<MCC>.3gppnetwork.org Used by eNBs and Each Service Provider Domain should only
possibly other network is allowed to use only be resolvable by
entities in network sub-domains entities within an

V0.1 Page 23 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

Where <MNC> and <MCC> are the MNC and MCC element self- consisting of MNC(s) operator’s network, or
of the Service Provider represented in decimal (base configuration to and MCC(s) that are in the case of
10) form, with any 2 digit MNC padded out to 3 digits discover an Operations allocated to them by network sharing,
by inserting a zero ("0") on the beginning e.g. 15 and Maintenance ITU-T and their local within the shared
becomes 015. (OAM) system. See national numbering operator’s network.
section 4.16 and also authority.
3GPP TS 23.003 [8]
section 23, for more
information.
For interworking with
an SNPN (e.g.
discovery of AMFs
from an SNPN by a
5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork. Used to identify Home
shared NG RAN), this
org Network Domain for a Domain needs to be
sub-domain can be
Stand-alone Non- resolvable by at least
used when the MCC,
Public Network all
Where <NID>, <MNC> and <MCC> are the NID, MNC and NID uniquely
(SNPN). See section roaming/interworking
MNC and MCC of the Service Provider represented identifies the SNPN.
4.20 and 3GPP TS partners for the
in decimal (base 10) form, with any 2-digit MNC For signalling within an
23.003 [8], section 12.7 services used by this
padded out to 3 digits by inserting a zero ("0") on the SNPN, this sub-
(NID) and section 28, domain name.
beginning e.g. 15 becomes 015. domain can be used
for more information.
regardless of whether
the MCC, MNC and
NID uniquely identifies
the SNPN or not.
Used by the MCPTT Each Service Provider
service in an XML text is allowed to include
Intentionally not
where confidentiality this domain name
mc1-encrypted.3gppnetwork.org resolvable by any
protection of a URI as when confidentiality
entity.
specified in TS 24.379 protection of a URI as
[55] is required. See specified in TS 24.379

V0.1 Page 24 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

Rel-13 version of [55] is required and the
3GPP TS 23.003 [8], URI is not used for
section 26.2, for more routing.
information.
Used in WLAN
inter-working,
specifically as a realm Neither a Service
in the Alternative NAI. Provider, a GRX/IPX
Its purpose is to enable Provider nor any other Intentionally not
unreachable.3gppnetwork.org the UE to retrieve a list entity should use this resolvable by any
of PLMNs behind a domain name. It is entity.
WLAN Access Point. simply reserved to
See 3GPP TS 23.003 never be used!
[8], section 14.6, for
more information.
Not used in any
particular service,
spn<SPN>.ipxsp.org however, can be used
by any Service
Domain needs to be
Where <SPN> is the Service Provider Number of the Provider for any
Each Service Provider resolvable by at least
Service Provider. An example is: "spn001.ipxsp.org". service they see fit.
is allowed to use only all
The main intention is to
.ipxsp.org SPNs that are roaming/interworking
Further sub-domains under this are the responsibility provide a domain
allocated to them by partners for the
of the owning Service Provider. However, it is name that Service
ITU-T. services used by this
recommended to use/reserve the sub-domains Providers without an
domain name.
defined above for the domain E.212 number range
"mnc<MNC>.mcc<MCC>.3gppnetwork.org". allocation can use
when connecting to the
IPX network.

V0.1 Page 25 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

.e164enum.net Used as the domain Each Service Provider
name for ENUM is allowed to use only
The sub-domains of this domain name correspond to
queries to the GRX/IPX sub-domains relating See section 5 for
reversed ITU-T E.164 numbers (as defined in ITU-T
Carrier ENUM as to their subscribers. more information.
Recommendation E.164 [37]).
defined in section 5 of See section 5 for more
the present document. information.
.in-addr.arpa Used for reverse
lookups for IPv4
addresses i.e. mapping
names to IPv4
addresses. This is
useful when
troubleshooting
The sub-domains of this domain name correspond to
inter-PLMN
reversed IPv4 addresses that belong to the Service
connections. Due to
Provider. Domain should be
available tools being
Each Service Provider resolvable by at least
pre-configured to use
shall populate this all interworking
this hierarchy for
domain for IP partners/Service
reverse look-ups, it
addresses assigned to Providers, roaming
would not be feasible
them only (except with partners and directly
to use any different
permission of the connected GRX/IPX
TLD.
actual owner). Providers.
.ip6.arpa Used for reverse
lookups for IPv6
addresses i.e. mapping
The sub-domains of this domain name correspond to names to IPv6
reversed IPv6 addresses that belong to the Service addresses. This is
Provider. useful when
troubleshooting
inter-PLMN
connections. Due to

V0.1 Page 26 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

available tools using
this hierarchy for
reverse look-ups, it
would not be feasible
to use any different
TLD.
Used for identifying
<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org
non-MNOs on the IPX
network. Shall be used Domain needs to be
Where UNIQUE-IPX-PROVIDER-ID is the IPX for identifying non One subdomain per resolvable by at least
provider company name or acronym. It is agreed MNOs in the 5G core IPX provider. An IPX all roaming/
ipxnetwork.org amongst IPX/GRX providers and assigned on a first architecture roaming provider shall not use interworking partners
come – first served basis (see section 5.2) and two subdomains. for the services used
Can also be used by
Annex X by this domain name.
any IPX Provider for
Further subdomains under this are the responsibility
any service they see
of the owning IPX provider.
fit.
May be used by non-
MNO entities on the
Domain needs to be
IPX network for 5G
resolvable by at least
core roaming services
5gc.<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org all roaming/
ipxnetwork.org they deliver. (Not on
interworking partners
behalf of an MNO)
for the services used
These services include
by this domain name.
5G roaming VAS
services (RVAS)
May be used by non- Domain needs to be
MNO entities on the resolvable by at least
5gc.mnc<MNC>.mcc<MCC>.<UNIQUE-IPX- IPX network for 5G all roaming/
ipxnetwork.org
PROVIDER-ID>.ipxnetwork.org core roaming services interworking partners
they deliver on behalf for the services used
of an MNO. These by this domain name.

V0.1 Page 27 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

services include hosted
SEPP and operator
group SEPP

Table 1: Definitive list of domain names owned by GSMA that are used on the GRX/IPX DNS

V0.1 Page 28 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

V0.1 Page 29 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

2.3.4 Domain names used on the Internet DNS (and owned by GSMA)
The following provides a summary of the domain names owned by GSMA that are used by
Service Providers on the Internet for 3GPP specific services. For more detail about each
domain name and/or sub-domain name, refer to the referenced documents.

V0.1 Page 30 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

Each Service Provider is
allowed to use only
sub-domains consisting of
Used in the Generic MNC(s) and MCC(s) that
gan.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org Access Network for are allocated to them by
home network ITU-T and their local
Where <MNC> and <MCC> are the MNC and domain names in national numbering
MCC of the Service Provider represented in node identifiers. authority.
decimal (base 10) form, with any 2 digit MNC See section 4.7 and
padded out to 3 digits by inserting a zero ("0") on 3GPP TS 23.003 The host names "psegw"
the beginning e.g. 15 becomes 015. [8], section 17.3, for and "pganc" under this
more information. sub-domain are reserved
for special use, as detailed
in 3GPP TS 23.003 [8],
section 17.3 Domains need to be
pub.3gppnetwork.org
resolvable on the
w-apn.mnc<MNC>.mcc<MCC>.pub.3gppnetwork. Each Service Provider is
Internet.
org Used in WLAN allowed to use only
inter-working for sub-domains consisting of
PDG addressing. MNC(s) and MCC(s) that
Where <MNC> and <MCC> are the MNC and See section 4.4 and are allocated to them by
MCC of the Service Provider represented in 3GPP TS 23.003 ITU-T. The same rules
decimal (base 10) form, with any 2 digit MNC [8], section 14, for apply for APN constructs,
padded out to 3 digits by inserting a zero ("0") on more information. as defined in GSMA PRD
the beginning e.g. 15 becomes 015. IR.34 [12].
h- Used in the Secure Each Service Provider is
slp.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org User Plane allowed to use only
Location feature for sub-domains consisting of
Where <MNC> and <MCC> are the MNC and Home SUPL MNC(s) and MCC(s) that
MCC of the Service Provider represented in Location Platform are allocated to them by
decimal (base 10) form, with any 2 digit MNC addressing. See ITU-T and their local

V0.1 Page 31 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

padded out to 3 digits by inserting a zero ("0") on section 4.8 and national numbering
the beginning e.g. 15 becomes 015. OMA-AD-SUPL-V1 authority.
_0-20070615-A [27]
section 7.2.2, for
more information.
Used in the Generic
bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org Authentication
Architecture for
BSF addressing
Where <MNC> and <MCC> are the MNC and when USIM is used
MCC of the Service Provider represented in in bootstrapping.
decimal (base 10) form, with any 2 digit MNC See section 4.6 and
padded out to 3 digits by inserting a zero ("0") on 3GPP TS 23.003
the beginning e.g. 15 becomes 015. [8], section 16, for
more information.
andsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.o
rg

Where <MNC> and <MCC> are the MNC and

Used in EPC and
MCC of the Service Provider represented in
WLAN inter working
decimal (base 10) form, with any 2 digit MNC
(3GPP Rel 8) home
padded out to 3 digits by inserting a zero ("0") on
agent addressing.
the beginning e.g. 15 becomes 015.
See 3GPP TS
ha- 23.003 [8], section Each Service Provider is
apn.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org 21, for more allowed to use only
information. sub-domains consisting of
MNC(s) and MCC(s) that
Where <MNC> and <MCC> are the MNC and are allocated to them by
MCC of the Service Provider represented in ITU T. The same rules
decimal (base 10) form, with any 2 digit MNC apply for APN constructs,

V0.1 Page 32 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

padded out to 3 digits by inserting a zero ("0") on as defined in GSMA PRD
the beginning e.g. 15 becomes 015. IR.34 [12].
Used in the OMA
Mobile Broadcast
Services (BCAST)
bcast.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.o enabler, version
Each Service Provider is
rg 1.1, for Service
allowed to use only
Guide discovery by
sub-domains consisting of
a client with access
Where <MNC> and <MCC> are the MNC and MNC(s) and MCC(s) that
to an IMSI. See
MCC of the Service Provider represented in are allocated to them by
section 4.12 and
decimal (base 10) form, with any 2 digit MNC ITU-T and their local
OMA-TS-
padded out to 3 digits by inserting a zero ("0") on national numbering
BCAST_Service_G
the beginning e.g. 15 becomes 015. authority.
uide-
V1_1-20100111-D
[40] for more
information.
Used for the
RCS/RCS-e
service.
Each Service Provider is
rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org
allowed to use only
Where <MNC> and <MCC> are the MNC and RCS/RCS-e service sub-domains consisting of
MCC of the Service Provider represented in may use further MNC(s) and MCC(s) that
decimal (base 10) form, with any two (2) digit MNC subdomain names are allocated to them by
padded out to three (3) digits by inserting a zero depending on the ITU-T and their local
("0") on the beginning for example 15 becomes RCS/RCS-e service national numbering
015. evaluation and authority.
developments (for
example
config.rcs.mnc

V0.1 Page 33 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

<MNC>.mcc<MCC
>.pub.3gppnetwork.
org). The
description and the
use of the
subdomain names
will be referenced
in the RCS/RCS-e
specifications
where this domain
can be used by all
RCS/RCS-e
versions.
Used in the Generic
bsf.ims.mnc<MNC>.mcc<MCC>.pub.3gppnetwork. Authentication Each Service Provider is
org Architecture for allowed to use only
BSF addressing sub-domains consisting of
Where <MNC> and <MCC> are the MNC and when ISIM is used MNC(s) and MCC(s) that
MCC of the Service Provider represented in in bootstrapping. are allocated to them by
decimal (base 10) form, with any 2 digit MNC See section 4.6 and ITU-T and their local
padded out to 3 digits by inserting a zero ("0") on 3GPP TS 23.003 national numbering
the beginning e.g. 15 becomes 015. [8], section 16, for authority.
more information.

xcap.ims.mnc<MNC>.mcc<MCC>.pub.3gppnetwor Used in
Each Service Provider is
k.org supplementary
allowed to use only
service
sub-domains consisting of
configuration using
Where <MNC> and <MCC> are the MNC and MNC(s) and MCC(s) that
XCAP as specified
MCC of the Service Provider represented in are allocated to them by
in IR.92 [46]. Also
decimal (base 10) form, with any 2 digit MNC ITU-T and their local
see section 4.13

V0.1 Page 34 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

padded out to 3 digits by inserting a zero ("0") on and 3GPP TS national numbering
the beginning e.g. 15 becomes 015. 23.003 [8], section authority.
13.9, for more
information.
Used in
epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwo inter-working
rk.org Each Service Provider is
untrusted non-
allowed to use only
3GPP access
sub-domains consisting of
Where <MNC> and <MCC> are the MNC and network to EPC.
MNC(s) and MCC(s) that
MCC of the Service Provider represented in See section 4.15
are allocated to them by
decimal (base 10) form, with any 2 digit MNC and 3GPP TS
ITU-T and their local
padded out to 3 digits by inserting a zero ("0") on 23.003 [8], section
national numbering
the beginning e.g. 15 becomes 015. 19.4.2.9, for more
information.

mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwor Used by a UE for

k.org MBMS Service Each Service Provider is
Announcement allowed to use only
Bootstrap. sub-domains consisting of
Where <MNC> and <MCC> are the MNC and See section 4.18 MNC(s) and MCC(s) that
MCC of the Service Provider represented in and 3GPP TS are allocated to them by
decimal (base 10) form, with any 2 digit MNC 23.003 [8], section ITU-T and their local
padded out to 3 digits by inserting a zero ("0") on 15.5, for more national numbering
the beginning e.g. 15 becomes 015. information.

epdg.epc.mcc<MCC>.visited- Used by a roaming

country.pub.3gppnetwork.org UE to determine
Details of usage is defined
whether visited
in Release 13 version of
country mandates
Where <MCC> is the MCC of the country in which 3GPP TS 23.402 [29],
the selection of an
the UE is located represented in decimal (base 10) section 4.5.4.5.
ePDG in this
form. country.

V0.1 Page 35 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Domain name Sub-domain(s) Explanation Rules of Usage Resolvability

See 3GPP TS
23.003 [8], section
19.4.2.9.3 for more
information.
Used by a WLAN
access network that
wlan.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.or is not connected to
g the GSMA inter- Each Service Provider is
PLMN backbone to allowed to use only
reach the HPMN of sub-domains consisting of
Where <MNC> and <MCC> are the MNC and the served user. MNC(s) and MCC(s) that
MCC of the Service Provider represented in Used in the Open are allocated to them by
decimal (base 10) form, with any 2-digit MNC Roaming standard ITU-T and their local
padded out to 3 digits by inserting a zero ("0") on as defined by the national numbering
the beginning e.g. 15 becomes Wireless
Broadband Alliance
(WBA

Table 2: Definitive list of domain names owned by GSMA that are used on the Internet DNS

V0.1 Page 36 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

2.3.5 Domain names used on the GRX/IPX DNS for UNI

Only the domain name "ipxuni.3gppnetwork.org" is defined for domain names of this type
(see 3GPP TS 23.003 [8]). However, there are currently no sub-domains reserved under this
domain name.

2.4 Non-service specific hostnames and domains

Having a consistent naming convention makes it easier for tracing and trouble-shooting as
well as easing the maintenance of Service Provider's DNS. The following convention is
recommended to achieve these goals. Although the usage of this naming methodology is
highly recommended, it is not mandated.

Service Provider nodes should have names for each interface with the following format:

<city>-<type>-<nbr>

where:

• <city> is the name, or shortened name, of the city/town (or closest, where applicable)
where the node is located
• <nbr> is a running number of similar devices at the same city (for DNS servers, use 0
to indicate the primary DNS Server)
• <type> describes device type and should be one of the following for GRX/IPX
connected hosts:

o dns - DNS servers

o ggsn
o sgsn
o rtr - router
o fw - firewall

Additional values for the <type> parameter are for further study for the GRX/IPX. For
example, the following are valid hostnames for interfaces on Service Provider nodes:

• helsinki-ggsn-4

The domain name to append to hostnames for nodes belonging to Service Providers should
be the following (see section 2.3 for more details on the domain name formats):

• node.mnc<MNC>.mcc<MCC>.3gppnetwork.org
• node.spn< SPN>.ipxsp.org

A combination of the above domain names could be used by a Service Provider; however,
for consistency it is better to use only one.

The following are thus example Fully Qualified Domain Names (FQDNs) for interfaces on
Service Provider nodes:

• helsinki-ggsn-4.node.mnc015.mcc234.3gppnetwork.org
• london-dns-23.node.spn001.ipxsp.org

V21.0 Page 37 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Note that usage of the hostnames and sub-domains specified within this section under
"mnc<MNC>.mcc<MCC>.gprs" is now deprecated, and Service Providers are recommended
to use either of "mnc<MNC>.mcc<MCC>.3ppgnetwork.org" or "spn<SPN>.ipxsp.org"
domains at their earliest convenience. Of course, usage of "mnc<MNC>.mcc<MCC>.gprs"
for the uses as stated in section 2.3.3, is not deprecated and should continue as per normal.

2.5 Host names for the evolved packet Core (EPC)

The naming of Nodes for the Evolved Packet Core is specified in clause 19 of 3GPP TS
23.003 [8]

2.6 Host names for the IP Multimedia Subsystem (IMS)

Within the IP Multimedia Subsystem (IMS) the following Naming Convention for IMS Nodes
shall be used <Node name>. <SP Domain Name>, where

• <Node name> may consist of one or more labels that uniquely identifies the IMS
node within the Service Provider network.
• To avoid conflicts with future other subdomains to the <SP Domain Name> it can be
considered good practice to include “.node” as the right-most label of the <Node
Name>
• <SP Domain Name> is a Domain Name that is owned by the Service provider.
• “ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org” is the recommended <SP Domain
Name> for all IMS Nodes.

“ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org” must be used as <SP Domain Name> for

IMS Nodes that are individually addressable over the IPX network by SIP or any other
protocol, and where those Node Names need to be resolved over the IPX DNS system.

Examples of IMS nodes that may need to be individually addressable, are all nodes that are
addressed using a SIP Route Header, such as the nodes hosting the functionalities of a P-
CSCF, S-CSCF, TRF, ATCF, and eMSC-S for I2.

3 General DNS Configuration for Service Providers

3.1 Introduction
This section gives some general information on DNS server configuration for operators. For
information on configuring DNS servers for specific services, see sections 4 and 5.

3.2 DNS Server Hardware

It is recommended that operators have physically separate Primary and Secondary DNS
servers. This helps provide the greatest service availability and allows for e.g. upgrading
DNS Servers without any service interruption.

3.3 DNS Server Software

Most commonly ISC BIND (usually version 4 or version 9) is the chosen software supplied
by equipment vendors with any new service equipment that utilises a DNS Nameserver.
Service Providers and IPX Providers should ensure that only the most secure version is
used in their live networks, and all security patches are applied. Note that no particular

V21.0 Page 38 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

version of BIND is recommended, because to do so here would provide potentially out of

date information to the reader.

Use of ISC BIND is fine for services which do not necessarily have a large data-fil (for
example: GPRS, MMS).

Such commercial DNS Namesserver solutions can also support legacy DNS data-fil (for
example, that used for GPRS roaming), thereby consolidating all operator DNS needs. Note
that it is out of the scope of this document, and the GSMA, to provide any recommendations
on commercial DNS Nameservers. In fact, diversity of DNS software used by Service
Providers and IPX Providers gives a better overall robustness of the DNS on GRX/IPX
network.

3.4 DNS Server naming

All DNS servers need to have an FQDN assigned to them. For Service Provider DNS
servers connected to the GRX/IPX, the naming conventions as specified in section 2.4 shall
be used.

3.5 Domain Caching

Since each service (e.g. GPRS, MMS etc.) has its own domain, a separate TTL value can be
set per service.

When setting the TTL value for a zone, careful consideration must be taken to ensure that
the right trade-off is made between performance and consistency. A small TTL value results
in a greater signalling overhead, greater processing overhead for the authoritative name
server(s) and greater time for a returning a result (an example: GPRS PDP Context set-up
time), but the data will be more up-to-date therefore allowing updates to propagate much
more quickly. A large TTL value results in a smaller signalling overhead, smaller processor
overhead for the authoritative name server(s) and usually shorter time for returning a result
to the requesting entity, but the data will be more likely to be out of date and therefore
resulting in updates taking longer to propagate.

It is highly recommended that negative caching is also used (available in ISC BIND versions
4.9, 8.x and 9.x and should be available in most commercial DNS solutions). Again, careful
consideration should be taken, considering factors such as the frequency of updates,
signalling overhead and processing overhead of the authoritative DNS server for the domain.

3.6 Reverse Mapping

Each operator is strongly recommended to provide PTR (Pointer) records for all IP
addresses that FQDNs refer to, for example for APNs, MMSC addresses and so on. This is
not needed for inter-working to be successful, but rather, is recommended as it aids in
trouble shooting/debugging activities such as performing a "traceroute".

Reverse mapping for IPv4 addressing uses the "in-addr.arpa" domain, and reverse mapping
for IPv6 addressing uses "ip6.arpa". See section 2.3.3 for more information.

3.7 Use of DNS Interrogation Modes

Two interrogation modes are defined in the DNS specifications: iterative and recursive.

V21.0 Page 39 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

In Iterative mode, a DNS server interrogates each DNS server in the hierarchy itself, in order
to resolve the requested domain name. In Recursive Mode, a DNS server interrogates only
the next DNS server in the DNS hierarchy. That DNS Server then takes on responsibility for
resolving the requested domain name and provides a final answer back to the original
requesting DNS server. Figure 6 below depicts both iterative and recursive queries:

1 1
2 6

2
5
3
4

3
4
6

: Iterative (left) and Recursive (Right) modes of DNS querying

In non-service aware IPX (Example: GRX), only Iterative DNS queries shall be used within
the GRX/IPX. This not only saves on DNS Server load but also to enables visibility of the
source of the original request at the destination, which is lost when using recursive queries.

If any recursive DNS queries are received by a DNS Server then they should be ignored.
The only elements that should issue recursive DNS queries are service nodes issuing DNS
requests to their Local Caching DNS Servers e.g. an SGSN querying its Local Caching DNS
Server for an APN (see section 4.2 for more information on GPRS, including APN
resolution).

3.8 Use of the GRX/IPX Root DNS Server

There are two possibilities to arrange DNS hierarchy. The first is for each Service Provider to
configure their own authoritative DNS Server for each domain name that needs to be
resolved for all inter-working and roaming partner Service Providers. The draw-back of this
approach is that it is not scalable because every time a new inter-working and/or roaming
partner agreement is made, or even any existing inter-working and/or roaming partner's DNS
Server details change, the aforementioned authoritative DNS Server must be updated
accordingly. Thus, this could be a potential operational intensive task, and most likely a
frequent source for inter-working and roaming problems. This alternative may be fine for
small Service Providers with few interworking and/or roaming partners, but is not
recommended due to the reasons stated. Therefore, this alternative is not further detailed in
the present document.

V21.0 Page 40 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Another alternative is to use the common GRX/IPX Root DNS Server, as provided for by the
GRX/IPX service provider (see section 2.2 for more detail on this architecture). Using the
GRX/IPX Root DNS Server enables modified DNS Server details for a Service Provider to
automatically propagate to all interworking and roaming partners (subject to caching time).
This alternative is the recommended one, and is thus the assumed deployment of
authoritative DNS Servers in the rest of the present document.

3.9 Provisioning of Service Provider's DNS servers

Service Providers should take care to share all appropriate data to enable all
roaming/inter-working partners routing to an authoritative DNS Server, that is a DNS Server
where their own domain names can be resolved by others. GSMA IR.21 (PRD or GSMA
InfoCentre database) and the GRX/IPX Root DNS should be used to ease such sharing of
data, wherever possible.

Service Providers can provision authoritative DNS Servers themselves or outsource to

another entity for example their GRX/IPX Provider.

Service providers may have all appropriate data available in a single level of authoritative
DNS servers, where each authoritative DNS server holds all the appropriate data for the
Service Provider.

Alternatively, Service Providers may choose to divide the appropriate data between a First
Level Authoritative DNS Servers and 2nd Level Authoritative DNS Servers whereby each
2nd-level Authoritative DNS server only holds a subset of the appropriate data for the
Service provider.

When information about DNS servers are exchanged with the GRX/IPX Root DNS and other
Service Providers for example via PRD IR.21, and when 2nd-Level Authoritative DNS server
are used, it is essential to make a clear distinction between the First Level Authoritative DNS
servers and 2nd-Level Authoritative DNS servers. This is to ensure that only First Level
Authoritative DNS server are published in the GRX/IPX Root DNS such that the first query to
an Operators DNS always goes the First Level Authoritative DNS and that the second level
DNS servers are reached only by means of referrals from the First Level Authoritative DNS
server.

3.10 Resource Records

Service Providers and IPX Providers should take care to provision only the DNS Resource
Records (RRs) that are necessary for service interworking, trouble shooting and O&M
(Operations & Maintenance).

3.11 Support for IPv4 and IPv6

Support for IPv4 and IPv6 on Service Provider DNS Nameservers is twofold: the ability to
serve data relating to IPv4 and IPv6 addresses, and connectivity to/from the nameserver.

For configuration information in a Nameserver, both IPv4 and IPv6 information can coexist
together. Service Providers just need to ensure that the Nameserver software used is
capable of supporting the relevant Resource Records (RR) required. The "A" RR is used to
hold IPv4 address information and the "AAAA" RR for IPv6 address information. Details on
reverse mapping (IPv4/IPv6 address to domain name) are specified in section 3.6.

V21.0 Page 41 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

For connectivity to a Nameserver, it is highly recommended that all Service Provider

Nameservers be reachable using IPv4. Any Nameservers serving IPv6 information should
also be reachable using IPv6.

See GSMA PRD IR.34 [12] and GSMA PRD IR.40 [42] for more information on
recommendations relating to IPv4 and IPv6 routing and addressing.

4 DNS Aspects for Standardised Services

4.1 Introduction
This section describes the DNS aspects of standardised services that utilise DNS.
Recommendations are made, where appropriate, beyond what is defined in the referenced
specifications in order to promote easier service interworking for Service Providers. The list
of services below is not exhaustive and other services that utilise DNS on the GRX/IPX can
be used.

If there are discrepancies between the description of the services and the referenced
specifications in the following sub-sections, what is stated in the referenced specifications
shall prevail.

4.2 General Packet Radio Service (GPRS)

4.2.1 Introduction
GPRS provides for a packet switched bearer in GSM/UMTS networks. Packets are tunnelled
between core network nodes that may or may not be in different PLMNs, using the GPRS
Tunnelling Protocol (GTP) as defined in 3GPP TS 29.060 [26].

Note that in UMTS, GPRS is referred to as "Packet Switched" access, however, this is just a
naming convention, and the mechanism remains the same.

For more information on GPRS/Packet Switched access, see GSMA PRD IR.33 [39], 3GPP
TS 23.060 [23], and 3GPP TS 29.060 [26].

4.2.2 APN resolution in PDP Context activation

PDP Context activations occur between the SGSN and the GGSN. PDP Contexts are
activated to an Access Point Name either provided by the MS, or derived by the network
(such as when the MS instructs the SGSN to use a "default" APN). It is the APN that
determines to which interface on which GGSN the PDP Context is to be established. See
section 2.3 for the format of APNs. Further details on the APN can be found in GSMA PRD
IR.33 [39].

An SGSN and a GGSN can be located in either the HPLMN or VPLMN. Both are in the
same network when the subscriber is in the HPLMN and also when the subscriber is
roaming in a VPLMN and is using a GGSN in the VPLMN (vGGSN). However, the SGSN
and GGSN are in different networks when the subscriber is roaming but using a GGSN in
the HPLMN (hGGSN).

GPRS roaming means the extension of packet switched services offered in the Home PLMN
to Visited PLMNs with which the HPLMN has a predefined commercial roaming agreement.

V21.0 Page 42 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

The necessary DNS queries for resolving an APN in order to activate a PDP Context are
described below. Note that the Authoritative DNS Server is usually located in the same
PLMN as the GGSN, but can be located elsewhere, for example, in the HPLMN's GRX/IPX
provider's network (due to the HPLMN outsourcing the Authoritative DNS Server).

VPLMN GRX/IPX Network VPLMN or HPLMN

Local Caching Root DNS Authoritative

SGSN GGSN
DNS Server Server DNS Server

PDP Context establishment procedure

: DNS message flow for PDP Context activations

1. Upon receiving a "PDP Context Activation" message from the MS, the SGSN checks
the APN (if one was provided) against the user subscription record it previously
obtained from the HLR when the MS attached, and then sends a recursive DNS Query
to the DNS Local Caching DNS server.
2. The Local Caching DNS Server checks its local cache for the IP address of the
requested FQDN. If it has this, processing skips to step 6. Otherwise, the Local Caching
DNS Server checks its local cache for the IP address of the Authoritative DNS Server.
If it does not already have this IP address, it then issues an iterative DNS Query to the
Root DNS Server otherwise, processing skips to step 4.
3. The Root DNS Server replies to the DNS Query received from the Local Caching DNS
with the details of the Authoritative DNS Server (for example, the FQDN and/or IP
address(es).
4. The Local Caching DNS Server sends an iterative DNS Query to the Authoritative DNS
Server (which will reside in the VPLMN, for vGGSN connection, and will reside in the
HPLMN for hGGSN connection).
5. The Authoritative DNS Server replies to DNS Query received from the Local Caching
DNS Server with the IP address of the GGSN.

V21.0 Page 43 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

9. The Local Caching DNS Server replies to the DNS Query received from the SGSN (in
step 1) with the result obtained from the Authoritative DNS Server. The SGSN then
commences GTP tunnel establishment and, all being well, data flow starts.

As can be seen in the above steps, there are less DNS queries for a subscriber using a
GGSN in the VPLMN as the Root DNS Server is not interrogated.

Note also that the Local Caching DNS Server could also be the Authoritative DNS Server for
the requested FQDN, in which case a final result can be given immediately to the SGSN.

4.2.3 Inter-SGSN handovers for active PDP Contexts

When an MS has one or more PDP Contexts activated and moves to a new Routing Area
that is serviced by a new SGSN, the new SGSN needs to connect to the old SGSN in order
to download the PDP Context information and any data that is still to be delivered to the MS.
It can do this by either using a mapping table which has SGSN addresses against a finite set
of Routing Areas, or it can translate the old Routing Area Code (as received from the MS)
into a FQDN upon which to resolve to an IP address using DNS.

The former method is most commonly used for intra-PLMN SGSN handovers, and the latter
is used for inter-PLMN SGSN handovers. However, both methods can be used for both
types of handovers.

The latter of the two aforementioned methods is depicted below for inter- and intra-PLMN
SGSN handovers. The FQDN created by the SGSN depends upon whether the SGSN
handover is a Routing Area Update, Routing Area Update in a network which has Intra
Domain Connection of RAN Nodes to Multiple CN Nodes or is an SRNS Relocation (see
3GPP TS 23.060 [23], section 6.9, for more information).

V21.0 Page 44 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

New VPLMN or HPLMN GRX/IPX Network Old VPLMN or HPLMN

New Local Caching Root DNS Authoritative

Old SGSN
SGSN DNS Server Server DNS Server

PDP Context handover procedure

: DNS message flow for PDP Context handovers between SGSNs

1. The new SGSN creates an FQDN using the old Routing Area Code (and the Network
Resource Identifier, if available) or the old RNC ID and then issues a recursive DNS
Query to the DNS server address configured in the SGSN (Local Caching DNS server).
2. The Local Caching DNS Server checks its local cache for the IP address of the
requested FQDN. If it has this, processing skips to step 6. Otherwise, the Local Caching
DNS Server checks its local cache for the IP address of the Authoritative DNS Server.
If it does not already have this IP address, it then issues an iterative DNS Query to the
Root DNS Server, otherwise, processing skips to step 4.
3. The Root DNS Server replies to the DNS Query received from the Local Caching DNS
with the details of the Authoritative DNS Server (for example, the FQDN and/or IP
address(es)).
4. The Local Caching DNS Server sends an iterative DNS Query to the Authoritative DNS
Server (which will reside in the VPLMN, for inter-PLMN handover, and will reside in the
HPLMN for intra-PLMN handover).
5. The Authoritative DNS Server replies to DNS Query received from the Local Caching
DNS Server with the IP address of the old SGSN.
6. The Local Caching DNS Server replies to the DNS Query received from the SGSN (in
step 1) with the result obtained from the Authoritative DNS Server. The New SGSN
then commences handover with the Old SGSN.

As can be seen in the above steps, there are less DNS queries for an intra-PLMN SGSN
handover as the Root DNS Server is not interrogated.

V21.0 Page 45 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Note also that the Local Caching DNS Server could also be the Authoritative DNS Server for
the requested FQDN, in which case a final result can be given immediately to the New
SGSN.

4.3 Multi-media Messaging Service (MMS)

4.3.1 Introduction
MMS inter-working is where a subscriber of one operator has the ability to send and receive
Multimedia Messages (MMs) to and from a subscriber of another operator. Unlike SMS inter-
working, the MM is always sent to the user via his “home” service centre. This means that in
all MMS inter-working scenarios, the MM is always transferred from the source operator’s
MMSC to the destination operator’s MMSC. Thus, MMS interworking requires use of a
standardised inter-MMSC protocol. This protocol is defined as SMTP (defined in IETF RFC
2821[13]) as profiled in the MMS specification 3GPP TS 23.140 [15].

DNS is used in MMS in order for the source MMSC to resolve the destination MMSC/SMTP
server. DNS MX Resource Records, as defined in IETF RFC 1035 [2], are required for
SMTP based Multimedia Message routeing and relaying. It should be noted that GSMA PRD
IR.34 [12] recommends that the ".gprs" TLD should be used when utilising the GRX/IPX
network as the interworking network between MMSCs. This format of FQDN, including
allowed sub-domains, is defined in section 2.3 of the present document.

The selection of a DNS tree/hierarchy to use (e.g. Internet or GRX/IPX) ultimately depends
on the interconnection network used. The interconnection network used can in turn depend
on where the MM is to be sent e.g. Internet for when delivering to an e-mail user, GRX/IPX
network for when delivering to another MMS subscriber. Thus, the resolution process may
differ depending on whether the MM is addressed to an MSISDN/E.164 number or to an
NAI/e-mail address.

There are also different commercial models for MMS inter-working between Operators.
These are essentially the "Direct Interconnect" model, where MMs are sent from Operator A
to Operator B directly, and the "Indirect Interconnect Model", where MMs are sent from
Operator A to an MMS Hub (and the MMS Hub then takes care of delivering the MM to
Operator B).

More information on MMS interworking can be found in GSMA PRD IR.52 [9].

4.3.2 MM delivery based on MSISDN for the Direct Interconnect model

The following figure and associated numbered steps describe the direct interconnect only
scenario for MMS inter-working of MMs addressed to an MSISDN/E.164 number:

V21.0 Page 46 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Operator A GRX/IPX Network Operator B

Local Caching Root DNS Authoritative

MMSC MMSC
DNS Server Server DNS Server

SMTP Message Transfer procedure

: MMS Direct Inter-network Delivery

1. Upon receiving a Multimedia Message (MM) from the MS, the MMSC converts the
destination MSISDN to an MMS FQDN (commonly of the form
"mms.mnc<MNC>.mcc<MCC>.gprs") by using one of the following methods:

• An HLR look-up using e.g. the MAP_SRI_For_SM operation. This returns the IMSI, of
which the MNC and MCC are extracted to create the MMS FQDN.

2. The MMSC then sends a recursive DNS query for the derived FQDN to the Local
Caching DNS Server.
3. The Local Caching DNS Server checks its local cache for the IP address of the
requested FQDN. If it has this, processing skips to step 6. Otherwise, the Local Caching
DNS Server checks its local cache for the IP address of the Authoritative DNS Server.
If it does not already have this IP address, it then issues an iterative DNS Query to the
Root DNS Server, otherwise processing skips to step 4.
4. The Root DNS Server replies to the DNS Query received from the Local Caching DNS
Server with the details of the Authoritative DNS Server (for example, the FQDN and/or
IP address(es)).
5. The Local Caching DNS Server sends an iterative DNS Query to the Authoritative DNS
Server.
6. The Authoritative DNS Server replies to the DNS Query received from the Local
Caching DNS Server with the IP address of the MMSC, or, a list of FQDNs and/or IP
addresses if the query was for an MX record.

V21.0 Page 47 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

7. The Local Caching DNS Server replies to the DNS Query received from the MMSC (in
step 1) with the result obtained from the Authoritative DNS Server. The MMSC then
commences an SMTP session with Operator B's MMSC to transfer the MM.

Note that the Local Caching DNS Server could also be the Authoritative DNS
Server for the requested FQDN, in which case a final result can be given
immediately to the MMSC.

4.3.3 MM delivery based on MSISDN for the Indirect Interconnect model

The following figure and associated numbered steps describe the MMS hub model of
interconnect for MMS inter-working of MMs addressed to an MSISDN/E.164 number:

Operator A Operator B or
GRX/IPX Network

Local Caching Authoritative MMSC or

MMSC
DNS Server DNS Server MMS Hub 1

SMTP Message Transfer procedure

: MMS Inter-operator Delivery

1. Upon receiving a Multimedia Message (MM) from the MS, the MMSC converts the
destination MSISDN to an MMS FQDN (commonly of the form
"mms.mnc<MNC>.mcc<MCC>.gprs") by using one of the following methods:

• An HLR look-up using e.g. the MAP_SRI_For_SM operation. This returns the IMSI, of
which the MNC and MCC are extracted to create the MMS FQDN.

The MMSC then sends a recursive DNS query for the derived FQDN to the Local Caching
DNS Server.

2. The Local Caching DNS Server checks its local cache for the IP address of the
requested FQDN. If it has this, processing skips to step 4. Otherwise, the Local Caching
DNS Server checks its local cache for the IP address of the Authoritative DNS Server.
In this model, the Authoritative DNS Server is always known.
3. The Authoritative DNS Server replies to the DNS Query received from the Local
Caching DNS Server with either the IP address of the MMS Hub to use or the

V21.0 Page 48 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

destination MMSC, or, a list of FQDNs and/or IP addresses if the query was for an MX
record.
4. The Local Caching DNS Server replies to the DNS Query received from the MMSC (in
step 1) with the result obtained from the Authoritative DNS Server. The MMSC then
commences an SMTP session either with Operator B's MMSC, or, to an identified MMS
Hub, to transfer the MM.

Note that there is more flexibility in the MMS Hub architecture than shown above, depending
on the MMS Hub provider used e.g. some Hub providers offer MSISDN/E.164 number
conversion/resolving, some offer complete hosting of the MMSC, and so on. See GSMA
PRD IR.52 [9] for more information on MM delivery using an MMS Hub, including a more full
description of the flexibility available in the architecture.

Note also that the Local Caching DNS Server could also be the Authoritative DNS Server for
the requested FQDN, in which case a final result can be given immediately to the MMSC.

4.3.4 MM delivery based on NAI/e-mail address

For MMs addressed to an NAI/e-mail address (as defined in IETF RFC 2822 [14]), the
message flow is the same as in Figure 7 except that the Internet's root DNS servers and
authoritative DNS servers are used, possibly with the use of referral DNS servers too.

4.4 WLAN Inter-working

4.4.1 Introduction
Figure 9 shows how local login and roaming login differ; it also demonstrates how Roaming
Partners actually connect to each other via inter-operator network. Case 1 is an example of
normal local login in the hot spot of Visited PLMN, where the user inserts his username &
password and is authenticated in the Visited PLMN. In this case, the RADIUS Roaming
Network is not utilised.

Case 2 in Figure 9 refers to a roaming login, where the user inserts his username (with
realm) and password in the hot spot of the Visited PLMN and authentication and request is
sent by way of a proxy to Home PLMN. The User is then authenticated in the Home PLMN.
Necessary RADIUS messages are transferred between RADIUS Roaming Proxies using the
IP based Inter-PLMN network, that is, the GRX/IPX.

Figure 9 shows also in principle the difference between the following two authentication
methods:

• Web Based Authentication

• SIM Based Authentication

Web Based (that is, using username/password) authentication is considered as an existing

first phase solution for the WLAN authentication. However, in the future there will be a target
solution utilising EAP solutions, where the Home PLMN HLR is involved.

V21.0 Page 49 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

: WLAN user authentication mechanism

The GRX/IPX network is used for transporting RADIUS authentication and accounting
messages for WLAN roaming services only, WLAN user data is not carried over GRX/IPX.

The IP address of the WLAN Roaming Proxy must be reachable via the GRX/IPX. Please
note that the first phase of WLAN roaming will not use the GRX/IPX Root DNS at all since
the IP addresses of the Home PLMN RADIUS server is statically configured in the Visited
PLMNs RADIUS server (the "next hop" list). In fact, RADIUS does not provide for a DNS
type solution for realm to AAA entity mapping. The utilising of Root DNS may be required in
future WLAN roaming solutions where Diameter instead of RADIUS is used, as Diameter
does provide for an optional realm to AAA entity mapping.

More information on WLAN roaming can be found in GSMA PRD IR.61 [10].

4.5 IP Multi-media Sub-system (IMS)

4.5.1 Introduction
The IP Multi-media Sub-system (IMS) provides a standardised architecture for providing
feature rich multimedia services/applications, such as speech communication, messaging,
real-time and turn-based gaming, shared online whiteboards etc. IMS services/applications
rely on sessions managed by the Session Initiation Protocol (SIP), as defined in IETF RFC
3261 [38], and profiled in 3GPP TS 24.229 [35] (which includes a set of standardised
extensions) to be used by Service Providers.

V21.0 Page 50 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Diameter is also used on some interfaces in the IMS architecture, however, these are
intra-Service Provider interfaces and so are outside the scope of this PRD.

Figure 10 shows an end-to-end IMS session. Only the basic architecture of involved IMS
network elements is shown. Please note that signalling and user data of an IMS session are
separated. Signalling and user data make use of different PDN connections, but use the
same (originating) IP address.

Home Network Home Network

IM Subsystem IM Subsystem
S-CSCF S-CSCF
Home Network A Mm Home Network B
Mm
P-CSCF I-CSCF I-CSCF P-CSCF
Inter-PLMN
Inter-Network
BG BG
IM Backbone
IP Backbone

UE SGSN GGSN GGSN SGSN UE

Gi Gi

: IMS Session Inter-working

IMS subscribers are addressed by SIP URIs or E.164 numbers represented as Tel URIs or
SIP URIs with the "user=phone" option. ENUM is specified in IMS as the means to convert
an E.164 number into one or more SIP URI as indicated in section 2.3.3. See GSMA PRD
NG.105 [56] for more information on ENUM Guidelines for Service Providers and IPX
Providers.

For resolving SIP URIs to SIP Servers (see IETF RFC 3263 [17]), the support of the NAPTR
Resource Record functionality (as defined in IETF RFC 3404 [7]) and the SRV Resource
Record functionality (as defined in IETF RFC 2782 [18]) is needed in the Service Provider's
DNS servers.

More information on IMS roaming and interworking can be found in GSMA PRD IR.65 [11].

4.5.2 SIP server configuration

There are several RFCs covering use of SIP in the DNS. These include IETF RFC 3824
[24], IETF RFC 3263 [17], and IETF RFC 3403 [6].

The reason this configuration is needed is as follows:

When a SIP session is initiated by a user, they address the session to either a SIP URI (e.g.
[email protected]) or an E.164 number. In both cases, the IMS needs to know the IP
address of the SIP server to which it can route the session. The SIP server information
contains the detail needed to provide the destination network's SIP server IP address to the
calling network based on the information in the SIP URI.

V21.0 Page 51 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

The approach described in this section is compliant with these RFCs and consists of 4
separate steps. It is consequently known as the “4-step approach”.

In order to improve performance/session establishment time, use of explicit IP addresses

instead of FQDNs eliminates the need for some DNS lookups and retains compatibility with
existing standards. However, using IP addresses instead of FQDNs is more restrictive.

4.5.2.1 Step 1
This is the ENUM related step and is performed only for cases where the service has been
addressed to an E.164 number. An IMS call to a user using the format [email protected]
would not require this step. Example of DNS data for a particular SIP URI and its servers
can be found in section 4.5.2.

4.5.2.2 Step 2
Having obtained the destination domain name the DNS is asked to provide matching SIP
Server Location Information. One or more NAPTR records may be retrieved and the calling
application examines these records to find the best match based on priorities and the
desired SIP protocol variant:
mnc001.mcc234.3gppnetwork.org. IN NAPTR 50 100 "s" "SIP+D2U" "" _sip._udp.example.com.
mnc001.mcc234.3gppnetwork.org. IN NAPTR 90 100 "s" "SIP+D2T" "" _sip._tcp.example.com.
mnc001.mcc234.3gppnetwork.org. IN NAPTR 90 100 "s" "SIPS+D2T" "" _sips._tcp.example.com.

In the above example, “D2U” indicates UDP-based SIP, “D2T” indicates TCP-based SIP,
and “SIPS+D2T” indicates UDP-based unencrypted SIP.

The presence of these fields indicates what variations of SIP are supported on a given SIP
server.

The "s" flag means the next stage is to look up an "SRV" record

4.5.2.3 Step 3
An example set of SIP server SRV records is as follows:

_sip._tcp.example.com. SRV 0 1 5060 sipserv1.example.com.

_sip._tcp.example.com. SRV 0 2 5060 sipserv2.example.com.
_sip._udp.example.com. SRV 0 1 5060 sipserv1.example.com.
_sip._udp.example.com. SRV 0 2 5060 sipserv2.example.com.
_sips._tcp.example.com. SRV 0 1 5060 sipserv3.example.com.
_sips._tcp.example.com. SRV 0 2 5060 sipserv4.example.com.

For each of the variations of the SIP protocols supported the SRV records describe:

• name of the server;

• which port number SIP uses; and
• where there are multiple servers, the weights & priorities to allow rough load
balancing.

The calling network asks the DNS for a SRV record for the host corresponding to the specific
service/protocol/domain combination that was returned in Step 2

V21.0 Page 52 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

If there are multiple records with the same service/protocol/domain combination, the caller
must sort the records based on which has the lowest priority. If there is more than one
record with the same priority, the record with the highest weight is chosen.

From the SRV record get the corresponding server name.

There is potential flexibility in this step for the destination operator to receive the SIP traffic
on different servers depending on the desired variation of the SIP protocol – TCP, UDP,
encrypted, unencrypted.

4.5.2.4 Step 4
For the server name returned in Step 3, do a standard DNS lookup to finds its IP address

This is a normal "A" (address) record lookup

sipserv1.example.com. IN A 101.1.2.3
sipserv2.example.com. IN A 101.1.2.4

4.5.3 Domain Names used

The domain names used for IMS based services are SIP Server names, however, there are
no restrictions in the standards as to what these domain names shall be (other than the
normal FQDN rules, as specified in the likes of IETF RFC 1034 [1] and IETF RFC 1035 [2]).
However, for service providers interconnecting across the GRX/IPX network, it is
recommended to use an MCC/MNC sub domain of ".3gppnetwork.org" as this is supported
already on the GRX/IPX DNS and also allows for SIP URIs returned using ENUM on the
GRX/IPX as specified in section 5.

It should be noted that right now, more "user friendly" domain names are not yet directly
supported on the GRX/IPX DNS. Work on supporting a much wider set of domain names is
ongoing.

4.6 Generic Authentication Architecture (GAA)

4.6.1 Introduction
The Generic Authentication Architecture is defined in 3GPP TS 33.220 [19]. It is a
standardised mechanism for securely distributing shared keys for later use by applications
on the UE.

NOTE: The address of the Bootstrapping Server Function (BSF) used by the UE is
dependent on whether USIM or ISIM is used in bootstrapping. See 3GPP TS
23.003 [8], section 16.

4.7 Generic Access Network (GAN)

4.7.1 Introduction
The Generic Access Network is defined in 3GPP TS 43.318 [20] and 3GPP TS 44.318 [21].
It provides for using unlicensed radio spectrum for accessing the GSM core network in order
to provide normal GSM services including both CS and PS. It was based on the work done
by the UMA forum.

V21.0 Page 53 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

4.8 Secure User Plane Location (SUPL)

4.8.1 Introduction
The Secure User Plane Location feature is defined in OMA
OMA-AD-SUPL-V1_0-20070615-A [27]. It provides a mechanism for carrying location
information between a user's SUPL Enabled Terminal (SET) and SUPL Location Platform
(SLP) in a Service Provider's network, in a way that does not rely on modifications to any
network interfaces or elements between the SET and SPL. This information can then be
used by the Service Provider to calculate the SET's location.

4.9 Enhanced Packet Core (EPC)

4.9.1 Introduction
The Enhanced Packet Core is defined in 3GPP TS 23.401 [28] and 3GPP TS 23.402 [29]. It
provides for a new and much more efficient PS core network to support E-UTRAN and
serves as part of the Enhanced Packet System (EPS).

It should be noted that EPC used to be known as SAE (Service Architecture Evolution) and
E-UTRAN used to be known as LTE (Long Term Evolution) RAN.

4.10 IMS Centralised Services (ICS)

4.10.1 Introduction
The IMS Centralised Services feature is defined in 3GPP TS 23.292 [30]. It enables the
provisioning of Supplementary Services and value added services (such as those offered
today via CAMEL) to the CS domain from IMS.

4.11 Access Network Discovery Support Function (ANDSF)

4.11.1 Introduction
The Access Network Discovery Support Function (ANDSF) is defined in 3GPP TS 23.402
[29]. It contains data management and control functionality necessary to provide network
discovery and selection assistance data according to Service Provider policy. The ANDSF
responds to requests from the UE for access network discovery information and may be able
to initiate data transfer to the UE, based on network triggers.

4.12 Mobile Broadcast Services (BCAST)

4.12.1 Introduction
Mobile Broadcast Services is a service enabler defined by the OMA in
OMA-TS-BCAST_Service_Guide-V1_1-20100111-D [40]. This enables service/content
providers to describe the services and content available (either free, subscription or one-off
fee) and how to access them as Mobile Broadcast services either over a Broadcast Channel
or over an Interaction Channel. From the user perspective the Service Guide can be seen as
an entry point to discover the currently available or scheduled services and content, and to
filter those based on their preferences.

V21.0 Page 54 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Discovery of a Service Guide Function is performed using DNS SRV records, or optionally,
using an FQDN derived from the IMSI, as specified in section 6.2.1 of
OMA-TS-BCAST_Service_Guide-V1_1-20100111-D [40]. The domain name to use when
deriving the FQDN from the IMSI is specified in section 2.3 of the present document.

4.13 The XCAP Root URI on Ut Interface for MMTEL/IMS profile for Voice and
SMS (XCAP)

4.13.1 Introduction
XCAP is a protocol defined in IETF RFC 4825 [44], 3GPP TS 24.623 [45], and is part of the
IMS profile for Voice and SMS documented in IR.92 [46]. This is used in manipulation of
supplementary service configuration.

The XCAP Root URI is defined in IETF RFC 4825 [44], and is used to identify the XCAP
Root, which is a context that contains all the documents across all application usages and
users that are managed by the XCAP server.

The XCAP Root URI takes the following format: "http://xcap.domain"

The domain part of the XCAP Root URI is derived in accordance with 3GPP TS 23.003 [8],
section 13.9.

4.14 RCS - Rich Communication Suite

4.14.1 Introduction
RCS as specified in the RCS specifications [48] is a simple and interoperable evolution to
voice and text, which enables customers to send instant messages, video chat and
exchange files in real time, that is rich call with content sharing, chat, file sharing etc. All
functions are built into the address book of mobile devices. RCS focuses on the
communications service aspects building on established interoperability principles within the
mobile operator ecosystem providing service definition, functional description and technical
realisation to develop new service packages for today's 'always-on' mobile users enabling
seamless user experience.

The description and the use of the reserved subdomain names will be referenced in the RCS
specifications where this domain can be used by all RCS specification versions.

4.15 Evolved Packet Data Gateway (ePDG)

4.15.1 Introduction
The Evolved Packet Data Gateway is defined in 3GPP TS 23.402 [29]. It provides PDN
connectivity to the Evolved Packet Core (EPC) over untrusted non-3GPP IP access
networks.

V21.0 Page 55 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

4.16 Network element self-configuration

4.16.1 Introduction
The concept of network element self-configuration is described in 3GPP TS 32.501 [50]. The
network elements self-configuration can be applied e.g. for eNBs that is defined in 3GPP TS
36.300 [51].

4.17 EPC and GPRS coexistence

4.17.1 Introduction
When configuring the authoritative DNS server, a mobile operator supporting both GPRS
and EPC roaming must consider that different DNS query procedures can be used in GPRS
(A/AAAA-record queries) compared with EPC (S-NAPTR queries).

GSMA PRD IR.88 [52] provides further details on the DNS configuration requirements for
different GPRS (2G/3G) and EPC coexistence scenarios.

4.18 MBMS Service Announcement Bootstrapping

4.18.1 Introduction
The method for bootstrapping for MBMS service announcement is described in 3GPP TS
26.346 [53]

4.19 5G Core (5GC)

4.19.1 Introduction
The 5G Core is defined in 3GPP TS 23.501 [37]. It provides support for a new and enhanced
PS core networks to support NG-RAN (refer also to 3GPP TS 23.501 [37]) and serves as
part of the 5G System (5GS).

4.19.2 Usage of DNS in Peer SEPP FQDN(s) discovery

Whenever an initiating SEPP (iSEPP) needs to contact another network, it needs to
determine the responding SEPP (rSEPP). For example: A vNRF addresses a hNRF by
making use of the hNRF FQDN as defined in 23.003 [59] subclause 28.3.2.3.3. The example
given there is:

For MCC = 012 and MNC = 345, the API root of the NRF services shall be:
"https://nrf.5gc.mnc345.mcc012.3gppnetwork.org/"
As a result of receiving this message, the iSEPP needs to establish a N32 connection with
the rSEPP, if no such connection has already been established. For this, it needs to discover
the IP address of the appropriate rSEPP.

The discovery approach described in this section consists of 3 steps, as follows.

4.19.2.1 Step 1
Based on the PLMN ID the well-known FQDN can be constructed. For MCC = 012 and MNC
= 345 the well-known FQDN shall be: sepp.5gc.mnc345.mcc012.3gppnetwork.org

V21.0 Page 56 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Unless specified and agreed otherwise this well-known FQDN shall be used by the iSEPP to
issue a DNS query to provide matching rSEPP(s) topology Information.

One or more NAPTR records may be retrieved for the "FQDN"

sepp.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org and the SEPP examines these
records to find the best match based on priorities. In the example below, the network with
MCC = 012 and MNC = 345 has one NAPTR record:
TTL order preference flags service regex replacement
sepp.5gc.mnc345.mcc012.3gppnetwork.org. 14400 IN NAPTR 50 100 “s” “x-3gpp-sepp:x-n32c” “” _n32._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org.

The service parameter shall be set to “x-3gpp-sepp:x-n32c”, indicating that peer entity is a
SEPP and the interface is N32c. The regex shall be empty.

From Release 17 onwards, TS 29.573 [62] supports different purposes for N32. The service
parameter shall be used to indicate the purpose of an N32c interface. Every supported
purpose shall have its own DNS record.

If the purpose for N32 establishment is not specified, the purpose shall be "ROAMING" only.

For purposes other than "ROAMING", the purpose string, i.e. the String from the column
"enumeration value" of table 6.1.5.3.9-1 of 3GPP Release 18 TS 29.573 [62], shall be
appended to the service parameter "x-3gpp-sepp:x-n32c:"

For the purpose "ROAMING" the purpose string is not appended to the service parameter
"x-3gpp-sepp:x-n32c".

The replacement string, i.e. the input to the SRV query, needs to be different for those
purposes that need to be routed via different N32 connections, and the same for those
purposes that need to be routed via the same N32 connection

NOTE: The correct release to reference should be aligned with the latest published release.

To give an example for an operator that would like to use two different N32 connections, one
for SMS_INTERCONNECT and one for ROAMING and DISASTER_ROAMING, the NAPTR
records could look as follows:
sepp.5gc.mnc345.mcc012.3gppnetwork.org. 14400 IN NAPTR 50 100 "s" "x-3gpp-sepp:x-n32c:SMS_INTERCONECT" ""
_n32_xy._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org.
sepp.5gc.mnc345.mcc012.3gppnetwork.org. 14400 IN NAPTR 50 100 "s" "x-3gpp-sepp:x-n32c" "" _n32_az._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org.
sepp.5gc.mnc345.mcc012.3gppnetwork.org. 14400 IN NAPTR 50 100 "s" 2x-3gpp-sepp:x-n32c:DISASTER_ROAMING" ""
_n32_az._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org.

The SRV records for the services _n32_xy and _n32_az would then also resolve to
separate host names.

The “s” flag means the next stage is to look up an “SRV” record.

A NAPTR record is quite static and therefore the recommended TTL value is between 4 and
12 hours.

V21.0 Page 57 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Note: Multiple NAPTR record lines may be foreseen in the future. For example:
one NAPTR record for roaming and one NAPTR record for (SMS)
interworking.

4.19.2.2 Step 2
In this step, the iSEPP issues a DNS SRV query in order to obtain the list of candidate
rSEPPs that it can use in order to setup the N32 connection.

An example set of SEPP server SRV records based on the first NAPTR record from step 1
which could be returned in the DNS reply, is as follows:
# _service._proto.name. TTL class SRV priority weight port target.
_n32._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org. 600 IN SRV 10 60 443 sepp1.5gc.mnc345.mcc012.3gppnetwork.org.
_n32._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org. 600 IN SRV 10 20 443 sepp2.5gc.mnc345.mcc012.3gppnetwork.org.
_n32._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org. 600 IN SRV 10 20 443 sepp3.5gc.mnc345.mcc012.3gppnetwork.org.
_n32._tcp.sepp.5gc.mnc345.mcc012.3gppnetwork.org. 600 IN SRV 20 0 443 sepp4.5gc.mnc345.mcc012.3gppnetwork.org.

From the SRV record, the rSEPP server FQDNs gets extracted.

SRV records could be volatile but for operational resons the recommended TTL should not
fall below 5 minutes.

Note: SRV records represent a topology of rSEPPs. This implies that iSEPP must
be SRV-cognizant.

4.19.2.3 Step 3
For the server names with the lowest integer in the priority field returned in step 2, a
standard DNS query is performed in order to obtain the servers’ IP addresses.

This is a normal “A/AAAA” (address) record lookup.

Seppl.5gc.mnc345.mcc012.3gppnetwork.org AAAA 2001:db80::1321:abcd
sepp2.5gc.mnc345.mcc012.3gppnetwork.org AAAA 2001:db80::5e0d:00de
sepp3.5gc.mnc345.mcc012.3gppnetwork.org AAAA 2001:db80::3900:0164

4.19.3 Domain Names used

The domain names of SEPP server names, shall be in the “5gc.” Subdomain of the
MCC/MNC sub domain of “.3gppnetwork.org”. More details and exceptions can be found in
PRD NG.113 [60] and PRD FS.34 [61].

4.19.4 Use of DNS servers in peer SEPP IP address discovery

The procedure to resolve the DNS A or AAAA records described in step 3 (section 4.19.2.3),
is described below.

V21.0 Page 58 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

: DNS message flow for iSEPP to discover IP address of rSEPP

1. Initiating SEPP should query the Local Caching DNS to perform the DNS lookup.
Initiating SEPP will send a recursive DNS Query to the Local Caching DNS server.
2. The Local Caching DNS Server checks its local cache for the IP address of the
requested resource record. If it has this record, and the record has not exceeded its
time to live, processing skips to step 6. Otherwise, the Local Caching DNS Server
checks its local cache for the IP address of the Authoritative DNS Server. If it does not
already have this IP address, it then issues an iterative DNS Query to the IPX network’s
Root DNS Server otherwise, processing skips to step 4.
3. The Root DNS Server replies to the DNS Query received from the Local Caching DNS
with the details of the Authoritative DNS Server (for example, the FQDN and/or IP
address(es).
4. The Local Caching DNS Server sends an iterative DNS query to the Authoritative DNS
Server to resolve the DNS Query received in step 1.
5. The Authoritative DNS Server will resolve the DNS Query received in step 4 and will
answer to the Local Caching DNS Server.
6. The Local Caching DNS Server replies to the DNS Query received from the initiating
SEPP (in step 1) with the result obtained from the Authoritative DNS Server.
7. Depending on the received answer (step 6), some additional DNS queries could be
required to discover the SEPP IP address. When discovered, the N32 handshake
procedure could start (as described in section 5.2 of 3GPP TS 29.573).

V21.0 Page 59 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

The initiating SEPP shall initiate N32 connections to (multiple, if applicable) rSEPPs with the
lowest integer in the priority field and it should distribute N32 traffic according to the provided
weight. Hence the procedure described in this paragraph shall be executed for all rSEPPs
with the lowest integer in the priority field . More details on load sharing and routing can be
found in NG.113 [60]:

4.19.5 Handling Non-MNO SEPPs

If rSEPP is non-MNO (e.g. outsourced or operator group SEPP) the NAPTR response may
include a NAPTR record pointing to a service at the non-MNO entity, for example:
sepp.5gc.mnc345.mcc012.ipxa.ipxnetwork.org. 14400 IN NAPTR 50 100 “s” “x-3gpp-sepp:x-n32c” “” _n32._tcp. Sepp.5gc.mnc345.mcc012.ipxa.ipxnetwork.org.

Subsequent SRV, A and AAAA DNS queries will then point to the right hosts.

4.20 Stand-alone NPN (SNPN)

4.20.1 Introduction
The SNPN is defined in 3GPP TS 23.501[37] as a 5GS deployed for non-public use and
operated by an NPN operator not relying on network functions provided by a PLMN.

5 Processes and Procedures relating to DNS

5.1 Introduction
This section describes the processes and procedures relating to DNS that apply to Service
Providers and GRX/IPX Providers.

5.2 Existing domains/sub-domains on the GRX/IPX network and their

Allocation
The domain names for use by Service Providers on the GRX/IPX network are the following:

• .gprs
• .3gppnetwork.org
• .ipxnetwork.org
• .ipxsp.org
• .e164enum.net
Only the sub-domains listed in section 2.3.3 for each of the above domains should be used.

The domain name ".e164enum.net" is used only for Carrier ENUM on the GRX/IPX; see
GSMA PRD NG.105 [56] for more information.

The domain names to be used by the GRX/IPX Providers on the GRX/IPX are the same as
those above, when a GRX/IPX Provider is hosting services on behalf of a Service Provider.
For all other services and also for GRX/IPX network equipment (for example routers, MMS
Hubs, etc.). For 5G SA roaming and interworking “.ipxnetwork.org” shall be used. For any
other use cases “.ipxnetwork.org” should be used, see section 2.3.3. The ".grx" domain
name also is commonly used, but should be reserved for legacy equipment on the GRX
network. The sub-domains on “.grx” and “ipxnetwork.org” are agreed amongst other

V21.0 Page 60 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

GRX/IPX Providers and assigned on a first come – first served basis in order to guarantee
uniqueness.

5.3 Procedures relating to new domain names on the GRX/IPX network

New domain names may be added to the GRX/IPX network's DNS by any Service Provider
or GRX/IPX Provider, in order to enable further services to be used on the NNI provided by
the GRX/IPX network. This could be to allow such things as resolution of domain names
used for national interconnect agreements, and so on. However, wherever possible, the
existing sub-domains of the domain names specified in section 2.3.3 should be reused.

It is recommended that new domain names to be added to the GRX/IPX network's DNS are:

• a sub-domain of a Country Code Top Level Domain (ccTLD);

• registered/reserved on the Internet, in order to prevent any issues of ownership;
• not provisioned on the Internet (that is. not resolvable, at least no more than is
absolutely necessary for example to retain ownership as per the rules of some ccTLD
authorities);
• hosted in their own authoritative DNS server(s) on the GRX/IPX network, which is
linked from the GRX/IPX Root DNS that is by using NS record entries (this eases
administration of the new domain name and also prevents the GRX/IPX Root DNS
becoming unmanageable); and
• used by an entity in addition to either their
"mnc<MNC>.mcc<MCC>.3gppnetwork.org" domain name ,
"mnc<MNC>.mcc<MCC>.<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org", "
<UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org" or "spn<SPN>.ipxsp.org" domain
name, as specified in section 2.3.3 (amongst other things, this enables network node
naming as per section 2.4).

The hosting authoritative DNS server(s) need to be reachable and respond to queries from
all Service Providers and/or GRX/IPX Providers that need to resolve associated FQDNs.
Ideally, access should be allowed to all entities on the GRX/IPX network, but only those who
need should have their queries properly serviced; the rest should be returned a standard
DNS or ICMP error.

Care should be taken to not inadvertently force another entity who is denied
access/resolvability of the domain name into (automatically or otherwise) trying to resolve it,
including (but not necessarily limited to):

• by using only, the new domain name in general network node naming (network node
naming should still be done as per section 2.4, using the domain names recommended
therein); and
• by returning it in a NAPTR and/or SRV record (for example as used in IMS/SIP, ENUM,
EPC).
For domain names that need to be resolvable on the UNI, the Internet DNS should always
be used. By design, the GRX/IPX DNS provides resolution only for entities connected to the
NNI.

V21.0 Page 61 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

5.4 GSMA Root DNS service and its access

5.4.1 GSMA Root DNS Service

The GSMA Root DNS Service provides authoritative naming management and address
resolution mechanisms for the mobile industry that includes GRX Providers, IPX Providers
and Mobile Network Operators. This translates into two main functions:

• Assignment and administration of domain names according this IR.67 specification

• Peering connection and DNS zone transfer services

In the SOA record of the root DNS a refresh timer of 900 seconds and a retry timer of 900
seconds is configured for the zones GPRS and 3GPPNETWORK.ORG. The secondary DNS
servers will try to update the configuration once every 15 minutes.

he GSMA Root DNS Server is currently available at multiple locations to provide high
availability service. GSMA reserves the right to add, relocate or decommission locations in
response with technological advancement, operational requirement and demand from the
industry.

5.4.2 Access to GSMA Root DNS Service

For an applicant, who is limited to GRX Provider, IPX Provider which facilitates a connection
from a Mobile Network Operator, or Operator requires the access to the service provided by
the GSMA.

The application and accreditation process is required prior to its connection and is managed
by the Manage Services team at GSMA. Applicant can contact the team by emailing
[email protected] to request access. An on boarding questionnaire will be provided for the
applicant to provide information required for the application and accreditation process, and
the service the applicant intend to utilize.

Once the applicant provides the necessary information, an accreditation process is

conducted. If the verification is passed, the applicant will enter service agreement with
GSMA and other terms as with associated parties, as deem necessary. The applicant also
needs to settle any required payment. If any information is missing or incorrect, the applicant
will need to resubmit the on boarding questionnaire.

If an application is either controversial or unsuccessful, it is escalated to GSMA staff for their

consideration and their final decision. The applicant can appeal against a rejection by
contacting the NG Director.

Once the application process completes, an account is created in the system with
associated access credentials and security appliance to access the dedicated web portal.
The peering and zone transfer between the applicant and the GSMA system can also be
established and tested. As final step of the activation process the Participant’s name servers
are provisioned in the GSMA system.

Applicant can start submitting information to the GSMA DNS Service through the web portal.
User can then can create, modify, delete or transfer domain names on behalf of Mobile
Network Operators and its other customers according to the operational manual maintained
by GSMA and its technology partner.

V21.0 Page 62 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

For any administrative, technical and operation issue regarding the service, including the
document required for the accreditation process, please contact [email protected] .

5.5 Delegation of sub-domains of “pub.3gppnetwork.org”

GSMA can delegate a sub-domain of pub.3gppnetwork.org to DNS of an MNO. The routine
specified by GSMA operations, that the MNO needs follow to do this, consists of the
following steps:

1. Identify MCC and MNC values for the MNO.

2. Identify CNAME record for the domain to be transferred.

The CNAME record shall be in format of:
<ABC>.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org

where

acceptable values of <ABC> are defined in 2.3.4 (other values might be added as needed;
see also NOTE 2 below)

<MNC> and <MCC> have to be replaced by respective values of the home network in
decimal format, with a 2-digit MNC padded out to 3 digits by inserting a 0 at the beginning.

NOTE 1: For RCS configuration server CNAME record should be in format of

http://config.rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org

NOTE 2: An operator may wish to delegate the entire

mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org sub-domain.

3. Create the Zone File on the MNO’s own NameServer/DNS with the NS record
specified in step 2.

4. Complete the Request Form in Annex B.1 and - if required for your use of the sub-
domain - also the Letter of Authorization in Annex B.2, and send both to GSMA at
[email protected]

NOTE 3: the Letter of Authorization format (Annex B.2) may need to be adapted
dependent on your selected Certificate Body’s requirements. If in doubt,
please contact a Certificate Body of your choice, and obtain a necessary
template to be filled in by MNO and signed by GSMA as the registrant of
3gppnetwork.org domain.

5. GSMA will process the request, delegate the requested subdomain to MNO’s
DNS, and return a signed copy of the Letter of Authorization to MNO.

NOTE 4: the typical maximum lead time to process the Request Form and sign the
Letter is five (5) working days.

NOTE 5: the requesting MNO is responsible for submitting the Letter to their
Certificate Authority.

V21.0 Page 63 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Annex A Sample BIND DNS Configuration for GPRS

A.1 Introduction
All sample configurations of this annex are in valid syntactical format for the ISC BIND DNS
server software. However, the samples are not from actual DNS configuration and contain
only example information, including sample IP addresses which are not valid. They are
provided for illustration purposes only. It is therefore highly recommended NOT to use these
samples in live networks! The GSM Association takes no responsibility of the usage of these
configurations in any operators DNS servers and/or live networks.

A.2 The "named.conf" file

The "named.conf" file has configuration information for BIND software. Following is only the
necessary configuration to get DNS running. There are many more options that may also be
useful, but which are not shown here, simply for making the examples as simple as possible.

A.2.1 The "named.conf" file for a PLMN Primary Nameserver

options {
directory "/var/named";
}; // where the files reside
zone "." in {
type hint;
file "gprs.hint";
}; // gprs root servers
zone "0.0.127.in-addr.arpa" in {
type primary;
notify no;
file "primary/0.0.127.in-addr.arpa";
}; // only contains information about localhost.
/*
* PLMN domain information
*/
zone "mnc091.mcc244.gprs" in {
type primary;
file "primary/mnc091.mcc244.gprs";
};
zone "sonera.fi.gprs" in {
type primary;
file "primary/sonera.fi.gprs";
}; // human readable operator id
zone "168.192.in-addr.arpa" in {
type primary;
file "primary/168.192.in-addr.arpa";
};

V21.0 Page 64 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

A.2.2 The "named.conf" file for a PLMN Secondary Nameserver

options {
directory "/var/named";
}; // where the files reside
zone "." in {
type hint;
file "gprs.hint";
}; // gprs root servers
zone "0.0.127.in-addr.arpa" in {
type primary;
notify no;
file "primary/0.0.127.in-addr.arpa";
}; // only contains information about localhost.
/*
* PLMN domain information
*/
zone "mnc091.mcc244.gprs" in {
type primary;
file "primary/mnc091.mcc244.gprs";
};
zone "sonera.fi.gprs" in {
type primary;
file "primary/sonera.fi.gprs";
}; // human readable operator id
zone "168.192.in-addr.arpa" in {
type primary;
file "primary/168.192.in-addr.arpa";
};
};

A.3 Zone Configuration Files

Recommended values for SOA records are as specified in ripe-203.

A.3.1 The "gprs.hint" file

This file contains ".gprs" root nameservers needed to initialise cache of ".gprs" nameservers.
Note that the “.” character is indeed significant.

. 518400 IN NS dns0.root.gprs.
dns0.root.gprs. IN A 172.22.1.5
. 518400 IN NS dns1.root.gprs.
dns1.root.gprs. IN A 10.254.243.7
. 518400 IN NS dns2.root.gprs.
dns2.root.gprs. IN A 192.168.17.232

A.4 The "0.0.127.in-addr.arpa" file

This file contains only information about localhost i.e. 127.0.0.1

$TTL 172800
@ IN SOA localhost.. hostmaster.localhost. (
2000030701 ; serial (YYYYMMDDvv)
86400 ; refresh (24 hours)

V21.0 Page 65 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

7200 ; retry (2 hours)

3600000 ; expire (1000 hours)
172800 ) ; minimum time to live (2 days)
1 IN PTR localhost.

A.4.1 PLMN zone files

PLMN may configure both mnc.mcc.gprs and operator.cc.gprs type domains that will share
exactly the same host information. In addition, early versions of GTPv0 did not have leading
zeroes to make mnc code always 3 digits long. In order to minimise both configuration work
and possible errors, zone files may include a common host configuration.

A.4.1.1 The "mnc091.mcc244.gprs" file

$TTL 172800
@ IN SOA mnc091.mcc244.gprs. hostmaster.mnc091.mcc244.gprs. (
2000030701 ; serial (YYYYMMDDvv)
86000 ; refresh (24 hours)
7200 ; retry (2 hours)
3600000 ; expire (1000 hours)
172800 ) ; minimum time to live (2 days)
IN NS dns0
IN NS dns1
$INCLUDE primary/hosts

A.4.1.2 The "sonera.fi.gprs" file

$TTL 172800
@ IN SOA sonera.fi.gprs. hostmaster.sonera.fi.gprs. (
2000030701 ; serial (YYYYMMDDvv)
86400 ; refresh (24 hours)
7200 ; retry (2 hours)
3600000 ; expire (1000 hours)
172800 ) ; minimum time to live (2 days)
IN NS dns0
IN NS dns1
$INCLUDE primary/hosts

A.4.2 The "hosts" file

This file contains IP address records for all hosts in the PLMN. The origin changes
depending on which file includes the contents i.e. after the names not ending at dot, the
current domain name is appended automatically.

Load balancing may be performed configuring same access point with several IP addresses
that actually are on different GGSNs. In this case, addresses are used in round-robin
fashion. However, DNS information is cached and a new query is performed only when the
TTL (time-to-live) has expired. Therefore, TTL of 0 seconds is configured for load balanced
access points.

dns0 IN A 192.168.1.2
dns1 IN A 192.168.2.2
;
; router
helsinki-rtr-1-fe-0-0 IN A 192.168.1.254

V21.0 Page 66 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

helsinki- rtr-1-fe-0-1 IN A 192.168.2.254

helsinki- rtr-1-fe-0-2 IN A 192.168.3.254
helsinki- rtr-1-s-1-0 IN A 172.22.5.6
;
; access point
ibm.com IN A 192.168.1.5
;
; load balanced access point
compaq.com 0 IN A 192.168.1.5
0 IN A 192.168.2.5
;
; service access point
internet IN A 192.168.2.2
;
; GGSN
helsinki-ggsn-15 IN A 192.168.1.5
helsinki- ggsn-25 IN A 192.168.2.5
helsinki- ggsn-22 IN A 192.168.2.2
;
; SGSN
helsinki-sgsn-1 IN A 192.168.3.3
; SGSN with RAI
racF1.lac12EF IN A 192.168.3.3

A.4.3 The "168.192.in-addr.arpa" file

There may be several PTR records so that each name associated with and address may
have reverse mapping also. Note that IP address is reversed in in-addr.arpa domain i.e.
192.168.1.254 will be 254.1.168.192.in-addr.arpa.

$TTL 172800
@ IN SOA dns0.sonera.fi.gprs. hostmaster.sonera.fi.gprs. (
2000030701 ; serial (YYYYMMDDvv)
86400 ; refresh (24 hours)
7200 ; retry (2 hours)
3600000 ; expire (1000 hours)
172800 ) ; minimum time to live (2 days)
IN NS dns0.sonera.fi.gprs.
IN NS dns1.sonera.fi.gprs.
5.1 IN PTR ibm.com.sonera.fi.gprs.
PTR ibm.com.mnc091.mcc244.gprs.
PTR compaq.com.sonera.fi.gprs.
PTR compaq.com.mnc091.mcc244.gprs.
PTR helsinki-ggsn-15.sonera.fi.gprs.
PTR helsinki- ggsn-15.mnc091.mcc244.gprs.
254.1 IN PTR helsinki-rtr-1-fe-0-0.sonera.fi.gprs.
PTR helsinki- rtr-1-fe-0-0.mnc091.mcc244.gprs.
2.2 IN PTR internet.sonera.fi.gprs.
PTR internet.mnc091.mcc244.gprs.
PTR helsinki-ggsn-2.sonera.fi.gprs.
PTR helsinki- ggsn-2.mnc091.mcc244.gprs.
5.2 IN PTR compaq.com.sonera.fi.gprs.
PTR compaq.com.mnc091.mcc244.gprs.

V21.0 Page 67 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

PTR helsinki-ggsn-25.sonera.fi.gprs.
PTR helsinki-ggsn-25.mnc091.mcc244.gprs.
254.2 IN PTR helsinki-rtr-1-fe-0-1.sonera.fi.gprs.
PTR helsinki-rtr-1-fe-0-1.mnc091.mcc244.gprs.
3.3 IN PTR helsinki-sgsn-1-fe.sonera.fi.gprs.
PTR helsinki-sgsn-1-fe.mnc091.mcc244.gprs.
PTR racF1.lac12EF.sonera.fi.gprs.
PTR racF1.lac12EF.mnc091.mcc244.gprs.
254.3 IN PTR helsinki-rtr-1-fe-0-2.sonera.fi.gprs.
PTR helsinki-rtr-1-fe-0-2.mnc091.mcc244.gprs.

V21.0 Page 68 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Annex B Forms for transfer of sub-domain of

“pub.3gppnetwork.org”

B.1 Request form

Request Form for Transfer of sub-domain of pub.3gppnetwork.org

Organisaction:
Technical Title:
Contact at Name:
MNO Email:
Mobile Number:

MNO Name:
MNO
Information MCC Value:
MNC Value:

NS Record for delegation of domain for an MNO shall

follow the format:

mnc<MNC>.mccc<MCC>.pub.3gppnetwork.org
NS Record for
Mnc_____.mcc_____.pub.3gppnetwork.org
MNO
where MNC and MNC of the MNO reflect the
corresponding MNC and MCC allocated by the
relevant authority and is padded with 0 in front if it has
been allocated with 2 digits

Zone File for Is the Zone file for the identified NS created on MNO’s
☐Yes
NS DNS Server

Name / IP Address
DNS Server
Details (IP Please provide MNO’s DNS Server Details and where
Address and the Zone files for the NS record had been created
FQDN)

If required, please complete the “Letter of

Letter of Authorization” for certificate issuance to
Authorization [email protected]

Organisaction:
Title:
Name:
Requestee Email:
Mobile Number:
Date:
Signature:

V21.0 Page 69 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

B.2 Letter of Authorization Template

Please fill out all required fields in the template and replace <ABC>, <MNC> and <MCC> as
specified in 6.5.

This letter can be adapted as per MNO’s selected Certificate Body’s requirement. The letter
must be signed by GSMA.

V21.0 Page 70 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

<Certificate Organisation Name>

<Contact Name at Certificate Organisation>

<Certificate Organisation Address>

<Certificate Organisation Fax Number/Email address>

Date: <Please type date>

To whom it may concern,

Dear Sir/Madam,

Re: Domain Authorization Letter

I confirm that:

Organization enrolling for the Digital Certificate set out below is: <Please type your MNO’s
full company name here> (“Certificate Applicant”)

Domain to be included in the certificate is:

<ABC>.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (“Domain”)

Registrant of the Domain is: GSM Association (“Registrant”)

Digital Certificate is the certificate relating to the Domain.

I am employed by the Registrant and am duly authorized to sign this Domain Authorization
Letter and to deal with all matters related to the registration of the Domain.

Certificate Applicant desires to install the Digital Certificate on its web server(s) for the
domain and ultimately to enable secure communications with its users.

V21.0 Page 71 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Registrant acknowledges that it has granted the Certificate Applicant the right to use the
Domain as a common name in the Digital Certificate request referenced above and to
otherwise use the Domain in connection with its business.

Regards,

Full Name: Javier Sendin

Job Title: Technical Director

Organization: GSM Association

Signature:__________________________

V21.0 Page 72 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Annex C Document Management

C.1 Document History

Approval Editor /
Version Date Brief Description of Change
Authority Company
0.1.0 14 October First draft – skeleton. Nick Russell,
-
2004 Vodafone
0.2.0 10 May Second draft, with most sections Nick Russell,
-
2005 filled in, or at least with place holders. Vodafone
0.2.1 11 May Changed the underlying Word Nick Russell,
-
2005 template to the new one. Vodafone
0.3.0 15 Enhancements of ENUM section,
November including addition of Number Nick Russell,
-
2005 Portability in ENUM, plus minor Vodafone
corrections and update of template.
0.9.0 16 Final draft for publication; contains
Nick Russell,
December only minor corrections to formatting -
Vodafone
2005 since previous version.
16
Nick Russell,
1.0 December Approved for publication. DAG
Vodafone
2005
26 January Nick Russell,
1.1 Minor formatting corrections. IREG
2006 Vodafone
Moved in the DNS information from
IR.34, ENUM section updated with
the agreements made in the ENUM
adhoc, updated the list of domains to
provide a list with those defined in
4 April and/or before 3GPP specification set IREG Nick Russell,
1.2
2006 Rel-6. Packet Vodafone

This version of the present document

is the first version to be classified as
"Unrestricted".
Clarification of references to 3GPP
documents (to show which specific
release is being referenced), addition
of health warnings about the old
9 August IREG Nick Russell,
1.3 MMS URI prefix and ENUMservice
2006 Packet Vodafone
field values, addition of health
warning about SIP URI provisioning
and some general
tidying-up/consolidation of text.

V21.0 Page 73 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
2.0 30 April Addition of the "No Root" ENUM
Nick Russell,
2007 architecture, plus some other DAG
Vodafone
miscellaneous corrections.
2.1 18 October Minor restructuring to move ENUM
2007 material into own section, clarification
in GPRS section and MMS section
on using iterative rather than
recursive DNS queries, clarification in IREG Nick Russell,
MMS section of DNS usage when Packet Vodafone
utilising one or more MMS Hubs and
direct interconnects, and renaming of
"No Root" ENUM model to "Multiple
Root".
2.2 14 April Addition of information on OMA's
2008 SUPL feature, including domain
name used and a new section giving
a brief overview of the feature (CR
#10). Also, some minor corrections to IREG Nick Russell,
the ENUM section are provided (CR Packet Vodafone
#11). Finally, a global replacement of
"MNO" to "Service Provider" has
been done, in-line with IPX
terminology.

V21.0 Page 74 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
3.0 26 Includes new GSMA logo on
September coversheet, change of "Operators" to
2008 "Service Providers" in the spec title,
and implementation of the following
CRs:
CR #12 (major): Implementation of
the conclusion from the ENUM White
Paper (EWP), plus other minor
corrections/enhancements. This
includes corrections to domain
names in sub-sections of 5.7
CR #13 (minor): Addition of EPC and
ICS specific sub-domains for DAG and
Nick Russell,
.3gppnetwork.org. IREG
Vodafone
CR #14 (minor): Addition of new sub- Packet
section to ENUMservices section to
specify the content of the
ENUMservices field for services
other than just those based on
IMS/SIP and MMS.
CR #15 (minor): Addition of
information about domain names,
including clearer indication of the
current limitations of the GRX/IPX
domain names currently supported.
Some minor editorial, non-technical
impacting corrections are also made.
3.1 8 Corrections to footer, plus
December implementation of the following CRs:
2008 CR #16 (minor): Addition of the
definition of the "user=phone" SIP
URI parameter in URIs returned in IREG Nick Russell,
IMS related ENUM responses. Packet Vodafone
CR #17 (minor): Correction to 4.5.1
(IMS section) to state that support of
NAPTR RRs are required in order to
support SIP/IMS.
3.2 6 May 2009 Implementation of CR # 18 (minor):
editorial enhancements to sections 1-
4, and implementation of the recently
IREG Nick Russell,
approved sub-domains of
Packet Vodafone
3gppnetwork.org (as requested by
3GPP and approved at Packet #37
and on email).

V21.0 Page 75 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
3.3 21 July Implementation of the following CRs:
2009 CR #19 (minor): Add Internet
assigned domain names to be used
as a sub-domain under
"3gppnetwork.org", in order to save
all Service Providers connected to
the IPX network to have to obtain an
E.212 number range in order to be
addressable. Also, the procedures
section is updated to reflect this
change, and also better describe the
current state-of-the-art.
CR #20 (minor): Add IR.33 (GPRS
Roaming Guidelines) in the IREG Nick Russell,
references section, add a new Packet Vodafone
domain name to be used for naming
of non-service specific nodes, add a
new section on hostnames and
domains (based on content from
IR.33), provide extra detail on DNS
Server software (also based on
content from IR.33), add new section
on DNS Server naming, add new
section on Resource Record usage,
and add references to IR.33 and the
GTP spec (3GPP TS 29.060) in
section 4.2 (GPRS). Also, some
instances of "operator" are corrected
to "Service Provider".
4.0 10 Implementation of CR #21 (Major):
December To document the lessons learned
2009 after the ENUM trial, and to make the
whole specification of the GRX/IPX Nick Russell,
Carrier ENUM take a more top-down DAG #64
Vodafone
approach.

New template also applied.

4.1 3 March Implementation of CR #22 (Minor):
2010 addition of "bcast" sub-domain to
"mnc<MNC>.mcc<MCC>.pub.3gppn
IREG
etwork.org". Minor editorial
Packet Nick Russell,
corrections also made, including
(email Vodafone
clarification on a zero being inserted
approval)
on the left side of any 2 digit MNCs
used in domain names e.g. 15
becomes 015.

V21.0 Page 76 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
5.0 21 July Implementation of CR#23 (Major):
2010 Updates to domain names used on Nick Russell,
DAG #71
the GRX/IPX network and inter-SP Vodafone
links
5.1 13 August Implementation of the following CRs:
2010 IREG
CR #24 (Minor): Support of IP
Packet Nick Russell,
versions in DNS
(email Vodafone
CR #25 (Minor): ENUMservice field approval)
value for SIP-I/PVI
6.0 1 Implementation of CR#26 (Major):
December Addition of new '.ipxuni' domain
2011 name and sub-domain name used for Gert Öster,
DAG#86
"well known" XCAP Root URI to Ericsson
"mnc<MNC>.mcc<MCC>.ipxuni.3gpp
network.org"
7.0 Implementation of the following CRs
- CR #28 (Major): Addition of new
subdomain for RCS/RCS-e as
“rcs.mnc>mnc>.mcc<mcc>.pub.3gpp
network.org”
CR #29 (Major): Removal of sub
domain name for the “XCAP root IREG#62 Gert Öster,
URI” from the “ipxuni” domain name Ericsson
DAG#92
and adding a new sub domain as
xcap.ims.mnc<mnc>.mcc<mcc>.pub.
3gppnetwork.org, and adding a new
subdomain for bootstrapping when
ISIM is used as
bsf.ims.mnc<mnc>.mcc<mcc>.
pub.3gppnetwork.org,

V21.0 Page 77 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
8.0 23/11/2012 Implemetation of the Following CRs
CR 29 (Major) To briefly describe
how GRX/IPX providers can
subscribe to the RootDNS and
access its services
CR 30(Major) Adding the possibility
to provide Non-authoritative final
ENUM responses for ported-out
users based on Legacy Number
Portability Information
CR 31(Major) Adding examples of
Number portability solutions allowing
the IPX/GRX ENUM to work for
countries without a national Tier-1
ENUM DNS server, as requested by
IWG IMQ and RCS-e.
CR 32(Major) Removal of text not IREG#63 Gert Öster,
considering that Local Breakout for it DAG#99 Ericsson
specified method for IMS roaming in
relation to VoLTE
CR 33(Major) Adding a further
example of ENUM NAPTR records
with regular expressions where part
of the result shall be substituted by
the “original” E.164 number.
CR 34(Major) To show that a Service
provider does not need to provide all
data for domain names the Service
provider is authoritative for one DNS
but that they may choose to imply
multiple levels of Authoritative DNSs
where a First level may refer to the
Second level Authoritative DNS
severs.

V21.0 Page 78 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
9.0 21/10/2013 Implemtation of the following CRs
CR1001 (Major) To add the
“ipxnetwork.org” TLD for IPX
providers that need a subdomain to
identify their equipment and realms.
CR1002 (Major) To add the
subdomain used for interworking
untrusted non-3GPP access
networks to the EPC using the
ePDG.
CR1003 (Major) to clarify that text on
Gert Öster,
provisioning in clause 5.4.3 only IREG#65
Ericsson
relates to ENUM and not HSS.
CR1004 (Major) To describe the
routine for delegation of
"pub.3gppnetwork.org" sub-domains
CR1005 (Major) To provide
information on DNS resolution when
IR.21 information is used.
CR 1006 (Major) To correct the e-
mail address for Root DNS questions
to reflect the new “gsma.com” e-mail
address
10.0 24/04/2014 Implemetation of the following CRs
CR 1007 (Major) To add the
subdomain for the “OAM System
Realm” that can be used for IP
autoconfiguration services e.g. in
Gert Öster,
case Self-Organizing Networks IREG#66
Ericsson
(SON) as defined by 3GPP
CR 1008 (Major) To provide
guidance on naming of IMS Nodes,
and to inform where guidance on
EPC node name can be found
11.0 16/04/2015 Implemetation of the following CRs
CR 1009 (Major) To add pointers to
IR.88 for DNS configuration
requirements in various 2G/3G and
LTE coexistence scenarios.
Gert Öster,
CR 1010 (Major) To add the NG#01
Ericsson
subdomain for “Bootstrapping of
MBMS service Announcements”
CR 1011 (Major) To correct e-mail
address to Delegation of
“pub.3gppnetwork.org”

V21.0 Page 79 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Approval Editor /
Version Date Brief Description of Change
Authority Company
12.0 01/02/2016 IR.67 CR1012 Resolver architecture Frederic
for service aware IPX Paquette Tata
NG
Communicatio
ns
13.0 06/09/2016 CR1013 Sub-domain for ePDG
Frederic
selection with DNS-based Discovery
Paquette Tata
of Regulatory requirements NG
Communicatio
CR1014 SOA Refresh Timer
ns
alignment on root DNS
14.0 21/11/2016 IR.67 CR1015IR.67 CR1015 DNS Frederic
Guidelines for Service Providers and Paquette
GRX and IPX Providers NG
Tatacommuni
cations
15.0 27/07/2017 IR.67 CR1017 DNS Guidelines for Frederic
service providers – removal of ENUM Paquette
content now in NG.105 NG
Tatacommuni
cations
16.0 09/06/2020 CR1018 Introducing New Sub- Sajid
domain for IWK with SNPN Soormally
(Nokia)
NG
Wayne Cutler
CR1019 Clean-up of References
(GSMA)

17.0 21/10/2020 CR1020 NNI Interworking - Wayne Cutler

NG
singledual registration IMS cores (GSMA)
18.0 06/05/2021 CR1021 DNS Guidelines for Service
Chris Li
Providers and GRX and IPX NG
(GSMA)
Providers
19.0 23/11/2021 CR1022 SEPP FQDN resolution André Nunes
NG
before N32 Handshake Procedure (Vodafone)
20.0 10/05/2022 CR1023 Naming scheme for non- Pieter
MNO entities on the IPX Network for Veenstra
NG
5G SA Roaming (NetNumber,
R1024 SEPP Discovery Inc.)
21.0 25/11/2022 CR1025 Adding “WLAN” to Wayne Cutler
NG
pub.3gppnetwork.org domain (GSMA)
22.0 31/05/2023 NRG 016_009 IR.67 CRxxxx to v21.0 Alf
N32 purpose_r7 Zugenmaier
NG
(NTT
DOCOMO)
23.0 02/02/2024 IR.67 CR1002 Change from CNAME Chris Li,
NG
to NS only GSMA

V21.0 Page 80 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

Other Information

Type Description
Document Owner NG Packet
Editor / Company Eddy Goffin (Orange)

It is our intention to provide a quality product for your use. If you find any errors or
omissions, please contact us with your comments. You may notify us at [email protected]

Your comments or suggestions & questions are always welcome.

V21.0 Page 81 of 82
GSM Association Non-confidential
Official Document IR.67 - DNS Guidelines for Service Providers and GRX and IPX Providers

V21.0 Page 82 of 82