[要約] RFC 2672は、DNSの非終端名のリダイレクションに関する仕様を定めたものであり、主な目的は、DNSクライアントがリダイレクションを処理できるようにすることです。
Network Working Group M. Crawford
Request for Comments: 2672 Fermilab
Category: Standards Track August 1999
Non-Terminal DNS Name Redirection
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. It differs from the CNAME record which maps a single node of the name space.
この文書では、別のドメインにDNSネームスペースのサブツリー全体をマッピングする機能を提供し、「DNAME」と呼ばれる新しいDNSリソースレコードを、定義されています。これは、名前空間の単一ノードをマップするCNAMEレコードとは異なります。
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 [KWORD].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【KWORD]に記載されているように解釈されます。
This Resource Record and its processing rules were conceived as a solution to the problem of maintaining address-to-name mappings in a context of network renumbering. Without the DNAME mechanism, an authoritative DNS server for the address-to-name mappings of some network must be reconfigured when that network is renumbered. With DNAME, the zone can be constructed so that it needs no modification when renumbered. DNAME can also be useful in other situations, such as when an organizational unit is renamed.
このリソースレコードとその処理規則は、ネットワークリナンバリングの文脈でアドレスから名前のマッピングを維持する問題に対する解決策として考案されました。そのネットワークを再番号付けされたときにDNAMEメカニズムがなければ、一部のネットワークのアドレスから名前のマッピングのための権威DNSサーバーを再設定する必要があります。再番号付けするとき、それは何の変更を必要としないようにDNAMEでは、ゾーンを構成することができます。 DNAMEはまた、組織単位の名前が変更された場合など、他の状況において有用であり得ます。
The DNAME RR has mnemonic DNAME and type code 39 (decimal).
DNAME RRはニーモニックDNAMEとタイプコード39（10進数）を有しています。
DNAME has the following format:
DNAMEの形式は次のとおりです。
<owner> <ttl> <class> DNAME <target>
<所有者> <TTL> <クラス> DNAME <目標>
The format is not class-sensitive. All fields are required. The RDATA field <target> is a <domain-name> [DNSIS].
フォーマットは、クラスと小文字が区別されません。全て必須項目です。 RDATAフィールド<対象>は、<ドメイン名> [DNSIS]です。
The DNAME RR causes type NS additional section processing.
DNAMEのRR原因はNS追加セクション処理を入力します。
The effect of the DNAME record is the substitution of the record's <target> for its <owner> as a suffix of a domain name. A "no-descendants" limitation governs the use of DNAMEs in a zone file:
DNAMEレコードの効果は、ドメイン名の接尾辞としての<所有者>のレコードの<対象>の置換です。 「非子孫」制限は、ゾーンファイル内DNAMEsの使用を支配します。
If a DNAME RR is present at a node N, there may be other data at N (except a CNAME or another DNAME), but there MUST be no data at any descendant of N. This restriction applies only to records of the same class as the DNAME record.
DNAME RRがノードNに存在する場合、（CNAMEまたは別のDNAME除く）Nにおける他のデータが存在してもよいが、この制限は、同じクラスとしてのレコードに適用されるNの任意の子孫でないデータがあってはなりませんDNAMEレコード。
This rule assures predictable results when a DNAME record is cached by a server which is not authoritative for the record's zone. It MUST be enforced when authoritative zone data is loaded. Together with the rules for DNS zone authority [DNSCLR] it implies that DNAME and NS records can only coexist at the top of a zone which has only one node.
DNAMEレコードがレコードのゾーンに対して権限のないサーバーによってキャッシュされている場合、このルールは、予測可能な結果を保証します。権威あるゾーンデータがロードされたときにそれが適用されなければなりません。一緒にDNSゾーン権限に関する規則[DNSCLR]とはDNAMEとNSレコードが1つのみのノードを有するゾーンの上部に共存できることを意味します。
The compression scheme of [DNSIS] MUST NOT be applied to the RDATA portion of a DNAME record unless the sending server has some way of knowing that the receiver understands the DNAME record format. Signalling such understanding is expected to be the subject of future DNS Extensions.
送信サーバは、受信機がDNAMEレコード形式を理解することを知っているいくつかの方法を持っていない限り[DNSIS]の圧縮方式は、DNAMEレコードのRDATA部分に適用してはいけません。シグナリングような理解は、将来のDNS拡張機能の対象となることが期待されます。
Naming loops can be created with DNAME records or a combination of DNAME and CNAME records, just as they can with CNAME records alone. Resolvers, including resolvers embedded in DNS servers, MUST limit the resources they devote to any query. Implementors should note, however, that fairly lengthy chains of DNAME records may be valid.
命名ループは、ちょうど彼らが一人でCNAMEレコードを持つことができますよう、DNAMEレコードまたはDNAMEとCNAMEレコードの組み合わせで作成することができます。 DNSサーバーに内蔵されたリゾルバを含むリゾルバは、それらが任意のクエリに専念リソースを制限しなければなりません。実装者は、DNAMEレコードのかなり長い鎖が有効であることを、しかし、注意してください。
To exploit the DNAME mechanism the name resolution algorithms [DNSCF] must be modified slightly for both servers and resolvers.
DNAME機構を利用する名前解決アルゴリズムは[DNSCF】サーバとレゾルバの両方のためにわずかに変更されなければなりません。
Both modified algorithms incorporate the operation of making a substitution on a name (either QNAME or SNAME) under control of a DNAME record. This operation will be referred to as "the DNAME substitution".
両方の修飾アルゴリズムは、名前（QNAME又はSNAMEいずれか）DNAMEレコードの制御下で置換を行う動作を組み込みます。この操作は、「DNAME置換」と呼ぶことにします。
For a server performing non-recursive service steps 3.c and 4 of section 4.3.2 [DNSCF] are changed to check for a DNAME record before checking for a wildcard ("*") label, and to return certain DNAME records from zone data and the cache.
セクション4.3.2の非再帰的なサービスステップ3.Cと4を実行するサーバーの場合は[DNSCF]は、ワイルドカード（「*」）のラベルをチェックする前にDNAMEレコードをチェックするために、ゾーンから特定のDNAMEレコードを返すように変更されていますデータキャッシュ。
DNS clients sending Extended DNS [EDNS0] queries with Version 0 or non-extended queries are presumed not to understand the semantics of the DNAME record, so a server which implements this specification, when answering a non-extended query, SHOULD synthesize a CNAME record for each DNAME record encountered during query processing to help the client reach the correct DNS data. The behavior of clients and servers under Extended DNS versions greater than 0 will be specified when those versions are defined.
バージョン0または非拡張クエリで拡張DNS [EDNS0]クエリを送信DNSクライアントは、非拡張クエリに答えるときに、この仕様を実装し、サーバが、CNAMEレコードを合成するべきで、DNAMEレコードの意味を理解していないと推定されますクエリ処理中に発生した各DNAMEレコードに対してクライアントが正しいDNSデータに到達するのに役立ちます。これらのバージョンが定義されている場合は0より大きく拡張DNSのバージョンの下でクライアントとサーバの動作が指定されます。
The synthesized CNAME RR, if provided, MUST have
合成されたCNAME RRは、提供されている場合、持っていなければなりません。
The same CLASS as the QCLASS of the query,
クエリのQCLASSと同じCLASS、
TTL equal to zero,
ゼロに等しいTTL、
An <owner> equal to the QNAME in effect at the moment the DNAME RR was encountered, and
DNAME RRが発生した時点で有効なQNAMEに等しい<所有者>、および
An RDATA field containing the new QNAME formed by the action of the DNAME substitution.
DNAME置換の作用によって形成された新しいQNAMEを含むRDATAフィールド。
If the server has the appropriate key on-line [DNSSEC, SECDYN], it MAY generate and return a SIG RR for the synthesized CNAME RR.
サーバーがオンライン[DNSSEC、SECDYN]適切なキーを持っている場合、それを合成CNAME RRのためのSIG RRを生成して返してもよいです。
The revised server algorithm is:
改訂されたサーバーのアルゴリズムは次のとおりです。
1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2.
1.設定またはネームサーバが再帰的なサービスを提供する意思があるかどうかに応じて対応して利用できる再帰の値をクリアします。再帰的なサービスは、クエリ内のRDビットを介して利用可能と要求された場合には、それ以外の場合は手順2、手順5に進みます。
2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4.
2. QNAMEに最も近い祖先であるゾーンの利用可能ゾーンを検索します。こうしたゾーンが見つかった場合、それ以外の場合は手順4、手順3に進みます。
3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node.
3.スタートゾーンで、ラベルで、ラベルを下に一致します。マッチング処理は、いくつかの方法を終了することができます。 QNAME全体が一致した場合、我々はノードを発見しました。
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME RR,
and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6.
それ以外の場合は、解答セクションにQTYPEに一致するすべてのRRをコピーして、手順6に進みます。
b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone.
B。マッチが正式なデータのうち、私たちを取るならば、我々は紹介しています。私たちは、ゾーンの底部に沿ってカットをマーキングNS RRを持つノードが発生した場合に発生します。
Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step 4.
返信の権限セクションにサブゾーンのNS RRをコピーします。アドレスは正式なデータまたはキャッシュから利用できない場合は、グルーRRを使用して、追加のセクションに用意されていどんなアドレス置きます。ステップ4に進みます。
c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see whether the last label matched has a DNAME record.
C。いくつかのラベルで、試合は（すなわち、対応するラベルが存在しない）ことは不可能である場合は、最後にマッチしたラベルがDNAMEレコードを持っているかどうかを調べます。
If a DNAME record exists at that point, copy that record into the answer section. If substitution of its <target> for its <owner> in QNAME would overflow the legal size for a <domain-name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise perform the substitution and continue. If the query was not extended [EDNS0] with a Version indicating understanding of the DNAME record, the server SHOULD synthesize a CNAME record as described above and include it in the answer section. Go back to step 1.
DNAMEレコードは、その時点で存在している場合は、解答セクションにそのレコードをコピーします。 QNAMEその<所有者>のために<対象>の置換は、<ドメイン名>の法的サイズをオーバーフローする場合、設定RCODEは[DNSUPD]と出口YXDOMAINします。それ以外の場合は置換を実行して続行します。クエリがDNAMEレコードの理解を示すバージョンと[EDNS0]拡張されなかった場合、サーバは、上述したようにCNAMEレコードを合成し、回答セクションに含めるべきです。ステップ1に戻ります。
If there was no DNAME record, look to see if the "*" label exists.
全くDNAMEレコードがなかった場合は、「*」ラベルが存在するかどうかを確認します。
If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit.
「*」ラベルが存在しない場合は、我々が探している名前は、我々が原因CNAMEに従っているクエリまたは名前の元のQNAMEであるかどうかを確認してください。名前がオリジナルである場合は、応答して終了して権限のあるネームエラーを設定します。それ以外の場合だけで終了。
If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6.
「*」ラベルが存在しない場合は、QTYPEに対するそのノードでのRRと一致します。任意の一致した場合、「*」のラベルを持つノードを解答セクションにコピーが、RRの所有者がQNAMEに設定し、そしてません。ステップ6に進みます。
4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. If QNAME is not found in the cache but a DNAME record is present at an ancestor of QNAME, copy that DNAME record into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6.
4.キャッシュにダウンマッチング開始します。 QNAMEがキャッシュ内で発見された場合、解答セクションにQTYPEと一致し、それに接続されているすべてのRRをコピーします。 QNAMEがキャッシュ内に見つからないが、DNAMEレコードはQNAMEの先祖である場合は、解答セクションにそのDNAMEレコードをコピーします。正式なデータからの代表団がなかった場合は、キャッシュから最適なものを探し、そして権威セクションにそれを置きます。ステップ6に進みます。
5. Use the local resolver or a copy of its algorithm (see resolver section of this memo) to answer the query. Store the results, including any intermediate CNAMEs and DNAMEs, in the answer section of the response.
5.クエリに答えるために（このメモのリゾルバのセクションを参照してください）ローカルリゾルバまたはそのアルゴリズムのコピーを使用してください。応答の回答セクションで、任意の中間のCNAMEとDNAMEsを含め、結果を保存します。
6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit.
6.のみ、クエリの追加セクションに有用であり得る他のRRを追加しようとローカルデータを使用します。出口。
Note that there will be at most one ancestor with a DNAME as described in step 4 unless some zone's data is in violation of the no-descendants limitation in section 3. An implementation might take advantage of this limitation by stopping the search of step 3c or step 4 when a DNAME record is encountered.
いくつかのゾーンのデータは、セクション3で無子孫の制限に違反しない限り実装はステップ3cの検索を停止することにより、この制限を利用するかもしれませんステップ4で説明したようにDNAMEと最大1人の祖先が存在するであろうことに注意してくださいまたはDNAMEレコードが検出されたステップ4。
A resolver or a server providing recursive service must be modified to treat a DNAME as somewhat analogous to a CNAME. The resolver algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d as 4.e and insert a new 4.d. The complete algorithm becomes:
再帰的なサービスを提供するリゾルバまたはサーバはCNAMEの幾分類似としてDNAMEを治療するように改変されなければなりません。 【DNSCF]セクション5.3.3のリゾルバアルゴリズムは4.eとしてステップ4.Dの番号を変更し、新しい4.d.を挿入するように改変されています完全なアルゴリズムは次のようになります。
1. See if the answer is in local information, and if so return it to the client.
1.答えはローカル情報であるかどうかを確認し、そして場合は、そう、それをクライアントに返します。
a. if the response answers the question or contains a name error, cache the data as well as returning it back to the client.
A。応答が質問に答えるか、名前の誤りが含まれている場合、クライアントに戻し、それを返すだけでなく、データをキャッシュします。
b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2.
B。応答が他のサーバーに優れた代表団が含まれている場合は、委任情報をキャッシュして、手順2に進みます。
c. if the response shows a CNAME and that is not the answer itself, cache the CNAME, change the SNAME to the canonical name in the CNAME RR and go to step 1.
C。応答がCNAMEを示し、それが答えそのものではない場合は、CNAMEをキャッシュCNAME RRでの正規名にSNAMEを変更し、1に進みます。
d. if the response shows a DNAME and that is not the answer itself, cache the DNAME. If substitution of the DNAME's <target> for its <owner> in the SNAME would overflow the legal size for a <domain-name>, return an implementation-dependent error to the application; otherwise perform the substitution and go to step 1.
D。応答がDNAMEを示し、それが答えそのものではない場合は、DNAMEをキャッシュします。 SNAMEでの<所有者>のためのDNAMEの<対象>の置換は、<ドメイン名>のための法的なサイズをオーバーフローする場合は、アプリケーションに実装依存のエラーを返します。それ以外の場合は置換を実行し、1に進みます。
e. if the response shows a server failure or other bizarre contents, delete the server from the SLIST and go back to step 3.
電子。応答は、サーバの障害やその他の奇妙な内容を示している場合、SLISTからサーバーを削除し、ステップ3に戻ります。
A resolver or recursive server which understands DNAME records but sends non-extended queries MUST augment step 4.c by deleting from the reply any CNAME records which have an <owner> which is a subdomain of the <owner> of any DNAME record in the response.
DNAMEレコードを理解するが、非拡張クエリーを送信リゾルバまたは再帰サーバは、応答から任意DNAMEレコードの<所有者>のサブドメインである<所有者>を有する任意のCNAMEレコードを削除することによって、ステップ4.Cを増強しなければなりません応答。
If an organization with domain name FROBOZZ.EXAMPLE became part of an organization with domain name ACME.EXAMPLE, it might ease transition by placing information such as this in its old zone.
ドメイン名FROBOZZ.EXAMPLEを持つ組織がドメイン名ACME.EXAMPLEを持つ組織の一部となった場合、それはその古いゾーンにこのような情報を配置することによって、移行を容易にすることがあります。
frobozz.example. DNAME frobozz-division.acme.example.
MX 10 mailhub.acme.example.
The response to an extended recursive query for www.frobozz.example would contain, in the answer section, the DNAME record shown above and the relevant RRs for www.frobozz-division.acme.example.
www.frobozz.exampleの拡張再帰クエリに対する応答は、回答セクションでは、上記示したDNAMEレコードとwww.frobozz-division.acme.exampleに関連するRRを含んでいるでしょう。
The classless scheme for in-addr.arpa delegation [INADDR] can be extended to prefixes shorter than 24 bits by use of the DNAME record. For example, the prefix 192.0.8.0/22 can be delegated by the following records.
in-addr.arpa委任のためのクラスレス方式は、[INADDR] DNAMEレコードを使用することによって24ビットより短いプレフィックスに拡張することができます。たとえば、接頭辞192.0.8.0/22は、以下のレコードにより委任することができます。
$ORIGIN 0.192.in-addr.arpa.
8/22 NS ns.slash-22-holder.example.
8 DNAME 8.8/22
9 DNAME 9.8/22
10 DNAME 10.8/22
11 DNAME 11.8/22
A typical entry in the resulting reverse zone for some host with address 192.0.9.33 might be
アドレス192.0.9.33といくつかのホストの結果として逆ゾーンでの典型的なエントリがあるかもしれません
$ORIGIN 8/22.0.192.in-addr.arpa.
33.9 PTR somehost.slash-22-holder.example.
The same advisory remarks concerning the choice of the "/" character apply here as in [INADDR].
「/」文字の選択に関する同じ顧問の発言は、[INADDR]のように、ここで適用されます。
If IPv4 network renumbering were common, maintenance of address space delegation could be simplified by using DNAME records instead of NS records to delegate.
IPv4ネットワークのリナンバリングが一般的であった場合は、アドレス空間の委任のメンテナンスは、委任するDNAMEレコードの代わりに、NSレコードを使用することによって単純化することができます。
$ORIGIN new-style.in-addr.arpa. 189.190 DNAME in-addr.example.net.
$ ORIGINのnew-style.in-addr.arpa。 189.190 DNAMEのin-addr.example.net。
$ORIGIN in-addr.example.net. 188 DNAME in-addr.customer.example.
$ ORIGINのin-addr.example.net。 188 DNAMEで-addr.customer.example。
$ORIGIN in-addr.customer.example. 1 PTR www.customer.example. 2 PTR mailhub.customer.example. ; etc ...
の$ ORIGINで-addr.customer.example。 1 PTRのwww.customer.example。 2 PTRのmailhub.customer.example。 ;等...
This would allow the address space 190.189.0.0/16 assigned to the ISP "example.net" to be changed without the necessity of altering the zone files describing the use of that space by the ISP and its customers.
これは、ISPおよびその顧客によってそのスペースの使用を記述したゾーンファイルを変更する必要なく変更することがISP「example.net」に割り当てられたアドレス空間190.189.0.0/16を可能にします。
Renumbering IPv4 networks is currently so arduous a task that updating the DNS is only a small part of the labor, so this scheme may have a low value. But it is hoped that in IPv6 the renumbering task will be quite different and the DNAME mechanism may play a useful part.
IPv4のネットワークをリナンバリングすると、現在DNSの更新は、労働のほんの一部であるように骨の折れる作業であるので、このスキームは、低い値を有することができます。しかし、IPv6にリナンバリング作業はかなり異なるものになることが期待されているとDNAMEメカニズムは、有用な部分を再生することができます。
This document defines a new DNS Resource Record type with the mnemonic DNAME and type code 39 (decimal). The naming/numbering space is defined in [DNSIS]. This name and number have already been registered with the IANA.
この文書では、ニーモニックDNAMEとタイプコード39（10進数）と新しいDNSリソースレコードのタイプを定義します。命名/ナンバリングスペースは、[DNSIS]で定義されています。この名前と番号は、すでにIANAに登録されています。
The DNAME record is similar to the CNAME record with regard to the consequences of insertion of a spoofed record into a DNS server or resolver, differing in that the DNAME's effect covers a whole subtree of the name space. The facilities of [DNSSEC] are available to authenticate this record type.
DNAMEレコードをDNAMEの効果は、ネームスペースのサブツリー全体をカバーすることで異なる、DNSサーバやリゾルバに偽装されたレコードの挿入の結果に関して、CNAMEレコードに似ています。 [DNSSEC]の施設は、このレコードタイプを認証するために利用されています。
[DNSCF] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
【DNSCF] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[DNSCLR]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月 "DNS仕様の明確化"。
[DNSIS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
【DNSIS] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[DNSSEC]イーストレイク、第三、D.およびC.カウフマン、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2065、1997年1月。
[DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[DNSUPD]いるVixie、P.、エド。、トムソン、S.、Rekhter、Y.、およびJ.は、バウンド "ドメインネームシステムの動的更新"、RFC 2136、1997年4月。
[EDNS0] Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[EDNS0]いるVixie、P.、 "DNS（EDNS0）のための拡張メカニズム"、RFC 2671、1999年8月。
[INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", RFC 2317, March 1998.
[INADDR] Eidnes、H.、デ・グルート、G.とP.いるVixie、 "クラスレスIN-ADDR.ARPA委任"、RFC 2317、1998年3月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[KWORD]ブラドナーの、S.、 "要件レベルを示すためのRFCsにおける使用のためのキーワード、" BCP 14、RFC 2119、1997年3月。
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[SECDYN] D.イーストレイクは、第三、RFC 2137、1997年4月、 "ドメインネームシステム動的な更新を固定します"。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
マット・クロフォードフェルミ研究所MS 368私書箱500バタビア、IL 60510 USA
Phone: +1 630 840-3461 EMail: crawdad@fnal.gov
電話：+1 630 840-3461 Eメール：crawdad@fnal.gov
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。