support by 百度翻译
translate by Xu__Jiayu
may some wrong,wel come to check
可能有误，欢迎指正
------------------------
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
JPRS
March 2011
E.164 到统一资源标识符 (URI)
动态授权发现系统 (DDDS) Application (ENUM)
Abstract
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.
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.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6116.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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
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
3.4.3.1. ENUM Services ..............................7
3.4.3.2. 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
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 "e164.arpa" 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
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].
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
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 e164.arpa, 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
This template defines the ENUM DDDS Application according to the
rules and requirements found in [RFC3402]. 被这个应用使用的DDDS
数据库可以在[RFC3403]中找到，且这个文献定义了NAPTR DNS资源记录的
类型type.
电话号码映射（ENUM）被设计为通过使用存储在DNS上的NAPTR记录由E.164获得URIs
为每个ENUM中的E.164利用一个众知的规则创建一个主键（正式域名FQDN，在顶级域名E164.arpa内）
从NAPTR记录查询和返回FQDN的解析过程依照本规范。
3.1. Application Unique String采用的特色字符串
采用独特字符串（AUS），把完全合格的E.164号码保留的第一个是‘+’字符，其他非数字字符去掉。
'+' 作为众知的锚点用于区分电话号码是不是E.164号码。
样例，E.164码号 "+44-116-496-0348"，为确认没有其他语法在AUS中，
删除其他非数字字符除了保留第一个‘+’，压缩成了 "+441164960348".
3.2. First Well Known Rule众知规则
用众知的规则把AUS转换成一个初始的主键。这个主键作为应用规则数据库的一个索引。
电话号码规则(ENUM)数据库在DNS，所以这些主键是正式域名（FQDN）.
为了把AUS转换成数据库中一个唯一的主键【译注：主键重值冲突就错误】，
E.164转换成域名采用这个算法：
1.删除所有的非数字字符样例：给一个E.164号码 "+44-20-7946-0148"
(先转换成一个AUS "+442079460148"), 这一步简单删第一个‘+’得
"442079460148".
2. 反转数字字符的到 "841064970244"
3. 在数字间加入点分隔符‘.’"8.4.1.0.6.4.9.7.0.2.4.4"
4. 在尾部追加字符串 ".e164.arpa."解析得域名： 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
E.164空间和应用数据库采用这种组织方式，利用名本身直接根据名得到空间的
最小粒度，所以生成主键没有深层次的处理。
域名在NAPTR请求记录中被使用（NAME）。这些记录可能包含最终的结果，或者他的标志
(FLAG2)字段为空。根据域名的格式生成一个新的主键需要向DNS进一步请求NAPTR记录。
3.3. Expected Output期望结果
最后动态授权发现系统（DDDS）环路最后输出是一个统一资源标识符URI。
输出的URI是绝对格式。<absolute-URI>是根据RFC3986中的ABNF范式产生的。
3.4. Valid Databases有效数据库
目前只有动态授权发现系统（DDDS）数据库被这个应用指定。
“(DDDS) Part Three: The DNS Database域名数据库"[RFC3403]指定了一个
DDDS数据库使用了NAPTR NDS资源记录包含了重写规则。数据库中的主键被编码成域名。
替换表达式中使用的字符集为UTF-8[RFC3629].
允许出现在E.164号码任意位置的字符作为可接受的输入。键中允许出现的字符
限定了当前在DNS定义的域名。
3.4.1. Optional Name Server Additional Section Processing可选域名服务器附加部分处理
一些域名服务器试图根据项目智能地插入附加信息部分(additional)
作为DNS的应答。例如，BIND会尝试判断他是否有权限把域名编码到一个
数据包里面。若有，将会把往应答报文的附加信息部分插入由域名查询到
的所有A记录直到最大的允许长度范围。因此检查附加信息对客户端是有用的。
电话号码映射（ENUM）增强的域名系统要弄明白当前NAPTR记录的内容并提供
服务插入更适当的信息到附加信息部分作为应答。因此，DNS服务器可能会解
析FLAG的值，并利用解析得到的信息，在DNS数据包的附加信息部分包含适当
的资源记录。鼓励客户端检查附加信息但不是必须。关于更多DNS应答数据包
的NAPTR记录和附加信息--参考RFC3403的章节4.2。
3.4.2. Flags
当DDDS算法结束时，数据库内容的FLAGS字段会有一个标志。这个时候只有一个标志‘U’。
这意味着这是最后一个规则，并且输出规则是一个URI[rfc3986]
--参考RFC3404的章节4.3
如果客户端遇到一个带有未知标志（FLAGS）的资源记录，客户端必须忽略他并跳到下一条规则。
这个标志检测优先权最高，因为标志可以控制当前域的解析位置。
一个新的标志（FLAGS）可能会改变正则（regexp）或者替换（replacement）字段的解析，
这样就不能确定一个资源记录的匹配目标。
如果这个标志（FLAGS）不存在，那么不是终结规则。
如果不是终结规则的，产生的结果一定是域名的重写规则。客户端必须使用
这个重写规则作为新的主键在动态授权发现系统(DDDS)回路中（即客户端将
会用这个FQDN查询NAPTR资源记录）
3.4.3. Service Parameters 服务参数
这个应用的服务参数采用的是扩展的巴科式范式（ABNF,RFC5234）,
在NAPTR记录中的的SERVICES字段保存终结规则。如果NAPTR是非终结规则，
则服务（SERVICES）字段需要为空，而客户端应该忽略它的内容。
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT / "-")
subtype = 1*32(ALPHA / DIGIT / "-")
换句话说，非可选项‘E2U’（用于表示电话号码映射（ENUM）只重写规则以减少记录冲突）
可以跟着一个或者多个enumserviceis，表明给定的断点提供的功能类别。
每个Enumservice通过第一个'+'标识。
3.4.3.1. ENUM Services电话号码映射服务
Enumservices 可能会指定并注册引用“IANA注册的ENUMSERVICES指南、
模版和IANA的考量[RFC6117]”的程序定义。这个注册过程是不开放给
任何type中带有‘-’作为第二个字符的ENUMSERVICE的。
此外，注册过程不公开给ENUMERSEIVICE的types以‘X-’开始。‘X-’为
实验和试用预留，任何这类的ENUMSERVICES不能使用正常流程注册。
任何的Enumservice的type以"P-"开始是专用于专用（private）网络。
例如,NAPTRS包含Enumservice的types以 "P-"开始不应该出现在全球
网络。即使ENUM客户端可以识别并处理ENUMSERVICE,他可能无法解决
生成包含在NAPTR中的统一资源标识符（URI）。这类的ENUMSERVICES
不予注册。
这样的有特殊使用意义的Enumservices，任何专用网络环境以外的系
统都不得对其提供DNS查询NAPTR资源记录集（RRSets）的应答。除了
ENUM客户端确认连接到的专用网络的NAPTRs是有意配置的，否则一定
要丢弃NAPTR的ENUMSERIVCE的type以‘P-’开头。
3.4.3.2. Compound NAPTRs and Implicit ORDER/PREFERENCE Values
一个NAPTR可能有一个或多个Enumservice。这些Enumservice共享一个
相同的正则字段（regexp field）因此生成一样的URI，这种‘复合’NAPTR
可以用来标识支持语音和电话("voice:tel")、短信和电话（“sms:tel”）
的Enumservices。这种情况的服务字段（Services）可以是
"E2U+voice:tel+sms:tel".
一个复NAPTR可以认为是多个单独Enumservice的NAPTRs集。这些重建的
NAPTRs共享相同的ORDER/PREFERENCEThese字段，在逻辑上根据先后顺序
有不同的优先权。假定处理上的优先权从左到右。
3.5. The ENUM Algorithm Always Returns a Single Rule
电话号码映射算法总是返回单一规则。个人应用程序可能有特定于
应用程序的知识或设施允许他们呈现多个结果或快速选择，但这些
不应该改变算法的操作。
3.6. Case Sensitivity in ENUM电话号码映射大小写敏感
大小写敏感在[RFC3761][RFC2916]都没有被提到，但是在互操作性
测试事件中已被视为一个问题。目前部署了大量大小写敏感客户端。
在NAPTR字段内容中唯一使用大小写敏感的是正则（regexp）字段
的子部分--参考RFC3402章节3.2 。在子部分，生成的输出记录时
大小写必须保留。其他地方不使用大小写敏感。
ENUM客户端接触的NAPTR记录字段可能保留不同的字段内容大写，
客户端必须使用大小不敏感的处理，ENUM客户端使用互联网发送查
询，在这个范畴通常称为‘（公用电话号码映射）public Enum’。
一些客户端在封闭网络操作，例如，通讯服务提供商操作的独立
数据网络。这些通常被称为“基础设施电话号码映射”。提供这种封闭
网络的所有区域通常都要知道一个大写ENUM记录字符串内容，作为供应
系统的这种网路经常需要小心控制。在这种环境下，客户端不接触
记录使用大写是“无法预期”，因此可以设计大小写敏感处理。只有
当客户端知道操作环境中所有的ENUM记录采用大写，遇到已知的并
控制客户端使用大小写敏感处理。
3.7. Collision Avoidance冲突避免
一个电话号码映射兼容应用只能传递他认为是E.164号码的数字给
enum客户端查询流程（例如：他一定不会传递数字串给ENUM查询流程）
由于数字计划可能随着时间的推移改变，客户端想知道它要查询的号码
是被分配还是在当前数字计划活动中是不可能的。因此客户端可以区分
数据是关联 E.164号码计划，还是关联数字字符串是很重要的。（即
数字不是依照E.164号码计划。）
运营商的责任是提供数据到域，确保与E.164查询相关数据数字不被误认为
与其他用途相关联的NAPTRs数据
三种技术用于实现:
o 作为目的的顶级域名除了与数据相关联的E.164计划之外，一定不是 e164.arpa.
o 使用E.164号码以外的其他应用必须不能以‘+’开始。在ENUM中使用的AUS必须以
‘+’开始。
o NAPTRs专用与其他的DDDS应用在他们的服务字段中一定不能包含E2U记号。
而NAPTRs专用与ENUM时必须包含E2U记号。
4. ENUM Service Example电话号码映射服务样例
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
NAPTR 100 50 "u" "E2U+sip"
"!^(\\+441632960083)$!sip:\\1@example.com!" .
NAPTR 100 51 "u" "E2U+h323"
"!^\\+441632960083$!h323:operator@example.com!" .
NAPTR 100 52 "u" "E2U+email:mailto"
"!^.*$!mailto:info@example.com!" .
这里描述3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. 最先联系SIP,
其次通过 H.323语音, 第三通过 SMTP 进行消息传递。注：Enumservice的
"sip", "h323", 以及"email" 在IANA中注册的Enumservice Types。他们
与协议或URI没有隐式连接的同名方案。
在所有情况中，解析过程的下一步是使用每个协议的解析机制（由URI指定方案
sip，h323，mailto）知道结点的联系。
在每一个的前两个记录，ERE子字段只匹配查询得到的电话号码
+441632960083.
在最后一个记录,ERE匹配了任意的采用的特色字符串（AUS）的值。
第一个记录还演示了如何使用匹配模式生成URI。
注：在DNS上的关于NAPTR资源记录的主文件语法(如上服务样例),
每个反斜杠必须使用第二个转义反斜杠。在不同方案下，域名系统上的线包仅有
一个反斜杠。
5. Clarification of DDDS Use in ENUM在电话号码映射上动态授权发现系统的使用说明
电话号码映射（ENUM）是一个DDDS应用。这意味着他的操作在依赖于DDDS。
DDDS设计得很灵活，但是可能造成解析的不同。这章节打算在DDDS的规格范围内覆盖
ENUM指定的文本解析。目的是确保ENUM客户端和配置系统使用E2U NAPTRs填充域的
互操作性。
在ENUM规格说明的不断研究工作中，随着ENUM客户端和配置系统间的实现方式和交互问题
的提出，[rfc5483]提供了对信息的分析方法。后序的提议分析及更进一步论述表达可以
在RFC5483中找到。
5.1. Collected Implications for ENUM Provisioning电话号码映射配置（服务）集意义
ENUM NAPTRs 不应该包括US-ASCII码的可打印字符之外的部分(U+0020 to U+007E
注：ASCII码分为控制字符和显示字符，可打印字符即显示字符)，
除非明确确定所有的ENUM客户端都设计支持正确处理那些字符。
如果ENUM区域提供商需要非ASCII字符，这些系统必须利用适当的机制（例如RFC3492/
RFC3987）编码非ASCII码字符成US-ASCII。非打印字符（即控制字符） 不应使用。因为
ENUM客户端可能需要以人类可读的形式展示NAPTR内容。
大小写敏感的flag('i')在ENUM是不适合的，不应该被提供在E2U NAPTRs的Regexp字段。
注册者和ENUM区域配置系统都不应该依赖于只考虑ENUM客户端ENUM NAPTRs的ORDER和
PREFERENCE/PRIORITY字段的值。因此，一个注册者应该加入她自己的区域，只联系
愿意支持的。这样，即便是再槽糕的ORDER和PREFERENCE/PRIORITY值都可以被使用者使用。
所有的E2U都应该保留一个默认的值在他们的ORDER字段，建议使用“100”，
因为它似乎是最常用的配置域。
一些ENUM客户端已经知道简单的预抛弃一些资源记录集因为这些记录在资源记录集中
没有比较低的ORDER值。而另一些的ENUM客户端在处理ORDER和PREFERENCE/PRIORITY
字段存在混乱，错误的把后者当作主要排序项而不是指定的前者。反过来，ENUM区域
配置中ORDER的值是变化的而PREFERENCE/PRIORITY的值是静态的，这样可能是有意的，
但是考虑到不同的客户的不同ORDER值，可能不会产生预期响应。
大量的NAPTRs带有相同的ORDER和相同的PREFERENCE/PRIORITY的字段值不应该被配置在一个
资源记录集中，除非naptrs真的是相同的且之间不存在优先级。实施者不应该假定DNS会以
特定的顺序交付资源记录值中的NAPTRs。
一个ENUM区域配置系统应该假定对于一个复NAPTRs，会默认从左到右的顺序处理这个
Naptrs的Enumservices。
ENUM区域配置系统应该假定，一旦一个非终结NAPTR被选择处理，这个非终结NAPTR涉及
的域名对应的单个域名环境中会把ORDER字段的值考虑在内。（即ORDER值只会被当前的
资源记录集中排序使用，而不会在NAPTR处理的其他资源记录集使用）
ENUM区域配置系统应该使用‘！’(U+0021)作为Regexp（正则表达式）分隔字符。
如果regexp分隔符在Repl子字段的静态文本中是一个字符，那么一定需要使用转义符
“转义“， BNF范式规范在在[RFC3402]章节3.2.(即“\!”,U+005C U+0021)
注：当一个NAPTR资源记录按照DNS主文件语法写入时，反斜杠本身一定需要使用第二个
反斜杠转义。
如果在电话号码映射（ENUM）的权威域名指针(NAPTR)的ERE子字段中，字面上的‘+’一定
要转义‘\+’（即U+005C U+002B）。注：一如既往，当一个NAPTR资源记录按照DNS主文件
语法写入时，反斜杠本身一定需要使用第二个反斜杠转义。
当一个客户行为不符合规范时，ENUM配置系统和他的用户要意识到一些ENUM客户端被检测
到不支持没有价值的ERE子字段表达式。
电话号码映射（ENUM）配置系统在NAPTRS的Repl子字段中应该谨慎使用规定的多重的
back-reference 模式。有些客户端在生成URIs时对字符表达式的缓冲空间有限制。
这些配置系统在使用的使用要检查back-reference 替换的模式，确保正则表达式的处
理不会产生过长的URIs（统一资源标识符）。
ENUM区域一定不可以根据RFC2916中过时的语法配置，配置NAPTRs的Services字段一定要
根据本文档的章节3.4.3。
在本文档中 [RFC2915] 和[RFC2916] 已过时，并分别被 [RFC3401]-[RFC3404]替代
NAPTR的ENUMSERIVCE的type以‘P-’开头的，任何专用网络环境以外的系统都不得对其提供
DNS查询NAPTR资源记录集（RRSets）的应答。这类的NAPTR是有专用意图的。
因为目前支持的限制，非终结NAPTRs不应该在ENUM区域中配置，除非清楚的所有的
ENUM客户端环境支持处理这些。
当填充NAPTRs的域名集时，ENUM区域配置系统不应该配置非终结NAPTRs以便在一个
ENUM查询中多余5个的这个NAPTRs会被处理。
在非终结的NAPTR中可能会遇到一个ENUM查询（即一个带有FLAGS为空的字段）
Services 字段应该为空。
一个非终结NAPTR在（非空）replacement字段中一定要包含目标域。
用于控制从非终结规则中的下一个主键输出的FQDN（正式域名）格式。
在一个用于查询ENUM的非终结NAPTR，对应Regexp字段一定要为空。
5.2. Collected Implications for ENUM Clients电话号码映射客户端集意义
如果一个NAPTR被抛弃，不应该导致ENUM查询终止处理应该继续资源记录集
中的下一个NAPTR（权威域名指针）
客户端在侦测到字符在US-ASCII码的打印字符范围之外时不应该抛弃NAPTRs。
(0x20 to 0x7E 十六进制)。
客户端可能会抛弃FLAGS、services或regexp字段字节值范围在US-ASCII之外
的字节（即字节大于0x70）。客户端要有能力处理遇到NAPTRs带有这类值而
不出错。
ENUM客户端一定要对检索到的NAPTR资源记录值排序成序列，排序利用的是这
些记录的ORDER和PREFERENCE。ORDER作为主排序项，低的数值优先。
PREFERENCE/PRIORITY 字段作为次排序项，值越低越优先。
ENUM客户端不应该抛弃NAPTR记录直到他被考虑或者记录之前在估计序列中已
经被接受 。
值得注意的是，如果这个记录在资源记录中有槽糕的ORDER值，这个记录
在被考虑之前一定不会被抛弃，除非记录已经被接受作为ENUM查询的结果。
当ENUM客户端展示可能了URLs列表给她最终的用户作为选择时，他可能展示
了所有的NAPTRs--不仅仅是当先未处理的ORDER字段值最低的。这个客户应
该保持由注册人指定的ORDER和PREFERENCE/PRIORITY的值。
ENUM客户端应该接收所有带有相同的ORDER和相同的PREFERENCE/PRIORITY字段值
的NAPTRs，并根据他们在DNS响应序列中出现处理。(进一步的随机化处理顺序是
毫无意义的，在中介的DNS服务器上可能已经这样做过了).
只有当排序的NAPTRs在单一的资源记录集中时，ENUM客户端应该考虑ORDER字段值。
在处理NAPTRs通过一系列的DNS查询时创建的遍历非终结NAPTR参照，
ORDER字段值不应该被考虑。
ENUM客户端接收复NAPTRs (即 一个带有多个Enumservices的)
应该用从左到右的顺序处理这些Enumservices，这样第一个Enumservices
是最左边的，而最后一个是最右边的。
ENUM客户端必须有能力处理使用不同的字符利用‘！’作为他们正则表达式的
分隔符而不出错。
ENUM客户端不应该假定分隔符是regexp字段的最后一个字符。
除非他们确信在他们的环境中的这种情况下，通常一个ENUM客户端可能
仍然会遇到一个NAPTRs被配置了‘i’FALG（大小写敏感）,哪怕那个flag
在一个 ENUM方案中没有影响。
ENUM客户端应该抛弃NAPTRs中regexp字段带有分隔符多于或少于3个没有
转义的实例。
本着接受的自由，如果ENUM客户端确认知道Regexp字段应该被怎样解析，
即使面临着错误的无转义的分隔符数目，他可以选择处理这个NAPTR。
如果不清楚怎么解析regexp字段，客户端一定要抛弃这个NAPTR。
ENUM客户端一定有能力处理NAPTRs在ERE子字段有有一定复杂度的模式而不出错。
ENUM客户端一定有能力处理NAPTRs在Repl子字段有多份回溯引用（back-reference）
的模式而不出错。
ENUM客户端一定有能力处理NAPTRs带有一个DDDS应用标识不是‘E2U’而不出错。.
当ENUM客户端收到一个复NAPTR（即多于一个的Enumservices）而里面带有不能处理
或者不能识别的Enumservices，ENUM客户端应该忽略这个Enumservice并且继续下一个
当前NAPTR里面的Enumservice字段的处理，只有当Enum不能处理NAPTR的全部Enumservices
才会丢弃这个NAPTR。这种情况不应该认为错误。
ENUM客户端必须依照在章节3.4.3定义的语法支持ENUM NAPTRs。客户端也必须
支持[RFC2916]中的过时语法。在某些领域依然支持就的NAPTRs语法。
[RFC3824]推荐这样支持。
ENUM客户端必须丢弃带有Enumservice type以“P-”开头的NAPTR，
除非一个ENUM客户端确认连接到专用网络的NAPTRs是有意配置的。
5.2.1. Non-Terminal NAPTR Processing非终结NAPTR处理
ENUM客户端必须有能力处理NAPTRs带有空的empty字段（非终结NAPTRs）而不出错。
更一般的，处理非终结NAPTR应该被执行，但是ENUM客户端可能会抛弃他们遇到的
非终结NAPTRs。
当遇到一个FLAGS字段为空的非终结NAPTR时，ENUM客户端应该忽略调SERVICES字段的
任何内容。
ENUM客户端接收到一个FLAGS字段为空的非终结NAPTR时，必须用replacement字段
作为控制正式域名（FQDN）用于下一轮ENUM查询。一个ENUM客户端必须抛弃replacement
字段为空或者包含的是无效正式域名（FQDN）的非终结NAPTR。根据定义，这类非
终结NAPTR的regexp字段为空。ENUM客户端必须忽略非终结NAPTR中不为空的regexp字段。
当处理一个ENUM查询多个域名时侦测到问题（被非终结NAPTR引用），这个ENUM查询不应该
被抛弃，而是继续处理这个发生域名问题的非终结NAPTR的下一个NAPTR。
如果一个非终结NAPTR涉及的其他所有NAPTRs在域中遍历结束，这些NAPTR会被抛弃，
ENUM客户端应该继续处理下一个NAPTR所“指referring”的资源记录集。
(即, 包含一个非终结NAPTR中的NAPTR引起遍历).
ENUM客户端必须有能力从一个ENUM查询中取出的非终结NAPTRs序列中引用循环返回
较早的FQDN（正式域名）。ENUM客户端一定要能够从循环中检测和恢复而不出错。
ENUM客户端可以把在一个单独的ENUM查询中多于5个非终结NAPTRs的遍历串当作
已进入引用循环的指示。
当一个非终结NAPTR的一个域名作为引用的结果输入，且ENUM客户端已检测到一个
潜在的引用循环时，客户端应该在他的处理中抛弃这个非终结NAPTR，
并继续清单列中的下一个NAPTR。不应该由非终结NAPTR表示DNS查询。
6. IANA Considerations
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
<http://www.ripe.net/data-tools/dns/enum/iab-instructions>).
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
e164.arpa is to change, as ITU TSB has an operational working
relationship with this technical contact that would need to be
reestablished.
See [RFC6117] for Enumservice-related IANA Considerations.
7. Security Considerations
7.1. DNS Security
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
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]):
o Evaluation of the SIP URI triggers a query on the SIP domainpart
for D2U/D2T NAPTRs.
o This in turn triggers a query on that record's target domain for
SRV records.
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 Finally, the local SIP User Agent Client will then attempt to
initiate a communications session to that IP address.
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.
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
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
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
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.
9. Changes from 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.
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 3.4.3.1).
10. 参考文献
10.1. 规范性引用 略
10.2. 资料性引用 略
Authors' Addresses
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA 02138
USA
Phone: +1-617-495-3864
EMail: sob@harvard.edu
Lawrence Conroy
Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey
United Kingdom
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://lawrence.tel
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F
3-8-1 Nishi-Kanda Chiyoda-ku
Tokyo 101-0165
JAPAN
EMail: fujiwara@jprs.co.jp
URI: http://jprs.jp/en/
Chinese translate by Xu__Jiayu 2017-03-23/30
