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
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.
著作権（C）インターネット協会（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リソースレコードのための公式の仕様です。 （RFC 3401）：それはまた、完全に「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されているシリーズの一部です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
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）は、動的に構成された委任システムをサポートするために、データへの文字列の遅延結合を実装するために使用されます。 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.
この文書では、ドメインネームシステム（DNS）はDDDSアプリケーションを機能させるルールのデータストアとして使用される方法を説明します。これは、任意の特定のアプリケーションや使用シナリオが指定されていません。文書の全シリーズは、「ダイナミックな委譲発見システム（DDDS）第一部：総合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）は、もともと統一資源識別子（URI）の委任セクションはで分解することができるようにDNSにルールセットを符号化する方法として、URNワーキンググループによって作成されました彼らは時間の経過とともに変化し、再委任することができたよう。結果は、ドメイン名に文字列を書き換えるために、クライアントプログラムによって使用される正規表現が含まれてリソースレコードでした。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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].
一般的な説明：このデータベースに指定されているドメインネームシステム（DNS）を使用し、[8]、[7]。
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コード一連の点として解釈され、UTF-8でASCII / Unicodeの同等の外のコードポイントが含まれている場合には、それを確実にするために注意を払わなければなりません代わりの一連のバイトとして。これは、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の解決アプリケーションは、そのスキームに正規表現マッチを固定するために左側にスキーム名を使用することができるだろう。その同じゾーン内のENUM特定のレコードは、すべてのアプリケーション固有文字列の先頭であることをENUMによって定義される「+」の文字との一致の左側を固定することができるだろう。この方法では、与えられたアプリケーション固有文字列は、1つまたは他のレコードではなく、両方を一致させることができます。
* 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].
<文字列>と<ドメイン名>を、ここで使用されるようには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アルゴリズム仕様の第二の重要な注意事項に留意されたいです。好みはなく、単純な負荷分散の観点から、当局の観点から同じことを考えられているルールへのサービスの高品質を伝える与えるために使用されます。
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.
FLAGS <文字列>レコード内のフィールドの書き換えや解釈の側面を制御するためのフラグを含みます。フラグはセット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.
SERVICES A <文字列>この委任パスこれに該当するサービスパラメータを指定します。これは、この分野で見つかった値を指定するには、アプリケーションの仕様次第です。
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アルゴリズムで述べたように、正規表現は累積的な方法で使用してはいけません、つまり、彼らは決して以前のNAPTR書き換えによって生成ドメイン名に、クライアントによって保持された元の文字列に適用されるべきです。後者は、いくつかのアプリケーションでは魅力的ですが、経験は非常に敏感で、非常に誤差が生じやすい、およびデバッグすることが極めて困難と障害するような使用を示しています。
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.
flagsフィールドで見つかったポテンシャル値に応じて照会する次のドメイン名であるREPLACEMENT 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の圧縮のため、具体的、歴史的な最適化です。フィールドも、相互に排他的です。レコードが両方のフィールドに値を持っていることが返された場合、誤りであるとみなされ、無視されたり、エラーが返されるべきである（SHOULD）のいずれか。
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サーバは、答えに関連する追加情報セクションにRRセットを追加し、回答セクション内のデータと同一の信憑性を持っているかもしれません。一般的に、これは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の整数でなければなりません。正規表現のフィールドは、このように多数のバックスラッシュを含めることができますので、注意して扱われるべきです。正しく入力して、正規表現をエスケープする方法については、セクション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（Uniform Resource Name）のレゾルバ発見サービス（RDS）[15]で使用するために作成されました。この例では、特定のURNは、URNについての質問に答えることができるリゾルバサービスを見つけるために、NAPTRレコードを使用する方法について説明します。このアプリケーションのための決定的な仕様のために[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
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:
このアプリケーション初のウェルノウンルールは、最初と2番目のコロンの間の文字を抽出することです。 「CID」だろう。このURNのために。アプリケーションは、データベース・有効なキーを構築するために、文字列「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。 ;; "2 \ $（*）。+ @ I！（[^ \。] + \。）：：CID。！^ URN！" "" "" 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つのレコードのみが存在するので、回答を注文することは問題ではありません。予備フィールドが空であるので、正規表現フィールドに設けられたパターンが使用されます。私たちは、それはそれがないている、一致するかどうかを確認するために全体のURNにその正規表現を適用します。代入式の\ 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からの完全なドメイン名を抽出しないことに注意してください。このような「バー」などのすべてのホストが、非常に独自の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における県旗サービス正規表現の交換 "" "z3950 + N2L + N2C" "" cidserver.example.comを注文します。 NAPTR 100 50 IN "" "RCDS + N2C" "" cidserver.example.com。 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レコードを照会する必要のあるドメイン名になることフラグを定義します。そのプロトコルを経由して利用可能なホスト、そのIPアドレス、プロトコル、およびサービス：クライアントはそれを行っていると、それは次のような情報を持っています。情報のこれらのビットを考えると、クライアントはそのサーバーに連絡し、それをURNについての質問をすることができるように十分なされています。
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".
正規表現は、CIDからドメイン名を抽出するために、\ 2を使用し、\ことを思い出してください。リテラルのマッチングのための「」ドメイン名の成分を分離する文字。 「\」のエスケープ文字であるので、バックスラッシュのリテラルの出現は、別のバックスラッシュでエスケープする必要があります。上記cid.urn.arpaレコードの場合には、正規表現は、「あるべきマスターファイルに入力^ URN：！CID：。+ @（[^ \\] + \\。）$（*。） ！\\ 2！私」。クライアントコードは、実際にレコードを受信すると、パターンはに変換されています "！：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におけるENUMワーキンググループは、電話番号が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.
現時点でENUMアプリケーションは、このデータベースを使用しています。これは、期間は、各桁の間に挿入され、このデータベースの有効な形態への最初のキーを変換するために、キー全体が反転され、次いで「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.0.7.7.1.e164.arpa。 10 NAPTR 100内の "U" "SIP + E2U" "^ * $一口：！。！！information@foo.se I"。 NAPTR 102 10 "U" "SMTP + E2U" IN "^ * $の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解決両方[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と前述の相互作用があります。正規表現でバックスラッシュは、クエリ応答に一度出現するために、ゾーンファイルに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.
正規表現は、任意のコードが含まれ、その後に処理することができますので、やみくもにPERLのようなものに渡されていない、正気をチェックする必要があります。
References
リファレンス
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling、M.、 "ダイナミックな委譲発見システム（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.、 "ダイナミックな委譲発見システム（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）第四部：統一資源識別子（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）パートファイブ：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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.及びL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10]クロッカー、D.、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[11] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[11]ダニエル、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：シェルとユーティリティ（第1巻）"、IEEE規格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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 2396、1998年8月。
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14]堀、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]ダニエル、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
マイケル・メオーリングベリサイン21345 Ridgetopサークルスターリング、バージニア州20166米国
EMail: michael@neonym.net URI: http://www.verisignlabs.com
電子メール：michael@neonym.net URI：http://www.verisignlabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。