Internet Engineering Task Force (IETF)                        S. Bradner
Request for Comments: 6116                            Harvard University
Obsoletes: 3761                                                L. Conroy
Category: Standards Track                            Roke Manor Research
ISSN: 2070-1721                                              K. Fujiwara
                                                              March 2011
Internet Engineering Task Force (IETF)                        S. Bradner
Request for Comments: 6116                            Harvard University
Obsoletes: 3761                                                L. Conroy
Category: Standards Track                            Roke Manor Research
ISSN: 2070-1721                                              K. Fujiwara
                                                              March 2011

The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)




This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761.

本文档讨论了使用域名系统(DNS)存储与E.164号码相关的数据,并将这些号码解析为可用于(例如)电话呼叫设置的URI。本文档还描述了如何使用DNS识别与E.164号码相关的服务。本文件淘汰了RFC 3761。

Status of This Memo


This is an Internet Standards Track document.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2011 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括简化的BSD许可证文本,如本规范第4.e节所述

the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents


   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Use of These Mechanisms for Private Dialing Plans ...............4
   3. The ENUM Application Specifications .............................4
      3.1. Application Unique String ..................................4
      3.2. First Well Known Rule ......................................5
      3.3. Expected Output ............................................5
      3.4. Valid Databases ............................................5
           3.4.1. Optional Name Server Additional Section Processing ..6
           3.4.2. Flags ...............................................6
           3.4.3. Service Parameters ..................................7
         ENUM Services ..............................7
         Compound NAPTRs and Implicit
                           ORDER/PREFERENCE Values ....................8
      3.5. The ENUM Algorithm Always Returns a Single Rule ............8
      3.6. Case Sensitivity in ENUM ...................................8
      3.7. Collision Avoidance ........................................9
   4. ENUM Service Example ...........................................10
   5. Clarification of DDDS Use in ENUM ..............................10
      5.1. Collected Implications for ENUM Provisioning ..............11
      5.2. Collected Implications for ENUM Clients ...................13
           5.2.1. Non-Terminal NAPTR Processing ......................15
   6. IANA Considerations ............................................16
   7. Security Considerations ........................................17
      7.1. DNS Security ..............................................17
      7.2. Caching Security ..........................................18
      7.3. Call Routing Security .....................................19
      7.4. URI Resolution Security ...................................19
   8. Acknowledgements ...............................................19
   9. Changes from RFC 3761 ..........................................19
   10. References ....................................................20
      10.1. Normative References .....................................20
      10.2. Informative References ...................................21
   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Use of These Mechanisms for Private Dialing Plans ...............4
   3. The ENUM Application Specifications .............................4
      3.1. Application Unique String ..................................4
      3.2. First Well Known Rule ......................................5
      3.3. Expected Output ............................................5
      3.4. Valid Databases ............................................5
           3.4.1. Optional Name Server Additional Section Processing ..6
           3.4.2. Flags ...............................................6
           3.4.3. Service Parameters ..................................7
         ENUM Services ..............................7
         Compound NAPTRs and Implicit
                           ORDER/PREFERENCE Values ....................8
      3.5. The ENUM Algorithm Always Returns a Single Rule ............8
      3.6. Case Sensitivity in ENUM ...................................8
      3.7. Collision Avoidance ........................................9
   4. ENUM Service Example ...........................................10
   5. Clarification of DDDS Use in ENUM ..............................10
      5.1. Collected Implications for ENUM Provisioning ..............11
      5.2. Collected Implications for ENUM Clients ...................13
           5.2.1. Non-Terminal NAPTR Processing ......................15
   6. IANA Considerations ............................................16
   7. Security Considerations ........................................17
      7.1. DNS Security ..............................................17
      7.2. Caching Security ..........................................18
      7.3. Call Routing Security .....................................19
      7.4. URI Resolution Security ...................................19
   8. Acknowledgements ...............................................19
   9. Changes from RFC 3761 ..........................................19
   10. References ....................................................20
      10.1. Normative References .....................................20
      10.2. Informative References ...................................21
1. Introduction
1. 介绍

This document discusses the use of the Domain Name System (DNS) [RFC1034] [RFC1035] for storage of data associated with E.164 [E.164] numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document includes a Dynamic Delegation Discovery System (DDDS) Application specification, as detailed in the document series described in [RFC3401]. This document obsoletes [RFC3761].


Using the process defined in this document, International Public Telecommunication Numbers in the international format defined in International Telecommunications Union (ITU) Recommendation E.164 [E.164] (called here "E.164 numbers") can be transformed into DNS names. Using existing DNS services (such as delegation through NS records and queries for NAPTR resource records), one can look up the services associated with that E.164 number. This takes advantage of standard DNS architectural features of decentralized control and management of the different levels in the lookup process.


The domain "" has been assigned to provide an infrastructure in the DNS for storage of data associated with E.164 numbers. To facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers who want these numbers to be listed in the DNS should contact the appropriate zone administrator as listed in the policy attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations.


Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world.


1.1. Terminology
1.1. 术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。

DNS resource record types mentioned in this document are defined, respectively, in [RFC1035] (NS, SOA, A, MX), [RFC3403] (NAPTR), and [RFC2782] (SRV).


All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in [RFC3402].


2. Use of These Mechanisms for Private Dialing Plans
2. 将这些机制用于私人拨号计划

Similar mechanisms might be used for other kinds of digit strings (such as numbers in private dialing plans). If these mechanisms are used for dialing plans (or for other unrelated digit strings), the domain apex used for such translation MUST NOT be, to avoid conflict with this specification.


Also, the Application Unique String (see Section 3.1) used with dialing plans SHOULD be the full number as specified, without the leading '+' character. The '+' character is used to further distinguish E.164 numbers in international format from dialed digit strings or other digit sequences.


For example, to address the E.164 number +44-3069-990038 a user might dial "03069990038" or "00443069990038" or "011443069990038". These dialed digit strings differ from one another, but none of them start with the '+' character.


Finally, if these techniques are used for dialing plans or other digit strings, implementers and operators of systems using these techniques for such purpose MUST NOT describe these schemes as "ENUM". The initial "E" in ENUM stands for E.164, and the term "ENUM" is used exclusively to describe application of these techniques to E.164 numbers according to this specification.


3. The ENUM Application Specifications
3. 枚举应用程序规范

This template defines the ENUM DDDS Application according to the rules and requirements found in [RFC3402]. The DDDS database used by this Application is found in [RFC3403], which is the document that defines the NAPTR DNS resource record type.

此模板根据[RFC3402]中的规则和要求定义ENUM DDDS应用程序。此应用程序使用的DDDS数据库位于[RFC3403]中,该文档定义了NAPTR DNS资源记录类型。

ENUM is designed as a way to translate from E.164 numbers to URIs using NAPTR records stored in DNS. The First Well Known Rule for any ENUM query creates a key (a fully qualified domain name, or FQDN, within the domain apex) from an E.164 number. This FQDN is queried for NAPTR records and returned records are processed and interpreted according to this specification.


3.1. Application Unique String
3.1. 应用程序唯一字符串

The Application Unique String (AUS) is a fully qualified E.164 number minus any non-digit characters except for the '+' character that appears at the beginning of the number. The '+' is kept to provide a well-understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace.


For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non-digits except for '+' are removed, yielding "+441164960348".


3.2. First Well Known Rule
3.2. 第一条众所周知的规则

The First Well Known Rule converts an AUS into an initial key. That key is used as an index into the Application's Rules Database. For ENUM, the Rules Database is the DNS, so the key is a fully qualified domain name (FQDN).


In order to convert the AUS to a unique key in this database, the string is converted into a domain name according to this algorithm:


1. Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148" (which would then have been converted into an AUS of "+442079460148"), this step would simply remove the leading '+', producing "442079460148". 2. Reverse the order of the digits. Example: "841064970244" 3. Put dots ('.') between each digit. Example: "" 4. Append the string "" to the end and interpret as a domain name. Example:

1. 删除除数字以外的所有字符。例如,给定E.164编号“+44-20-7946-0148”(该编号随后将转换为“+442079460148”的AUS),此步骤将简单地删除前导“+”,生成“442079460148”。2.颠倒数字的顺序。示例:“841064970244”3。在每个数字之间加上点('.')。示例:“”4。将字符串“”追加到末尾并解释为域名。示例。

The E.164 namespace and this Application's database are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself, so no further processing is required to generate the initial key.


This domain name is used to request NAPTR records. Each of these records may contain the end result or, if its flags field is empty, produces a new key in the form of a domain name that is used to request further NAPTR records from the DNS.


3.3. Expected Output
3.3. 预期产量

The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the <absolute-URI> production in the Collected ABNF found in [RFC3986].

根据[RFC3986]中收集的ABNF中的<absolute URI>结果,最后一个DDDS循环的输出是绝对形式的统一资源标识符。

3.4. Valid Databases
3.4. 有效数据库

At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite Rules. The keys for this database are encoded as domain names.

目前,仅为此应用程序指定了一个DDDS数据库。“动态委派发现系统(DDDS)第三部分:DNS数据库”[RFC3403]指定使用NAPTR DNS资源记录包含重写规则的DDDS数据库。此数据库的密钥编码为域名。

The character set used for the substitution expression is UTF-8 [RFC3629]. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a key are those that are currently defined for DNS domain names.


3.4.1. Optional Name Server Additional Section Processing
3.4.1. 可选名称服务器附加部分处理

Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information.


It is also easy to contemplate an ENUM enhanced nameserver that understands the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret flag values and use that information to include appropriate resource records in the additional information section of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See Section 4.2 of [RFC3403] ("Additional Information Processing") for more information on NAPTR records and the additional information section of a DNS response packet.


3.4.2. Flags
3.4.2. 旗帜

This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [RFC3986]. See Section 4.3 of [RFC3404].


If a client encounters a resource record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields.


A novel flag might change the interpretation of the Regexp and/or Replacement fields such that it is impossible to determine if a resource record matched a given target.


If this flag is not present, then this Rule is non-terminal. If a Rule is non-terminal, then the result produced by this rewrite Rule MUST be an FQDN. Clients MUST use this result as the new Key in the


DDDS loop (i.e., the client will query for NAPTR resource records at this FQDN).


3.4.3. Service Parameters
3.4.3. 服务参数

Service Parameters for this Application take the following Augmented Backus-Naur Form (ABNF, specified in [RFC5234]) and are found in the Services field of the NAPTR record that holds a terminal Rule. Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content.

此应用程序的服务参数采用以下扩展的Backus Naur形式(ABNF,在[RFC5234]中指定),可在保存终端规则的NAPTR记录的服务字段中找到。如果NAPTR持有非终端规则,则“服务”字段应为空,客户端应忽略其内容。

         service-field = "E2U" 1*(servicespec)
         servicespec   = "+" enumservice
         enumservice   = type 0*(subtypespec)
         subtypespec   = ":" subtype
         type          = 1*32(ALPHA / DIGIT / "-")
         subtype       = 1*32(ALPHA / DIGIT / "-")
         service-field = "E2U" 1*(servicespec)
         servicespec   = "+" enumservice
         enumservice   = type 0*(subtypespec)
         subtypespec   = ":" subtype
         type          = 1*32(ALPHA / DIGIT / "-")
         subtype       = 1*32(ALPHA / DIGIT / "-")

In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) is followed by one or more Enumservices that indicate the class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character.

换句话说,非可选的“E2U”(用于表示仅枚举重写规则以减轻记录冲突)后面是一个或多个枚举服务,指示给定端点提供的功能类别。每个Enumservice都由一个初始“+”字符表示。 ENUM Services 枚举服务

Enumservices may be specified and registered via the process defined in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]. This registration process is not open to any Enumservice that has '-' as the second character in its type string.


In particular, this registration process is not open to Enumservice types starting with the facet "X-". This "X-" facet is reserved for experimental or trial use, and any such Enumservices cannot be registered using the normal process.


Finally, any Enumservice type that starts with the facet "P-" is intended for use exclusively on private networks. As such, NAPTRs containing Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes and can engage in the Enumservice, it may be incapable of resolving the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered.


Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets (RRSets) from entities outside the private network context in which these Enumservices are intended for use. Unless an ENUM client is sure


that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.

如果它连接到为其配置和使用这些NAPTR的专用网络,则它必须丢弃Enumservice类型以“P-”方面开头的任何NAPTR。 Compound NAPTRs and Implicit ORDER/PREFERENCE Values 复合NAPTRs和隐式顺序/首选项值

It is possible to have more than one Enumservice associated with a single NAPTR. These Enumservices share the same Regexp field and so generate the same URI. Such a "compound" NAPTR could well be used to indicate a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices. The Services field in that case would be "E2U+voice:tel+sms:tel".


A compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values but should be treated as if each had a logically different priority. A left-to-right priority is assumed.


3.5. The ENUM Algorithm Always Returns a Single Rule
3.5. 枚举算法始终返回单个规则

The ENUM algorithm always returns a single Rule. Individual applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm.


3.6. Case Sensitivity in ENUM
3.6. 枚举中的区分大小写

Case sensitivity was not mentioned at all in [RFC3761] (or [RFC2916]), but has been seen as an issue during interoperability test events since then. There are a lot of case-sensitive clients in current deployment.


The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field (see Section 3.2 of [RFC3402] for Regexp field definitions). In that sub-field, case must be preserved when generating the record output. Elsewhere, case sensitivity is not used.


Where ENUM clients can be exposed to NAPTR records that may hold field content of different capitalization, clients MUST use case-insensitive processing. ENUM clients that operate using the Internet to send their queries, typically called "Public ENUM" scenarios, fall into this category.


Some ENUM clients operate within closed networks; for example, within isolated data networks operated by Communication Service Providers. These are typically called "Infrastructure ENUM" scenarios. All


zones provisioned within such closed networks usually have a known capitalization for ENUM record string content, as provisioning systems for such networks are often carefully controlled. In such an environment, clients are never exposed to records with capitalization that is "unexpected" and so can be (and have been) designed with case sensitive processing. Only if a client is known to operate in an environment in which capitalization of all ENUM records it will encounter is known and controlled MAY that client use case sensitive processing.


3.7. Collision Avoidance
3.7. 避碰

An ENUM-compliant application MUST only pass numbers to the ENUM client query process that it believes are E.164 numbers (e.g., it MUST NOT pass dialed digit strings to the ENUM query process).


Since number plans may change over time, it can be impossible for a client to know if the number it intends to query is assigned and active within the current number plan. Thus it is important that such clients can distinguish data associated with the E.164 number plan from that associated with other digit strings (i.e., numbers NOT in accordance with the E.164 number plan).


It is the responsibility of operators that are provisioning data into domains to ensure that data associated with a query on an E.164 number cannot be mistaken for data associated with other uses of NAPTRs.


Three techniques are used to achieve this:


o the domain apex used for purposes other than data associated with the E.164 number plan MUST NOT be

o 用于与E.164编号计划相关的数据以外的目的的域顶点不得为。

o for use other than with E.164 numbers, the Application Unique String MUST NOT begin with the '+' character, whilst for ENUM use, the AUS MUST begin with this character.

o 对于除E.164数字以外的其他用途,应用程序唯一字符串不得以“+”字符开头,而对于枚举使用,AUS必须以该字符开头。

o NAPTRs that are intended for other DDDS applications MUST NOT include the E2U token in their service field, whilst NAPTRs intended for ENUM use MUST include this token.

o 用于其他DDDS应用程序的NAPTR不得在其服务字段中包含E2U令牌,而用于枚举的NAPTR必须包含此令牌。

4. ENUM Service Example
4. 枚举服务示例

$ORIGIN NAPTR 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\!" . NAPTR 100 51 "u" "E2U+h323" "!^\\+441632960083$!!" . NAPTR 100 52 "u" "E2U+email:mailto" "!^.*$!!" .

$ORIGIN。NAPTR 100 50“u”E2U+sip!^(\\+44163296083)$!sip:\\!" . NAPTR 100 51“u”E2U+h323“!^\\+441632960083$!!" . NAPTR 100 52“u”E2U+电子邮件:mailto”“!^.*$!!" .

This describes that the domain is preferably contacted by SIP, secondly via H.323 for voice, and thirdly by SMTP for messaging. Note that the Enumservice tokens "sip", "h323", and "email" are Enumservice Types registered with IANA, and they have no implicit connection with the protocols or URI schemes with the same names.


In all cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols (specified by the URI schemes sip, h323, and mailto) to know what node to contact.


In each of the first two records, the ERE sub-field matches only queries that have been made for the telephone number +441632960083. In the last record, the ERE matches any Application Unique String value. The first record also demonstrates how the matched pattern can be used in the generated URI.


Note that where NAPTR resource records are shown in DNS master file syntax (as in this example above), each backslash must itself be escaped using a second backslash. The DNS on-the-wire packet will have only a single backslash in each case.


5. Clarification of DDDS Use in ENUM
5. 澄清ENUM中DDDS的使用

ENUM is a DDDS Application. This means that it relies on the DDDS for its operation. DDDS is designed to be flexible, but that opens the possibility of differences of interpretation. This section is intended to cover ENUM-specific interpretation of text within the DDDS specifications. The goal is to ensure interoperability between ENUM clients and provisioning systems used to populate domains with E2U NAPTRs.

ENUM是一个DDDS应用程序。这意味着它的运作依赖于DDDS。DDDS的设计是灵活的,但这就打开了解释差异的可能性。本节旨在涵盖DDDS规范中特定于枚举的文本解释。目标是确保枚举客户端和用于使用E2U NAPTR填充域的供应系统之间的互操作性。

As part of on-going development work on the ENUM specifications, [RFC5483] provides an (informative) analysis of the way in which ENUM client and provisioning system implementations behave and the interoperability issues that have arisen. The following recommendations reflect that analysis, and further narrative explaining the issues can be found in that RFC.


5.1. Collected Implications for ENUM Provisioning
5.1. 收集的枚举资源调配的含义

ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range (U+0020 to U+007E) unless it is clear that all ENUM clients they are designed to support will be able to process such characters correctly. If ENUM zone provisioning systems require non-ASCII characters, these systems MUST encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate mechanism (such as those in [RFC3492], [RFC3987]). Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form.

ENUM NAPTR不应包含可打印US-ASCII等效范围(U+0020到U+007E)之外的字符,除非明确说明其设计支持的所有ENUM客户端都能够正确处理此类字符。如果枚举区域设置系统需要非ASCII字符,则这些系统必须通过应用适当的机制(如[RFC3492]、[RFC3987]中的机制)对非ASCII数据进行编码,以仅发出US-ASCII字符。不应使用不可打印的字符,因为枚举客户端可能需要以人类可读的形式呈现NAPTR内容。

The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs.

区分大小写标志('i')不适用于枚举,不应设置到E2U NAPTRs的Regexp字段中。

The Registrant and the ENUM zone provisioning system he or she uses SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.


All E2U NAPTRs SHOULD hold a default value in their ORDER field. A value of "100" is recommended, as it seems to be used in most provisioned domains.

所有E2U NAPTR应在其订单字段中保留默认值。建议使用值“100”,因为它似乎用于大多数已配置的域。

Some ENUM clients have been known to pre-discard NAPTRs within an RRSet simply because these records do not have the lowest ORDER value found in that RRSet. Other ENUM client implementations appear to have confused ORDER and PREFERENCE/PRIORITY fields, using the latter as the major sort term rather than the former as specified. Conversely, ENUM zones have been provisioned within which the ORDER value varies but the PREFERENCE/PRIORITY field value is static. This may have been intentional, but given the different client behavior in the face of varying ORDER field values, it may not produce the desired response.


Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical and there is no preference between them. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.


An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left-to-right order within such NAPTRs.


ENUM zone provisioning systems SHOULD assume that, once a non-terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will be considered only within the context of that referenced domain (i.e., the ORDER value will be used only to sort within the current RRSet and will not be used in the processing of NAPTRs in any other RRSet).


ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character.


If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.

如果Regexp分隔符是Repl子字段的静态文本中的一个字符,则必须使用[RFC3402]第3.2节所示BNF规范的转义分隔符产品对其进行“转义”(即“\!”,U+005C U+0021)。请注意,在DNS主文件语法中输入NAPTR资源记录时,必须使用第二个反斜杠对反斜杠本身进行转义。

If present in the ERE sub-field of an ENUM NAPTR, the literal character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note that, as always, when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.

如果存在于枚举NAPTR的ERE子字段中,则文字字符“+”必须转义为“\+”(即U+005C U+002B)。请注意,与往常一样,当以DNS主文件语法输入NAPTR资源记录时,必须使用第二个反斜杠对反斜杠本身进行转义。

Whilst this client behavior is non-compliant, ENUM provisioning systems and their users should be aware that some ENUM clients have been detected with poor (or no) support for non-trivial ERE sub-field expressions.


ENUM provisioning systems SHOULD be cautious in the use of multiple back-reference patterns in the Repl sub-field of NAPTRs they provision. Some clients have limited buffer space for character expansion when generating URIs. These provisioning systems SHOULD check the back-reference replacement patterns they use, ensuring that regular expression processing will not produce excessive-length URIs.


ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete syntax of [RFC2916], and MUST be provisioned with NAPTRs in which the Services field is according to Section 3.4.3 of this document.


[RFC2915] and [RFC2916] have been obsoleted by [RFC3401]-[RFC3404] and by this document, respectively.


Enumservices in which the Enumservice type starts with the facet "P-" MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use.


As current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it is clear that all ENUM clients that this environment supports can process these.


When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query.


In a non-terminal NAPTR that may be encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty.


A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field, as this field will be interpreted as holding the FQDN that forms the next key output from this non-terminal Rule. The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query.


5.2. Collected Implications for ENUM Clients
5.2. 收集对枚举客户端的影响

If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate and processing SHOULD continue with the next NAPTR in the returned RRSet.


ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal).


ENUM clients MAY discard NAPTRs that have octets in the Flags, Services, or Regexp fields that have byte values outside the US-ASCII equivalent range (i.e., byte values above 0x7F). Clients MUST be ready to encounter NAPTRs with such values without failure.


ENUM clients MUST sort the records of a retrieved NAPTR RRSet into sequence using the ORDER and PREFERENCE fields of those records. The ORDER is to be treated as the major sort term, with lowest numerical values being earlier in the sequence. The PREFERENCE/PRIORITY field is to be treated as the minor sort term, with lowest numerical values being earlier in the sequence.

ENUM客户端必须使用检索到的NAPTR RRSet记录的顺序和首选项字段将这些记录按顺序排序。顺序将被视为主要排序项,最低数值在序列中较早。首选项/优先级字段将被视为次要排序项,最低数值在序列中较早。

ENUM clients SHOULD NOT discard a NAPTR record until it is considered or a record previous to it in the evaluation sequence has been accepted.


Notably, if a record has a "worse" ORDER value than others in this RRSet, that record MUST NOT be discarded before consideration unless a record has been accepted as the result of this ENUM query.


Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MAY present all NAPTRs -- not just the ones with the lowest currently unprocessed ORDER field value. The client SHOULD observe the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.


ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence in which they appear in the DNS response. (There is no benefit in further randomizing the order in which these are processed, as intervening DNS Servers might have done this already).


ENUM clients SHOULD consider the ORDER field value only when sorting NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by traversal of non-terminal NAPTR references.


ENUM clients receiving compound NAPTRs (i.e., ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so that the first Enumservice to be processed will be the leftmost one, and the last will be the rightmost one.


ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.


ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field.


Unless they are sure that in their environment this is the case, in general an ENUM client may still encounter NAPTRs that have been provisioned with a following 'i' (case-insensitive) flag, even though that flag has no effect at all in an ENUM scenario.


ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field.


In the spirit of being liberal with what it will accept, if the ENUM client is sure how the Regexp field should be interpreted, it MAY choose to process the NAPTR even in the face of an incorrect number of unescaped delimiter characters. If it is not clear how the Regexp field should be interpreted, the client MUST discard the NAPTR.


ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure.


ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failure.


ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.


When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognize one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.


ENUM clients MUST support ENUM NAPTRs according to syntax defined in Section 3.4.3. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs. The informational [RFC3824] recommended such support.

ENUM客户端必须根据第3.4.3节中定义的语法支持ENUM NAPTRs。ENUM客户端还应根据[RFC2916]的过时语法支持ENUM NAPTRs;仍然有保留“旧”语法NAPTR的区域。参考[RFC3824]建议提供此类支持。

Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.


5.2.1. Non-Terminal NAPTR Processing
5.2.1. 非终端NAPTR处理

ENUM clients MUST be ready to process NAPTRs with an empty Flags field ("non-terminal" NAPTRs) without failure. More generally, non-terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they encounter.


ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field.


ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the FQDN to be used in the next round of the ENUM query. An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or does not contain a valid FQDN. By definition, it follows that the Regexp field will be empty in such a non-terminal NAPTR. If present in a non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM clients.


If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD


continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred.


If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (i.e., the one including the non-terminal NAPTR that caused the traversal).


ENUM clients MUST be prepared to encounter a referential loop in which a sequence of non-terminal NAPTRs are retrieved within an ENUM query that refer back to an earlier FQDN. ENUM clients MUST be able to detect and recover from such a loop, without failure.


ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as an indication that a referential loop has been entered.


When a domain is about to be entered as the result of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, the client SHOULD discard the non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query indicated by that non-terminal NAPTR.


6. IANA Considerations
6. IANA考虑

RFC 2916 and then RFC 3761 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions that were provided by the IAB (as described in [RFC3245]). The domain was delegated according to those instructions (which are published at <>).

RFC 2916和RFC 3761(本文件取代)要求IANA按照IAB提供的说明(如[RFC3245]所述)委托E164.ARPA域。已根据这些说明(发布于)委派域<>).

Names within this zone are to be delegated to parties consistent with ITU Recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should be assigned in accordance with that Recommendation.


The IAB is to coordinate with the ITU Telecommunications Standardization Bureau (TSB) if the technical contact for the domain is to change, as ITU TSB has an operational working relationship with this technical contact that would need to be reestablished.

如果域e164.arpa的技术联系人发生变化,IAB将与ITU电信标准化局(TSB)进行协调,因为ITU TSB与该技术联系人之间存在需要重新建立的运营工作关系。

See [RFC6117] for Enumservice-related IANA Considerations.


7. Security Considerations
7. 安全考虑
7.1. DNS Security
7.1. DNS安全

As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kinds of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself.


There are multiple types of attacks that can happen against DNS that ENUM implementations should consider. See Threat Analysis of the Domain Name System [RFC3833] for a review of the various threats to the DNS.


Because of these threats, a deployed ENUM service SHOULD include mechanisms to mitigate these threats. Most of the threats can be solved by verifying the authenticity of the data via mechanisms such as DNS Security (DNSSEC) [RFC4033].


Others, such as Denial-Of-Service attacks, cannot be solved by data authentication. It is important to remember that these threats include not only the NAPTR lookups themselves, but also the various records needed for the services to be useful (for example NS, MX, SRV, and A records).


Even if DNSSEC is deployed, it cannot protect against every kind of attack on DNS. ENUM is often used for number or address translation; retrieving an address through an ENUM lookup with DNSSEC support does not, however, ensure that the service is immune to attack. It is unwise for a service blindly to trust that the address it has retrieved is valid and that the entity to which it connects using that address is the service peer it intended to contact. A service SHOULD always authenticate the entity to which it connects during the service setup phase, and not rely on address or identity data retrieved outside that service.


Finally, as an ENUM service will be implementing some type of security mechanism, software that implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses and other EDNS0 signaling (see [RFC2671]), unknown resource records (see [RFC3597]), and so on.


7.2. Caching Security
7.2. 缓存安全性

The DNS architecture makes extensive use of caching of records at intermediary nodes to improve performance. The propagation time (for changes to resource records to be reflected in query responses to end nodes) approaches the "time to live" value for those records. There may be a number of different resource records involved in the resolution of a communication target. Changes to these records may not be synchronized (particularly if these resource records indicate different times to live). Thus a change in any one of these records may cause inappropriate decisions on communications targets to be made. Given that DNS Update (specified in [RFC2136]) can introduce quite rapid changes in content in different zones, these transient states may become important.


Consider a typical set of queries that follow an ENUM query that returns a SIP URI (for details, see [RFC3263]):

考虑EnUM查询返回一个SIP URI的一组典型查询(详情请参阅[RCF3263]):

o Evaluation of the SIP URI triggers a query on the SIP domainpart for D2U/D2T NAPTRs.

o 对SIPURI的评估会触发对D2U/D2T NAPTR的SIP domainpart的查询。

o This in turn triggers a query on that record's target domain for SRV records.

o 这反过来会触发该记录的目标域上的SRV记录查询。

o The SRV records will return the SIP server hostname, which will trigger a further query on that hostname for an A record to get the server's associated IP address.

o SRV记录将返回SIP服务器主机名,这将触发对该主机名的进一步查询,以获取服务器的关联IP地址。

o Finally, the local SIP User Agent Client will then attempt to initiate a communications session to that IP address.

o 最后,本地SIP用户代理客户端将尝试发起到该IP地址的通信会话。

The E2U NAPTR may have changed its URI, indicating a new SIP identity. The D2U NAPTR for the SIP URI domainpart may have changed its target. The SRV record pointed to by that D2U NAPTR may have changed its target hostname. The hostname's A record may have changed its IP address. Finally, if the server exists in an environment where IP-addresses are dynamically assigned (for example, when using DHCP [RFC2131]), an unexpected end point may have been allocated to the IP address returned from the SIP resolution chain.

E2U NAPTR可能已更改其URI,表示新的SIP标识。SIP URI domainpart的D2U NAPTR可能已更改其目标。D2U NAPTR指向的SRV记录可能已更改其目标主机名。主机名的A记录可能已更改其IP地址。最后,如果服务器存在于动态分配IP地址的环境中(例如,当使用DHCP[RFC2131]时),则可能已将意外端点分配给从SIP解析链返回的IP地址。

In environments where changes to any of the chain of resource records or dynamic assignments to IP addresses occur, those systems provisioning this data SHOULD take care to minimize changes and to consider the respective times to live of resource records and/or DHCP lease times. Users of this data SHOULD take care to detect and recover from unintended communications session attempts; in a transient environment, these may occur.


7.3. Call Routing Security
7.3. 呼叫路由安全

There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name-translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes.


7.4. URI Resolution Security
7.4. URI解析安全性

A large amount of security issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the Enumservice used, as specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117].


8. Acknowledgements
8. 致谢

This document is an update of RFC 3761, which was edited by Patrik Faltstrom and Michael Mealling. Please see the Acknowledgements section in that RFC for additional acknowledgements. The authors would also like to thank Alfred Hoenes and Bernie Hoeneisen for their detailed reviews.

本文件是由Patrik Faltstrom和Michael Mealling编辑的RFC 3761的更新。请参阅该RFC中的确认部分,以了解更多确认。作者还要感谢阿尔弗雷德·霍恩斯和伯尼·霍内森的详细评论。

9. Changes from RFC 3761
9. RFC 3761的变更

A section has been added to explain the way in which DDDS is used with this specification. These recommendations have been collected from experience of ENUM deployment. Differences of interpretation of the DDDS specifications led to interoperability issues; this document updates RFC 3761 to add many clarifications, intended to ameliorate interoperability.

增加了一节来解释DDDS与本规范一起使用的方式。这些建议是从ENUM部署的经验中收集的。DDDS规范解释的差异导致互操作性问题;本文档更新了RFC 3761,添加了许多澄清,旨在改善互操作性。

Clarifications include a default value for the ORDER field and for the Regexp delimiter character, required use of Replacement field in non-terminal NAPTRs, and that string matching is case insensitive (Section 3.6).


Other substantive changes include removing the discussion of registration mechanisms, (now specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]), correcting an existing error by adding "-" as a valid character in the type and subtype fields specified in Services Parameters (Section 3.4.3) and adding the "P-" private service type (Section


10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.


[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034]Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 1034,1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 1035,1987年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.


[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.


[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.


[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.

[RFC3492]Costello,A.,“Punycode:应用程序中国际化域名的Unicode引导字符串编码(IDNA)”,RFC 3492,2003年3月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau,F.,“UTF-8,ISO 10646的转换格式”,STD 63,RFC 3629,2003年11月。

[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[RFC3761]Faltstrom,P.和M.Mealling,“E.164到统一资源标识符(URI)动态委托发现系统(DDDS)应用程序(ENUM)”,RFC 3761,2004年4月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986]Berners Lee,T.,Fielding,R.,和L.Masinter,“统一资源标识符(URI):通用语法”,STD 66,RFC 3986,2005年1月。

[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

[RFC3987]Duerst,M.和M.Suignard,“国际化资源标识符(IRIs)”,RFC 3987,2005年1月。

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]Crocker,D.,Ed.,和P.Overell,“语法规范的扩充BNF:ABNF”,STD 68,RFC 5234,2008年1月。

10.2. Informative References
10.2. 资料性引用

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.


[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.

[RFC2136]Vixie,P.,Ed.,Thomson,S.,Rekhter,Y.,和J.Bound,“域名系统中的动态更新(DNS更新)”,RFC 21361997年4月。

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

[RFC2671]Vixie,P.,“DNS的扩展机制(EDNS0)”,RFC 26711999年8月。

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[RFC2782]Gulbrandsen,A.,Vixie,P.和L.Esibov,“用于指定服务位置(DNS SRV)的DNS RR”,RFC 2782,2000年2月。

[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.

[RFC2915]Mealling,M.和R.Daniel,“命名机构指针(NAPTR)DNS资源记录”,RFC 2915,2000年9月。

[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.

[RFC2916]Faltstrom,P.,“E.164编号和DNS”,RFC 29162000年9月。

[RFC3245] Klensin, J., Ed., and IAB, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 3245, March 2002.

[RFC3245]Klensin,J.,Ed.,和IAB,“电话号码映射(ENUM)操作决策的历史和背景:为ITU-T研究组2(SG2)提供的信息性文件”,RFC 32452002年3月。

[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.

[RFC3263]Rosenberg,J.和H.Schulzrinne,“会话启动协议(SIP):定位SIP服务器”,RFC 3263,2002年6月。

[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[RFC3401]Mealling,M.“动态委托发现系统(DDDS)第一部分:综合DDDS”,RFC 3401,2002年10月。

[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.


[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.

[RFC3824]Peterson,J.,Liu,H.,Yu,J.,和B.Campbell,“在会话启动协议(SIP)中使用E.164号码”,RFC 38242004年6月。

[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[RFC3833]Atkins,D.和R.Austein,“域名系统(DNS)的威胁分析”,RFC 38332004年8月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全介绍和要求”,RFC 4033,2005年3月。

[RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues and Experiences", RFC 5483, March 2009.

[RFC5483]Conroy,L.和K.Fujiwara,“ENUM实施问题和经验”,RFC 5483,2009年3月。

[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" RFC 6117, March 2011.

[RFC6117]Hoenesen,B.,Mayrhofer,A.,和J.Livingood,“Enumservices的IANA注册:指南、模板和IANA注意事项”,RFC 61172011年3月。

Authors' Addresses


Scott Bradner Harvard University 29 Oxford St. Cambridge MA 02138 USA


   Phone: +1-617-495-3864
   Phone: +1-617-495-3864

Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom


   Phone: +44-1794-833666
   Phone: +44-1794-833666

Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku Tokyo 101-0165 JAPAN