[要約] RFC 2540は、Detached Domain Name System（DNS）情報に関する仕様を提供しています。このRFCの目的は、DNS情報の分離と再利用を可能にするための方法を提案することです。
Network Working Group D. Eastlake
Request for Comments: 2540 IBM
Category: Experimental March 1999
Detached Domain Name System (DNS) Information
デタッチされたドメイン名システム（DNS）情報
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.
このメモは、インターネットコミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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
ドメイン名システム（DNS）は、非常に利用可能なサービスを提供できる複製された階層分散データベースシステム[RFC 1034、1035]です。インターネットホスト名が翻訳、自動SMTPメールルーティング、およびその他の基本的なインターネット機能に対処するための運用基準を提供します。[RFC 2535]に記載されているようにDNSは拡張されており、パブリック暗号化キーの一般的な保管を許可します
the DNS and to enable the authentication of information retrieved from the DNS though digital signatures.
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に関係なく、ITおよびRRS署名は、署名の有効期限の後に認証されるとは見なされません。
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日の開始以来、NETWORD（Big-Endian）の順序で、Leap Secondsを無視してGMTが署名されていない秒数です。この時期は、この基準の最初の提案の前にできないことに注意してください。したがって、32ビットの署名数量と見なされる実際の検索時間の初期バイトは、常に20ヘクスよりも大きくなります。分離したDNS情報の終了は、0x20に等しい「検索時間」フィールド初期バイトによって示されます。ゼロのリーディングされていないバイトを備えた「検索時間」フィールドの使用は、64ビット（実際には8つの主要なゼロビットと56ビット数量）を示します。この64ビット形式は、検索時間が0xffffffffffより大きい場合に必要です。これは2106年のある時間です。0x01〜0x1Fの初期バイトの検索時間の意味は予約されています（セクション5を参照）。 RRSの長さの性質が変動するため、通常、検索時間は互いに32ビットアライメントされません。
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]。$日付の後に、上記のセクション2.1の検索時間について説明されているように、次の情報がDNSシステムから取得された日時が続きます。yyyyが年であるyyyymmddhhmmmss（9999年以降に4桁以上になる可能性がある場合）は、最初のmmは月数（01-12）、DDは月（01-）です。31）、HHは24時間の表記法（00-23）、2番目のmmは瞬間（00-59）、SSは2番目（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.)
ドキュメントは、キーリソースレコード（RR）のDNSから取得されたキーによって認証される場合があります。後でこのドキュメントの信頼性を証明するために、その公開キーのキーRR、そのキーRRに署名するSIG RR、そのSIGを認証するために使用されるキーのキーRRに署名するSIG RRは、SIGとキーを介して望ましいでしょう。よく知られている信頼できるキーに到達するまで、おそらくDNSルートまたはサードパーティ認証サービスのキーに達するまで。（場合によっては、これらの主要なRRは、実際にSIGが実際にそのようなレコードセットに署名するため、実際に同じ所有者とクラスを持つキー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
このドキュメント全体は、分離されたDNS情報を表す手段に関するものです。このような分離されたリソースレコードは、[RFC 2535]で説明されているように、セキュリティ関連および/または安全な情報である場合があります。分離した形式は、分離したセットの全体的なセキュリティを提供しません
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.
情報または検索時間と情報の間の関連性。これは、分離した情報形式を他の形式の署名で包むことで提供できます。ただし、分離された情報にSIG RRSが伴う場合、その有効期間はそれらの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] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
Author's Address
著者の連絡先
Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512
ドナルドE.イーストレイク3rd IBM 65 Shindegan Hill Road、RR＃1カーメル、ニューヨーク10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。