Network Working Group                                        D. Eastlake
Request for Comments: 2540                                           IBM
Category: Experimental                                        March 1999
        
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.

版权所有(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
        
   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
        
1. Introduction
1. 介绍

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)是一个复制的分层分布式数据库系统[RFC10341035],可以提供高可用性服务。它为Internet主机名到地址转换、自动SMTP邮件路由和其他基本Internet功能提供了操作基础。DNS已经按照[RFC 2535]中的描述进行了扩展,以允许将公共加密密钥存储在数据库中

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一部分的权威主文件之外存储信息而设计的。但是,在某些情况下,这可能很有用,特别是在与存档的安全信息相关的情况下。

2. General Format
2. 通用格式

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是什么,它和它签署的任何RRs在签名过期后都不能被认为是经过身份验证的。

2.1 Binary Format
2.1 二进制格式

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    |
    +-+-+-+-+-+-+-+-+
        
                         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日格林尼治标准时间开始以来的无符号秒数,忽略闰秒,按网络(大端)顺序排列。请注意,此时间不能在本标准的初始提案之前。因此,实际检索时间的初始字节(视为32位无符号量)始终大于20十六进制。分离的DNS信息的结束由等于0x20的“检索时间”字段初始字节表示。使用前导无符号字节为零的“检索时间”字段表示64位(实际上是8个前导零位加56位)。当检索时间大于0xFFFFFFFF(即2106年的某个时间)时,需要此64位格式。保留初始字节在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 count—在上一次检索时检索到的以下资源记录的无符号整数(以网络顺序为字节)。

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计数之后,使用原点通过指针进行名称压缩。

2.2. Text Format
2.2. 文本格式

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]的规定相同,但$INCLUDE control条目被禁止,并且需要新的$DATE条目(除非信息集为空)$日期后接从DNS系统获取以下信息的日期和时间,如上文第2.1节中检索时间所述。它采用文本格式YYYYMMDDHHMMSS,其中YYYY是年份(可能超过四位数,以涵盖9999年之后的年份),第一个MM是月号(01-12),DD是月的一天(01-31),HH是24小时表示法中的小时(00-23),第二个MM是分钟(00-59),SS是第二个(00-59)。因此,$日期必须出现在第一个RR之前,并且在通过分离的信息检索时间的每次更改时出现。

3. Usage Example
3. 用法示例

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检索的密钥进行身份验证。为了稍后证明本文件的真实性,最好通过SIG和密钥RRs保留该公钥的密钥RR、签名该密钥RR的SIG RR、用于认证该SIG的密钥RR等,直到达到众所周知的可信密钥,可能是DNS根目录或某些第三方身份验证服务的密钥。(在某些情况下,这些密钥RRs实际上是具有相同所有者和类别的密钥RRs集,因为SIG实际上对这些记录集进行签名。)

This information could be preserved as a set of detached DNS information blocks.

此信息可以作为一组分离的DNS信息块保留。

4. IANA Considerations
4. IANA考虑

Allocation of meanings to retrieval time fields with a initial byte of between 0x01 and 0x1F requires an IETF consensus.

初始字节在0x01和0x1F之间的检索时间字段的意义分配需要IETF共识。

5. Security Considerations
5. 安全考虑

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 RRs中指示其有效期,因此检索时间可能是次要的。

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 25351999年3月。

Author's Address

作者地址

Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512

纽约州卡梅尔市新德干山路65号东湖第三IBM公司,邮编10512

   Phone:   +1-914-276-2668(h)
            +1-914-784-7913(w)
   Fax:     +1-914-784-3833(w)
   EMail:   dee3@us.ibm.com
        
   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.

版权所有(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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。