draft-ietf-dnsext-dnssec-protocol-01.txt

bind-3.2.

Arends, et al.          Expires September 1, 2003               [Page 6]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


2.2 Including SIG RRs in a Zone

   For each authoritative RRset in the zone (which excludes NS RRsets at
   delegation points and glue RRsets), there MUST be at least one SIG
   record that meets all of the following requirements:

   o  The SIG owner name is equal to the RRset owner name;

   o  The SIG class is equal to the RRset class;

   o  The SIG Type Covered field is equal to the RRset type;

   o  The SIG Original TTL field is equal to the TTL of the RRset;

   o  The SIG RR's TTL is equal to the TTL of the RRset;

   o  The SIG Labels field is equal to the number of labels in the RRset
      owner name, not counting the null root label or any wildcard
      label;

   o  The SIG Signer's Name field is equal to the name of the zone
      containing the RRset; and

   o  The SIG Algorithm, Signer's Name, and Key Tag fields identify a
      zone key KEY record at the zone apex.

   The process for constructing the SIG RR for a given RRset is
   described in [10].  An RRset MAY have multiple SIG RRs associated
   with it.

   A SIG RR itself MUST NOT be signed, since signing a SIG RRset would
   add no value and would create an unterminated dependency loop in the
   signing process.

   The NS RRset which appears at the zone apex name MUST be signed, but
   the NS RRsets which appear at delegation points (that is, the NS
   RRsets in the parent zone which delegate the name to the child zone's
   name servers) MUST NOT be signed.  Glue address RRsets associated
   with delegations MUST NOT be signed.

   The difference between the set of owner names which require SIG
   records and the set of owner names which require NXT records is
   subtle and worth highlighting.  SIG records are present at the owner
   names of all authoritative RRsets.  NXT records are present at the
   owner names of all names for which the signed zone is authoritative
   and also at the owner names of delegations from the signed zone to
   its children.  Neither NXT nor SIG records are present (in the parent
   zone) at the owner names of glue address RRsets.  Note, however, that



Arends, et al.          Expires September 1, 2003               [Page 7]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   this distinction is for the most part only visible during the zone
   signing process, because NXT RRsets are authoritative data, and
   therefore are signed, thus any owner name which has an NXT RRset will
   have SIG RRs as well in the signed zone.

2.3 Including NXT RRs in a Zone

   Each owner name in the zone MUST have an NXT resource record, except
   for the owner names of any glue address RRsets.  The process for
   constructing the NXT RR for a given name is described in [10].

2.4 Including DS RRs in a Zone

   The DS resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD be present at a delegation point when the
   child zone is signed.  The DS RRset MAY contain multiple records,
   each referencing a key used by the child zone to sign its apex KEY
   RRset.  All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
   appear at non-delegation points nor at a zone's apex.

   A DS RR SHOULD point to a KEY RR which is present in the child's apex
   KEY RRset, and the child's apex KEY RRset SHOULD be signed by the
   corresponding private key.

   Construction of a DS RR requires knowledge of the corresponding KEY
   RR in the child zone, which implies communication between the child
   and parent zones.  This communication is an operational matter not
   covered by this document.

2.5 Changes to the CNAME Resource Record.

   If a CNAME RRset is present at a name in a signed zone, appropriate
   SIG and NXT RRsets are REQUIRED at that name.  Other types MUST NOT
   be present at that name.

   This is a modification to the original CNAME definition given in [1].
   The original definition of the CNAME RR did not allow any other types
   to co-exist with a CNAME record, but a signed zone requires NXT and
   SIG RRsets for every authoritative name.  To resolve this conflict,
   the definition of the CNAME resource record is hereby modified to
   allow for the co-existence of NXT and SIG RRsets.

2.6 Example of a Secure Zone

      {{secure zone here}}

      Editors' note: Zone file example deferred pending hackery to add
      zone files in a format usable by xml2rfc.  Goal here is to show a



Arends, et al.          Expires September 1, 2003               [Page 8]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


      (small) complete signed zone.

   The apex KEY set includes two KEY RRs, and the KEY RDATA Flags
   indicate that each of these KEY RRs is a zone key.  The first zone
   KEY is used to sign the apex KEY RRset, and a DS record for this key
   is provided to the parent zone.  The second zone KEY is used to sign
   all the other RRsets in the zone.  A non-zone KEY RR is also stored
   at "host1.example.com"; this KEY might be used by SIG(0) to
   authenticate transactions from this host.

   The zone includes a wildcard entry "*.a.example.com".  Note that the
   "*.a.example.com" name is used in constructing NXT chains, and that
   the SIG covering the "*.a.example.com" MX RRset has a label count of
   3.

   The zone also includes two delegations.  The delegation to
   "insecure.example.com" includes an NS RRset, glue address records,
   and an NXT RR, but note that only the NXT RRset is signed.  The
   "secure.example.com" delegation provides a DS RR, and note that only
   NXT and DS RRsets are signed.































Arends, et al.          Expires September 1, 2003               [Page 9]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


3. Serving

   This section describes the behavior of a security-aware authoritative
   name server.  A security-aware authoritative name server MUST support
   the EDNS0 [6] message size extension, MUST support a message size of
   at least 1220 octets, and SHOULD support a message size of 4000
   octets [8].  Since functions specific to security-aware recursive
   name servers included components of both resolving and serving,
   issues specific to security-aware recursive name servers are
   described in Section 4.

   Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR
   DO [7] bit set to one, a security-aware authoritative name server for
   a signed zone MUST include additional SIG, NXT, and DS RRs according
   to the following rules:

   o  SIG RRs which can be used to authenticate a response MUST be
      included in the response automatically according to the rules in
      Section 3.1;

   o  NXT RRs which can be used to provide authenticated denial of
      existence MUST be included in the response automatically according
      to the rules in Section 3.3;

   o  Either DS RRs or an NXT RR proving that no DS RRs exist MUST be
      included in referrals automatically according to the rules in
      Section 3.4.

   DNSSEC does not change the DNS zone transfer protocol.  Zone transfer
   requirements are reviewed in Section 3.6.

   A security-aware name server which receives a DNS query which does
   not include the EDNS OPT pseudo-RR, or which has the DO bit set to
   zero, MUST treat the SIG, KEY, and NXT RRs as it would any other
   RRset, and MUST NOT perform any of the additional processing
   described above.  Since the DS RR type has the peculiar property of
   only existing in the parent zone at delegation points, DS RRs always
   require some special processing, as described in Section 3.5.

3.1 Including SIG RRs in a Response

   When a query has the DO bit set to one, the authoritative name server
   SHOULD attempt to send SIG RRs which can be used to authenticate the
   RRsets in the response.  Inclusion of SIG RRs in a response is
   subject to the following rules:

   o  When a signed RRset is placed in the Answer section, its SIG RRs
      are also placed in the Answer section.  The SIG RRs have a higher



Arends, et al.          Expires September 1, 2003              [Page 10]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


      priority for inclusion than any other RRsets which may need to be
      included.  If space does not permit the inclusion of these SIG
      RRs, the response MUST be considered truncated, and the TC bit
      MUST be set.

   o  When a signed RRset is placed in the Authority section, its SIG
      RRs are also placed in the Authority section.  The SIG RRs have a
      higher priority for inclusion than any other RRsets that may need
      to be included.  If space does not permit the inclusion of these
      SIG RRs, the response MUST be considered truncated, and the TC bit
      MUST be set.

   o  When a signed RRset is placed in the Additional section, its SIG
      RRs are also placed in the Additional section.  If space does not
      permit the inclusion of these SIG RRs, the response MUST NOT be
      considered truncated just because these SIG RRs didn't fit.


3.2 Including KEY RRs In a Response

   When a query has the DO bit set to one and requests the SOA or NS RRs
   at the apex of a signed zone, then a security-aware authoritative
   name server for that zone SHOULD return the KEY RRset with the same
   name in the Additional section.  If Additional section processing
   results in more data than will fit in the response message, address
   glue RRs have higher priority than KEY RRs.  SIG RR(s) associated
   with the KEY RRset SHOULD also be included in the Additional section
   (see Section 3.1).

      Editors' note: Didn't the WG decide that DS RR removes the need
      for Additional section processing for KEY RRs?  If so, this
      subsection should be deleted.


3.3 Including NXT RRs In a Response

      Editors' note: This whole section uses the phrase "query name
      exists", which is somewhat ambiguous when discussing internal
      nodes with no RRs.  We are reasonably certain that, as used here,
      the phrase only refers to names which are the owner name for least
      one RR.   Better phrasing needed.

   When a query has the DO bit set to one, security-aware authoritative
   name servers for a signed zone MUST include NXT RRs in each of the
   following cases:

   Case 1: The query name exists, but the requested RR type does not
      exist.



Arends, et al.          Expires September 1, 2003              [Page 11]

Internet-Draft        DNSSEC Protocol Modifications           March 2003


   Case 2: The query name does not exist, and no wildcard can be
      expanded to answer the query.

   Case 3: The query name does not exist, but a wildcard can be expanded
      to positively answer the query.

   Note that, in each case, a set of NXT RRs is included to provide
   authenticated denial of existence.

   NXT RRs are also included in a referral response when no DS RR is
   present; in this case, the NXT RR proves that no DS RR exists for the
   delegation.  Referrals are discussed in more detail in Section 3.4.

3.3.1 Case 1: Query Name Exists, but RR Type Not Present

   If the query name exists but the requested RR type is not present at
   the name, then the NXT RR associated with the query name MUST be
   included in the Authority section.  Any SIG(s) associated with the
   NXT RRset are also included in the Authority section (see Section
   3.1) If space does not permit the inclusion of the NXT RR (or its
   associate SIG RRs), the response MUST be considered truncated and the
   TC bit MUST be set.

   Note that, since the query name exists, no wildcard expansion applies
   to this query, and a single NXT RR suffices to prove the requested
   type does not exist.

3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches

   If the query name does not exist, and no wildcard expansion matches
   the query, then the Authority section of the response MUST include
   the following NXT RRs:

   o  An NXT RR proving that there was no exact match for the name; and

   o  An NXT RR proving that there was no wildcard which would have
      matched the query.

   If space does not permit the inclusion of these NXT RRs, the response
   MUST be considered truncated, and the TC bit MUST be set.  Any SIG(s)
   associated with the NXT RRsets MUST also be included in the Authority
   section (see Section 3.1).

      Editors' note: Should lack of space to include the SIGs cause the
      packet to be considered truncated?

   Appendix A provides an algorithm which computes the appropriate NXT