Detached Domain Name System (DNS) Information
A format for storing DNS answers offline with timestamps.
Eastlake 3rd, D., "Detached Domain Name System (DNS) Information", RFC 2540, DOI 10.17487/RFC2540, March 1999, <https://www.rfc-editor.org/info/rfc2540>.
@misc{rfc2540,
series = {Request for Comments},
number = 2540,
howpublished = {RFC 2540},
publisher = {RFC Editor},
doi = {10.17487/RFC2540},
url = {https://www.rfc-editor.org/info/rfc2540},
author = {D. Eastlake 3rd},
title = {{Detached Domain Name System (DNS) Information}},
pagetotal = 6,
year = 1999,
month = mar,
} RFC text
Contents
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.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
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
1. Introduction
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.
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.
2. General Format
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.
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.
2.1 Binary Format
The standard binary format for detached DNS information is as
follows:
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.
RR count - an unsigned integer number (with bytes in network order)
of following resource records retrieved at the preceding
retrieval time.
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.
2.2. Text Format
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.
3. Usage Example
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.)
This information could be preserved as a set of detached DNS
information blocks.
4. IANA Considerations
Allocation of meanings to retrieval time fields with a initial byte
of between 0x01 and 0x1F requires an IETF consensus.
5. Security Considerations
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.
References
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., " Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 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.
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.
AI ELI5
On this page
§1Introduction
The Domain Name System (DNS) is the distributed database that translates internet hostnames to IP addresses. Normally, you look up a name every time you need it, and the answer might be different each time (the record might change, or you might get a different server). However, sometimes you need to keep a copy of a DNS answer permanently—for example, to prove that a website existed at a particular time, or to verify the authenticity of a record after the fact.
This RFC defines how to save DNS answers in a standard format, along with the time they were retrieved. The format includes both a binary (machine-readable) version and a text (human-readable) version.
This is a way to save what the DNS server said, and when it said it. You can keep these copies and check them later.
§2Binary and Text Formats
The binary format stores detached DNS information as a sequence of blocks, each containing a retrieval time and zero or more DNS resource records (RRs) that were fetched at that time. Each block begins with a 32-bit retrieval time (seconds since 1 January 1970 GMT), followed by a 16-bit count of RRs, then the RRs themselves in the same binary format used by DNS messages. Multiple blocks can follow, each with its own timestamp and set of RRs. The end of the data is marked by a retrieval time field starting with the byte 0x20 (32 decimal).
The text format uses the standard DNS zone file format (as defined in RFC 1035) with one addition: a new $DATE entry that specifies the retrieval time in the form YYYYMMDDHHMMSS. A $DATE must appear before the first resource record and at each change of retrieval time.
The binary version is a compact record: the time, a count of answers, then the answers. The text version is a readable file that looks like a DNS zone file but has date stamps.
§3Freshness and Validity
Unlike live DNS, where a server forgets old records when their Time To Live (TTL) expires, detached DNS information is stored offline and the TTL is not counted down. Instead, the validity of a record is determined by comparing the current time to the retrieval time plus the original TTL. If current_time - retrieval_time > TTL, the record is considered stale according to normal DNS rules.
Additionally, if a resource record is a digital signature (a SIG RR in DNSSEC), the signature has its own expiration time. Even if the TTL has not expired, the signature cannot be trusted after its signature expiration time.
This approach allows detached DNS information to be used for historical verification: you can see what the DNS said on a particular date, and verify whether that information was supposed to be authoritative at that time.
A saved DNS answer gets stale just like the live one would, but you record when you saved it so you can calculate when it went stale.
§4Use Cases and Security
One common use case is building an authenticated chain for DNSSEC verification. If you retrieve a key record and the signature on that key from the DNS, you can save both. Later, to prove that a document was signed with a particular key at a particular time, you present the archived DNS records along with the signature. The verifier can check that the key was legitimate at that time by verifying the signature with that key, and confirming that the key was not expired.
The detached format itself does not provide security; it is just a container. Security comes from the digital signatures inside the DNS records (SIG RRs) or from wrapping the entire detached information block with another signature.
An important limitation: the detached format does not prevent an attacker from replacing the entire file with a different one. It only allows verification of records that include their own digital signatures. Therefore, it is recommended that the detached information be further signed or protected when it is used for important purposes.
You can use saved DNS answers to prove something was true on a certain date. You can also wrap them in a signature to prevent someone from tampering with the saved file.
§5Reserved and Future Extensions
The binary format reserves retrieval time values with an initial byte between 0x01 and 0x1F for future use. The initial byte 0x20 marks the end of the data. All other initial bytes (0x21 and higher) represent normal 32-bit retrieval times, which covers all timestamps from March 1985 onward.
When timestamps exceed the 32-bit limit (sometime in the year 2106), a 64-bit format will be needed: an initial byte of 0x00, followed by 8 zero bits and a 56-bit timestamp, allowing dates far into the future.
Assignment of meanings to the reserved range (0x01 to 0x1F) requires IETF consensus.
The format saves room for future improvements. If computers need to handle dates after 2106, a longer timestamp format is available.