[要約] RFC 3403は、DDDSの一部であるDNSデータベースに関するものであり、動的な委任の発見システムを提供することを目的としています。
Network Working Group M. Mealling
Request for Comments: 3403 VeriSign
Obsoletes: 2915, 2168 October 2002
Category: Standards Track
Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
動的委任ディスカバリーシステム（DDDS）パート3：ドメイン名システム（DNS）データベース
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).
このドキュメントでは、ルールの分散データベースとしてドメイン名システム（DNS）を使用した動的委任ディスカバリーシステム（DDDS）データベースについて説明します。キーはドメイン名であり、ルールは命名権限ポインター（NAPTR）リソースレコード（RR）を使用してエンコードされます。
Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
このドキュメントはRFC 2915を廃止しているため、NAPTR DNSリソースレコードの公式仕様です。また、「動的委任ディスカバリーシステム（DDDS）パート1：包括的なDDD」（RFC 3401）で完全に指定されているシリーズの一部でもあります。他のシリーズを読むことなく、このシリーズのドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DDDS Database Specification . . . . . . . . . . . . . . . . 3
4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Additional Information Processing . . . . . . . . . . . . . 7
4.2.1 Additional Section processing by DNS servers . . . . . . . . 7
4.2.2 Additional Section processing by resolver/applications . . . 7
4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 7
5. Application Specifications . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Advice for DNS Administrators . . . . . . . . . . . . . . . 10
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
The Dynamic Delegation Discovery System (DDDS) is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached.
動的に構成された委任システムをサポートするために、動的委任ディスカバリーシステム（DDDS）を使用してデータへの文字列の怠zyな結合を実装します。DDDSは、端末条件に達するまで文字列変換ルールを反復的に適用することにより、DDDSデータベース内に保存されたデータにいくつかの一意の文字列をマッピングすることにより機能します。
This document describes the way in which the Domain Name System (DNS) is used as a data store for the Rules that allow a DDDS Application to function. It does not specify any particular application or usage scenario. The entire series of documents is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. It is very important to note that it is impossible to read and understand any document in that series without reading the related documents.
このドキュメントは、DDDSアプリケーションを機能させるルールのデータストアとしてドメイン名システム（DNS）が使用される方法について説明します。特定のアプリケーションまたは使用法のシナリオは指定されていません。一連のドキュメント全体は、「動的委任ディスカバリーシステム（DDDS）パート1：包括的なDDDS」（RFC 3401）[1]で指定されています。関連するドキュメントを読むことなく、そのシリーズのドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) specified here was originally produced by the URN Working Group as a way to encode rule-sets in DNS so that the delegated sections of a Uniform Resource Identifiers (URI) could be decomposed in such a way that they could be changed and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name.
ここで指定された命名権限ポインター（NAPTR）DNSリソースレコード（RR）は、元々DNSのルールセットをエンコードする方法としてURNワーキンググループによって生成されたため、ユニフォームリソース識別子（URI）の委任されたセクションを分離することができます。それらを時間の経過とともに変更して再配置することができるような方法。結果は、クライアントプログラムで使用される正規表現を含むリソースレコードで、文字列をドメイン名に書き換えました。
Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet.
コンパクトさと表現率比のために正規表現が選択され、かなり小さなDNSパケットで多くの情報をエンコードできるようにしました。
Over time this process was generalized for other Applications and Rule Databases. This document defines a Rules Database absent any particular Application as there may be several Applications all taking advantage of this particular Rules Database.
時間が経つにつれて、このプロセスは他のアプリケーションおよびルールデータベースに一般化されました。このドキュメントでは、この特定のルールデータベースをすべて活用しているいくつかのアプリケーションがある可能性があるため、特定のアプリケーションがないため、ルールデータベースを定義します。
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 [6].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[6]で説明されているように解釈される。
All other terminology, especially capitalized terms, is taken from [3].
他のすべての用語、特に大文字の用語は[3]から取られています。
General Description: This database uses the Domain Name System (DNS) as specified in [8] and [7].
一般的な説明：このデータベースは、[8]および[7]で指定されているドメイン名システム（DNS）を使用します。
The character set used to specify the various values of the NAPTR records is UTF-8 [17]. Care must be taken to ensure that, in the case where either the input or the output to the substitution expression contains code points outside of the ASCII/Unicode equivalence in UTF-8, any UTF-8 is interpreted as a series of code-points instead of as a series of bytes. This is to ensure that the internationalized features of the POSIX Extended Regular Expressions are able to match their intended code-points. Substitution expressions MUST NOT be written where they depend on a specific POSIX locale since this would cause substitution expressions to loose their ability to be universally applicable.
NAPTRレコードのさまざまな値を指定するために使用される文字セットは、UTF-8です[17]。入力または置換式への出力のいずれかが、UTF-8のASCII/ユニコード等価の外側のコードポイントを含む場合、UTF-8が一連のコードポイントとして解釈されることを確認するために注意する必要があります。一連のバイトとしての代わりに。これは、POSIXの拡張正規表現の国際化された機能が、意図したコードポイントを一致させることができるようにするためです。置換式は、特定のPOSIXロケールに依存する場所で書かれてはなりません。これにより、置換式が普遍的に適用できる能力を失うためです。
All DNS resource records have a Time To Live (TTL) associated with them. When the number of seconds has passed since the record was retrieved the record is no longer valid and a new query must be used to retrieve the new records. Thus, as mentioned in the DDDS Algorithm, there can be the case where a given Rule expires. In the case where an application attempts to fall back to previously retrieved sets of Rules (either in the case of a bad delegation path or some network or server failure) the application MUST ensure that none of the records it is relying on have expired. In the case where even a single record has expired, the application is required to start over at the beginning of the algorithm.
すべてのDNSリソースレコードには、それらに関連付けられている時間（TTL）があります。レコードが取得されてから秒数が経過した場合、レコードはもはや有効ではなく、新しいレコードを取得するために新しいクエリを使用する必要があります。したがって、DDDSアルゴリズムで述べたように、特定のルールの有効期限が切れる場合があります。アプリケーションが以前に取得したルールのセットに戻ろうとする場合（悪い委任パスまたはネットワーク障害またはサーバー障害の場合）、アプリケーションは、依存しているレコードが期限切れになっていないことを確認する必要があります。単一のレコードでさえ有効期限が切れた場合、アルゴリズムの開始時に最初からやり直すためにアプリケーションが必要です。
Key Format: A Key is a validly constructed DNS domain-name.
キー形式：キーは、有効に構築されたDNSドメイン名です。
Lookup Request: In order to request a set of rules for a given Key, the client issues a request, following standard DNS rules, for NAPTR Resource Records for the given domain-name.
ルックアップリクエスト：特定のキーの一連のルールを要求するために、クライアントは、指定されたドメイン名のNAPTRリソースレコードの標準DNSルールに従ってリクエストを発行します。
Lookup Response: The response to a request for a given Key (domain-name) will be a series of NAPTR records. The format of a NAPTR Resource Record can be found in Section 4.
ルックアップ応答：特定のキー（ドメイン名）のリクエストに対する応答は、一連のNAPTRレコードになります。NAPTRリソースレコードの形式は、セクション4に記載されています。
Rule Insertion Procedure: Rules are inserted by adding new records to the appropriate DNS zone. If a Rule produces a Key that exists in a particular zone then only the entity that has administrative control of that zone can specify the Rule associated with that Key.
ルール挿入手順：適切なDNSゾーンに新しいレコードを追加することにより、ルールが挿入されます。ルールが特定のゾーンに存在するキーを生成する場合、そのゾーンの管理制御を持つエンティティのみがそのキーに関連付けられたルールを指定できます。
Collision Avoidance: In the case where two Applications may use this Database (which is actually the case with the ENUM and URI Resolution Applications, Section 6.2), there is a chance of collision between rules where two NAPTR records appear in the same domain but they apply to more than one Application. There are three ways to avoid collisions:
衝突回避：2つのアプリケーションがこのデータベースを使用できる場合（実際にはenumおよびURI解像度アプリケーションの場合、セクション6.2の場合です）、2つのNAPTRレコードが同じドメインに表示されるルール間で衝突する可能性がありますが、複数のアプリケーションに適用します。衝突を回避するには3つの方法があります。
* create a new zone within the domain in common that contains only NAPTR records that are appropriate for the application. E.g., all URI Resolution records would exist under urires.example.com and all ENUM records would be under enum.example.com. In the case where this is not possible due to lack of control over the upstream delegation the second method is used.
* アプリケーションに適したNAPTRレコードのみを含む、共通のドメイン内に新しいゾーンを作成します。たとえば、すべてのURI解像度のレコードはurires.example.comに存在し、すべてのenumレコードはenum.example.comの下にあります。上流の委任の制御がないためにこれが不可能な場合、2番目の方法が使用されます。
* write the regular expression such that it contains enough of the Application Unique string to disambiguate it from any other. For example, the URI Resolution Application would be able to use the scheme name on the left hand side to anchor the regular expression match to that scheme. An ENUM specific record in that same zone would be able to anchor the left hand side of the match with the "+" character which is defined by ENUM to be at the beginning of every Application Unique String. This way a given Application Unique String can only match one or the other record, not both.
* 正規表現を書いて、それが他のいずれかのアプリケーションを明確にするのに十分なアプリケーションの一意の文字列を含むようにします。たとえば、URI解像度アプリケーションは、左側のスキーム名を使用して、そのスキームに正規表現の一致を固定することができます。同じゾーンの列挙特定のレコードは、すべてのアプリケーションの一意の文字列の先頭にあるように列挙で定義される「」文字で、一致の左側を固定することができます。このようにして、特定のアプリケーションの一意の文字列は、両方ではなく、どちらか他のレコードと一致します。
* if two Application use different Flags or Services values then a record from another Application will be ignored since it doesn't apply to the Services/Flags in question.
* 2つのアプリケーションが異なるフラグまたはサービス値を使用する場合、問題のサービス/フラグには適用されないため、別のアプリケーションからのレコードは無視されます。
The packet format of the NAPTR RR is given below. The DNS type code for NAPTR is 35.
NAPTR RRのパケット形式を以下に示します。NAPTRのDNSタイプコードは35です。
The packet format for the NAPTR record is as follows
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
<character-string> and <domain-name> as used here are defined in RFC 1035 [7].
ここで使用されている<文字通り>および<domain-name>は、RFC 1035 [7]で定義されています。
ORDER A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately represent the ordered list of Rules. The ordering is from lowest to highest. If two records have the same order value then they are considered to be the same rule and should be selected based on the combination of the Preference values and Services offered.
ルールの順序付けられたリストを正確に表すために、NAPTRレコードを処理する必要がある順序を指定する16ビットの符号なし整数を注文します。注文は最低から最高から最高です。2つのレコードに同じ順序値がある場合、それらは同じルールと見なされ、提供される優先値とサービスの組み合わせに基づいて選択する必要があります。
PREFERENCE Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. It is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client MAY look at records with higher preference values if it has a good reason to do so such as not supporting some protocol or service very well.
優先DNS用語に敬意を表して「優先」と呼ばれますが、このフィールドはDDDSアルゴリズムの優先度値と同等です。これは、NAPTRレコードが等しい次数値を持つ順序を処理する必要がある16ビットの非署名整数であり、高い数値の前に低い数値を処理する必要があります。これは、MXレコードの優先フィールドに似ており、ドメイン管理者がより有能なホストまたは軽量プロトコルにクライアントを誘導できるように使用されるためです。クライアントは、一部のプロトコルやサービスを非常によくサポートしていないなどの正当な理由がある場合、より高い選好値のレコードを見ることができます。
The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. The only exception to this is noted in the second important Note in the DDDS algorithm specification concerning allowing clients to use more complex Service determination between steps 3 and 4 in the algorithm. Preference is used to give communicate a higher quality of service to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
順序と好みの重要な違いは、一致が見つかった後、クライアントは異なる順序でレコードを考慮してはならないが、同じ順序でレコードを処理することができるが、異なる好みであることです。これの唯一の例外は、クライアントがアルゴリズムのステップ3と4の間でより複雑なサービス決定を使用できるようにすることに関するDDDSアルゴリズム仕様の2番目の重要なメモに記載されています。優先順位は、機関の観点からは同じと見なされるが、単純な負荷分散の観点からではなく、より高いサービスのサービスをルールに通信するために使用されます。
It is important to note that DNS contains several load balancing mechanisms and if load balancing among otherwise equal services should be needed then methods such as SRV records or multiple A records should be utilized to accomplish load balancing.
DNSにはいくつかの負荷分散メカニズムが含まれており、それ以外の場合は等しいサービス間の負荷分散が必要な場合、SRVレコードや複数のAレコードなどのメソッドを使用して負荷分散を達成する必要があることに注意することが重要です。
FLAGS A <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set A-Z and 0-9. The case of the alphabetic characters is not significant. The field can be empty.
レコード内のフィールドの書き換えと解釈の側面を制御するためのフラグを含むフラグA <文字ストリング>。フラグは、セットA-Zと0-9の単一文字です。アルファベット文字の場合は重要ではありません。フィールドは空にすることができます。
It is up to the Application specifying how it is using this Database to define the Flags in this field. It must define which ones are terminal and which ones are not.
このデータベースを使用してこのフィールドのフラグを定義する方法を指定するのは、アプリケーション次第です。どの端子であり、どのものが端子であるかを定義する必要があります。
SERVICES A <character-string> that specifies the Service Parameters applicable to this this delegation path. It is up to the Application Specification to specify the values found in this field.
この代表団のパスに適用されるサービスパラメーターを指定するサービス<文字ストリング>。このフィールドで見つかった値を指定するのは、アプリケーション仕様次第です。
REGEXP A <character-string> containing a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. See the DDDS Algorithm specification for the syntax of this field.
次のドメイン名をルックアップに構築するために、クライアントが保持している元の文字列に適用される置換式を含むregexp a <文字ストリング>。このフィールドの構文については、DDDSアルゴリズムの仕様を参照してください。
As stated in the DDDS algorithm, The regular expressions MUST NOT be used in a cumulative fashion, that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite. The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, and extremely difficult to debug.
DDDSアルゴリズムに記載されているように、正規表現は累積的な方法で使用する必要はありません。つまり、クライアントが保持している元の文字列にのみ適用する必要があります。後者はいくつかのアプリケーションで魅力的ですが、経験により、そのような使用が非常に過失に敏感で、非常にエラーが発生しやすく、デバッグが非常に困難であることが示されています。
REPLACEMENT A <domain-name> which is the next domain-name to query for depending on the potential values found in the flags field. This field is used when the regular expression is a simple replacement operation. Any value in this field MUST be a fully qualified domain-name. Name compression is not to be used for this field.
交換a <ドメイン名>は、フラグフィールドで見つかった潜在的な値に応じてクエリする次のドメイン名です。このフィールドは、正規表現が単純な交換操作である場合に使用されます。このフィールドの値は、完全に適格なドメイン名でなければなりません。このフィールドには名前の圧縮は使用されません。
This field and the REGEXP field together make up the Substitution Expression in the DDDS Algorithm. It is simply a historical optimization specifically for DNS compression that this field exists. The fields are also mutually exclusive. If a record is returned that has values for both fields then it is considered to be in error and SHOULD be either ignored or an error returned.
このフィールドとRegexpフィールドは、DDDSアルゴリズムの置換式を一緒に構成します。これは、このフィールドが存在するDNS圧縮のための特に歴史的な最適化です。フィールドも相互に排他的です。両方のフィールドの値を持つレコードが返された場合、それは誤っていると見なされ、無視されるか、エラーを返します。
Additional section processing requires upgraded DNS servers, thus it will take many years before applications can expect to see relevant records in the additional information section.
追加のセクション処理には、アップグレードされたDNSサーバーが必要であるため、アプリケーションが追加情報セクションに関連するレコードが表示されることが期待されるまでに何年もかかります。
DNS servers MAY add RRsets to the additional information section that are relevant to the answer and have the same authenticity as the data in the answer section. Generally this will be made up of A and SRV records but the exact records depends on the application.
DNSサーバーは、回答に関連する追加情報セクションにrrsetを追加し、回答セクションのデータと同じ信頼性を持つ場合があります。通常、これはAとSRVレコードで構成されますが、正確なレコードはアプリケーションに依存します。
Applications MAY inspect the Additional Information section for relevant records but Applications MUST NOT require that records of any type be in the Additional Information section of any DNS response in order for clients to function. All Applications must be capable of handling responses from nameservers that never fill in the Additional Information part of a response.
アプリケーションは、関連する記録について追加情報セクションを検査する場合がありますが、アプリケーションは、クライアントが機能するために、あらゆるタイプのレコードがDNS応答の追加情報セクションにあることを要求してはなりません。すべてのアプリケーションは、応答の追加情報部分を記入しない名前の名前サーバーからの応答を処理できる必要があります。
The master file format follows the standard rules in RFC-1035. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535. The Flags and Services and Regexp fields are all quoted <character-string>s. Since the Regexp field can contain numerous backslashes and thus should be treated with care. See Section 7 for how to correctly enter and escape the regular expression.
マスターファイル形式は、RFC-1035の標準ルールに従います。16ビットの署名されていない整数である順序と選好は、0〜65535の整数でなければなりません。フラグとサービスとregexpフィールドはすべて、<文字弦> sを引用しています。regexpフィールドには多数のバックスラッシュが含まれている可能性があるため、注意して扱う必要があります。正規表現を正しく入力して逃れる方法については、セクション7を参照してください。
This DDDS Database is usable by any application that makes use of the DDDS algorithm. In addition to the items required to specify a DDDS Application, an application wishing to use this Database must also define the following values:
このDDDSデータベースは、DDDSアルゴリズムを使用するアプリケーションで使用できます。DDDSアプリケーションを指定するために必要なアイテムに加えて、このデータベースを使用したいアプリケーションも次の値を定義する必要があります。
o What domain the Key that is produced by the First Well Known Rule belongs to. Any application must ensure that its rules do not collide with rules used by another application making use of this Database. For example, the 'foo' application might have all of its First Well Known Keys be found in the 'foo.net' zone.
o 最初によく知られているルールによって生成されるキーは、どのドメインに属します。アプリケーションは、このデータベースを使用する別のアプリケーションで使用されているルールとそのルールが衝突しないようにする必要があります。たとえば、「foo」アプリケーションには、最初によく知られているすべてのキーが「foo.net」ゾーンにあります。
o What the allowed values for the Services and Protocols fields are.
o サービスフィールドとプロトコルの許可された値は何ですか。
o What the expected output is of the terminal rewrite rule in addition to how the Flags are actually encoded and utilized.
o 予想される出力は、フラグが実際にエンコードされ、利用される方法に加えて、端末の書き換えルールのものです。
The NAPTR record was originally created for use with the Uniform Resource Name (URN) Resolver Discovery Service (RDS) [15]. This example details how a particular URN would use the NAPTR record to find a resolver service that can answer questions about the URN. See [2] for the definitive specification for this Application.
NAPTRレコードは、元々、ユニフォームリソース名（URN）Resolver Discovery Service（RDS）で使用するために作成されました[15]。この例では、特定のURNがNAPTRレコードを使用して、URNに関する質問に答えることができるリゾルバーサービスを見つける方法を詳しく説明しています。このアプリケーションの決定的な仕様については、[2]を参照してください。
Consider a URN namespace based on MIME Content-Ids (this is very hypothetical so do not rely on this). The URN might look like this:
Mime Content-IDに基づいたurnネームスペースを検討してください（これは非常に仮説的なので、これに依存しないでください）。urnは次のように見えるかもしれません：
urn:cid:199606121851.1@bar.example.com
This Application's First Well Known Rule is to extract the characters between the first and second colon. For this URN that would be 'cid'. The Application also specifies that, in order to build a Database-valid Key, the string 'urn.arpa' should be appended to the result of the First Well Known Rule. The result is 'cid.urn.arpa'. Next, the client queries the DNS for NAPTR records for the domain-name 'cid.urn.arpa'. The result is a single record:
このアプリケーションで最初によく知られているルールは、第1コロンと2番目のコロンの間に文字を抽出することです。このurのために、それは「cid」になります。また、アプリケーションは、データベースValidキーを構築するために、文字列「urn.arpa」を最初によく知られているルールの結果に追加する必要があることも指定しています。結果は「cid.urn.arpa」です。次に、クライアントは、ドメイン名「cid.urn.arpa」のNAPTRレコードのDNSを照会します。結果は単一のレコードです。
cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
cid.urn.arpa。;;naptr 100 10 "" "" "
Since there is only one record, ordering the responses is not a problem. The replacement field is empty, so the pattern provided in the regexp field is used. We apply that regexp to the entire URN to see if it matches, which it does. The \2 part of the substitution expression returns the string "example.com". Since the flags field is empty, the lookup is not terminal and our next probe to DNS is for more NAPTR records where the new domain is 'example.com'.
レコードは1つしかないため、応答を注文することは問題ではありません。交換場は空であるため、regexpフィールドで提供されるパターンが使用されます。そのregexpをur全体に適用して、それが一致するかどうかを確認します。置換式の\ 2部分は、文字列「Example.com」を返します。フラグフィールドは空であるため、ルックアップは端末ではなく、DNSへの次のプローブは、新しいドメインが「Example.com」であるより多くのNAPTRレコードを対象としています。
Note that the rule does not extract the full domain name from the CID, instead it assumes the CID comes from a host and extracts its domain. While all hosts, such as 'bar', could have their very own NAPTR, maintaining those records for all the machines at a site could be an intolerable burden. Wildcards are not appropriate here since they only return results when there is no exactly matching names already in the system.
ルールはCIDから完全なドメイン名を抽出しないことに注意してください。代わりに、CIDがホストから来ていると仮定し、そのドメインを抽出します。「bar」などのすべてのホストは独自のNaptrを持つことができますが、サイトのすべてのマシンの記録を維持することは耐え難い負担になる可能性があります。ワイルドカードは、システム内に既に正確に一致する名前がない場合にのみ結果を返すため、ここでは適切ではありません。
The record returned from the query on "example.com" might look like:
「Example.com」のクエリから返されたレコードは、次のように見えるかもしれません。
example.com. ;; order pref flags service regexp replacement IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.
Example.com。;;NAPTR 100 50 "A" "Z3950 N2L N2C" "" "cidserver.example.comでのnaptr 100 50" a "a" a "a" a "a" a "a" a "a" a "a" a "naptr 100 50"の注文サービスの交換。in naptr 100 50 "a" "rcds n2c" "" cidserver.example.com。in naptr 100 50 "s" "http n2l n2c n2r" "" www.example.com。
Continuing with the example, note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The Application defines the flag 'a' to mean a terminal lookup and that the output of the rewrite will be a domain-name for which an A record should be queried. Once the client has done that, it has the following information: the host, its IP address, the protocol, and the services available via that protocol. Given these bits of information the client has enough to be able to contact that server and ask it questions about the URN.
この例を継続して、注文フィールドと優先フィールドの値はすべてのレコードで等しいため、クライアントはレコードを自由に選択できることに注意してください。アプリケーションは、端子検索を意味するフラグ「A」を定義し、書き換えの出力がAレコードを照会するドメイン名になることを定義します。クライアントがそれを行ったら、次の情報があります：ホスト、そのIPアドレス、プロトコル、およびそのプロトコルを介して利用可能なサービス。これらの情報を考えると、クライアントはそのサーバーに連絡してurについて質問することができるほど十分です。
Recall that the regular expression used \2 to extract a domain name from the CID, and \. for matching the literal '.' characters separating the domain name components. Since '\' is the escape character, literal occurrences of a backslash must be escaped by another backslash. For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually receives the record, the pattern will have been converted to "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i".
正規表現が\ 2を使用してCIDからドメイン名を抽出したことを思い出してください。リテラルを一致させるために。ドメイン名コンポーネントを分離する文字。「\」はエスケープキャラクターであるため、バックスラッシュの文字通りの出現は、別のバックスラッシュによって逃げなければなりません。上記のcid.urn.arpaレコードの場合、マスターファイルに入力された正規表現は「！^urn：cid：。 @（[^\\。] \\。）（。*）$！\\ 2！i "。クライアントコードが実際にレコードを受信すると、パターンは「！^urn：cid：。 @（[^\。] \。）（。*）$！\ 2！i "に変換されます。
The ENUM Working Group in the IETF has specified a service that allows a telephone number to be mapped to a URI [18]. The Application Unique String for the ENUM Application is the E.164 telephone number with the dashes removed. The First Well Known Rule is to remove all characters from the the telephone number and then use the entire number as the first Key. For example, the phone number "770-555-1212" represented as an E.164 number would be "+1- 770-555-1212". Converted to the Key it would be "17705551212".
IETFの列挙ワーキンググループは、電話番号をURIにマッピングできるサービスを指定しました[18]。enumアプリケーション用のアプリケーション一意の文字列は、ダッシュが削除されたE.164の電話番号です。最初によく知られているルールは、電話番号からすべての文字を削除し、最初のキーとして全体の番号を使用することです。たとえば、E.164番号として表される電話番号「770-555-1212」は「1-770-555-1212」になります。キーに変換すると、「17705551212」になります。
The ENUM Application at present only uses this Database. It specifies that, in order to convert the first Key into a form valid for this Database, periods are inserted between each digit, the entire Key is inverted and then "e164.arpa" is appended to the end. The above telephone number would then read "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to retrieve Rewrite Rules as NAPTR records.
現在の列挙アプリケーションは、このデータベースのみを使用しています。最初のキーをこのデータベースに有効なフォームに変換するために、各桁の間に期間が挿入され、キー全体が反転し、「E164.ARPA」が最後に追加されることを指定します。上記の電話番号には、「2.1.2.1.5.5.5.0.7.7.1.e164.ARPA」と読み取られます。このドメイン名は、NAPTRレコードとしてルールを書き換えるために使用されます。
For this example telephone number we might get back the following NAPTR records:
この例の電話番号では、次のNAPTRレコードを取り戻す可能性があります。
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .
$ origin 2.1.2.1.5.5.5.5.0.7.7.1.e164.arpa。in naptr 100 10 "u" "sip e2u" "！^。*$！sip：information@foo.se！i"。in naptr 102 10 "u" "smtp e2u" "！^。*$！mailto：information@foo.se！i"。
Both the ENUM [18] and URI Resolution [4] Applications use the 'u' flag. This flag states that the Rule is terminal and that the output is a URI which contains the information needed to contact that telephone service. ENUM also uses the same format for its Service Parameters. These state that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail.
Enum [18]とURI Resolution [4]アプリケーションの両方が「U」フラグを使用します。このフラグは、ルールは端末であり、出力はその電話サービスに連絡するために必要な情報を含むURIであると述べています。Enumは、サービスパラメーターにも同じ形式を使用します。これらは、電話のサービスにアクセスするために使用される利用可能なプロトコルは、セッション開始プロトコルまたはSMTPメールのいずれかであると述べています。
Beware of regular expressions. Not only are they difficult to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers.
正規表現に注意してください。自分で正しいことをするのが難しいだけでなく、前述のDNSとの相互作用があります。正規表現のバックスラッシュは、クエリ応答に1回表示するために、ゾーンファイルに2回入力する必要があります。さらに真剣に、ダブルバックスラッシュの必要性は、おそらくDNSサーバーのすべての実装者によってテストされていないでしょう。
In order to mitigate zone file problems, administrators should encourage those writing rewrite rules to utilize the 'default delimiter' feature of the regular expression. In the DDDS specification the regular expression starts with the character that is to be the delimiter. Hence if the first character of the regular expression is an exclamation mark ('!') for example then the regular expression can usually be written with fewer backslashes.
ゾーンファイルの問題を軽減するために、管理者は、正規表現の「デフォルトの区切り文字」機能を利用するために、書くルールを書き直すことを奨励する必要があります。DDDS仕様では、正規表現は、区切り文字となるキャラクターから始まります。したがって、正規表現の最初の特性が感嘆符（ '！'）である場合、通常、正規表現はバックスラッシュを少なくして書くことができます。
A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known Service Parameter combination.
クライアントは、「注文」フィールドで指定された順序で複数のNAPTRレコードを処理する必要があります。既知のサービスパラメーターの組み合わせを提供する最初のレコードを単に使用してはなりません。
When multiple RRs have the same "order" and all other criteria being equal, the client should use the value of the preference field to select the next NAPTR to consider. However, because it will often be the case where preferred protocols or services exist, clients may use this additional criteria to sort the records.
複数のRRが同じ「順序」を持ち、他のすべての基準が等しい場合、クライアントは設定フィールドの値を使用して次のNAPTRを選択する必要があります。ただし、優先プロトコルまたはサービスが存在する場合が多いため、クライアントはこの追加基準を使用してレコードをソートすることができます。
If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths.
書き換えの後の検索が失敗した場合、クライアントは、他の書き換えパスを追求するためにバックアップするのではなく、失敗を報告することを強くお勧めします。
The values for the Services and Flags fields will be determined by the Application that makes use of this DDDS Database. Those values may require a registration mechanism and thus may need some IANA resources. This specification by itself does not.
サービスフィールドとフラグフィールドの値は、このDDDSデータベースを利用するアプリケーションによって決定されます。これらの値には登録メカニズムが必要になる場合があるため、IANAリソースが必要になる場合があります。この仕様自体はそうではありません。
The NAPTR record, like any other DNS record, can be signed and validated according to the procedures specified in DNSSEC.
NAPTRレコードは、他のDNSレコードと同様に、DNSSECで指定された手順に従って署名および検証できます。
This Database makes identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem.
このデータベースは、通常のドメイン名と同じ攻撃を受ける他の名前空間の識別子を作成します。彼らは以前に簡単に解決できなかったので、これは問題と見なされるかもしれないし、そうでないかもしれません。
Regular expressions should be checked for sanity, not blindly passed to something like PERL since arbitrary code can be included and subsequently processed.
任意のコードを含めて処理できるため、正規表現は正気をチェックする必要があります。
References
参考文献
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[4] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）解像度アプリケーション」、RFC 3404、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] Mealling、M。、「動的委任発見システム（DDDS）パート5：URI.ARPA割り当て手順」、RFC 3405、2002年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[7] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[8] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[9] Gulbrandsen、A.、Vixie、P。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、RFC 2782、2000年2月。
[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] Crocker、D。、「構文仕様のための拡張BNF：ABNF」、RFC 2234、1997年11月。
[11] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[11] Daniel、R。、「urn解像度でHTTPを使用するための些細な条約」、RFC 2169、1997年6月。
[12] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[12] IEEE、「情報技術のIEEE標準 - ポータブルオペレーティングシステムインターフェイス（POSIX） - パート2：シェルとユーティリティ（Vol。1）」、IEEE STD 1003.2-1992、1993年1月。
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[13] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[15] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[15] Sollins、K。、「均一なリソース名の解決の建築原理」、RFC 2276、1998年1月。
[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[16] Daniel、R。およびM. Mealling、「ドメイン名システムを使用した均一なリソース識別子の解像度」、RFC 2168、1997年6月。
[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[17] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[18] Faltstrom、P。、「E.164番号とDNS」、RFC 2916、2000年9月。
Author's Address
著者の連絡先
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling Verisign 21345 Ridgetop Circle Sterling、VA 20166 US
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。