Article Directory
1 Introduction
DNS 4种新resource record types introduced by DNS Security Extensions (DNSSEC) : DNS public key (DNSKEY), resource record signature (RRSIG), Next Secure (NSEC) and delegated signer (DS). This document defines the use of each resource record (RR), RDATA format of RR and its representation format (ASCII representation).
1.1 Background and related documents
This document is part of a series of documents defining DNSSEC and should be read together as a collection.
[RFC4033] contains an introduction to DNSSEC and definitions of commonly used terms; readers should be familiar with this document. [RFC4033] also contains a list of other documents updated and discontinued by this collection.
[RFC4035] defines the DNSSEC protocol operation.
Readers should also be familiar with the basic DNS concepts described in [RFC1034] and [RFC1035], as well as their subsequent updates, especially [RFC2181] and [RFC2308].
This document defines DNSSEC resource records. All numeric DNS type codes given in this document are decimal integers.
1.2 Keywords
In this document, "must", "not", "must", "must", "not", "should", "should", "recommendation", "may", "optional" and other keywords in this document are explained [RFC2119].
2. DNSKEY resource record
DNSSEC uses public key encryption to RRsetsign and authenticate the DNS resource record set ( ). 公钥存储In the DNSKEY resource record, and used in the DNSSEC authentication process described in [RFC4035]: the zone uses a private key to sign its authoritative RRset, and stores the corresponding public key in the DNSKEY RR. Then, the parser can use the public key to verify the signatures covering rrset in the area to authenticate them.
DNSKEY RR is not used to store arbitrary public key records, nor can it be used to store certificates or public keys that are not directly related to the DNS infrastructure.
The DNSKEY RR type is 48.
DNSKEY RR has nothing to do with class.
DNSKEY RR has no special TTL requirements.
2.1 DNSKEY RDATA Wire Format
The RDATA of DNSKEY RR is composed of 2 octet tag fields, 1 octet protocol field, 1 octet algorithm field and 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 Flags field
The seventh bit of the flag field is the area key tag. If the 7th bit is 1, then the DNSKEY record has a DNS zone key, and the owner name of the DNSKEY RR must be a zone name. If the 7th bit is 0, then the DNSKEY record will retain other types of DNS public keys and cannot be used to verify the value of RRSIGs.
The 15th bit of the Flags field is the security entry point flag, which is described in [RFC3757]. If the value of the 15th bit is 1, then the DNSKEY record holds a key that will be used as a security entry point. This flag is only a reminder for zone signing or debugging software to use this DNSKEY record; during the signature verification process, the verifier cannot change their behavior in any way based on the setting of this bit. This also means that the DNSKEY RR with the SEP bit set also needs to set the zone key flag in order to be able to legally generate the signature. DNSKEY RR with SEP set and without zone key flag cannot be used to verify RRSIGs that override rrset.
Bits 0-6 and 8-14 are reserved: These bits must be 0 when creating DNSKEY RR, and must be ignored when receiving.
2.1.2 Protocol field
The protocol field must be 3. If DNSKEY RR is found to be a value other than 3 during signature verification, it must be considered invalid.
2.1.3 Algorithm field
The algorithm field identifies the encryption algorithm of the public key and determines the format of the public key field. The list of DNSSEC algorithm types can be found in Appendix A.1
2.1.4 Public Key field
The public key field contains public key material. The format depends on the algorithm used to store the key and is described in a separate document.
2.1.5 Description of DNSKEY RDATA design
Although the value of the Protocol field is always 3, it is reserved for backward compatibility with earlier versions of the key record.
2.2 The manifestation of DNSKEY RR
The format of the RDATA part is as follows:
The flag field must be represented as an unsigned decimal integer. Given the currently defined flag, 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 expressed as an unsigned decimal integer or as the algorithm mnemonic specified in Appendix A.1.
The public key field must be expressed as the Base64 encoding of the public key. Spaces are allowed in Base64 text. For the definition of Base64 encoding, see [RFC3548].
2.3 DNSKEY RR example
The following DNSKEY RR stores the DNS zone key of example.com.
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )
The first four text fields specify the owner name, TTL, class, and RR type (DNSKEY). The value 256 indicates that the value of the region key bit (the 7th bit) in the Flags field is 1. The value 3 is a fixed protocol value. The value 5 represents the public key algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1, and points out that the format of the RSA/SHA1 public key field is defined in [RFC3110]. The rest of the text is the Base64 encoding of the public key.
3. RRSIG Resource Record
DNSSEC uses public key encryption to sign and authenticate RRset. 数字签名存储In the RRSIG resource record, and used in the DNSSEC authentication process described in [RFC4035]. The verifier can use these RRSIG RRs to verify the rrset in the area. RRSIG RR can only be used to carry verification materials (digital signatures) used to protect DNS operations.
The RRSIG record contains the signature of an RRset with a specific name, class, and type. RRSIG RR 指定签名的有效间隔, and use the algorithm, the name of the signer, and the key tag to identify the DNSKEY RR containing the public key. The verifier can use the public key to verify the signature.
Because each authoritative RRset in the area must be protected by a digital signature, for names containing CNAME RRs, RRSIG RRs must be provided. This is a change to the traditional DNS specification [RFC1034], which stipulates that if a name has a CNAME, then it is the only type allowed in the name. RRSIG and NSEC (see Section 4) must have the same name as the CNAME resource record in the signed zone.
The Type value of the RRSIG RR type is 46.
RRSIG RR has nothing to do with class.
The RRSIG RR must have the same class as the RRset it covers.
The RRSIG record contains the signature of an RRset with a specific name, class, and type. RRSIG RR specifies the effective interval of the signature, and uses the algorithm, the name of the signer, and the key tag to identify the DNSKEY RR containing the public key. The verifier can use the public key to verify the signature.
3.1 RRSIG RDATA wire format
The RDATA of RRSIG RR consists of a 2-byte type coverage field, a 1-byte algorithm field, a 1-byte tag, a 4-byte original TTL field, a byte signature expiration field, and a 4-byte signature start field. , 2-byte key tag field, as well as the signer’s name field and 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 Type override field
3.1.2 Algorithm number field
3.1.3 Label field
3.1.4 Original TTL field
3.1.5 Signature expiration and initial fields
3.1.6 Key Tag Field
The Key Tag field contains the Key Tag value of the DNSKEY RR verifying this signature, arranged in network byte order. Appendix B explains how to calculate the key tag value.
3.1.7 Signer name field
3.1.8 Signature field
3.2 RRSIG RR manifestation
3.3 RRSIG RR example
4 NSEC Resource Record
The NSEC resource record lists two separate things: the next owner name (in the canonical order of the zone), which contains the authoritative data or delegation point NS RRset, and the RR type at the owner name of the NSEC RR [RFC3845] set. The complete set of NSEC RRs in a zone indicates which authoritative rrsets exist in the zone, and forms an authoritative owner name chain in the zone. As described in [RFC4035], this information is used to provide an authenticated denial of existence for DNS data.
Because every authoritative name in the zone must be part of the NSEC chain, NSEC RRs must appear for names that contain CNAME RRs. This is a change to the traditional DNS specification [RFC1034], which stipulates that if a name has a CNAME, then it is the only type allowed in the name. RRSIG (see Section 3) and NSEC must have the same name as the CNAME resource record in the signed zone.
Please refer to [RFC4035] to understand how a zone signer can determine exactly which NSEC RRs it must include in the zone.
The Type value of NSEC RR is 47.
NSEC RR has nothing to do with class.
The NSEC RR should have the same TTL value as the SOA minimum TTL field. This is the spirit of negative caching ([RFC2308]).
4.1 NSEC RDATA Wire Format
The RDATA of NSEC RR is shown in the figure below:
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 Next domain name field
4.1.2 Type bitmap field
4.1.3 NSEC RDATA contains wildcard names
4.2 NSEC RR manifestation
4.3 NSEC RR example
5 DS resource records
DS RR refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. By storing the key tag, the algorithm number and the DNSKEY RR的摘要DS RR, the DNSKEY RR is referenced. Please note that although the digest should be sufficient to identify the public key, storing the key tag and key algorithm can help improve the efficiency of the identification process. By authenticating the DS record, the parser can point to the DS record DNSKEY RR验证. The key authentication process is described in [RFC4035].
DS RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. DS RR is only the 出现在委托的上级(parent) side, which is the authoritative data in the parent zone. For example, the DS RR of "example.com" is stored in the "com" zone (parent zone) instead of being stored in the "example.com" zone (child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (subzone). This simplifies DNS zone management and zone signing, but introduces special response processing requirements for DS RR; these are described in [RFC4035].
The Type value of the DS record is 43.
DS resource records are class independent.
DS RR has no special TTL requirements.
5.1 DS RDATA Wire Format
The RDATA of a DS RR includes a 2-byte key tag field, a 1-byte algorithm field, a 1-byte 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 Key Tag Field
The Key Tag field lists the key tag of the DNSKEY RR referenced by the DS record in network byte order.
The key tag used by DS RR is the same as the key tag used by RRSIG RRs. Appendix B describes how to calculate the key tag.
5.1.2 Algorithm field
The algorithm field lists the algorithm number of the DNSKEY RR referenced by the DS record.
The algorithm number used by DS RR is the same as the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the types of algorithm numbers.
5.1.3 Summary Type Field
By including the digest of DNSKEY RR, DS RR refers to 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 Summary field
The DS record refers to the DNSKEY RR by including the digest of the DNSKEY RR.
By connecting the canonical form of the fully qualified owner name of DNSKEY RR with DNSKEY RDATA, the digest algorithm is applied to calculate the digest.
// “|” 表示连接
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
The size of the digest depends on the digest algorithm and the size of the DNSKEY RR. At the time of writing this article, the only defined digest algorithm is SHA-1, which generates a 20-byte digest.
5.2 Processing of DS RRs when verifying response
DS RR links the identity verification chain across regional boundaries, so you need to be extra careful when handling it. The DNSKEY RR referenced in the DS RR must be the DNSSEC zone key. The DNSKEY RR flag must set the 7th bit flag. If the DNSKEY flag does not indicate the DNSSEC zone key, then DS RR (and the DNSKEY RR it refers to) cannot be used in the verification process.
5.3 The manifestation of DS RR
The format of the RDATA part is as follows:
The key tag field must be expressed as an unsigned decimal integer.
The algorithm field must be expressed as an unsigned decimal integer or the algorithm mnemonic specified in Appendix A.1.
The summary type field must be expressed as an unsigned decimal integer.
The summary must be expressed as a case-insensitive sequence of hexadecimal numbers. Allow spaces in hexadecimal text.
5.4 Examples of DS RR
The following example shows a DNSKEY RR and its corresponding DS RR.
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 )
The first four text fields specify the name, TTL, class, and RR type (DS). The value 60485 is the key tag of the corresponding "dskey.example.com". The value 5 represents the algorithm used by this "dskey.example.com". DNSKEY RR. The value 1 is the algorithm used to construct the summary, and the rest of the RDATA text is the hexadecimal summary.
6 Canonical form and order of resource records
This section defines the canonical form of resource records, the canonical ordering of DNS names, and the canonical ordering of resource records in RRset. The construction of the NSEC name chain requires a canonical name sequence. In order to construct and verify RRSIG RRs, a standardized RR form and ordering in the RRset are required.
6.1 DNS name order specification
For DNS security purposes, the owner name is sorted by treating a single label as an unsigned left-aligned byte string. If there is not an octet, sorting is done before the zero value octet, and uppercase US-ASCII letters are treated as lowercase US-ASCII letters.
To calculate the canonical order of a set of DNS names, first sort the names according to the most important (rightmost) label. For the most important tags with the same name, continue to be sorted according to their next most important tags, and so on.
For example, the following names are sorted in the order of canonical DNS names. The most important label is "example". At this level, "example" is sorted first, followed by names ending in "a.example", and then names ending in "z.example". The names of each layer are sorted in the same way.
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example
6.2 RR format specification
For the sake of DNS security, the canonical form of RR is the connection format of RR:
- Each domain name in RR is fully expanded (no DNS name compression) and fully qualified
- All uppercase US-ASCII letters in the RR owner’s name are replaced by corresponding lowercase US-ASCII letters
- If the type of NS RR, MD, Man Financial CNAME, SOA, MB, MG, Mr., PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, group, PX, NXT, NAPTR, KX, deep water lifeboat , DNAME, A6, RRSIG, or NSEC, all uppercase us-ascii DNS names containing RDATA are replaced with the corresponding lowercase us-ascii letters
- If the owner name of the RR is a wildcard name, the owner name is the original unexpanded form, including the "*" tag (without wildcard replacement); and,
- The RR's TTL is set to its original value appearing in the original authoritative zone or the original TTL field of the overriding RRSIG RR.
6.3 Specification of RR order in an RRser
For the purpose of DNS security, RRs with the same owner name, class, and type are sorted by treating the canonical RDATA part of each RR as a left-aligned unsigned eight-byte sequence. There are no eight bytes before the byte.
[RFC2181] specifies that RRset does not allow duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when placing the RRset in canonical form, it must treat it as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (what it accepts is free), then in order to calculate the canonical form of RRset, it must delete all duplicate RR(s) with one exception.
A. DNSSEC algorithm and digest type
A.1 DNSSEC algorithm type
DNSKEY, RRSIG and DS RRs use 8 digits to identify the security algorithm used. These values are stored in the "Algorithm Number" field in the resource record RDATA.
Some algorithms are only applicable to zone signatures (DNSSEC), some are only applicable to transaction security mechanisms (SIG(0) and TSIG), and some are applicable to both. The ones that can be used for zone signatures may appear in DNSKEY, RRSIG, and DS RRs. As described in [RFC2931], those that can be used for transaction security will appear in SIG(0) and key RRs.
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 is available for IETF standard action allocation.
A.1.1 Types of private algorithms
Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in DNSKEY RR and the signature area in RRSIG RR start with a wired-encoded domain name, which cannot be compressed. The domain name indicates the private algorithm to be used, and the rest of the public key area is determined by the algorithm. Entities should only use the domain names they control to specify their private algorithms.
Algorithm number 254 is reserved for private use and will never be assigned to a specific algorithm. The public key area in DNSKEY RR and the signature area in RRSIG RR start with an unsigned length byte, followed by a BER-encoded object identifier (ISO OID) of that length. OID represents the private algorithm being used, and the remaining area is the area required by the algorithm. Entities should only use the oid they control to specify their private algorithm.
A.2 DNSSEC digest types
The "Digest Type" field in the DS resource record type identifies the encryption digest algorithm used by the resource record. The following table lists the currently defined digest algorithm types.
VALUE Algorithm STATUS
0 Reserved -
1 SHA-1 MANDATORY
2-255 Unassigned -
B. Key Tag calculation
The key tag field in RRSIG and DS resource record types provides an effective mechanism for selecting public keys. In most cases, the combination of owner name, algorithm, and key tag can effectively identify DNSKEY records. Both RRSIG and DS resource records have corresponding DNSKEY records. When multiple candidate DNSKEY RRs are available, the Key tag field in RRSIG and DS records can be used to help effectively select the corresponding DNSKEY RR.
However, it must be noted that the key tag is not the only identifier. In theory, two different DNSKEY RRs may have the same owner name, the same algorithm, and the same key tag. The key tag is used to limit the possible candidate keys, but it cannot uniquely identify the DNSKEY record. Implementations cannot assume that the key tag uniquely identifies DNSKEY RR.
Except for Algorithm 1, the key tags of all DNSKEY algorithm types are the same (see Appendix B.1 for the key tag definition of Algorithm 1). First, divide RDATA (wire format) into a series of 2 byte groups. Then add these groups, ignoring any carry.
A reference implementation of the key tag algorithm is an ANSI C function, as shown below, using the RDATA part of DNSKEY RR as input. It is not necessary to use the following reference code verbatim, but the value of the key tag must be the same as the value generated by the reference implementation for the same input.
Please note that the algorithm for calculating the key tag is almost the same as the checksum algorithm used in other Internet protocols that we are familiar with, but not exactly the same. The key tag must be calculated using the algorithm described here, rather than using a complementary checksum.
The following ANSI C reference implementation calculates the value of the key tag. This reference implementation is applicable to all algorithm types except Algorithm 1 (see Appendix B.1). The input is the connection format of the RDATA part of DNSKEY RR. The code is written for clarity, not efficiency.
/*
* 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 of Algorithm 1 (RSA/MD5)
Due to historical reasons, the definition of the key tag of Algorithm 1 (RSA/MD5) is different from the key tag of all other algorithms. For DNSKEY RR using Algorithm 1, the key tag is defined as the most effective 16 bits of the 24 bits of the public key modulus (that is, the 4th to the last byte and the 3rd to the last byte of the public key modulus).
Please note that algorithm 1 is not recommended.