RFC 4034
Resource Records for the DNS Security Extensions
RFC 4034 💖 Resource Records for the DNS Security Extensions
Okay bestie, this one is RFC 4034, Resource Records for the DNS Security Extensions, from the Network Working Group 🎀. It's a Standards Track doc dated March 2005. Five authors wrote it: R. Arends (Telematica Instituut), R. Austein (ISC), M. Larson (VeriSign), D. Massey (Colorado State University), and S. Rose (NIST) 👑. It obsoletes RFC 2535, 3008, 3090, 3445, 3655, 3658, 3755, 3757, and 3845, and it updates RFC 1034, 1035, 2136, 2181, 2308, 3225, 3007, 3597, and 3226 ✨.
Status of This Memo
This doc is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions 🗣️. For where this protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 📨.
Copyright Notice
Copyright (C) The Internet Society (2005). 🌸
Abstract
This doc is part of a family describing the DNS Security Extensions (DNSSEC) 🧚. DNSSEC is a bundle of resource records and protocol changes that give the DNS source authentication 🔐. This doc defines four records: the public key (DNSKEY) record, the delegation signer (DS) record, the resource record digital signature (RRSIG) record, and the authenticated denial of existence (NSEC) record. It goes deep on the purpose and format of each one, and every record gets an example 💅.
This doc obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. 🦋
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . 3
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
2.1.4. The Public Key Field . . . . . . . . . . . . . 5
2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
3.1.1. The Type Covered Field . . . . . . . . . . . . 7
3.1.2. The Algorithm Number Field . . . . . . . . . . 8
3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
3.1.5. Signature Expiration and Inception Fields. . . 9
3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
3.1.7. The Signer's Name Field. . . . . . . . . . . . 9
3.1.8. The Signature Field. . . . . . . . . . . . . . 9
3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
4.1.1. The Next Domain Name Field . . . . . . . . . . 13
4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
5.2. Processing of DS RRs When Validating Responses . . . . 17
5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
6. Canonical Form and Order of Resource Records . . . . . . . . 18
6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . 23
A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 291. Introduction ✨
DNSSEC adds four brand-new DNS resource record types 🌈: DNSKEY (DNS Public Key), RRSIG (Resource Record Signature), NSEC (Next Secure), and DS (Delegation Signer). This doc covers what each resource record (RR) is for, its RDATA format, and its presentation format (ASCII representation) 💜.
1.1. Background and Related Documents
This doc is one member of the DNSSEC family, and you should read the whole set together, like a playlist 🎀.
[RFC4033] is the intro to DNSSEC and the place where the common terms get defined, and you're assumed to already know it. It also has a list of the other documents this set updates and obsoletes 📋.
[RFC4035] defines the DNSSEC protocol operations. 🛠️
You're also assumed to know the basic DNS concepts from [RFC1034], [RFC1035], and the later documents that update them, especially [RFC2181] and [RFC2308] 🧠.
This doc defines the DNSSEC resource records. All numeric DNS type codes given in this doc are decimal integers 🔢.
1.2. Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 📖.
2. The DNSKEY Resource Record 🔑
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets) 🔐. The public keys live in DNSKEY resource records, and they're used in the DNSSEC authentication process described in [RFC4035]. A zone signs its authoritative RRsets with a private key and stores the matching public key in a DNSKEY RR. A resolver can then use that public key to validate the signatures covering the RRsets in the zone, and that's how it authenticates them 💖.
The DNSKEY RR is not a junk drawer for random public keys, so it MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure. 🙈
The Type value for the DNSKEY RR type is 48 🍓.
The DNSKEY RR is class independent. 🌸
The DNSKEY RR has no special TTL requirements. ✨
2.1. DNSKEY RDATA Wire Format
The RDATA for a DNSKEY RR is made of a 2 octet Flags Field, a 1 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key Field 🧩.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1.1. The Flags Field 🚩
Bit 7 of the Flags field is the Zone Key flag 🗝️. If bit 7 has value 1, the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name MUST be the name of a zone. If bit 7 has value 0, the DNSKEY record holds some other type of DNS public key, and it MUST NOT be used to verify RRSIGs that cover RRsets.
Bit 15 of the Flags field is the Secure Entry Point flag, which is described in [RFC3757] 👑. If bit 15 has value 1, the DNSKEY record holds a key intended for use as a secure entry point. This flag is only a hint for zone signing or debugging software about how this DNSKEY record is meant to be used. Validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit. It also means that a DNSKEY RR with the SEP bit set would also need the Zone Key flag set in order to be able to generate signatures legally. A DNSKEY RR with the SEP set and the Zone Key flag not set MUST NOT be used to verify RRSIGs that cover RRsets 💅.
Bits 0-6 and 8-14 are reserved 🚧: these bits MUST have value 0 upon creation of the DNSKEY RR, and they MUST be ignored upon receipt.
2.1.2. The Protocol Field 🎀
The Protocol Field MUST have value 3. If the DNSKEY RR is found to have any other value, it MUST be treated as invalid during signature verification.
2.1.3. The Algorithm Field 🧮
The Algorithm field identifies the public key's cryptographic algorithm, and it determines the format of the Public Key field. You can find a list of DNSSEC algorithm types in Appendix A.1. 📚
2.1.4. The Public Key Field 🗝️
The Public Key Field holds the public key material. Its format depends on the algorithm of the key being stored, and separate documents describe those formats 🧁.
2.1.5. Notes on DNSKEY RDATA Design 💭
Although the Protocol Field always has value 3, it's kept around for backward compatibility with early versions of the KEY record. Iconic loyalty 🥹👑.
2.2. The DNSKEY RR Presentation Format 🎨
Here's how the presentation format of the RDATA portion goes 📝.
The Flag field MUST be represented as an unsigned decimal integer. Given the flags that are currently defined, the possible values are: 0, 256, and 257 🔢.
The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3 🌸.
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in Appendix A.1 🦋.
The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548] 🫶.
2.3. DNSKEY RR Example ✨
okay so here's a real DNSKEY RR for example.com 🎀 it's giving textbook, and I'm obsessed with how clean it looks 😭
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )so the first four fields are the owner name, TTL, Class, and RR type (DNSKEY) 💖 then the 256 means the Zone Key bit (bit 7) in the Flags field is set to 1 🔑 the 3 is the fixed Protocol value 🫶 and the 5 is the public key algorithm 💅
Appendix A.1 says algorithm type 5 is RSA/SHA1, and that the RSA/SHA1 public key field format is defined in [RFC3110]. 🦋
the rest of it is just the public key, Base64 encoded 🌸 yes, the whole thing is one big blob, and yes, that's normal 💀
3. The RRSIG Resource Record ✨
okay bestie, DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets) 🔐 the signatures live in RRSIG resource records, and they get used in the DNSSEC authentication process described in [RFC4035] 🧚 a validator can use these RRSIG RRs to authenticate RRsets from the zone 👑
the RRSIG RR MUST only be used to carry verification material (digital signatures) used to secure DNS operations. no other vibes allowed 🙅♀️
an RRSIG record holds the signature for an RRset with a particular name, class, and type 🎀 the RRSIG RR gives a validity interval for the signature, and it uses the Algorithm, the Signer's Name, and the Key Tag to find the DNSKEY RR with the public key that a validator can use to verify the signature 🔍
here's the drama 🎭 every authoritative RRset in a zone has to be protected by a digital signature, so RRSIG RRs have to be there for names that contain a CNAME RR. this changes the old rule in [RFC1034], which said that if a CNAME exists for a name, it's the only type allowed at that name 😭 so in a signed zone, an RRSIG and an NSEC (see Section 4) MUST exist for the same name as a CNAME resource record.
the Type value for the RRSIG RR type is 46 🔢
the RRSIG RR is class independent 🌈
an RRSIG RR MUST have the same class as the RRset it covers 💜
the TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers. this is an exception to the [RFC2181] rules for TTL values of individual RRs inside an RRset 🙈 so RRSIG RRs with the same owner name can have different TTLs, as long as the RRsets they cover have different TTLs.
3.1. RRSIG RDATA Wire Format 🧩
the RDATA for an RRSIG RR is made of: a 2 octet Type Covered field, a 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL field, a 4 octet Signature Expiration field, a 4 octet Signature Inception field, a 2 octet Key tag, the Signer's Name field, and the Signature field 📦
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1.1. The Type Covered Field 🎯
the Type Covered field tells you the type of the RRset this RRSIG covers 💅
3.1.2. The Algorithm Number Field 🔢
the Algorithm Number field tells you which cryptographic algorithm made the signature 🔐 you can find the list of DNSSEC algorithm types in Appendix A.1
3.1.3. The Labels Field 🏷️
the Labels field holds the number of labels in the original RRSIG RR owner name. this matters because a validator uses it to figure out whether the answer was synthesized from a wildcard 👀 if it was, the validator can use this value to work out which owner name was used when the signature was made.
to validate a signature, the validator needs the original owner name that was used to create it. if that original owner name has a wildcard label ("*"), the server may have expanded the owner name while building the response, and then the validator has to rebuild the original owner name before it can validate the signature 🧠 [RFC4035] explains how to use the Labels field to rebuild it.
the value of the Labels field MUST NOT count either the null (root) label that ends the owner name, or the wildcard label (if there is one) 🙅♀️ the value of the Labels field MUST be less than or equal to the number of labels in the RRSIG owner name. for example, www.example.com. has a Labels field value of 3, and *.example.com. has a Labels field value of 2. Root (.) has a Labels field value of 0 🌸
even though the wildcard label isn't counted in the Labels field of the RRSIG RR, it's still part of the RRset's owner name when the signature is generated or verified 🦋
3.1.4. Original TTL Field ⏳
the Original TTL field is the TTL of the covered RRset as it appears in the authoritative zone 📜
it's needed because a caching resolver decrements the TTL of a cached RRset 😭 to validate a signature, a validator needs that original TTL. [RFC4035] explains how to use the Original TTL field value to rebuild the original TTL.
3.1.5. Signature Expiration and Inception Fields 📅
the Signature Expiration and Inception fields give a validity period for the signature ✨ the RRSIG record MUST NOT be used for authentication before the inception date, and it MUST NOT be used for authentication after the expiration date 🚫
the Signature Expiration and Inception field values are a date and time, written as a 32-bit unsigned number of seconds since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order ⏰ the longest interval this format can show without wrapping is about 136 years 🤯 an RRSIG RR can have an Expiration field value that's numerically smaller than its Inception field value. that can happen when the expiration is near the 32-bit wrap-around point, or when the signature is long lived 🌀 because of that, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]. as a direct result, these fields can't refer to dates more than 68 years in the past or the future 💀
3.1.6. The Key Tag Field 🔑
the Key Tag field holds the key tag value of the DNSKEY RR that validates this signature, in network byte order. Appendix B explains how to calculate Key Tag values 🧮
3.1.7. The Signer's Name Field 🪪
the Signer's Name field is the owner name of the DNSKEY RR that a validator is supposed to use to validate this signature. the Signer's Name field MUST contain the name of the zone of the covered RRset. and a sender MUST NOT use DNS name compression on the Signer's Name field when sending an RRSIG RR 🚫🗜️
3.1.8. The Signature Field ✍️
the Signature field holds the cryptographic signature that covers the RRSIG RDATA (leaving out the Signature field itself) and the RRset named by the RRSIG owner name, RRSIG class, and RRSIG Type Covered field 💖 the format of this field depends on the algorithm being used, and those formats are described in separate companion documents 📚
3.1.8.1. Signature Calculation 🧪
a signature covers the RRSIG RDATA (leaving out the Signature Field) and the data RRset named by the RRSIG owner name, RRSIG class, and RRSIG Type Covered fields 🎀 the RRset is in canonical form (see Section 6), and the set RR(1),...RR(n) gets signed like this:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) wherehere's what all the bits mean 👇
- "|" means concatenation 🔗
- RRSIG_RDATA is the wire format of the RRSIG RDATA fields, with the Signer's Name field in canonical form and the Signature field left out 📦
- RR(i) is built like this:
RR(i) = owner | type | class | TTL | RDATA length | RDATA- "owner" is the fully qualified owner name of the RRset in canonical form. for RRs with wildcard owner names, the wildcard label IS included in the owner name 🌟
- each RR MUST have the same owner name as the RRSIG RR 💜
- each RR MUST have the same class as the RRSIG RR 🌈
- each RR in the RRset MUST have the RR type listed in the RRSIG RR's Type Covered field 🎯
- each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field ⏳
- any DNS names in the RDATA field of each RR MUST be in canonical form; and 🔤
- the RRset MUST be sorted in canonical order. 📚
see Sections 6.2 and 6.3 for the details on canonical form and ordering of RRsets 🫶
3.2. The RRSIG RR Presentation Format 📝
okay so the presentation format of the RDATA part goes like this 💅
the Type Covered field is written as an RR type mnemonic. when the mnemonic isn't known, the TYPE representation from [RFC3597], Section 5, MUST be used 🙏
the Algorithm field value MUST be written either as an unsigned decimal integer or as an algorithm mnemonic, as listed in Appendix A.1 🔢
the Labels field value MUST be written as an unsigned decimal integer 🏷️
the Original TTL field value MUST be written as an unsigned decimal integer ⏳
the Signature Expiration Time and Inception Time field values MUST be written either as an unsigned decimal integer counting seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where:
YYYYis the year (0001-9999, but see Section 3.1.5) 📅MMis the month number (01-12) 🌙DDis the day of the month (01-31) ☀️HHis the hour, in 24 hour notation (00-23) ⏰mmis the minute (00-59) 🕐SSis the second (00-59) ⏱️
you can always tell these two formats apart, because YYYYMMDDHHmmSS is always exactly 14 digits, while a 32-bit unsigned integer in decimal can never be longer than 10 digits 🧠✨
the Key Tag field MUST be written as an unsigned decimal integer 🔑
the Signer's Name field value MUST be written as a domain name 🪪
the Signature field is written as a Base64 encoding of the signature. whitespace is allowed inside the Base64 text. see Section 2.2 🌸
3.3. RRSIG RR Example ✨
okay bestie, let's look at a real one 🎀 this RRSIG stores the signature for the A RRset of host.example.com:
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )the first four fields give us the owner name, TTL, Class, and RR type (RRSIG) 💅 then A is the Type Covered field, and 5 tells you the algorithm used (RSA/SHA1) to make the signature 🔥 the 3 is the number of Labels in the original owner name, and 86400 in the RRSIG RDATA is the Original TTL for the covered A RRset. 20030322173103 and 20030220173103 are the expiration and inception dates, in that order 🌸 2642 is the Key Tag, and example.com. is the Signer's Name. the rest of that messy-looking text is just a Base64 encoding of the signature 🙈
note that the combo of RRSIG owner name, class, and Type Covered is what tells you this RRSIG covers the "host.example.com" A RRset 💖 the Label value of 3 means no wildcard expansion was used ✨ and the Algorithm, Signer's Name, and Key Tag together say this signature can be checked with an example.com zone DNSKEY RR whose algorithm is 5 and whose key tag is 2642 👑
4. The NSEC Resource Record ✨
okay so the NSEC record lists two things: the next owner name (in the canonical ordering of the zone) that has authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name [RFC3845] 🦋 all the NSEC RRs in a zone together show which authoritative RRsets exist and also form a chain of authoritative owner names 🧚 this is what gives you authenticated denial of existence for DNS data, as described in [RFC4035] 💜
here's the lowkey big change 👀 every authoritative name in a zone has to be part of the NSEC chain, so NSEC RRs must be present for names containing a CNAME RR. this is a change to the traditional DNS spec [RFC1034], which said that if a CNAME is present for a name, it's the only type allowed at that name 💀 so now an RRSIG (see Section 3) and NSEC MUST exist for the same name as a CNAME resource record in a signed zone 🔥
see [RFC4035] for how a zone signer figures out exactly which NSEC RRs it has to include in a zone 🌈
the type value for the NSEC RR is 47 🎀
the NSEC RR is class independent 💅
the NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. this is in the spirit of negative caching ([RFC2308]) ✨
4.1. NSEC RDATA Wire Format
the RDATA of the NSEC RR 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.1.1. The Next Domain Name Field
the Next Domain field holds the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset 🌸 for how canonical ordering works, see Section 6.1 📖 the Next Domain Name value in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR) 👑 that's how you know the owner name of that NSEC RR is the last name in the canonical ordering of the zone 🧚
a sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR 🙅♀️
owner names of RRsets the zone is NOT authoritative for (like glue records) MUST NOT be listed in the Next Domain Name, unless at least one authoritative RRset exists at the same owner name 🫶
4.1.2. The Type Bit Maps Field
the Type Bit Maps field tells you which RRset types exist at the NSEC RR's owner name 💖
the RR type space gets split into 256 window blocks, each one representing the low-order 8 bits of the 16-bit RR type space 🦋 each block that has at least one active RR type is encoded with a single octet window number (0 to 255), a single octet bitmap length (1 to 32) for how many octets the block's bitmap uses, and up to 32 octets (256 bits) of bitmap 🔥
blocks show up in the NSEC RR RDATA in increasing numerical order ✨
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
where "|" denotes concatenation.each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order 🌈 the first bit is bit 0. for window block 0, bit 1 is RR type 1 (A), bit 2 is RR type 2 (NS), and so on. for window block 1, bit 1 is RR type 257, and bit 2 is RR type 258 🎀 if a bit is set, an RRset of that type is present for the NSEC RR's owner name. if a bit is clear, no RRset of that type is present there 💅
bits for pseudo-types MUST be clear, since they don't show up in zone data 🙈 and if you run into them, they MUST be ignored when you read them 🫶
blocks with no types present MUST NOT be included ✨ trailing zero octets in the bitmap MUST be omitted 💜 the length of each block's bitmap is set by the type code with the largest numerical value in that block, among the RR types present at the NSEC RR's owner name 🌸 trailing zero octets that aren't specified MUST be interpreted as zero octets 🧚
the bitmap for the NSEC RR at a delegation point needs some extra attention, bestie 👀 bits for the delegation NS RRset and the RR types the parent zone has authoritative data for MUST be set 🔥 bits for any non-NS RRset the parent is NOT authoritative for MUST be clear 💅
a zone MUST NOT include an NSEC RR for any domain name that only holds glue records 🙅♀️
4.1.3. Inclusion of Wildcard Names in NSEC RDATA
if a wildcard owner name shows up in a zone, the wildcard label ("*") is treated as a literal symbol 🦋 it gets treated the same as any other owner name when generating NSEC RRs ✨ wildcard owner names appear in the Next Domain Name field without any wildcard expansion 🌈 [RFC4035] describes how wildcards affect authenticated denial of existence 💖
4.2. The NSEC RR Presentation Format
the presentation format of the RDATA portion goes like this 🎀
the Next Domain Name field is shown as a domain name 💅
the Type Bit Maps field is shown as a sequence of RR type mnemonics 🌸 when the mnemonic isn't known, you MUST use the TYPE representation described in [RFC3597], Section 5 🫶
4.3. NSEC RR Example
the following NSEC RR identifies the RRsets associated with alfa.example.com. and the next authoritative name after alfa.example.com. 🧚
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )the first four text fields give the name, TTL, Class, and RR type (NSEC) ✨ the entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order 👑 the A, MX, RRSIG, NSEC, and TYPE1234 mnemonics mean there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets associated with the name alfa.example.com. 🔥
the RDATA section of the NSEC RR above would be encoded as:
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20if the validator can authenticate this NSEC record, it can be used to prove that beta.example.com does not exist, or to prove that there is no AAAA record associated with alfa.example.com 🌈 authenticated denial of existence is discussed in [RFC4035] 🦋
5. The DS Resource Record
the DS Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process 💖 a DS RR points at a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR 🧚 the digest should be enough to identify the public key, but storing the key tag and key algorithm makes the identification process more efficient ✨ once you authenticate the DS record, a resolver can authenticate the DNSKEY RR it points to 👑 the key authentication process is described in [RFC4035] 🔥
the DS RR and its corresponding DNSKEY RR have the same owner name, but they live in different places 🌸 the DS RR only appears on the upper (parental) side of a delegation, and it's authoritative data in the parent zone 💅 for example, the DS RR for "example.com" is stored in the "com" zone (the parent) rather than in "example.com" (the child) 🎀 the corresponding DNSKEY RR is stored in the "example.com" zone (the child) 🫶 this makes DNS zone management and zone signing simpler, but it also brings special response processing requirements for the DS RR, which are described in [RFC4035] 🌈
the type number for the DS record is 43 ✨
the DS resource record is class independent 💜
the DS RR has no special TTL requirements 🦋
5.1. DS RDATA Wire Format
the RDATA for a DS RR is made of a 2 octet Key Tag field, a 1 octet Algorithm field, a 1 octet Digest Type field, and a Digest field 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.1. The Key Tag Field
the Key Tag field lists the key tag of the DNSKEY RR the DS record refers to, in network byte order 💖
the Key Tag used by the DS RR is identical to the Key Tag used by RRSIG RRs 🧚 Appendix B describes how to compute a Key Tag ✨
5.1.2. The Algorithm Field
the Algorithm field lists the algorithm number of the DNSKEY RR the DS record refers to 👑
the algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs 🔥 Appendix A.1 lists the algorithm number types 🌸
5.1.3. The Digest Type Field
the DS RR refers to a DNSKEY RR by including a digest of that DNSKEY RR 💅 the Digest Type field identifies the algorithm used to construct the digest 🎀 Appendix A.2 lists the possible digest algorithm types 🫶
5.1.4. The Digest Field ✨
okay so the DS record points at a DNSKEY RR by including a digest of that DNSKEY RR 🦋
the digest gets calculated by smooshing together the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then running that through the digest algorithm 💅
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
"|" denotes concatenation
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.the size of the digest can change depending on the digest algorithm and how big the DNSKEY RR is 🌸 as of right now, the only defined digest algorithm is SHA-1, which produces a 20 octet digest. 💜
5.2. Processing of DS RRs When Validating Responses 🔥
the DS RR is the thing that links the authentication chain across zone boundaries, so it needs extra care when you process it 🫶 the DNSKEY RR that the DS RR refers to MUST be a DNSSEC zone key. the DNSKEY RR Flags MUST have Flags bit 7 set. if the DNSKEY flags don't indicate a DNSSEC zone key, then the DS RR (and the DNSKEY RR it references) MUST NOT be used in the validation process 🙈
bestie, this is the one to remember. a DS that doesn't point at a zone key is not allowed in validation, period 💀
5.3. The DS RR Presentation Format 🎀
the presentation format of the RDATA portion goes like this:
- The Key Tag field MUST be represented as an unsigned decimal integer.
- The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1.
- The Digest Type field MUST be represented as an unsigned decimal integer.
- The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text.
5.4. DS RR Example 🧚
here's a DNSKEY RR and its matching DS RR, so you can see how they look side by side 👀
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )so the first four text fields are the name, TTL, Class, and RR type (DS) ✨ the value 60485 is the key tag for the "dskey.example.com." DNSKEY RR, and the value 5 tells you the algorithm that DNSKEY uses 🔑 the value 1 is the algorithm used to build the digest, and the rest of the RDATA text is the digest in hexadecimal 🌈
6. Canonical Form and Order of Resource Records 👑
this section sets up a canonical form for resource records, a canonical ordering of DNS names, and a canonical ordering of resource records within an RRset. a canonical name order is required to build the NSEC name chain 🔗 and a canonical RR form and ordering within an RRset are required to construct and verify RRSIG RRs 💖
6.1. Canonical DNS Name Order 💜
for DNS security, owner names get ordered by treating each label as an unsigned left-justified octet string. the absence of an octet sorts before a zero value octet, and uppercase US-ASCII letters get treated as if they were lowercase US-ASCII letters 🍓
to compute the canonical order of a set of DNS names, you start by sorting the names by their most significant (rightmost) labels. for names where the most significant label is the same, you keep going by sorting on the next most significant label, and so on 🦋
for example, these names are sorted in canonical DNS name order. the most significant label is "example". at that level, "example" sorts first, then the names ending in "a.example", then the names ending in "z.example". the names inside each level get sorted the same way 🌸
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example6.2. Canonical RR Form 🎀
for DNS security, the canonical form of an RR is the wire format of the RR where:
- every domain name in the RR is fully expanded (no DNS name compression) and fully qualified;
- all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters;
- if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters;
- if the owner name of the RR is a wildcard name, the owner name is in its original unexpanded form, including the
*label (no wildcard substitution); and - the RR's TTL is set to its original value as it appears in the originating authoritative zone or the Original TTL field of the covering RRSIG RR.
6.3. Canonical RR Ordering within an RRset 🧚
for DNS security, RRs with the same owner name, class, and type get sorted by treating the RDATA portion of the canonical form of each RR as a left-justified unsigned octet sequence, where the absence of an octet sorts before a zero octet 🌈
[RFC2181] says an RRset isn't allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). so if an implementation detects duplicate RRs while putting the RRset into canonical form, it MUST treat this as a protocol error. if the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset 🫠
7. IANA Considerations 📋
this document doesn't introduce any new IANA considerations, because all of the protocol parameters it uses were already assigned by earlier specs ✨ BUT, since DNSSEC has had a long and kinda convoluted evolution, this section tries to describe the current state of the IANA registries and other protocol parameters that are (or once were) related to DNSSEC 🌀
please refer to [RFC4035] for additional IANA considerations 📚
- DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol described in [RFC2931] and to the transaction KEY Resource Record described in [RFC2930].
- DNS Security Algorithm Numbers: [RFC2535] created an IANA registry for DNSSEC Resource Record Algorithm field numbers and assigned values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] altered this registry to include flags for each entry regarding its use with the DNS security extensions. Each algorithm entry could refer to an algorithm that can be used for zone signing, transaction security (see [RFC2931]), or both. Values 6-251 are available for assignment by IETF standards action ([RFC3755]). See Appendix A for a full listing of the DNS Security Algorithm Numbers entries at the time of this writing and their status for use in DNSSEC. [RFC3658] created an IANA registry for DNSSEC DS Digest Types and assigned value 0 to reserved and value 1 to SHA-1.
- KEY Protocol Values: [RFC2535] created an IANA Registry for KEY Protocol Values, but [RFC3445] reassigned all values other than 3 to reserved and closed this IANA registry. The registry remains closed, and all KEY and DNSKEY records are required to have a Protocol Octet value of 3.
- Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, this registry only contains assignments for bit 7 (the ZONE bit) and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). As stated in [RFC3755], bits 0-6 and 8-14 are available for assignment by IETF Standards Action.
8. Security Considerations 🚨
this document describes the format of four DNS resource records used by the DNS security extensions, and it presents an algorithm for calculating a key tag for a public key 🔐 other than the items described below, the resource records themselves introduce no security considerations. please see [RFC4033] and [RFC4035] for additional security considerations related to using these records 🛡️
the DS record points to a DNSKEY RR by using a cryptographic digest, the key algorithm type, and a key tag. the DS record is intended to identify an existing DNSKEY RR, but it is theoretically possible for an attacker to generate a DNSKEY that matches all the DS fields 😱 the probability of building a matching DNSKEY depends on the type of digest algorithm in use. the only currently defined digest algorithm is SHA-1, and the working group believes that constructing a public key that would match the algorithm, key tag, and SHA-1 digest given in a DS record would be a sufficiently difficult problem, so such an attack is not a serious threat at this time 🧱
the key tag helps select DNSKEY resource records efficiently, but it does NOT uniquely identify a single DNSKEY resource record. two distinct DNSKEY RRs can have the same owner name, the same algorithm type, and the same key tag. an implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances 💀 please see Appendix B for further details.
the table of algorithms in Appendix A and the key tag calculation algorithms in Appendix B include the RSA/MD5 algorithm for completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as explained in [RFC3110] 🙅♀️
9. Acknowledgements 🫶
this document was created from the input and ideas of the members of the DNS Extensions Working Group and its mailing list 💌 the editors want to say a huge thank you for the comments and suggestions received during the revision of these security extension specifications 🌷 explicitly listing everyone who contributed during the decade DNSSEC was under development would be impossible, but [RFC4033] includes a list of some of the participants who were kind enough to comment on these documents 👑
10. References 📚
10.1. Normative References
okay bestie, these are the docs this spec leans on 📚 you can't really follow RFC 4034 without them, so they're "normative" 🫶
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🌸
- [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🌸
- [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. 🔢
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅 this is the one that defines the capital-letter key words, so yes it matters a lot
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. 🧚
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. 🦋
- [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. 🔑
- [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. ✍️
- [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. 🔐
- [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. 🎀
- [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. 🍓
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. ❓
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003. 👑 the DS record, our main character!
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. 🫶
- [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004. ⭐
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. 🌈 the intro doc, go read it first
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 🛠️
10.2. Informative References
these ones are just extra reading, not required 🦋 handy for background tho
- [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. 🕰️ the older DNSSEC spec
- [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999. 🔑
- [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. 🌸
- [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. 🗝️
- [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004. 💜
Appendix A. DNSSEC Algorithm and Digest Types ✨
the DNS security extensions are built to be independent of the crypto algorithms underneath 🧁 so the DNSKEY, RRSIG, and DS records all carry a DNSSEC Algorithm Number to say which algorithm they're using. the DS record also has a Digest Algorithm Number that says which digest algorithm built it 💅 the currently defined types are listed below, and more can be added whenever cryptography moves forward. no notes 💀
A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms. 🔥 that's a hard rule, not a suggestion!!
A.1. DNSSEC Algorithm Types
the DNSKEY, RRSIG, and DS records use an 8-bit number to name the security algorithm, stored in the "Algorithm number" field of the RDATA 🔢
some algorithms are only for zone signing (DNSSEC), some are only for transaction security (SIG(0) and TSIG), and some do both 🌈 the zone-signing ones can show up in DNSKEY, RRSIG, and DS records, while the transaction ones live in SIG(0) and KEY records, as described in [RFC2931]. ✍️
Zone
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved
6 - 251 Available for assignment by IETF Standards Action.A.1.1. Private Algorithm Types
algorithm number 253 is reserved for private use and will never be given to a specific algorithm 🕵️♀️ the public key area in a DNSKEY record and the signature area in an RRSIG record both start with a wire-encoded domain name, which MUST NOT be compressed 🙅♀️ that name tells you which private algorithm to use, and whatever comes after it depends on that algorithm. only use domain names you actually control to label your private algorithms, bestie!
algorithm number 254 is also reserved for private use and will never be assigned to a specific algorithm 🌸 this time the public key area and the signature area both start with an unsigned length byte, followed by a BER encoded Object Identifier (ISO OID) of that length. the OID says which private algorithm is in play, and the rest is whatever that algorithm needs. again, only use OIDs you control!
A.2. DNSSEC Digest Types
the DS record has a "Digest Type" field that tells you which cryptographic digest algorithm was used to build it 🍓 here's the list of the digest types defined so far:
VALUE Algorithm STATUS
0 Reserved -
1 SHA-1 MANDATORY
2-255 Unassigned -Appendix B. Key Tag Calculation 🔑
the Key Tag field in RRSIG and DS records is a shortcut for picking out a public key quickly 🧚 most of the time, the owner name plus algorithm plus key tag can pin down a DNSKEY record. RRSIG and DS records each have a matching DNSKEY record, so when more than one DNSKEY candidate shows up, the Key Tag helps you pick the right one fast ⚡
BUT here's the tea: the key tag is NOT a unique identifier 🙈 it's theoretically possible for two different DNSKEY records to share the same owner name, algorithm, and key tag. it just narrows down the candidates, it doesn't name one for sure. Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR. 🚫
the key tag is calculated the same way for every DNSKEY algorithm type except algorithm 1 (see Appendix B.1 for that one 🫠). the method is to treat the DNSKEY RDATA, in wire format, as a series of 2-octet groups, add them all together, and ignore any carry bits 🧮
here's a reference implementation written as an ANSI C function, which takes the RDATA portion of a DNSKEY RR as input 💻 you don't have to copy it word for word, but the numerical value of the Key Tag MUST be identical to what this reference implementation would give for the same input. 💖
note that the key tag calculation is almost, but not quite, the same as the familiar ones-complement checksum used in lots of other Internet protocols. Key Tags MUST be calculated using the algorithm described here, NOT the ones-complement checksum! 🙅♀️
the reference implementation below calculates a Key Tag. it applies to every algorithm type except algorithm 1 (see Appendix B.1), and the input is the wire format of the DNSKEY RDATA. it was written for clarity, not speed 🌷
/*
* Assumes that int is at least 16 bits.
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}B.1. Key Tag for Algorithm 1 (RSA/MD5)
algorithm 1 (RSA/MD5) gets its own key tag rule, for historical reasons 🕰️ for a DNSKEY RR using algorithm 1, the key tag is the most significant 16 bits of the least significant 24 bits of the public key modulus. in other words, the 4th-to-last and 3rd-to-last octets of the modulus 🧐
⚠️ heads up: Algorithm 1 is NOT RECOMMENDED. 💀 please don't pick it for new stuff!
Authors' Addresses 💌
here's where to find the authors, if you want to slide into their inboxes 🦋
Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873
EMail: massey@cs.colostate.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.govFull Copyright Statement 🎀
Copyright (C) The Internet Society (2005). ©️
this document is subject to the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights. 🔒
this document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 🫶
Intellectual Property ✨
okay so the IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this doc are valid or in scope 🙈 it also doesn't say whether any license under those rights is available or not, and it hasn't gone hunting for those rights on its own either 💅 if you want the rules about rights in RFC docs, check out BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat are in the IETF on-line IPR repository at http://www.ietf.org/ipr 🦋 the same goes for any assurances of licenses that will be made available, plus the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification 🌸
and the IETF invites any interested party to flag any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard 💌 send that info to the IETF at ietf-ipr@ietf.org ✉️
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society 🫶🌈
📦 where this page comes from
- ietf: rfc4034 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms