RFC 2540

RFC 2540: Detached Domain Name System (DNS) Information 🎀

okay bestie, this one is the Detached Domain Name System (DNS) Information spec, written by D. Eastlake (Donald E. Eastlake 3rd) at IBM and dated March 1999 🧚 It's an Experimental category doc, and it doesn't list any RFCs it obsoletes or updates 💅 It's RFC 2540, from the Network Working Group.

---

Status of This Memo ✨

ok so this memo defines an Experimental Protocol for the Internet community 🦋 It is not an Internet standard of any kind. The authors want your discussion and suggestions for improvement 🫶 Distribution of this memo is unlimited.

Copyright Notice 💜

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌸

so the vibe is: a standard format for representing detached DNS information 📦 It's expected to be super useful for storing info pulled from the Domain Name System (DNS), including security info, in archives or in places that aren't 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 DNS is a replicated hierarchical distributed database system [RFC 1034, 1035] that can provide highly available service 👑 It's the operational backbone for Internet host name to address translation, automatic SMTP mail routing, and other basic Internet stuff 💅 The DNS got extended (see [RFC 2535]) so public cryptographic keys can be stored in it in general, and so info pulled from the DNS can be authenticated with digital signatures 🔐

ngl, the DNS was never really built for storing stuff outside of its active zones and authoritative master files, the parts that are connected to the DNS 🙈 But there can be times it's super useful to do that, especially with archived security info 🍓

2. General Format 🎀

the formats for detached Domain Name System (DNS) information are pretty much the same as the ones for connected DNS info 💖 The main difference: elements of the connected DNS (unless they're an authoritative server for the zone holding the info) are required to count down the Time To Live (TTL) for each DNS Resource Record (RR), then toss them out (maybe fetching a fresh copy) once the TTL hits zero ⏳

detached info is different 😭 It might get stored in an off-line file where it can't be updated, and it could be used to authenticate old data, or it might arrive over non-DNS protocols long after it was pulled from the DNS 📁 So counting down the TTL for detached DNS info isn't practical 🙅‍♀️ The data might also need to stick around past the point where the TTL (which is defined as an unsigned field) would underflow 🧮 To keep track of how fresh this detached data is, it comes with its retrieval time ⏰

whatever grabs the info from the DNS has to attach this retrieval time to it ✨ After that, the retrieval time stays fixed 🔒 Once the current time minus the retrieval time goes past the TTL for any particular detached RR, it's no longer a valid copy in the normal connected DNS scheme 💀 That might make it invalid for some detached uses too 🫠 If the RR is a SIG (signature) RR, it also has an expiration time 🗓️ No matter what the TTL says, it and any RRs it signs can't be considered authenticated after the signature expiration time 🚫

2.1 Binary Format 🧩

the standard binary format for detached DNS info looks like this 👀

                     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    |
+-+-+-+-+-+-+-+-+

here's the breakdown, the fields are super specific 🤓

• Retrieval time: the time the info right after it was grabbed from the connected DNS system 🕰️ It's an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds, in network (big-endian) order. This time can't be before the initial proposal of this standard, so the first byte of an actual retrieval time, read as a 32 bit unsigned quantity, is always going to be bigger than 20 hex 😳 The end of detached DNS info is marked by a "retrieval time" field whose initial byte is 0x20 🛑 If a "retrieval time" field has a leading unsigned byte of zero, it's a 64 bit format (actually 8 leading zero bits plus a 56 bit quantity) 🧠 This 64 bit format will be required once retrieval time is larger than 0xFFFFFFFF, which happens sometime in the year 2106 🚀 Retrieval times with an initial byte between 0x01 and 0x1F are reserved (see section 5) 🔒 Retrieval times won't generally be 32 bit aligned with respect to each other, since RRs have variable length 📏
• RR count: an unsigned integer (bytes in network order) of the resource records that follow, all retrieved at the retrieval time just before them 🔢
• Resource Records: the actual data, in the same format it would have if it were sent in a DNS response 📨 Name compression via pointers is allowed, with the origin at the start of that particular detached information data section, right after the RR count 🗜️

2.2. Text Format 📝

the standard text format for detached DNS info follows the rules for zone master files [RFC 1035], with two twists ✨ The $INCLUDE control entry is prohibited 🚫 And the new $DATE entry is required (unless the info set is empty) 📅 $DATE is followed by the date and time the info after it was obtained from the DNS system, as described for retrieval time in section 2.1 above ⏰ It's written as YYYYMMDDHHMMSS, where:

• YYYY is the year (it can 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 hour notation (00-23) 🕐
• the second MM is the minute (00-59) ⏱️
• SS is the second (00-59) ⚡

so a $DATE has to show up before the first RR, and again at every change in retrieval time throughout the detached info 💖

3. Usage Example 🦋

say a document gets authenticated by a key pulled from the DNS in a KEY resource record (RR) 🔑 To prove later that the document is legit, you'd want to keep the KEY RR for that public key, the SIG RR that signs that KEY RR, the KEY RR for the key used to authenticate that SIG, and so on, through SIG and KEY RRs, until you reach a well known trusted key 🏰 That might be 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 record sets like that 🧩)

this info could be preserved as a set of detached DNS information blocks 📦✨

4. IANA Considerations 🌷

giving meanings to retrieval time fields with an initial byte between 0x01 and 0x1F requires an IETF consensus 🫶

5. Security Considerations 🔐

the whole doc is about a way to represent detached DNS info, and I'm going to be serious here 😤 Detached resource records may be security relevant and/or secured info, as described in [RFC 2535] 🚨 The detached format provides no overall security for sets of detached info, or for the association between retrieval time and the info 💀 That can be added by wrapping the detached info format with some other form of signature 🔏 However, if the detached info comes with SIG RRs, its validity period is indicated in those SIG RRs, so the retrieval time might be of secondary importance 🙏

⚠️ bestie, the big takeaway: detached format alone does NOT protect the set or the link between retrieval time and the data. Wrap it in another signature or rely on the SIG RR validity period.

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. 🌈