Domain Name System Security (DNSSEC) Signing Authority
RFC 3008

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                      B. Wellington
Request for Comments: 3008                                       Nominum
Updates: 2535                                              November 2000
Category: Standards Track

         Domain Name System Security (DNSSEC) Signing Authority

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document proposes a revised model of Domain Name System Security
   (DNSSEC) Signing Authority.  The revised model is designed to clarify
   earlier documents and add additional restrictions to simplify the
   secure resolution process.  Specifically, this affects the
   authorization of keys to sign sets of records.

   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 [RFC2119].

1 - Introduction

   This document defines additional restrictions on DNSSEC signatures
   (SIG) records relating to their authority to sign associated data.
   The intent is to establish a standard policy followed by a secure
   resolver; this policy can be augmented by local rules.  This builds
   upon [RFC2535], updating section 2.3.6 of that document.

   The most significant change is that in a secure zone, zone data is
   required to be signed by the zone key.

   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
   security extensions [RFC2535] is assumed.

Wellington                  Standards Track                     [Page 1]
RFC 3008                DNSSEC Signing Authority           November 2000

2 - The SIG Record

   A SIG record is normally associated with an RRset, and "covers" (that
   is, demonstrates the authenticity and integrity of) the RRset.  This
   is referred to as a "data SIG".  Note that there can be multiple SIG
   records covering an RRset, and the same validation process should be
   repeated for each of them.  Some data SIGs are considered "material",
   that is, relevant to a DNSSEC capable resolver, and some are
   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
   validation.  Immaterial SIGs may have application defined roles.  SIG
   records may exist which are not bound to any RRset; these are also
   considered immaterial.  The validation process determines which SIGs
   are material; once a SIG is shown to be immaterial, no other
   validation is necessary.

   SIGs may also be used for transaction security.  In this case, a SIG
   record with a type covered field of 0 is attached to a message, and
   is used to protect message integrity.  This is referred to as a
   SIG(0) [RFC2535, RFC2931].

   The following sections define requirements for all of the fields of a
   SIG record.  These requirements MUST be met in order for a DNSSEC
   capable resolver to process this signature.  If any of these
   requirements are not met, the SIG cannot be further processed.
   Additionally, once a KEY has been identified as having generated this
   SIG, there are requirements that it MUST meet.

2.1 - Type Covered

   For a data SIG, the type covered MUST be the same as the type of data
   in the associated RRset.  For a SIG(0), the type covered MUST be 0.

2.2 - Algorithm Number

   The algorithm specified in a SIG MUST be recognized by the client,
   and it MUST be an algorithm that has a defined SIG rdata format.

2.3 - Labels

   The labels count MUST be less than or equal to the number of labels
   in the SIG owner name, as specified in [RFC2535, section 4.1.3].

2.4 - Original TTL

   The original TTL MUST be greater than or equal to the TTL of the SIG
   record itself, since the TTL cannot be increased by intermediate
   servers.  This field can be ignored for SIG(0) records.

Wellington                  Standards Track                     [Page 2]
RFC 3008                DNSSEC Signing Authority           November 2000

2.5 - Signature Expiration and Inception

   The current time at the time of validation MUST lie within the
   validity period bounded by the inception and expiration times.

2.6 - Key Tag

   There are no restrictions on the Key Tag field, although it is
   possible that future algorithms will impose constraints.

2.7 - Signer's Name

   The signer's name field of a data SIG 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.  The only exception that the