RFC6116

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 [phone] 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碼号 "[phone]"，為确認沒有其他文法在AUS中，
   删除其他非數字字元除了保留第一個‘+’，壓縮成了 "[phone]".

3.2.  First Well Known Rule衆知規則

   用衆知的規則把AUS轉換成一個初始的主鍵。這個主鍵作為應用規則資料庫的一個索引。
   電話号碼規則(ENUM)資料庫在DNS，是以這些主鍵是正式域名（FQDN）.
   
   為了把AUS轉換成資料庫中一個唯一的主鍵【譯注：主鍵重值沖突就錯誤】，
   E.164轉換成域名采用這個算法：                                                

   1.删除所有的非數字字元樣例：給一個E.164号碼 "[phone]" 
    (先轉換成一個AUS "[phone]"), 這一步簡單删第一個‘+’得
      "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"
           "!^(\\[phone])$!sip:\\[email protected]!"    .
       NAPTR 100 51 "u" "E2U+h323"
           "!^\\[phone]$!h323:[email protected]!"    .
       NAPTR 100 52 "u" "E2U+email:mailto"
           "!^.*$!mailto:[email protected]!"    .

   這裡描述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子字段隻比對查詢得到的電話号碼
   [phone].
   在最後一個記錄,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: [phone]
   EMail: [email protected]


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

   Phone: [phone]
   EMail: [email protected]
   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: [email protected]
   URI:   http://jprs.jp/en/

Chinese translate by Xu__Jiayu 2017-03-23/30