Network Working Group D. Eastlake
Request for Comments: 2540 IBM
Category: Experimental March 1999
Detached Domain Name System (DNS) Information
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet.
標準フォーマットを取り外しDNS情報を表すために定義されます。これは、アーカイブコンテキストやインターネットに接続されていない状況で、セキュリティ情報など、ドメインネームシステム（DNS）から取得した情報を格納するための使用であることが予想されます。
Table of Contents
目次
Abstract...................................................1
1. Introduction............................................1
2. General Format..........................................2
2.1 Binary Format..........................................3
2.2. Text Format...........................................4
3. Usage Example...........................................4
4. IANA Considerations.....................................4
5. Security Considerations.................................4
References.................................................5
Author's Address...........................................5
Full Copyright Statement...................................6
The Domain Name System (DNS) is a replicated hierarchical distributed database system [RFC 1034, 1035] that can provide highly available service. It provides the operational basis for Internet host name to address translation, automatic SMTP mail routing, and other basic Internet functions. The DNS has been extended as described in [RFC 2535] to permit the general storage of public cryptographic keys in the DNS and to enable the authentication of information retrieved from the DNS though digital signatures.
ドメインネームシステム（DNS）は、高可用性サービスを提供することができる複製階層型分散データベースシステム[RFC 1034、1035]です。これは、アドレス変換、自動SMTPメールルーティング、およびその他の基本的なインターネット機能にインターネットホスト名の運用基盤を提供します。 [RFC 2535]に記載されているようにDNSがDNSに公開暗号鍵の一般的な保管を可能にするために、デジタル署名しかしDNSから取得した情報の認証を可能にするために拡張されています。
The DNS was not originally designed for storage of information outside of the active zones and authoritative master files that are part of the connected DNS. However there may be cases where this is useful, particularly in connection with archived security information.
DNSは本来、アクティブゾーンと接続されているDNSの一部である権威あるマスターファイルの外に情報を格納するために設計されていませんでした。しかし、特にアーカイブされたセキュリティ情報に関連して、これが有用である場合もあります。
The formats used for detached Domain Name System (DNS) information are similar to those used for connected DNS information. The primary difference is that elements of the connected DNS system (unless they are an authoritative server for the zone containing the information) are required to count down the Time To Live (TTL) associated with each DNS Resource Record (RR) and discard them (possibly fetching a fresh copy) when the TTL reaches zero. In contrast to this, detached information may be stored in a off-line file, where it can not be updated, and perhaps used to authenticate historic data or it might be received via non-DNS protocols long after it was retrieved from the DNS. Therefore, it is not practical to count down detached DNS information TTL and it may be necessary to keep the data beyond the point where the TTL (which is defined as an unsigned field) would underflow. To preserve information as to the freshness of this detached data, it is accompanied by its retrieval time.
剥離ドメインネームシステム（DNS）情報のために使用されるフォーマットは、接続されたDNS情報のために使用されるものと同様です。主な違いは、（接続されているDNSシステムの要素は（それらが情報を含むゾーンに対して権限サーバでない限り）各DNSリソースレコード（RR）に関連付けられた生存時間（TTL）をカウントダウンし、それらを廃棄するために必要とされることですTTLがゼロに達したときに、おそらく）新しいコピーをフェッチします。これとは対照的に、独立した情報は、それが更新され、おそらく歴史的データを認証するために使用されるか、またはそれをDNSから取得したずっと後の非DNSプロトコルを介して受信されるかもしれないことができないオフラインファイルに格納することができます。したがって、剥離DNS情報TTLをカウントダウンすることは現実的ではない、（符号なしフィールドとして定義されている）TTLがアンダーフローになる点を越えてデータを保持する必要があるかもしれません。このデタッチされたデータの鮮度に関する情報を保存するために、それは、その検索時間を伴います。
Whatever retrieves the information from the DNS must associate this retrieval time with it. The retrieval time remains fixed thereafter. When the current time minus the retrieval time exceeds the TTL for any particular detached RR, it is no longer a valid copy within the normal connected DNS scheme. This may make it invalid in context for some detached purposes as well. If the RR is a SIG (signature) RR it also has an expiration time. Regardless of the TTL, it and any RRs it signs can not be considered authenticated after the signature expiration time.
どのようにそれで、この検索時間を関連付ける必要がありますDNSから情報を取得します。検索時間は、その後、固定されたままです。現在時刻マイナス検索時間は、任意の特定の剥離RRのTTLを超えた場合、それはもはや正常に接続DNSスキーム内で有効なコピーではありません。これは、同様に、いくつかの独立した目的のコンテキストでは無効にすることがあります。 RRはSIG（署名）RRである場合、それはまた有効期限を有しています。かかわらず、TTLの、それそれが署名任意のRRは、署名の有効期限後に認証考えることはできません。
The standard binary format for detached DNS information is as follows:
次のように取り外しDNS情報のための標準的なバイナリ形式です。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first retrieval time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| next retrieval time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hex 20 |
+-+-+-+-+-+-+-+-+
Retrieval time - the time that the immediately following information was obtained from the connected DNS system. It is an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds, in network (big-endian) order. Note that this time can not be before the initial proposal of this standard. Therefore, the initial byte of an actual retrieval time, considered as a 32 bit unsigned quantity, would always be larger than 20 hex. The end of detached DNS information is indicated by a "retrieval time" field initial byte equal to 0x20. Use of a "retrieval time" field with a leading unsigned byte of zero indicates a 64 bit (actually 8 leading zero bits plus a 56 bit quantity). This 64 bit format will be required when retrieval time is larger than 0xFFFFFFFF, which is some time in the year 2106. The meaning of retrieval times with an initial byte between 0x01 and 0x1F is reserved (see section 5). Retrieval times will not generally be 32 bit aligned with respect to each other due to the variable length nature of RRs.
検索時間 - 直後の情報は、接続されたDNSシステムから得られた時刻。これは、1970年1月1日、GMT、うるう秒を無視して、ネットワーク内（ビッグエンディアン）オーダーの開始からの秒の符号なしの数です。今回は、この標準の最初の提案の前にすることはできないことに注意してください。したがって、32ビットの符号なし数と考え、実際の検索時間の最初のバイトは、常に20進よりも大きいであろう。取り外しDNS情報の端部は0x20に等しい「検索時間」フィールド最初のバイトで示されています。ゼロの主要符号なしバイトと「検索時間」フィールドの使用は、64ビット（実際には8先行ゼロビットと56ビットの量）を示しています。検索時間は、年が0x01と0x1Fの間の最初のバイトと検索時間の意味が予約されている2106でいくつかの時間で0xFFFFFFFFを、よりも大きい場合、この64ビットフォーマットが必要とされるであろう（セクション5を参照）。検索時間は、一般に32ビットが原因RRの可変長性質に互いに対して整列していないであろう。
RR count - an unsigned integer number (with bytes in network order) of following resource records retrieved at the preceding retrieval time.
RRカウント - 先行検索時に検索されたリソースレコードを、次の（ネットワーク順のバイトを有する）の符号なし整数を。
Resource Records - the actual data which is in the same format as if it were being transmitted in a DNS response. In particular, name compression via pointers is permitted with the origin at the beginning of the particular detached information data section, just after the RR count.
リソースレコード - それはDNS応答で送信されたかのように同じ形式である実際のデータ。具体的には、ポインタを介して、名前圧縮はちょうどRRカウントした後、特定の一戸建て情報データセクションの開始時を原点とする許可されています。
The standard text format for detached DNS information is as prescribed for zone master files [RFC 1035] except that the $INCLUDE control entry is prohibited and the new $DATE entry is required (unless the information set is empty). $DATE is followed by the date and time that the following information was obtained from the DNS system as described for retrieval time in section 2.1 above. It is in the text format YYYYMMDDHHMMSS where YYYY is the year (which may be more than four digits to cover years after 9999), the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). Thus a $DATE must appear before the first RR and at every change in retrieval time through the detached information.
ゾーンマスタファイル用に規定されるように切り離されたDNS情報の標準的なテキスト形式は、[RFC 1035] $が制御エントリが含まれていることを除いて禁止されていると（情報セットが空でない限り）新しい$ DATEエントリが必要です。 $日付は、上記セクション2.1に検索時間について記載したように、以下の情報は、DNSシステムから取得された日付と時刻が続きます。それは、YYYYは年テキスト形式YYYYMMDDHHMMSSである（9999年後をカバーするために4桁以上であってよい）、最初のMMは月番号（01-12）、DDは月の日です（01-です31）、HHは24時間表記（00-23）で時間で、第二のMMは分（00-59）であり、SSは秒（00-59）です。したがって、$日は最初のRR前と取り外した情報を通じて検索時間内のすべての変更時に表示される必要があります。
A document might be authenticated by a key retrieved from the DNS in a KEY resource record (RR). To later prove the authenticity of this document, it would be desirable to preserve the KEY RR for that public key, the SIG RR signing that KEY RR, the KEY RR for the key used to authenticate that SIG, and so on through SIG and KEY RRs until a well known trusted key is reached, perhaps the key for the DNS root or some third party authentication service. (In some cases these KEY RRs will actually be sets of KEY RRs with the same owner and class because SIGs actually sign such record sets.)
文書には、KEYリソースレコード（RR）にDNSから取得したキーによって認証される可能性があります。後でこの文書の真正性を証明するために、その公開鍵のKEY RRを維持することが望ましいであろう、SIG RRはそのKEY RR、SIGなどSIGとKEYていることを認証するために使用するキーのKEY RRを署名よく知られている信頼できるキーまでのRRは、DNSルートまたは一部のサードパーティの認証サービスのために、おそらくキーに達しています。 （のSIGは、実際にそのようなレコードセットに署名するため、いくつかの場合において、これらのKEY RRは実際には同じ所有者とクラスでKEY RRのセットとなります。）
This information could be preserved as a set of detached DNS information blocks.
この情報は切り離されたDNS情報ブロックのセットとして保存することができます。
Allocation of meanings to retrieval time fields with a initial byte of between 0x01 and 0x1F requires an IETF consensus.
が0x01と0x1Fの間の最初のバイトと時間フィールドを検索するための意味の割り当ては、IETFコンセンサスを必要とします。
The entirety of this document concerns a means to represent detached DNS information. Such detached resource records may be security relevant and/or secured information as described in [RFC 2535]. The detached format provides no overall security for sets of detached information or for the association between retrieval time and information. This can be provided by wrapping the detached information format with some other form of signature. However, if the detached information is accompanied by SIG RRs, its validity period is indicated in those SIG RRs so the retrieval time might be of secondary importance.
この文書の全体が切り離されたDNS情報を表現するための手段に関するものです。 [RFC 2535]に記載されているような剥離リソースレコードは、セキュリティ関連、および/または保護された情報であってもよいです。剥離フォーマットは、取り外し情報セットまたは検索時間情報との間の関連付けのための全体的なセキュリティを提供しません。これは、署名のいくつかの他の形で剥離情報フォーマットを包むことによって提供することができます。切り離された情報は、SIGのRRを伴っている場合は検索時間が二次的に重要であるかもしれないので、しかし、その有効期間は、これらのSIGのRRに示されています。
References
リファレンス
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC 1035] Mockapetris, P., " Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
Author's Address
著者のアドレス
Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512
ドナルドE.イーストレイク3位IBM 65 Shindeganヒルロード、RR＃1カーメル、NY 10512
Phone: +1-914-276-2668(h) +1-914-784-7913(w) Fax: +1-914-784-3833(w) EMail: dee3@us.ibm.com
電話番号：+ 1-914-276-2668（H）+ 1-914-784-7913（W）ファックス：+ 1-914-784-3833（W）メール：dee3@us.ibm.com
Full Copyright Statement
完全な著作権声明
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。