diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-00.txt new file mode 100644 index 0000000000..03b95d793e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-00.txt @@ -0,0 +1,1342 @@ +Network Working Group R. Arends +Internet-Draft Nominum +Expires: August 23, 2002 M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 22, 2002 + + + Resource Records for DNS Security Extensions + draft-ietf-dnsext-dnssec-records-00 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 23, 2002. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The DNS Security Extensions (DNSSEC) introduce four resource records: + the KEY, DS, SIG, and NXT resource records. This document defines + the purpose and the RDATA format for each of these records. This + document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications that + + + +Arends, et al. Expires August 23, 2002 [Page 1] + +Internet-Draft DNSSEC Resource Records February 2002 + + + provide source authentication for the DNS. This document obsoletes + RFC 2535 and incorporates changes from all updates to RFC 2535. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 DNSSEC Document Family . . . . . . . . . . . . . . . . . . 4 + 2. The Key Resource Record . . . . . . . . . . . . . . . . . 5 + 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6 + 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6 + 2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6 + 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 + 2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7 + 2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 + 3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10 + 3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 + 3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11 + 3.3 Calculating the signature . . . . . . . . . . . . . . . . 11 + 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13 + 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13 + 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13 + 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14 + 5. The DS Resource Record (placeholder) . . . . . . . . . . . 15 + 6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 16 + 6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 16 + 6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 + References . . . . . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22 + + + +Arends, et al. Expires August 23, 2002 [Page 2] + +Internet-Draft DNSSEC Resource Records February 2002 + + + A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 23 + Full Copyright Statement . . . . . . . . . . . . . . . . . 24 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 3] + +Internet-Draft DNSSEC Resource Records February 2002 + + +1. Introduction + + The reader to assumed to be familiar with common DNSSEC terminology + as defined in [13] and familiar with the basic DNS concepts described + in RFC1034 [1] and RFC1035 [2]. + + The DNS Security Extensions (DNSSEC) introduce four resource records: + KEY, DS, SIG, and NXT resource records. This document defines the + purpose of each resource record, the RDATA format, the ASCII + representation, and an example of each RR type is given. Sections 2- + 5 describe the KEY, DS, SIG, and NXT records. Section 6 describe the + DNSSEC header bits. + +1.1 DNSSEC Document Family + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication the Domain Name System (DNS). An + introduction to DNSSEC and definition of common terms can be found in + (RFC TBA). A description of DNS protocol modifications can be found + in (RFC TBA). This document defines the DNSSEC resource records. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 4] + +Internet-Draft DNSSEC Resource Records February 2002 + + +2. The Key Resource Record + + Public keys used by the DNS infrastructure are stored in KEY resource + records. A secure DNS zone will store its public key in a KEY RR and + this KEY RR can be used to authenticate other RR sets in the zone. + The KEY RR MAY also be used to store other types of DNS public keys, + such as the keys used by SIG(0) [10] or TKEY [9]. These public keys + are used to authenticate DNS messages such as a request to + dynamically update a DNS zone. + + The KEY RR MUST only be used for public keys used for DNS purposes, + all other uses are obsolete. The KEY RR plays an essential role in + the secure processing of DNS messages and is included in various + responses. The KEY RR MUST NOT be used to store certificates or + public keys that do not directly relate to the DNS infrastructure. + Examples of certificates and public keys that MUST NOT be stored in + the KEY RR include X.509 certificates, IPSEC public keys, and SSH + public keys. + + The type number for the KEY RR is 25. + + The KEY RR is class independent. + +2.1 KEY RDATA Wire Format + + The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol + Octet, a one octet Algorithm number, and the public key. + + 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". Bits 0-6 and 8-15 + are reserved for future use. Bits 0-6 and 8-15 MUST be set to 0 and + MUST be ignored during processing. + + The zone key flag (bit 7) determines whether the KEY holds a DNS zone + key. If bit 7 is 1, then the KEY record holds a DNS zone key. If + bit 7 is 0, then the KEY record holds some other type of DNSSEC + + + +Arends, et al. Expires August 23, 2002 [Page 5] + +Internet-Draft DNSSEC Resource Records February 2002 + + + infrastructure public key, such as a public key used by SIG(0) or + TKEY. Resolvers MUST check the zone key flag in order to determine + if the KEY record holds a DNS zone key. + +2.1.1.1 Explanation for Choice of Bit 7 + + The choice of bit 7 as the zone key flag was made in order to provide + backwards compatibility with an earlier version of the KEY record. + This earlier version was defined in [6] and [15] eliminated all flags + except the bit 7 zone key flag. + +2.1.2 The Protocol Octet Field + + The Protocol Octet value MUST be 3. Name servers and resolvers + SHOULD reject KEY records with a Protocol Octet value other than 3. + +2.1.2.1 Explanation for a Fixed Value Protocol Octet Field + + The Protocol Octet field is included for backwards compatibility with + an earlier version of the KEY record. This earlier version of the + KEY record was defined in [6] and [15] restricted the possible + Protocol Octet values to 3. + +2.1.3 The Algorithm and Public Key Fields + + The Algorithm Field identifies the public key's cryptographic + algorithm and determines the format of the Public Key Field. + + Algorithm values are defined in separate documents. The following + table shows the currently defined Algorithm formats: + + VALUE Algorithm RFC STATUS + 0 Reserved - - + 1 RSA/MD5 RFC 2536 NOT RECOMMENDED + 2 Diffie-Hellman RFC 2539 OPTIONAL + 3 DSA RFC 2536 MANDATORY + 4 elliptic curve - reserved + 5 RSA/SHA1 RFC 3110 MANDATORY + 6-251 available for assignment - + 252 reserved - indirect keys + 253 private - domain name + 254 private - OID + 255 reserved - - + + EDITORS NOTE: indirect keys (252), private keys 253/254 and the + implication of making a key MANDATORY need further clarification. + This clarification will be in the next version of this document. + + + + +Arends, et al. Expires August 23, 2002 [Page 6] + +Internet-Draft DNSSEC Resource Records February 2002 + + +2.2 The KEY RR Presentation Format + + A KEY RR may appear as a single line. The presentation format of the + RDATA portion is as follows: + + The Flag field is represented as an unsigned integer. + + The Protocol Octet field is represented as the unsigned integer 3. + + The Algorithm Field is represented as an unsigned integer or as + mnemonic specified. The mnemonic is listed in the document defining + the algorithm. + + The Public Key Field is a Base 64 encoding of the Public Key Field. + +2.3 KEY RR Examples + +2.3.1 Example 1 + + The following KEY RR stores a DNS zone key for isi.edu. + + isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf + + xxDw==) + + 256 indicates the flags field has the zone key bit is set. 3 is the + fixed Protocol Octet value. 5 indicates the public key algorithm is + RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the + public key and the format of the public key is defined in [12]. + + Resolvers might use this public key to authenticate signed RR sets + such as the A RR set for www.isi.edu. The authentication process + used by resolvers is described in [14]. + +2.3.2 Example 2 + + The following KEY RR stores a public key used by SIG(0) + + ddnskey.isi.edu. 86400 IN KEY 0 3 3 ( AQPT0sh3WjVeRY3WqpBjtf + + xxDw==) + + 0 indicates the flags field does not have the zone key bit is not + set. 3 is the fixed Protocol Octet value. 5 indicates the public + key algorithm is DSA [7]. The remaining text is base 64 encoding of + the public key and the format of the public key is defined in [7]. + + This public key can be used to sign dynamic DNS updates for the + + + +Arends, et al. Expires August 23, 2002 [Page 7] + +Internet-Draft DNSSEC Resource Records February 2002 + + + isi.edu zone. The process is for signing the dynamic DNS updates is + described in [11]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 8] + +Internet-Draft DNSSEC Resource Records February 2002 + + +3. The SIG Resource Record + + The SIG or "signature" resource record (RR) is the fundamental way + that data is authenticated in the secure Domain Name System (DNS). + As such it is the heart of the security provided. + + The SIG RR authenticates an RRset [5] of a particular type, class, + and name and binds it to a time interval and the signer's name. The + signer is the key (and associated KEY record) from which the RR + originated. A SIG record can also be used for transaction security + [transaction ref/section]. This type of SIG is known as SIG(0) and + its RDATA is in the same format, with some values loosing their + meaning and given default values. The variations are mentioned in + [10]. + + The type number for the SIG RR type is 24. + + The SIG RR is class independent, but MUST have the same class as the + RRset it covers. The TTL for the SIG RR SHOULD be the same as the + RRset it covers. + +3.1 The SIG RDATA + + The RDATA portion of a SIG RR is as shown 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type covered | algorithm | labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | signature expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | signature inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | key tag | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + + | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + / / + / signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 9] + +Internet-Draft DNSSEC Resource Records February 2002 + + +3.1.1 The Type Covered Field + + For RRset SIGs, the type covered MUST be the same as the type of data + in the associated RRset. For SIG(0), this field MUST be zero [10] + +3.1.2 The Algorithm Number Field + + The Algorithm Number field in the RDATA is the same field as found in + the algorithm field of the KEY record RDATA [section 2.2.3]. + +3.1.3 The Labels Field + + The "labels" octet is an unsigned count of how many labels there are + in the original SIG RR owner name. This does not count null labels + for root and any initial "*" for a wildcard. The labels count MUST + be less than or equal to the number of labels in the SIG owner name. + +3.1.4 Original TTL Field + + The "original TTL" field is included in the RDATA portion to avoid + authentication problems caused by caching servers decrementing the + real TTL field. The signatures covers this field (as part of the SIG + RDATA) while the TTL field is not. In a SIG(0), the Original TTL + field (and the TTL field) MUST be zero. + + The "original TTL" value MUST be greater than or equal to the TTL of + the SIG record itself. + +3.1.5 Signature Expiration and Inception Fields + + The SIG is valid from the "signature inception" time until the + "signature expiration" time. Both are unsigned numbers of seconds + since the start of 1 January 1970, GMT, ignoring leap seconds. Ring + arithmetic is used as for DNS SOA serial numbers [3], which means + that these times can never be more than about 68 years in the past or + the future. This means that these times are ambiguous modulo ~136.09 + years. + + A SIG RR may have an expiration time numerically less than the + inception time if the expiration time is near the 32-bit wrap around + point and/or the signature is long lived. + +3.1.6 The Key Tag Field + + The "Key Tag" is a two-octet quantity that is used to efficiently + select between multiple keys that may be applicable. The Key Tag + value may differ depending on the key algorithm in use, as described + in Appendix (A). + + + +Arends, et al. Expires August 23, 2002 [Page 10] + +Internet-Draft DNSSEC Resource Records February 2002 + + +3.1.7 The Signer's Name Field + + The signer's name field MUST contain the name of the zone to which + the data and signature belong. The combination of signer's name, key + tag, and algorithm MUST identify a zone key if the SIG is to be + considered material. In a SIG(0), the signer's name MUST be the + originating host of the DNS message [10]. + +3.1.8 The Signature Field + + The actual signature portion of the SIG RR binds the other RDATA + fields to the RRset of the "type covered" RRs with that owner name + and class. + +3.2 The NXT RR Presentation Format (placeholder) + + This section will be here in the next revision. + +3.3 Calculating the signature + + To generate the signature over an RRset, a data sequence is + constructed as follows (where "|" is concatenation): + + signature = sign(RDATA | RR(1) | RR(2)... ) + + RR(N) = name | class | type | original TTL(stored in SIG RDATA) | + RDATA + + To generate a signature over a DNS message (SIG(0)), a data sequence + is constructed as follows: + + If the DNS message is sent via UDP: + + signature = sign(RDATA | full query | full response - SIG(0)) + + If the DNS message is sent via TCP, the first packet's SIG(0) is + calculated as above, with each additional packet (if any) calculated + as follows: + + signature = sign(RDATA | DNS payload - SIG(0) | previous packet) + + where "previous packet" is the previous DNS packet with accompanying + SIG(0), but without any other headers (i.e. TCP/IP, etc.). + + In all the examples, + + RDATA is the wire format of all the RDATA fields in the SIG RR itself + (including the canonical form of the signer's name) before but not + + + +Arends, et al. Expires August 23, 2002 [Page 11] + +Internet-Draft DNSSEC Resource Records February 2002 + + + including the signature, and + + RR(num) is the RRset with the same owner name and class and type + covered as the SIG RR in canonical form. + + Name is the Fully Qualified Domain Name (FQDN) in canonical form. + + The canonical form for a Resource Record (RR) is the wire format of + the RR. Names MUST be expanded (no name compression allowed). Name + characters MUST be set to lower case. Wildcards MUST be unexpanded. + The RR MUST have the original TTL. + + How this data sequence is processed into the signature is algorithm + dependent. These algorithm dependent formats and procedures are + described in separate documents. + + SIGs SHOULD NOT be generated for any "meta-type" such as ANY, AXFR, + etc. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 12] + +Internet-Draft DNSSEC Resource Records February 2002 + + +4. The NXT Resource Record + + The collection of NXT or "next" resource records (RR) is used to + indicate what names and RRsets [5] exist in a zone. + + The NXT RR lists the next canonical name in the zone and lists what + RR types are present for the current name of the NXT RR. + + The set of NXT RRs in a zone is a chain of all authoritative names in + that zone. + + Glue address records MUST NOT be covered by a NXT RR. + + The type number for the NXT RR is 30. + + The NXT RR is class independant. + + The NXT RR TTL SHOULD NOT exceed the zone minimum TTL. + +4.1 NXT RDATA Wire Format + + The RDATA of the NXT RR is as shown 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 map / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The "next domain name" field contains the next owner name in + canonical order. Canonical order means sorted by label, highest + level label first. The "next domain name" field of the NXT RR at the + last name in the zone contains the zone apex name. + + Glue address record names MUST NOT be covered by the "next domain + name" field. + + The "next domain name" field allows message compression. + +4.1.2 The Type Bit Map Field + + The "type bit map" field format contains a single bit per RR type for + RRsets with the same owner name as the NXT RR. A one bit indicates + + + +Arends, et al. Expires August 23, 2002 [Page 13] + +Internet-Draft DNSSEC Resource Records February 2002 + + + that an RRset of that type exist for the owner name. A zero bit + indicates that no RRset of that type exist for the owner name. + + The first bit represents RR type zero. RR type number zero is not + assigned and the corresponding bit MUST be zero. If the zero bit is + one, it indicates that an unspecified format is used. This format is + not used when there exist an RR type number greater than 127. + + The OPT RR [8] type MUST NOT be covered by the type bit map field + since it is not part of the zone data. The corresponding OPT RR type + bit (40) MUST be zero. + + Trailing zero octets MUST be omitted. Trailing zero octets not + specified MUST be interpreted as zero octets. Glue address record + types MUST NOT be covered by the type bit map field. + +4.2 The NXT RR Presentation Format + + A NXT RR may appear as a single line. The presentation format of the + RDATA portion is as follows: + + The "next domain name" field is represented as a domain name. + + The "type bit map" field is represented as a sequence of RR type + mnemonics or as an unsigned integer. + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 14] + +Internet-Draft DNSSEC Resource Records February 2002 + + +5. The DS Resource Record (placeholder) + + [This section will be finalised once DS has WG consensus and is + proposed standard] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 15] + +Internet-Draft DNSSEC Resource Records February 2002 + + +6. DNSSEC message bits + + There are 3 new bits allocated for use with DNSSEC. The DO bit is + used to indicate to a server that the resolver is able to accept + DNSSEC security RRs (KEY SIG NXT DS). The CD and AD bits are used to + indicate if non-authenticated data is accepted, and if data is + authenticated. + +6.1 The AD and CD Header Bits + + Two bits are allocated in the header section. The CD (checking + disabled) bit and the AD (authentic data) bit. + + The Header contains the following fields: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The usage of the CD and AD bits are defined in [14] + +6.2 The DO Extended Flags Field Bit + + The DO (DNSSEC OK) bit is allocated from the EDNS0 [8] extended flags + field. In the context of the OPT RR, the DO bit is the most + significant bit in the 3rd octet of the TTL field. + + The TTL field of the OPT RR is defined as follows: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | EXTENDED-RCODE | VERSION | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |DO| Z | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + + +Arends, et al. Expires August 23, 2002 [Page 16] + +Internet-Draft DNSSEC Resource Records February 2002 + + + The usage of the DO bit is defined in [14] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 17] + +Internet-Draft DNSSEC Resource Records February 2002 + + +7. IANA Considerations + + This document clarifies the use of existing types and introduces no + new IANA considerations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 18] + +Internet-Draft DNSSEC Resource Records February 2002 + + +8. Security Considerations + + This document describes the format of resource records used by DNS + security. The threats facing DNS are described in a seperate + document and these records are used to help counter those threats. + The records themselves introduce no new security considerations, but + the protocol use of these records is described in a second document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 19] + +Internet-Draft DNSSEC Resource Records February 2002 + + +9. Acknowledgements + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 20] + +Internet-Draft DNSSEC Resource Records February 2002 + + +References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [6] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [10] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", + February 2002. + + [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC + Protocol", February 2002. + + [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in + progress), January 2002. + + + + +Arends, et al. Expires August 23, 2002 [Page 21] + +Internet-Draft DNSSEC Resource Records February 2002 + + +Authors' Addresses + + Roy Arends + Nominum, Inc. + 2385 Bay Street + Redwood City, CA 94063 + USA + + EMail: roy.arends@nominum.com + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-3460 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 22] + +Internet-Draft DNSSEC Resource Records February 2002 + + +Appendix A. Key Tag Calculation + + The key tag field in the SIG RR is just a means of more efficiently + selecting the correct KEY RR to use when there is more than one KEY + RR candidate available, for example, in verifying a signature. It is + possible for more than one candidate key to have the same tag, in + which case each must be tried until one works or all fail. The + following reference implementation of how to calculate the Key Tag, + for all algorithms other than algorithm 1, is in ANSI C. It is coded + for clarity, not efficiency. + + /* assumes int is at least 16 bits + first byte of the key tag is the most significant byte of return + value + second byte of the key tag is the least significant byte of + return value + */ + + int keytag ( + + unsigned char key[], /* the RDATA part of the KEY RR */ + unsigned int keysize, /* the RDLENGTH */ + ) + { + long int ac; /* assumed to be 32 bits or larger */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i&1) ? key[i] : key[i]<<8; + ac += (ac>>16) & 0xFFFF; + return ac & 0xFFFF; + } + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 23] + +Internet-Draft DNSSEC Resource Records February 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 23, 2002 [Page 24] +