draft-ietf-dnsext-dnssec-records-03.txt

bind-3.2.

   the signature and uses the Algorithm, the Signer's Name, and the Key
   Tag to identify the public key (KEY RR) that can be used to verify
   the signature.

   The SIG RR may cover a transaction instead of an RRset.  In this
   case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear
   in any zone, and its use and processing are outside the scope of this
   document.  Please see [7] for further details.

   The Type value for the SIG RR type is 24.

   The SIG RR MUST have the same class as the RRset it covers.

   The SIG RR TTL value SHOULD match the TTL value of the RRset it
   covers.

3.1 SIG RDATA Wire Format

   The RDATA for a SIG RR consists 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            |                               /



Arends, et al.           Expires August 26, 2003                [Page 9]

Internet-Draft           DNSSEC Resource Records           February 2003


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Signature                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


3.1.1 The Type Covered Field

   The Type Covered field identifies the type of the RRset which is
   covered by this SIG record.

   If Type Covered field has a value of 0, the record is referred to as
   a transaction signature; please see [7] for further details.

3.1.2 The Algorithm Number Field

   The Algorithm Number field identifies the cryptographic algorithm
   used to create the signature.  A list of DNSSEC algorithm types can
   be found in Appendix A.1

3.1.3 The Labels Field

   The Labels field specifies the number of labels in the original SIG
   RR owner name.  It is included to handle signatures associated with
   wildcard owner names.

   To validate a signature, the validator requires the original owner
   name that was used when the signature was created.  If the original
   owner name contains a wildcard label ("*"), the owner name may have
   been expanded by the server during the response process, in which
   case the validator will need to reconstruct the original owner name
   in order to validate the signature.  [11] describes how to use the
   Labels field to reconstruct the original owner name.

   The value of the Label field MUST NOT count either the null (root)
   label that terminates the owner name or the wildcard label (if
   present).  The value of the Label field MUST be less than or equal to
   the number of labels in the SIG owner name.  For example,
   "www.example.com." has a Label field value of 3, and "*.example.com."
   has a Label field value of 2.  Root (".") has a Label field value of
   0.

   Note that, although the wildcard label is not included in the count
   stored in the Label field of the SIG RR, the wildcard label is part
   of the RRset's owner name when generating or verifying the signature.



Arends, et al.           Expires August 26, 2003               [Page 10]

Internet-Draft           DNSSEC Resource Records           February 2003


3.1.4 Original TTL Field

   The Original TTL field specifies the TTL of the covered RRset as it
   appears in the authoritative zone.

   The Original TTL field is necessary because a caching resolver
   decrements the TTL value of a cached RRset.  In order to validate a
   signature, a resolver requires the original TTL.  [11] describes how
   to use the Original TTL field value to reconstruct the original TTL.

   The Original TTL value MUST be greater than or equal to the TTL value
   of the SIG record itself.

3.1.5 Signature Expiration and Inception Fields

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The SIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.

   Signature Expiration and Inception field values are in POSIX.1 time
   format, a 32-bit unsigned number of seconds elapsed since 1 January
   1970 00:00:00 UTC, ignoring leap seconds, in network byte order.  The
   longest interval which can be expressed by this format without
   wrapping is approximately 136 years.  A SIG RR can have an Expiration
   field value which is numerically smaller than the Inception field
   value if the expiration field value is near the 32-bit wrap-around
   point or if the signature is long lived.  Because of this, all
   comparisons involving these fields MUST use "Serial number
   arithmetic" as defined in [4].  As a direct consequence, the values
   contained in these fields cannot refer to dates more than 68 years in
   either the past or the future.

3.1.6 The Key Tag Field

   The Key Tag field contains the key tag value of the KEY RR that
   validates this signature.  The process of calculating the Key Tag
   value is given in Appendix B.

3.1.7 The Signer's Name Field

   The Signer's Name field value identifies the owner name of the KEY RR
   used to authenticate this signature.  The Signer's Name field MUST
   contain the name of the zone of the covered RRset, unless the Type
   Covered field value is 0.  A sender MUST NOT use DNS name compression
   on the Signer's Name field when transmitting a SIG RR.  A receiver
   which receives a SIG RR containing a compressed Signer's Name field
   SHOULD decompress the field value.



Arends, et al.           Expires August 26, 2003               [Page 11]

Internet-Draft           DNSSEC Resource Records           February 2003


3.1.8 The Signature Field

   The Signature field contains the cryptographic signature which covers
   the SIG RDATA (excluding the Signature field) and the RRset specified
   by the SIG owner name, SIG class, and SIG Type Covered field.

3.1.8.1 Signature Calculation

   A signature covers the SIG RDATA (excluding the Signature Field) and
   covers the RRset specified by the SIG owner name, SIG class, and SIG
   Type Covered field.  The RRset is in canonical form (see Section 6)
   and the set RR(1),...RR(n) is signed as follows:

         signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where

            "|" denotes concatenation;

            SIG_RDATA is the wire format of the SIG RDATA fields with
               the Signer's Name field in canonical form and
               the Signature field excluded;

            RR(i) = owner | class | type | 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 SIG RR;

               Each RR MUST have the same class as the SIG RR;

               Each RR in the RRset MUST have the RR type listed in the
               SIG RR's Type Covered field;

               Each RR in the RRset MUST have the TTL listed in the SIG
               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.


3.2 The SIG RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Type Covered field value is represented either as an unsigned



Arends, et al.           Expires August 26, 2003               [Page 12]

Internet-Draft           DNSSEC Resource Records           February 2003


   decimal integer or as the mnemonic for the covered RR type.

   The Algorithm field value is represented either as an unsigned
   decimal  integer or as an algorithm mnemonic as specified in Appendix
   A.1.

   The Labels field value is represented as an unsigned decimal integer.

   The Original TTL field value is represented as an unsigned decimal
   integer.

   The Signature Inception Time and Expiration Time field values are
   represented in the form YYYYMMDDHHmmSS in UTC, where:

      YYYY is the year (0000-9999, but see Section 3.1.5);

      MM is the month number (01-12);

      DD is the day of the month (01-31);

      HH is the hour in 24 hours notation (00-23);

      mm is the minute (00-59);

      SS is the second (00-59).

   The Key Tag field is represented as an unsigned decimal integer.

   The Signer's Name field value is represented as a fully qualified
   domain name.

   The Signature field is represented as a Base64 encoding of the
   signature.  Whitespace is allowed within the Base64 text.  For a
   definition of Base64 encoding see [3] Section 5.2.

3.3 SIG RR Example

   The following a SIG RR stores the signature for the A RRset of
   host.example.com:

   host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )




Arends, et al.           Expires August 26, 2003               [Page 13]

Internet-Draft           DNSSEC Resource Records           February 2003


   The first four fields specify the owner name, TTL, Class, and RR type
   (SIG).  The "A" represents the Type Covered field.  The value 5
   identifies the Algorithm used (RSA-SHA1) to create the signature.
   The value 3 is the number of Labels in the original owner name.  The
   value 86400 in the SIG RDATA is the Original TTL for the covered A
   RRset.  20030322173103 and 20030220173103 are the expiration and
   inception dates, respectively.  2642 is the Key Tag, and example.com.
   is the Signer's Name.  The remaining text is a Base64 encoding of the
   signature.

   Note that combination of SIG RR owner name, class, and Type Covered
   indicate that this SIG covers the "host.example.com" A RRset.  The
   Label value of 3 indicates that no wildcard expansion was used.  The
   Algorithm, Signer's Name, and Key Tag indicate this signature can be
   authenticated using an example.com zone KEY RR whose algorithm is 5
   and key tag is 2642.



































Arends, et al.           Expires August 26, 2003               [Page 14]

Internet-Draft           DNSSEC Resource Records           February 2003


4. The NXT Resource Record

   The NXT resource record lists two separate things: the owner name of
   the next authoritative RRset in the canonical ordering of the zone,
   and the set of RR types present at the NXT RR's owner name.  The
   complete set of NXT RRs in a zone both indicate which authoritative
   RRsets exist in a zone and also form a chain of authoritative owner
   names in the zone.  This information is used to provide authenticated
   denial of existence for DNS data, as described in [11].

   The type value for the NXT RR is 30.

   The NXT RR is class independent.

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 owner name of the next
   authoritative RRset in the canonical ordering of the zone; see
   Section 6.1 for an explanation of canonical ordering.  The value of
   the Next Domain Name field in the last NXT record in the zone is the
   name of the zone apex (the owner name name of the zone's SOA RR).

   A sender MUST NOT use DNS name compression on the Next Domain Name
   field when transmitting an NXT RR.  A receiver which receives an NXT
   RR containing a compressed Next Domain Name field SHOULD decompress
   the field value.

   Owner names of non-authoritative RRsets (such as 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 Map Field

   The Type Bit Map field identifies the RRset types which exist at the
   NXT RR's owner name.



Arends, et al.           Expires August 26, 2003               [Page 15]

Internet-Draft           DNSSEC Resource Records           February 2003


   Each bit in the Type Bit Map field corresponds to an RR type.  Bit 1
   corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
   and so forth.  If a bit is set to 1, it indicates that an RRset of
   that type is present for the NXT's owner name.  If a bit is set to 0,
   it indicates that no RRset of that type present for the NXT's owner
   name.

   Bit 1 MUST NOT indicate glue address records.

   Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can
   never appear in zone data.

   Trailing zero octets MUST be omitted.  The length of the Type Bit Map
   field varies, and is determined by the type code with the largest
   numerical value among the set of RR types present at the NXT RR's
   owner name.  Trailing zero octets not specified MUST be interpreted
   as zero octets.

   The above Type Bit Map format MUST NOT be used when an RR type code
   with numerical value greater than 127 is present.

   Bit 0 in the Type Bit Map field indicates the Type Bit Map format.  A
   value of 0 in bit 0 denotes the format described above, therefore bit
   0 MUST have a value of 0.  The format and meaning of a Type Bit Map
   with a value of 1 in bit 0 is undefined.

4.1.3 Inclusion of Wildcard Names in NXT RDATA

   If a wildcard owner name appears in a zone, the wildcard label ("*")
   is treated as a literal symbol and is treated the same as any other
   owner name for purposes of generating NXT RRs.  Wildcard owner names
   appear in the Next Domain Name field without any wildcard expansion.
   [11] describes the impact of wildcards on authenticated denial of
   existence.

4.2 The NXT RR Presentation Format

   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 either as a sequence of RR type
   mnemonics or as a sequence of unsigned decimal integers denoting the
   RR type codes.

4.3 NXT RR Example

   The following NXT RR identifies the RRsets associated with



Arends, et al.           Expires August 26, 2003               [Page 16]

Internet-Draft           DNSSEC Resource Records           February 2003


   alfa.example.com.  and identifies the next authoritative name after
   alfa.example.com.

   alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT

   The first four text fields specify the name, TTL, Class, and RR type
   (NXT).  The entry host.example.com.  is the next authoritative name
   after alfa.example.com.  (in canonical order).  The A, MX, SIG and
   NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated
   with the name alfa.example.com.

   Note the NXT record can be used for authenticated denial of
   existence.  If the example NXT record were authenticated, it could be
   used to prove that beta.example.com.  does not exist, or could be
   used to prove there is no AAAA record associated with
   alfa.example.com.  Authenticated denial of existence is discussed in
   [11]