RFC3403 日本語訳
3403 Dynamic Delegation Discovery System (DDDS) Part Three: The DomainName System (DNS) Database. M. Mealling. October 2002. (Format: TXT=31058 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Mealling Request for Comments: 3403 VeriSign Obsoletes: 2915, 2168 October 2002 Category: Standards Track
コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 3403 ベリサインは以下を時代遅れにします。 2915、2168年2002年10月のカテゴリ: 標準化過程
Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
ダイナミックな委譲発見システム(DDDS)パートThree: ドメインネームシステム(DNS)データベース
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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).
このドキュメントは、Rulesの分散データベースとしてドメインネームシステム(DNS)を使用することでDynamic DelegationディスカバリーSystem(DDDS)データベースについて説明します。 キーズはドメイン名です、そして、Rulesは、Naming Authority Pointer(NAPTR)リソースRecord(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.
このドキュメントがRFC2915を時代遅れにするので、それはNAPTR DNS Resource Recordのための公式の仕様書です。 また、それはシリーズの一部です、すなわち、完全に指定されて、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS。」(RFC3401) 他のものを読まないでこのシリーズでどんなドキュメントも読んで、理解しているのが不可能であることに注意するのは非常に重要です。
Mealling Standards Track [Page 1] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[1ページ]RFC3403を荒びきにします。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 DDDSデータベース仕様. . . . . . . . . . . . . . . . 3 4。 レゾルバ/アプリケーション.74.3Master File Format. . . . . . . . . . . . . . . . . . . . . 7 5によるDNSサーバ. . . . . . . . 7 4.2.2Additionalセクション処理によるNAPTR RR Format. . . . . . . . . . . . . . . . . . . . . . 5 4.1Packet Format. . . . . . . . . . . . . . . . . . . . . . . 5 4.2Additional情報Processing. . . . . . . . . . . . . 7 4.2.1Additionalセクション処理。 アプリケーション仕様. . . . . . . . . . . . . . . . . 8 6。 例. . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1のつぼの例. . . . . . . . . . . . . . . . . . . . . . . . 8 6.2のE164の例. . . . . . . . . . . . . . . . . . . . . . . . 10 7。 DNS管理者. . . . . . . . . . . . . . . 10 8のためのアドバイス。 注意. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9。 IANA問題. . . . . . . . . . . . . . . . . . . . 11 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . 11参照. . . . . . . . . . . . . . . . . . . . . . . . . 12作者のアドレスの.13の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 14
1. Introduction
1. 序論
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.
Dynamic DelegationディスカバリーSystem(DDDS)はストリングの怠惰な結合をデータに実装するのに使用されます、ダイナミックに構成された委譲システムをサポートするために。DDDSは、DDDS Databaseの中に末期的状態に達するまで繰り返しにストリング変換規則を適用することによって保存されたデータに何らかのユニークなストリングを写像することによって、機能します。
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 Applicationを機能させるRulesにデータ・ストアとして使用される方法を述べます。 それはどんな特定用途や用法シナリオも指定しません。 ドキュメントのシリーズもの全巻は指定されて、「ダイナミックな委譲発見システム(DDDS)は1つを分ける」ということです。 「包括的なDDDS」(RFC3401)[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.
ここで指定されたNaming Authority Pointer(NAPTR)DNS Resource Record(RR)は元々、Uniform Resource Identifier(URI)の代表として派遣されたセクションをそれらを変えることができたような方法で分解して、時間がたつにつれて再代表として派遣することができるようにDNSで規則セットをコード化する方法としてURN作業部会によって生産されました。 結果はストリングをドメイン名に書き直すのにクライアントプログラムで使用される正規表現を含んでいたResource Recordでした。
Mealling Standards Track [Page 2] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[2ページ]RFC3403を荒びきにします。
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.
時間がたつにつれて、このプロセスは他のApplicationsとRule Databasesのために一般化されました。 このドキュメントは少しも特定のApplicationなしでこの特定のRules Databaseを利用する数個のApplicationsがすべて、あるかもしれないとRules Databaseを定義します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[6]で説明されるように本書では解釈されることであるべきですか?
All other terminology, especially capitalized terms, is taken from [3].
[3]から他のすべての用語(特に大文字で書かれた用語)を取ります。
3. DDDS Database Specification
3. DDDSデータベース仕様
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も一連のコード・ポイントとして代替式への入力か出力のどちらかがUTF-8にASCII/ユニコードの等価性の外にコード・ポイントを含む場合で解釈されるのを保証するために注意しなければなりません。 これは、POSIX Extended Regular Expressionsの国際化している特徴が彼らの意図しているコード・ポイントに合うことができるのを保証するためのものです。 代替式はこれで一般に適切になる彼らの能力を発射するでしょう、したがって、それらが特定の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リソース記録には、それらに関連しているTime To Live(TTL)があります。 記録が検索されて以来秒数が終わっているとき、記録はもう有効ではありません、そして、新しい記録を検索するのに新しい質問を使用しなければなりません。 したがって、DDDS Algorithmで言及されるように、ケースが与えられたRuleが期限が切れるところにあることができます。 アプリケーションがRules(何らかの悪い委譲経路の場合、ネットワークまたはサーバ失敗における)の以前に検索されたセットへ後ろへ下がるのを試みる場合では、アプリケーションは、それが当てにしている記録のいずれも期限が切れていないのを確実にしなければなりません。 ただ一つの記録さえ期限が切れた場合では、アプリケーションが、アルゴリズムの始めにやり直すのに必要です。
Mealling Standards Track [Page 3] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[3ページ]RFC3403を荒びきにします。
Key Format: A Key is a validly constructed DNS domain-name.
主要な形式: Keyは確実に組み立てられた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.
ルックアップ要求: 与えられたKeyのために1セットの規則を要求するために、クライアントは要求を出します、標準のDNS規則に従って、与えられたドメイン名のためのNAPTR Resource Recordsのために。
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.
ルックアップ応答: 与えられたKey(ドメイン名)を求める要求への応答は一連のNAPTR記録になるでしょう。 セクション4でNAPTR Resource Recordの形式を見つけることができます。
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ゾーンに新しい記録を追加することによって、挿入されます。 Ruleが特定のゾーンに存在するKeyを生産するなら、そのゾーンの運営管理コントロールを持っている実体だけがそのKeyに関連しているRuleを指定できます。
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:
衝突回避用レーダー警報装置: 2ApplicationsがこのDatabase(実際にENUMとURI Resolution Applicationsがあるケース、セクション6.2である)を使用するかもしれない場合には、規則の間の衝突の見込みが2つのNAPTR記録が同じドメインに現れますが、それらが1Applicationに適用するところにあります。 衝突を避ける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 Resolution記録がurires.example.comの下に存在しているでしょう、そして、enum.example.comの下にすべてのENUM記録があるでしょう。 これが管理欠如のために上流の委譲の上で可能でない場合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.
* Application Uniqueストリングをいかなる他のもそれのあいまいさを除くことができるくらい含むように、正規表現を書いてください。 例えば、URI Resolution Applicationは、正規表現マッチをその体系に据えつけるのに左側で体系名を使用できるでしょう。 その同じゾーンでのENUMの特定の記録はあらゆるアプリケーションのユニークなストリングの始めに、あるようにENUMによって定義される「+」キャラクタとのマッチの左側を据えつけることができるでしょう。 このように、与えられたApplication Unique Stringは両方ではなく、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.
* 2Applicationが異なったFlagsかServices値を使用すると、それが問題のServices/旗に適用されないので、別のApplicationからの記録は無視されるでしょう。
Mealling Standards Track [Page 4] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[4ページ]RFC3403を荒びきにします。
4. NAPTR RR Format
4. NAPTR RR形式
4.1 Packet Format
4.1 パケット・フォーマット
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 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAPTR記録のためのパケット・フォーマットが以下の通りの1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5である、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| オーダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 好み| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / FLAGS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / SERVICES / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REGEXP / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REPLACEMENT / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
<character-string> and <domain-name> as used here are defined in RFC 1035 [7].
<文字列>とここで使用される<ドメイン名>はRFC1035[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.
ORDER A、正確にRulesの規則正しいリストを表すためにNAPTRが記録するオーダーを指定する16ビットの符号のない整数を処理しなければなりません。 最も低いのから最も高くなるまで注文があります。 2つの記録に同じオーダー値があるなら、それらは、同じ規則であると考えられて、値とServicesが提供したPreferenceの組み合わせに基づいて選択されるべきです。
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.
PREFERENCE Although、それはDNS用語を重んじて「好み」と呼ばれて、この分野はDDDS AlgorithmのPriority値に同等です。 等しいOrderと共にどのNAPTR記録でオーダーを指定する16ビットの符号のない整数が以前処理される処理されて、下位の数が大きい数であったならSHOULDを評価するということです。 これは、MX記録の選択領域と同様であり、ドメイン管理者が、よりできるホストか、より軽い重さのプロトコルにクライアントを向けることができるように、使用されています。 それにそれほど何らかのプロトコルかサービスをよくサポートしないのなどようにそうする十分な理由があるなら、クライアントは、より高い好みの値がある記録を見るかもしれません。
Mealling Standards Track [Page 5] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[5ページ]RFC3403を荒びきにします。
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.
OrderとPreferenceの重要な違いはマッチがいったん見つけられるとクライアントが異なったOrderがある記録を考えてはいけませんが、彼らが同じOrderにもかかわらず、異なったPreferencesと共に記録を処理するかもしれないということです。 クライアントがアルゴリズムでステップ3と4の間の、より複雑なService決断を使用するのを許容することに関してこれへの唯一の例外がDDDSアルゴリズム仕様に基づく第2重要なNoteに述べられます。 好みは与えるのにおいて使用されています。権威見地から同じように考えられる規則により高いサービスの質を伝えますが、簡単なロードバランシング見地からコミュニケートするというわけではなくなってください。
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<文字列>含有は、書き直しの局面と記録における、分野の解釈を制御するために弛みます。 旗はセット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.
この分野でFlagsを定義するのは、それがどうこのDatabaseを使用しているかを指定するApplication次第です。 それはどれが端末であるか、そして、どれが端末でないかを定義しなければなりません。
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<はこれに適切なService Parametersを指定する>をキャラクタで結びます。この委譲経路。 この野原で発見される値を指定するのは、Application Specification次第です。
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 Algorithm仕様を見てください。
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書き直しで生産されたいずれのドメイン名にも述べないので。 後者は使用目的によっては誘惑していますが、経験は、そのような使用は欠点非常に敏感で、誤り非常に傾向があって、デバッグするのが非常に難しいのを示しました。
Mealling Standards Track [Page 6] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[6ページ]RFC3403を荒びきにします。
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.
旗の野原で発見される潜在的価値に依存するために質問する次のドメイン名である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 AlgorithmにSubstitution Expressionを作ります。 単に、特にこれがさばくDNS圧縮のための歴史的な最適化が存在しているということです。 また、分野も互いに唯一です。 両方の分野への値を持っている記録を返すなら、間違っているとそれを考えました、そして、無視されて、SHOULDはそうか誤りが戻りました。
4.2 Additional Information Processing
4.2 追加情報処理
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サーバを必要とします、その結果、アプリケーションが、追加情報部で関連記録を見ると予想できる前にそれは何年もかかるでしょう。
4.2.1 Additional Section Processing by DNS Servers
4.2.1 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サーバは、答えに関連している追加情報部にRRsetsを追加して、答え部にデータと同じ信憑性を持っているかもしれません。 一般にこれはAとSRV記録で作られるでしょうが、正確な記録はアプリケーションによります。
4.2.2 Additional Section Processing by Resolver/Applications
4.2.2 レゾルバ/アプリケーションによる追加セクション処理
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.
アプリケーションは関連記録のためにAdditional情報部を点検するかもしれませんが、クライアントが機能するように、Applicationsは、どんなタイプに関する記録もどんなDNS応答のAdditional情報部でそうであることも必要としてはいけません。 すべてのApplicationsは応答のAdditional情報部分に決して記入しないネームサーバからの取り扱い応答ができなければなりません。
4.3 Master File Format
4.3 基本ファイル形式
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の整数になるでしょう。 Flags、Services、およびRegexp分野はすべてが<文字列>sを引用したということです。 以来、Regexp分野は、多数のバックスラッシュを含むことができて、その結果、慎重に扱われるべきです。 正しく正規表現にセクション7を見て、入って、どう逃げてくださいか。
Mealling Standards Track [Page 7] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[7ページ]RFC3403を荒びきにします。
5. Application Specifications
5. アプリケーション仕様
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 DatabaseはDDDSアルゴリズムを利用するどんなアプリケーションでも使用可能です。 また、DDDS Applicationを指定しなければならなかった項目に加えて、このDatabaseを使用したがっているアプリケーションは以下の値を定義しなければなりません:
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 First Well Known Ruleによって生産されるKeyはどんなドメインに属しますか? どんなアプリケーションも、規則がこのDatabaseを利用する別のアプリケーションで使用される規則に衝突しないのを確実にしなければなりません。 例えば、'foo'アプリケーションで、'foo.net'ゾーンでFirst Well Knownキーズのすべてを見つけるかもしれません。
o What the allowed values for the Services and Protocols fields are.
o Servicesとプロトコル分野への許容値は何ですか?
o What the expected output is of the terminal rewrite rule in addition to how the Flags are actually encoded and utilized.
o Flagsが実際にコード化されて、どう利用されるかに加えて予想された出力が何であるかという端末の書き直しのことであることは統治されます。
6. Examples
6. 例
6.1 URN Example
6.1 つぼの例
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記録は元々、使用のためにUniform Resource Name(URN)レゾルバディスカバリーService(RDS)[15]で作成されました。 この例は特定のURNがURNに関する質問に答えることができるレゾルバサービスを見つけるのにどうNAPTR記録を使用するだろうかを詳しく述べます。 このApplicationに、決定的な仕様のための[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-イドに基づくURN名前空間を考えてください(これが非常に仮定しているので、これを当てにしないでください、)。 URNはこれに似るかもしれません:
urn:cid:199606121851.1@bar.example.com
つぼ: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:
このApplicationのFirst Well Known Ruleは1番目と2番目のコロンの間にキャラクタを抽出することになっています。 このURNに関しては、それは'Cid'でしょう。 また、Applicationは、ストリング'urn.arpa'がDatabase有効なKeyを造るためにFirst Well Known Ruleの結果に追加されるべきであると指定します。 結果は'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。 ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
Mealling Standards Track [Page 8] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[8ページ]RFC3403を荒びきにします。
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分野に提供されたパターンは使用されています。 私たちはそれが合っているかどうかを見る全体のURNにそのregexpを適用します。(それはURNをします)。 代替式の2円の部分がストリング"example.com"を返します。 旗以来、分野は人影がありません、そして、ルックアップは端末ではありません、そして、DNSへの私たちの次の徹底的調査は、より多くのNAPTR記録のために新しいドメインが'example.com'であるところにあります。
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。 ;; オーダーprefがサービスregexp交換IN NAPTR100 50“a"「z3950+N2L+N2C」に旗を揚げさせる、「「cidserver.example.com。」 IN NAPTR100 50“a"「rcds+N2C」、「「cidserver.example.com。」 IN NAPTR100 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.
例を続行して、クライアントが自由にどんな記録も選ぶことができるように、注文と選択領域の値がすべての記録において等しいことに注意してください。 Applicationは、書き直しの出力が端末のルックアップと、ドメイン名になることをA記録が質問されるべきである意味するために旗の'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円使用したリコール、および\、リテラルを合わせる、'.'ドメイン名コンポーネントを切り離しているキャラクタ。 '\'が拡張文字であるので、別のバックスラッシュでバックスラッシュの文字通りの発生から逃げなければなりません。 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".
Mealling Standards Track [Page 9] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[9ページ]RFC3403を荒びきにします。
6.2 E164 Example
6.2 164Eの例
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 ApplicationのためのApplication Unique Stringはダッシュを取り除いているE.164電話番号です。 First Well Known Ruleは電話番号からすべてのキャラクタを外して、次に、最初のKeyとして全体の数を使用することになっています。 「例えば、E.164番号として表された電話番号「770-555-1212」は」 +1が770-555-1212であるならそうするでしょうに。」 Keyに変換されて、それは「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 Applicationは現在のところ、このDatabaseを使用するだけです。 このDatabaseに、有効なフォームに最初のKeyを変換するために各ケタの間に期間を挿入して、全体のKeyが逆さであり、次に、終わりまで"e164.arpa"を追加するのは指定します。 そして、上の電話番号は"2.1.2.1.5.5.5.0.7.7.1.e164.arpa"を読むでしょう。 そして、このドメイン名は、NAPTRが記録するようにRewrite Rulesを検索するのに使用されます。
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" .
$発生源2.1.2.1.5.5.5.0.7.7.1.e164.arpa。 $!一口: 「IN NAPTR100 10「u」「一口+E2U!」」 ^* information@foo.se!i 、$!mailto: 」 . IN NAPTR102 10「」 u「smtp+E2U!」」 ^* 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'旗を使用します。 この旗はRuleが端末であり、出力がその電話サービスに連絡するのに必要である情報を含むURIであると述べます。 また、ENUMはService Parametersに同じ形式を使用します。 これらは、その電話のサービスにアクセスするのに使用される利用可能なプロトコルがSession InitiationプロトコルかSMTPメールであると述べます。
7. Advice for DNS Administrators
7. DNS管理者のためのアドバイス
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との以前に言及された相互作用があります。 質問応答に一度現れるように二度regexpのどんなバックスラッシュもゾーンファイルに入力しなければなりません。 より真剣に、二重バックスラッシュの必要性はたぶんDNSサーバのすべての作成者によってテストされていません。
Mealling Standards Track [Page 10] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[10ページ]RFC3403を荒びきにします。
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仕様では、デリミタであることになっています。 したがって、例えば、正規表現の最初のキャラクタが感嘆符('!')であるなら、通常、より少ないバックスラッシュで正規表現を書くことができます。
8. Notes
8. 注意
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記録を処理しなければならなくて、それは知られているService Parameter組み合わせを提供する最初の記録を絶対に使用してはいけません。
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.
複数のRRsに同じ「オーダー」と他のすべての等しい評価基準があるとき、クライアントは次の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.
書き直しの後のルックアップが失敗するなら、クライアントが他の書き直し経路を追求しない裏刷よりむしろことを報告するよう強く奨励されます。
9. IANA Considerations
9. IANA問題
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.
ServicesとFlags分野への値はこのDDDS Databaseを利用するApplicationによって決定されるでしょう。 それらの値は、登録メカニズムを必要として、その結果、いくつかのIANAリソースを必要とするかもしれません。 それ自体でこの仕様はそうしません。
10. Security Considerations
10. セキュリティ問題
The NAPTR record, like any other DNS record, can be signed and validated according to the procedures specified in DNSSEC.
いかなる他のDNS記録のようにも、DNSSECで指定された手順によると、NAPTR記録に署名して、有効にすることができます。
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.
このDatabaseは正常なドメイン名と同じ攻撃を条件として他の名前空間から識別子を作ります。 それらが以前容易に溶解性でない時から、これは問題であると考えられるかもしれません。
Regular expressions should be checked for sanity, not blindly passed to something like PERL since arbitrary code can be included and subsequently processed.
盲目的に何かPerlのようなものに通過されるのではなく、正規表現は、勝手な規準を含んでいて、次に処理できるので、正気がないかどうかチェックされるべきです。
Mealling Standards Track [Page 11] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[11ページ]RFC3403を荒びきにします。
References
参照
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[4] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)解決アプリケーション」、RFC3404、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、RFC3405、2002年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[7]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[8]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[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」、RFC2782、2000年2月。
[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] クロッカー、D.、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[11] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[11] ダニエル、R.、「つぼの解決にHTTPを使用するための些細なコンベンション」、RFC2169、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、「情報技術--携帯用のオペレーティングシステムインタフェース(POSIX)--第2部のIEEE規格:」 「シェルとユーティリティ(Vol.1)」、IEEE Std1003.2-1992、1月1993日
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[13]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
Mealling Standards Track [Page 12] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[12ページ]RFC3403を荒びきにします。
[15] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[15]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。
[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[16] ダニエルとR.とM.食事、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、RFC2168、1997年6月。
[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[17]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[18]Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日
Author's Address
作者のアドレス
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル
EMail: michael@neonym.net URI: http://www.verisignlabs.com
メール: michael@neonym.net ユリ: http://www.verisignlabs.com
Mealling Standards Track [Page 13] RFC 3403 DDDS DNS Database October 2002
DDDS DNSデータベース2002年10月に標準化過程[13ページ]RFC3403を荒びきにします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Mealling Standards Track [Page 14]
標準化過程を荒びきにします。[14ページ]
一覧
スポンサーリンク