1、 ETSI TR 184 012 V1.1.1 (2015-05) Network Technologies (NTECH); Description of the DNS protocol usage in IP based operators networks TECHNICAL REPORT ETSI ETSI TR 184 012 V1.1.1 (2015-05) 2 Reference DTR/NTECH-00003-NNAR-DNS Keywords addressing, DNS, enum ETSI 650 Route des Lucioles F-06921 Sophia A
2、ntipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The presen
3、t document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such version
4、s and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the curr
5、ent status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be
6、reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restr
7、iction extend to reproduction in all media. European Telecommunications Standards Institute 2015. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of
8、its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TR 184 012 V1.1.1 (2015-05) 3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g31 Scope 5g32 References 5g32.1 Normative re
9、ferences . 5g32.2 Informative references 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 DNS use cases in IP based operators networks 7g34.1 Service discovery . 7g34.1.1 Service access point discovery 7g34.1.2 Locating service capabilities . 7g34.2 IP Address reso
10、lution . 7g34.3 Load sharing and load balancing 8g34.4 Number portability real time operational database . 9g34.5 Indicating security association . 9g34.6 Identification/locating television channels . 10g34.7 Identification of IP Connectivity Service Provider 10g34.7.1 DNS reverse mapping . 10g34.7.
11、2 Identification of Access Network Provider . 10g35 DNS functionalities within IP based operators networks . 11g35.1 DNS topology . 11g35.2 DNS resolver 12g35.3 DNS stub resolver 12g35.4 Authoritative DNS server . 12g35.5 DNS protocol format 12g35.6 The d interface . 12g35.7 The d interface 13g36 Op
12、tions to make the DNS usage more scalable and reliable 13g36.1 Optimization options 13g36.2 DNS stub resolver 13g36.3 DNS resolver 14g36.4 Authoritative DNS server . 15g36.5 DNS transport . 15g3History 16g3ETSI ETSI TR 184 012 V1.1.1 (2015-05) 4 Intellectual Property Rights IPRs essential or potenti
13、ally essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, I
14、PRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/ipr.etsi.org). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be giv
15、en as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Network Technologies (NTECH). Modal
16、 verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NO
17、T allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TR 184 012 V1.1.1 (2015-05) 5 1 Scope The present document describes different use cases for the usage of the DNS protocol (e.g. Service Location, NP/ENUM, address resolution) in IP based operators networks. The DNS base p
18、rotocol itself is defined in RFC 1035 i.16. The present document describes the behaviour and details for DNS protocol usage in IP based operators networks, transport options for DNS messages, DNS protocol behaviour and configuration as well as options to make the usage of the DNS protocol more relia
19、ble (e.g. timer characteristics etc.). The use cases described here and options to make the usage of the DNS protocol more reliable are principal ones for network operators and not intended to be exhaustive. 2 References 2.1 Normative references References are either specific (identified by date of
20、publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not found to be publicly availab
21、le in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present
22、 document. Not applicable. 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference
23、document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the
24、user with regard to a particular subject area. i.1 ICANN: “Internet Consensus Policy 2: Criteria for Establishment of New Regional Internet Registries“. i.2 ETSI TS 182 028: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN integrated IPTV subsys
25、tem Architecture“. i.3 IETF RFC 5966: “DNS Transport over TCP - Implementation Requirements“. i.4 ETSI TS 124 229: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on Session Initiation Protocol
26、(SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229)“. i.5 IETF RFC 3263: “Session Initiation Protocol (SIP): Locating SIP Servers“. i.6 ETSI TR 184 003: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Portability of telephone num
27、bers between operators for Next Generation Networks (NGNs)“. ETSI ETSI TR 184 012 V1.1.1 (2015-05) 6 i.7 IETF RFC 3761: “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)“. i.8 ETSI TS 184 009: “Telecommunications and Internet converged Ser
28、vices and Protocols for Advanced Networking (TISPAN); Rules covering the use of TV URIs for the Identification of Television Channels“. i.9 IETF RFC 2838: “Uniform Resource Identifiers for Television Broadcasts“. i.10 IETF RFC 2396: “Uniform Resource Identifiers (URI): Generic Syntax“. i.11 IETF RFC
29、 2782: “A DNS RR for specifying the location of services (DNS SRV)“. i.12 IETF RFC 3403: “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database“. i.13 IETF RFC 1034: “Domain names - concepts and facilities“. i.14 IETF RFC 2317: “Classless IN-ADDR.ARPA delegatio
30、n“. i.15 IETF RFC 3596: “DNS Extensions to Support IP Version 6“. i.16 IETF RFC 1035: “Domain names - implementation and specification“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: access network provider: servi
31、ce provider that provides physical and IP connectivity to a user equipment (UE) via a fixed or mobile access 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AfriNIC African Network Information Centre APNIC Asia Pacific Network Information Centre ARIN Am
32、erican Registry for Internet Numbers IANA Internet Assigned Numbers Authority DDDS Dynamic Delegation Discovery System DNS Domain Name System ENUM tElephone NUMber mapping FQDN Fully Qualified Domain Name ICANN Internet Corporation for Assigned Names and Numbers IETF Internet Engineering Task Force
33、IP Internet Protocol IPTV Internet Protocol TeleVision LACNIC Latin America or querying a distinct RR type and obtain the service capabilities from the answer. In the first case the DNS client forms a FQDN which labels associate distinct service capabilities (e.g. SRV RFC 2782 i.11). On a try and fa
34、il basis the DNS is queried with this FQDN in the query section. When there is a RR delivered this service (DNS response code 0 - no error) is available in the DNS domain. When there is a negative answer (DNS response code 3 - NX Domain) this service does not exist in that domain. The application wh
35、ich triggers the DNS client can try to form a new FQDN which labels associate a similar service and sends a new DNS query with another FQDN in the query section. When there is no positive answer the application can try another FQDN or can stop using the DNS for service location for this current proc
36、ess. In the second case the queried DNS Resource Records contain in their data section information regarding the available services for the domain. Therefore the DNS delivers typically several DNS RRs. So the DNS client can analyse this answer and select the best matching RR for the further processi
37、ng of the communication service. A typical example for such a kind of service location is ENUM. The services field within the NAPTR RR i.12 contains a character-string that specifies the service parameters applicable to the queried FQDN. 4.2 IP Address resolution The impetus for the development of t
38、he domain system in the 1980s was the growth in the Internet. In the early days of the Internet the mapping of hostnames to IP addresses was provided in a single file (HOSTS.TXT) which was distributed via File Transfer Protocol by all hosts. This has now been replaced by the DNS. Whereas today the D
39、NS provides possibilities for managing more than 100 different Resource Record types (http:/www.iana.org/assignments/dns-parameters), the mapping of hostnames to IPv4 (DNS Resource Record Type 1) and IPv6 addresses (DNS Resource Record Type 28) is still a key functionality of the DNS. It should be m
40、entioned that the queried resource record type is independent of DNS transport protocol. A DNS client can: query an IPv4 address of a given FQDN by using IPv4 or IPv6 transport; and ETSI ETSI TR 184 012 V1.1.1 (2015-05) 8 query an IPv6 address of a given FQDN by using IPv6 or IPv4 transport. Resolvi
41、ng an IPv4/IPv6 address for a given/configured FQDN instead of configuring static IP addresses reduces the necessity of configuration on DNS client side. 4.3 Load sharing and load balancing The basic idea of DNS load sharing is to associate several resource records with a single domain name. When th
42、e DNS responds to a request, it returns the whole list of resource records to the client. The resource records are then used in a round-robin or load-sharing fashion, thus providing some form of load balancing. Four types of DNS load sharing techniques are possible: Load Sharing with round-robin DNS
43、 DNS views a.k.a. Split DNS Parsing and analyzing fields of the DNS query and calculating an answer DNS resource records with fields for priority indication Load sharing with round-robin DNS In its simplest implementation round-robin DNS works by responding to DNS requests not only with a single IP
44、address, but a list of IP addresses of several servers that host identical services. The order in which IP addresses from the list are returned is the basis for the term round-robin. With each DNS response, the IP address sequence in the list is permuted. Usually, basic IP clients attempt connection
45、s with the first address returned from a DNS query so that on different connection attempts clients would receive service from different servers, thus distributing the overall load among servers. DNS views Setting up different views, or visibility, of the DNS space to internal and external resolvers
46、 is usually referred to as a Split DNS setup. This mechanism can also be used in order to distribute load on servers. Due to the configuration of different views for different IP source address ranges on an authoritative DNS server, the authoritative DNS server will provide to each DNS client depend
47、ent on the IP address of the DNS client a preconfigured response. The figure 1 provides an overview on how an authoritative DNS server can process and answer a DNS query based on the source address of the query packet of the DNS client. ETSI ETSI TR 184 012 V1.1.1 (2015-05) 9 match-clients (IP addre
48、ss range 1)view 1yes match-clients (IP address range 2)noview 2yes match-clients (IP address range any)noview 3yes authoritative DNS server or external resolverDNSClientFigure 1: Processing of a DNS answer based on the IP address of the DNS client Parsing and analyzing fields of the DNS query and ca
49、lculating an answer Similar to the split DNS approach where different DNS clients will be served with different answers based on a more or less static configuration it is possible to parse all or selected fields of a DNS query and calculate a DNS answer on demand based on distinct characteristics of the content of these fields. A typical use case here is the realization of DNS reverse mapping. DNS resource records with fields for priority indication Some resource record types contain in their data format fields which ma
