DNS Extensions                                                 R. Arends
Internet-Draft                                      Telematica Instituut
Expires: August 16, 2004                                       M. Larson
                                                                VeriSign
                                                              R. Austein
                                                                     ISC
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                       February 16, 2004

         Protocol Modifications for the DNS Security Extensions
                  draft-ietf-dnsext-dnssec-protocol-05

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 16, 2004.

Copyright Notice

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

Abstract

   This document is part of a family of documents which describe the DNS
   Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of new resource records and protocol modifications which
   add data origin authentication and data integrity to the DNS.  This
   document describes the DNSSEC protocol modifications.  This document

Arends, et al.          Expires August 16, 2004                 [Page 1]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   defines the concept of a signed zone, along with the requirements for
   serving and resolving using DNSSEC.  These techniques allow a
   security-aware resolver to authenticate both DNS resource records and
   authoritative DNS error indications.

   This document obsoletes RFC 2535 and incorporates changes from all
   updates to RFC 2535.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Background and Related Documents . . . . . . . . . . . . . .  4
   1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Editors' Notes . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.1 Open Technical Issues  . . . . . . . . . . . . . . . . . . .  4
   1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . .  4
   1.3.3 Typos and Minor Corrections  . . . . . . . . . . . . . . . .  5
   2.    Zone Signing . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1   Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . .  6
   2.2   Including RRSIG RRs in a Zone  . . . . . . . . . . . . . . .  6
   2.3   Including NSEC RRs in a Zone . . . . . . . . . . . . . . . .  7
   2.4   Including DS RRs in a Zone . . . . . . . . . . . . . . . . .  8
   2.5   Changes to the CNAME Resource Record.  . . . . . . . . . . .  8
   2.6   Example of a Secure Zone . . . . . . . . . . . . . . . . . .  9
   3.    Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.1   Authoritative Name Servers . . . . . . . . . . . . . . . . . 10
   3.1.1 Including RRSIG RRs in a Response  . . . . . . . . . . . . . 11
   3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11
   3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12
   3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14
   3.1.5 Responding to Queries for Type AXFR or IXFR  . . . . . . . . 16
   3.1.6 The AD and CD Bits in an Authoritative Response  . . . . . . 17
   3.2   Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17
   3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
   3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
   3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
   3.3   Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19
   4.    Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.1   EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.2   Signature Verification Support . . . . . . . . . . . . . . . 20
   4.3   Determining Security Status of Data  . . . . . . . . . . . . 21
   4.4   Preconfigured Public Keys  . . . . . . . . . . . . . . . . . 22
   4.5   Response Caching . . . . . . . . . . . . . . . . . . . . . . 22
   4.6   Handling of the CD and AD bits . . . . . . . . . . . . . . . 22
   4.7   Rate Limiting  . . . . . . . . . . . . . . . . . . . . . . . 23
   4.8   Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
   4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24
   4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24

Arends, et al.          Expires August 16, 2004                 [Page 2]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24
   5.    Authenticating DNS Responses . . . . . . . . . . . . . . . . 26
   5.1   Special Considerations for Islands of Security . . . . . . . 27
   5.2   Authenticating Referrals . . . . . . . . . . . . . . . . . . 27
   5.3   Authenticating an RRset Using an RRSIG RR  . . . . . . . . . 28
   5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29
   5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30
   5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31
   5.3.4 Authenticating A Wildcard Expanded RRset Positive
         Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   5.4   Authenticated Denial of Existence  . . . . . . . . . . . . . 32
   5.5   Authentication Example . . . . . . . . . . . . . . . . . . . 33
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 34
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 35
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
         Normative References . . . . . . . . . . . . . . . . . . . . 37
         Informative References . . . . . . . . . . . . . . . . . . . 38
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
   A.    Signed Zone Example  . . . . . . . . . . . . . . . . . . . . 40
   B.    Example Responses  . . . . . . . . . . . . . . . . . . . . . 46
   B.1   Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
   B.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47
   B.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . . 48
   B.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . . 49
   B.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . . 50
   B.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50
   B.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51
   B.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . . 52
   C.    Authentication Examples  . . . . . . . . . . . . . . . . . . 54
   C.1   Authenticating An Answer . . . . . . . . . . . . . . . . . . 54
   C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54
   C.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55
   C.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . . 55
   C.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . . 55
   C.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . . 55
   C.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56
   C.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56
   C.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . . 56
         Intellectual Property and Copyright Statements . . . . . . . 57

Arends, et al.          Expires August 16, 2004                 [Page 3]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

1. Introduction

   The DNS Security Extensions (DNSSEC) are a collection of new resource
   records and protocol modifications which add data origin
   authentication and data integrity to the DNS. This document defines
   the DNSSEC protocol modifications. Section 2 of this document defines
   the concept of a signed zone and lists the requirements for zone
   signing. Section 3 describes the modifications to authoritative name
   server behavior necessary to handle signed zones. Section 4 describes
   the behavior of entities which include security-aware resolver
   functions. Finally, Section 5 defines how to use DNSSEC RRs to
   authenticate a response.

1.1 Background and Related Documents

   The reader is assumed to be familiar with the basic DNS concepts
   described in RFC1034 [RFC1034] and RFC1035 [RFC1035].

   This document is part of a family of documents which define DNSSEC.
   An introduction to DNSSEC and definition of common terms can be found
   in [I-D.ietf-dnsext-dnssec-intro].  A definition of the DNSSEC
   resource records can be found in [I-D.ietf-dnsext-dnssec-records].

1.2 Reserved Words

   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.3 Editors' Notes

1.3.1 Open Technical Issues

1.3.2 Technical Changes or Corrections

   Please report technical corrections to dnssec-editors@east.isi.edu.
   To assist the editors, please indicate the text in error and point
   out the RFC that defines the correct behavior.  For a technical
   change where no RFC that defines the correct behavior, or if there's
   more than one applicable RFC and the definitions conflict, please
   post the issue to namedroppers.

   An example correction to dnssec-editors might be: Page X says
   "DNSSEC RRs SHOULD be automatically returned in responses."  This was
   true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
   DNSSEC RR types MUST NOT be included in responses unless the resolver
   indicated support for DNSSEC.

Arends, et al.          Expires August 16, 2004                 [Page 4]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

1.3.3 Typos and Minor Corrections

   Please report any typos corrections to dnssec-editors@east.isi.edu.
   To assist the editors, please provide enough context for us to find
   the incorrect text quickly.

   An example message to dnssec-editors might be: page X says "the
   DNSSEC standard has been in development for over 1 years".   It
   should read "over 10 years".

Arends, et al.          Expires August 16, 2004                 [Page 5]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

2. Zone Signing

   DNSSEC introduces the concept of signed zones.  A signed zone
   includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
   the rules specified in Section 2.1, Section 2.2, Section 2.3 and
   Section 2.4, respectively.  A zone that does not include these
   records according to the rules in this section is an unsigned zone.

   DNSSEC requires a change to the definition of the CNAME resource
   record [RFC1035].  Section 2.5 changes the CNAME RR to allow RRSIG
   and NSEC RRs to appear at the same owner name as a CNAME RR.

2.1 Including DNSKEY RRs in a Zone

   To sign a zone, the zone's administrator generates one or more
   public/private key pairs and uses the private key(s) to sign
   authoritative RRsets in the zone.  For each private key used to
   create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with
   the public component stored in the zone. A zone key DNSKEY RR MUST
   have the Zone Key bit of the flags RDATA field set to one -- see
   Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records].  Public keys
   associated with other DNS operations MAY be stored in DNSKEY RRs that
   are not marked as zone keys but MUST NOT be used to verify RRSIGs.

   If the zone is delegated and does not wish to act as an island of
   security, the zone MUST have at least one DNSKEY RR at the apex to
   act as a secure entry point into the zone.  This DNSKEY would then be
   used to generate a DS RR at the delegating parent (see
   [I-D.ietf-dnsext-dnssec-records]).

   DNSKEY RRs MUST NOT appear at delegation points.

2.2 Including RRSIG RRs in a Zone

   For each authoritative RRset in a signed zone, there MUST be at least
   one RRSIG record that meets all of the following requirements:

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

   o  The RRSIG class is equal to the RRset class;

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

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

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

   o  The RRSIG Labels field is equal to the number of labels in the

Arends, et al.          Expires August 16, 2004                 [Page 6]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

      RRset owner name, not counting the null root label and not
      counting the leftmost label if it is a wildcard;

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

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

   The process for constructing the RRSIG RR for a given RRset is
   described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
   multiple RRSIG RRs associated with it.

   An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
   would add no value and would create an infinite loop in the signing
   process.

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

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the parent zone's DS RRset and each additional
   algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset.

2.3 Including NSEC RRs in a Zone

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record. The
   process for constructing the NSEC RR for a given name is described in
   [I-D.ietf-dnsext-dnssec-records].

   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
   value field in the zone SOA RR.

   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRset at any particular owner name.  That is, the signing process
   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
   not the owner name of any RRset before the zone was signed.

   The type bitmap of every NSEC resource record in a signed zone MUST
   indicate the presence of both the NSEC record itself and its
   corresponding RRSIG record.

   The difference between the set of owner names that require RRSIG

Arends, et al.          Expires August 16, 2004                 [Page 7]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   records and the set of owner names that require NSEC records is
   subtle and worth highlighting.  RRSIG records are present at the
   owner names of all authoritative RRsets.  NSEC 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 NSEC nor RRSIG records are
   present (in the parent zone) at the owner names of glue address
   RRsets.  Note, however, that this distinction is for the most part is
   only visible during the zone signing process, because NSEC RRsets are
   authoritative data, and are therefore signed, thus any owner name
   which has an NSEC RRset will have RRSIG RRs as well in the signed
   zone.

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 public key in the child zone used to verify the
   RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
   RRsets MUST NOT appear at a zone's apex.

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

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
   (i.e., the NS RRset from the same zone containing the DS RRset).

   Construction of a DS RR requires knowledge of the corresponding
   DNSKEY 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
   RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
   name for secure dynamic update purposes is also allowed.  Other types
   MUST NOT be present at that name.

   This is a modification to the original CNAME definition given in
   [RFC1034].  The original definition of the CNAME RR did not allow any
   other types to coexist with a CNAME record, but a signed zone
   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
   this conflict, this specification modifies the definition of the
   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.

Arends, et al.          Expires August 16, 2004                 [Page 8]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

2.6 Example of a Secure Zone

   Appendix A shows a complete example of a small signed zone.

Arends, et al.          Expires August 16, 2004                 [Page 9]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

3. Serving

   This section describes the behavior of entities that include
   security-aware name server functions.  In many cases such functions
   will be part of a security-aware recursive name server, but a
   security-aware authoritative name server has some of the same
   requirements as a security-aware recursive name server does.
   Functions specific to security-aware recursive name servers are
   described in Section 3.2; functions specific to authoritative servers
   are described in Section 3.1.

   The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
   are as used in [RFC1034].

   A security-aware name server MUST support the EDNS0 [RFC2671] message
   size extension, MUST support a message size of at least 1220 octets,
   and SHOULD support a message size of 4000 octets [RFC3226].

   A security-aware name server that receives a DNS query that does not
   include the EDNS OPT pseudo-RR or that has the DO bit set to zero
   MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
   RRset, and MUST NOT perform any of the additional processing
   described below.  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.1.4.1.

   DNSSEC allocates two new bits in the DNS message header: the CD
   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
   is controlled by resolvers; a security-aware name server MUST copy
   the CD bit from a query into the corresponding response.  The AD bit
   is controlled by name servers; a security-aware name server MUST
   ignore the setting of the AD bit in queries.  See Section 3.1.6,
   Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details
   on the behavior of these bits.

3.1 Authoritative Name Servers

   Upon receiving a relevant query that has the EDNS [RFC2671] OPT
   pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
   name server for a signed zone MUST include additional RRSIG, NSEC,
   and DS RRs according to the following rules:

   o  RRSIG RRs that can be used to authenticate a response MUST be
      included in the response according to the rules in Section 3.1.1;

   o  NSEC RRs that can be used to provide authenticated denial of
      existence MUST be included in the response automatically according
      to the rules in Section 3.1.3;

Arends, et al.          Expires August 16, 2004                [Page 10]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
      be included in referrals automatically according to the rules in
      Section 3.1.4.

   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
   discusses zone transfer requirements.

3.1.1 Including RRSIG RRs in a Response

   When responding to a query that has the DO bit set to one, a
   security-aware authoritative name server SHOULD attempt to send RRSIG
   RRs that a security-aware resolver can use to authenticate the RRsets
   in the response.  Inclusion of RRSIG RRs in a response is subject to
   the following rules:

   o  When placing a signed RRset in the Answer section, the name server
      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
      RRs have a higher priority for inclusion than any other RRsets
      that may need to be included.  If space does not permit inclusion
      of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Authority section, the name
      server MUST also place its RRSIG RRs in the Authority section.
      The RRSIG RRs have a higher priority for inclusion than any other
      RRsets that may need to be included.  If space does not permit
      inclusion of these RRSIG RRs, the name server MUST set the TC bit.

   o  When placing a signed RRset in the Additional section, the name
      server MUST also place its RRSIG RRs in the Additional section.
      If space does not permit inclusion of both the RRset and its
      associated RRSIG RRs, the name server MUST NOT set the TC bit
      solely because these RRSIG RRs didn't fit.

3.1.2 Including DNSKEY RRs In a Response

   When responding to a query that has the DO bit set to one and that
   requests the SOA or NS RRs at the apex of a signed zone, a
   security-aware authoritative name server for that zone MAY return the
   zone apex DNSKEY RRset in the Additional section.  In this situation,
   the DNSKEY RRset and associated RRSIG RRs have lower priority than
   any other information that would be placed in the additional section.
   The name server SHOULD NOT include the DNSKEY RRset unless there is
   enough space in the response message for both the DNSKEY RRset and
   its associated RRSIG RR(s). If there is not enough space to include
   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
   NOT set the TC bit solely because these RRs didn't fit (see Section
   3.1.1).

Arends, et al.          Expires August 16, 2004                [Page 11]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

3.1.3 Including NSEC RRs In a Response

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

   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
      but does not contain any RRsets that exactly match <SNAME, SCLASS,
      STYPE>.

   Name Error: The zone does not contain any RRsets that match <SNAME,
      SCLASS> either exactly or via wildcard name expansion.

   Wildcard Answer: The zone does not contain any RRsets that exactly
      match <SNAME, SCLASS> but does contain an RRset that matches
      <SNAME, SCLASS, STYPE> via wildcard name expansion.

   Wildcard No Data: The zone does not contain any RRsets that exactly
      match <SNAME, SCLASS>, does contain one or more RRsets that match
      <SNAME, SCLASS> via wildcard name expansion, but does not contain
      any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
      expansion.

   In each of these cases, the name server includes NSEC RRs in the
   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
   not present in the zone and that the response that the name server is
   returning is correct given the data that are in the zone.

3.1.3.1 Including NSEC RRs: No Data Response

   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
   include the NSEC RR for <SNAME, SCLASS> along with its associated
   RRSIG RR(s) in the Authority section of the response (see Section
   3.1.1).  If space does not permit inclusion of the NSEC RR or its
   associated RRSIG RR(s), the name server MUST set the TC bit (see
   Section 3.1.1).

   Since the search name exists, wildcard name expansion does not apply
   to this query, and a single signed NSEC RR suffices to prove the
   requested RR type does not exist.

3.1.3.2 Including NSEC RRs: Name Error Response

   If the zone does not contain any RRsets matching <SNAME, SCLASS>
   either exactly or via wildcard name expansion, then the name server
   MUST include the following NSEC RRs in the Authority section, along
   with their associated RRSIG RRs:

Arends, et al.          Expires August 16, 2004                [Page 12]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   o  An NSEC RR proving that there is no exact match for <SNAME,
      SCLASS>; and

   o  An NSEC RR proving that the zone contains no RRsets that would
      match <SNAME, SCLASS> via wildcard name expansion.

   In some cases a single NSEC RR may prove both of these points, in
   that case the name server SHOULD only include the NSEC RR and its
   RRSIG RR(s) once in the Authority section.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST set the TC bit (see Section 3.1.1).

   The owner names of these NSEC and RRSIG RRs are not subject to
   wildcard name expansion when these RRs are included in the Authority
   section of the response.

   Note that this form of response includes cases in which SNAME
   corresponds to an empty non-terminal name within the zone (a name
   which is not the owner name for any RRset but which is the parent
   name of one or more RRsets).

3.1.3.3 Including NSEC RRs: Wildcard Answer Response

   If the zone does not contain any RRsets which exactly match <SNAME,
   SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
   STYPE> via wildcard name expansion, the name server MUST include the
   wildcard-expanded answer and the corresponding wildcard-expanded
   RRSIG RRs in the Answer section, and MUST include in the Authority
   section an NSEC RR and associated RRSIG RR(s) proving that the zone
   does not contain a closer match for <SNAME, SCLASS>.  If space does
   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
   server MUST set the TC bit (see Section 3.1.1).

3.1.3.4 Including NSEC RRs: Wildcard No Data Response

   This case is a combination of the previous cases.  The zone does not
   contain an exact match for <SNAME, SCLASS>, and while the zone does
   contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
   none of those RRsets match STYPE.  The name server MUST include the
   following NSEC RRs in the Authority section, along with their
   associated RRSIG RRs:

   o  An NSEC RR proving that there are no RRsets matching STYPE at the
      wildcard owner name which matched <SNAME, SCLASS> via wildcard
      expansion; and

   o  An NSEC RR proving that there are no RRsets in the zone which

Arends, et al.          Expires August 16, 2004                [Page 13]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

      would have been a closer match for <SNAME, SCLASS>.

   In some cases a single NSEC RR may prove both of these points, in
   which case the name server SHOULD only include the NSEC RR and its
   RRSIG RR(s) once in the Authority section.

   The owner names of these NSEC and RRSIG RRs are not subject to
   wildcard name expansion when these RRs are included in the Authority
   section of the response.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST set the TC bit (see Section 3.1.1).

3.1.3.5 Finding The Right NSEC RRs

   As explained above, there are several situations in which a
   security-aware authoritative name server needs to locate an NSEC RR
   which proves that a particular SNAME does not exist.  Locating such
   an NSEC RR within an authoritative zone is relatively simple, at
   least in concept.  The following discussion assumes that the name
   server is authoritative for the zone which would have held the
   nonexistent SNAME.  The algorithm below is written for clarity, not
   efficiency.

   To find the NSEC which proves that name N does not exist in the zone
   Z which would have held it, construct sequence S consisting of every
   name in Z, sorted into canonical order
   [I-D.ietf-dnsext-dnssec-records].  Find the name M which would have
   immediately preceded N in S if N had existed.  M is the owner name of
   the NSEC RR which proves that N does not exist.

   The algorithm for finding the NSEC RR which proves that a given name
   is not covered by any applicable wildcard is similar, but requires an
   extra step.  More precisely, the algorithm for finding the NSEC
   proving that the applicable wildcard name does not exist is precisely
   the same as the algorithm for finding the NSEC RR which proves that
   any other name does not exist: the part that's missing is how to
   determine the name of the nonexistent applicable wildcard.  In
   practice, this is easy, because the authoritative name server has
   already checked for the presence of precisely this wildcard name as
   part of step (1)(c) of the normal lookup algorithm described in
   Section 4.3.2 of [RFC1034].

3.1.4 Including DS RRs In a Response

   When responding to a query which has the DO bit set to one, a
   security-aware authoritative name server returning a referral
   includes DNSSEC data along with the NS RRset.

Arends, et al.          Expires August 16, 2004                [Page 14]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   If a DS RRset is present at the delegation point, the name server
   MUST return both the DS RRset and its associated RRSIG RR(s) in the
   Authority section along with the NS RRset.  The name server MUST
   place the NS RRset before the DS RRset and its associated RRSIG
   RR(s).

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR which proves that the DS RRset is not
   present and the NSEC RR's associated RRSIG RR(s) along with the NS
   RRset.  The name server MUST place the NS RRset before the NSEC RRset
   and its associated RRSIG RR(s).

   Including these DS, NSEC, and RRSIG RRs increases the size of
   referral messages, and may cause some or all glue RRs to be omitted.
   If space does not permit inclusion of the DS or NSEC RRset and
   associated RRSIG RRs, the name server MUST set the TC bit (see
   Section 3.1.1).

3.1.4.1 Responding to Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone cut.  For example, the DS RRset for the
   delegation of "foo.example" is stored in the "example" zone rather
   than in the "foo.example" zone.  This requires special processing
   rules for both name servers and resolvers, since the name server for
   the child zone is authoritative for the name at the zone cut by the
   normal DNS rules but the child zone does not contain the DS RRset.

   A security-aware resolver sends queries to the parent zone when
   looking for a needed DS RR at a delegation point (see Section 4.2).
   However, special rules are necessary to avoid confusing
   security-oblivious resolvers which might become involved in
   processing such a query (for example, in a network configuration that
   forces a security-aware resolver to channel its queries through a
   security-oblivious recursive name server).  The rest of this section
   describes how a security-aware name server processes DS queries in
   order to avoid this problem.

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  the name server has received a query for the DS RRset at a zone
      cut; and

   o  the name server is authoritative for the child zone; and

   o  the name server is not authoritative for the parent zone; and

Arends, et al.          Expires August 16, 2004                [Page 15]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   o  the name server does not offer recursion.

   In all other cases, the name server either has some way of obtaining
   the DS RRset or could not have been expected to have the DS RRset
   even by the pre-DNSSEC processing rules, so the name server can
   return either the DS RRset or an error response according to the
   normal processing rules.

   If all of the above conditions are met, however, the name server is
   authoritative for SNAME but cannot supply the requested RRset.  In
   this case, the name server MUST return an authoritative "no data"
   response showing that the DS RRset does not exist in the child zone's
   apex.  See Appendix B.8 for an example of such a response.

3.1.5 Responding to Queries for Type AXFR or IXFR

   DNSSEC does not change the DNS zone transfer process.  A signed zone
   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
   records have no special meaning with respect to a zone transfer
   operation, and these RRs are treated as any other resource record
   type.

   An authoritative name server is not required to verify that a zone is
   properly signed before sending or accepting a zone transfer.
   However, an authoritative name server MAY choose to reject the entire
   zone transfer if the zone fails meets any of the signing requirements
   described in Section 2.  The primary objective of a zone transfer is
   to ensure that all authoritative name servers have identical copies
   of the zone.  An authoritative name server which chooses to perform
   its own zone validation MUST NOT selectively reject some RRs and
   accept others.

   DS RRsets appear only on the parental side of a zone cut and are
   authoritative data in the parent zone.  As with any other
   authoritative RRset, the DS RRset MUST be included in zone transfers
   of the zone in which the RRset is authoritative data: in the case of
   the DS RRset, this is the parent zone.

   NSEC RRs appear in both the parent and child zones at a zone cut, and
   are authoritative data in both the parent and child zones.  The
   parental and child NSEC RRs at a zone cut are never identical to each
   other, since the NSEC RR in the child zone's apex will always
   indicate the presence of the child zone's SOA RR while the parental
   NSEC RR at the zone cut will never indicate the presence of an SOA
   RR.  As with any other authoritative RRs, NSEC RRs MUST be included
   in zone transfers of the zone in which they are authoritative data:
   the parental NSEC RR at a zone cut MUST be included zone transfers of
   the parent zone, while the NSEC at the zone apex of the child zone

Arends, et al.          Expires August 16, 2004                [Page 16]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   MUST be included in zone transfers of the child zone.

   RRSIG RRs appear in both the parent and child zones at a zone cut,
   and are authoritative in whichever zone contains the authoritative
   RRset for which the RRSIG RR provides the signature.  That is, the
   RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
   authoritative in the parent zone, while the RRSIG for any RRset in
   the child zone's apex will be authoritative in the child zone. As
   with any other authoritative RRs, RRSIG RRs MUST be included in zone
   transfers of the zone in which they are authoritative data.

3.1.6 The AD and CD Bits in an Authoritative Response

   The CD and AD bits are designed to be used in communication between
   security-aware resolvers and security-aware recursive name servers.
   This bits are for the most part not relevant to query processing by
   security-aware authoritative name servers.

   Since a security-aware name server does not perform signature
   validation for authoritative data during query processing even when
   the CD bit is set to zero, a security-aware name server SHOULD ignore
   the setting of the CD bit when composing an authoritative response.

   A security-aware name server MUST NOT set the AD bit in a response
   unless the name server considers all RRsets in the Answer and
   Authority sections of the response to be authentic.  A security-aware
   name server's local policy MAY consider data from an authoritative
   zone to be authentic without further validation, but the name server
   MUST NOT do so unless the name server obtained the authoritative zone
   via secure means (such as a secure zone transfer mechanism), and MUST
   NOT do so unless this behavior has been configured explicitly.

   A security-aware name server which supports recursion MUST follow the
   rules for the CD and AD bits given in Section 3.2 when generating a
   response that involves data obtained via recursion.

3.2 Recursive Name Servers

   As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
   recursive name server is an entity which acts in both the
   security-aware name server and security-aware resolver roles. This
   section uses the terms "name server side" and "resolver side" to
   refer to the code within a security-aware recursive name server which
   implements the security-aware name server role and the code which
   implements the security-aware resolver role, respectively.

   The resolver side follows the usual rules for caching and negative
   caching which would apply to any security-aware resolver.

Arends, et al.          Expires August 16, 2004                [Page 17]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

3.2.1 The DO bit

   The resolver side of a security-aware recursive name server MUST set
   the DO bit when sending requests, regardless of the state of the DO
   bit in the initiating request received by the name server side.  If
   the DO bit in an initiating query is not set, the name server side
   MUST strip any authenticating DNSSEC RRs from the response, but MUST
   NOT strip any DNSSEC RRs that the initiating query explicitly
   requested.

3.2.2 The CD bit

   The CD bit exists in order to allow a security-aware resolver to
   disable signature validation in a security-aware name server's
   processing of a particular query.

   The name server side MUST copy the setting of the CD bit from a query
   to the corresponding response.

   The name server side of a security-aware recursive name server MUST
   pass the sense of the CD bit to the resolver side along with the rest
   of an initiating query, so that the resolver side will know whether
   or not it is required to verify the response data it returns to the
   name server side. If the CD bit is set to one, it indicates that the
   originating resolver is willing to perform whatever authentication
   its local policy requires, thus the resolver side of the recursive
   name server need not perform authentication on the RRsets in the
   response.  When the CD bit is set to one the recursive name server
   SHOULD, if possible, return the requested data to the originating
   resolver even if the recursive name server's local authentication
   policy would reject the records in question. That is, by setting the
   CD bit, the originating resolver has indicated that it takes
   responsibility for performing its own authentication, and the
   recursive name server should not interfere.

   If the resolver side implements a BAD cache (see Section 4.7) and the
   name server side receives a query which matches an entry in the
   resolver side's BAD cache, the name server side's response depends on
   the sense of the CD bit in the original query.  If the CD bit is set,
   the name server side SHOULD return the data from the BAD cache; if
   the CD bit is not set, the name server side MUST return RCODE 2
   (server failure).

3.2.3 The AD bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be

Arends, et al.          Expires August 16, 2004                [Page 18]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   authentic, and SHOULD set the AD bit if and only if the resolver side
   considers all RRsets in the Answer section and any relevant negative
   response RRs in the Authority section to be authentic.  The resolver
   side MUST follow the procedure described in Section 5 to determine
   whether the RRs in question are authentic.

3.3 Example DNSSEC Responses

   See Appendix B for example response packets.

Arends, et al.          Expires August 16, 2004                [Page 19]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

4. Resolving

   This section describes the behavior of entities which include
   security-aware resolver functions.  In many cases such functions will
   be part of a security-aware recursive name server, but a stand-alone
   security-aware resolver has many of the same requirements.  Functions
   specific to security-aware recursive name servers are described in
   Section 3.2.

4.1 EDNS Support

   A security-aware resolver MUST include an EDNS [RFC2671] OPT
   pseudo-RR with the DO [RFC3225] bit set to one when sending queries.

   A security-aware resolver MUST support a message size of at least
   1220 octets, SHOULD support a message size of 4000 octets, and MUST
   advertise the supported message size using the "sender's UDP payload
   size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST
   handle fragmented UDP packets correctly regardless of whether any
   such fragmented packets were received via IPv4 or IPv6.  Please see
   [RFC3226] for discussion of these requirements.

4.2 Signature Verification Support

   A security-aware resolver MUST support the signature verification
   mechanisms described in Section 5, and MUST apply them to every
   received response except when:

   o  The security-aware resolver is part of a security-aware recursive
      name server, and the response is the result of recursion on behalf
      of a query received with the CD bit set;

   o  The response is the result of a query generated directly via some
      form of application interface which instructed the security-aware
      resolver not to perform validation for this query; or

   o  Validation for this query has been disabled by local policy.

   A security-aware resolver's support for signature verification MUST
   include support for verification of wildcard owner names.

      Editors' note: The rest of this section is expected to change once
      the WG reaches closure on Q-23.

   A security-aware resolver MUST attempt to retrieve missing DS,
   DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
   RRs in order to perform signature verification.

Arends, et al.          Expires August 16, 2004                [Page 20]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   A security-aware resolver MUST attempt to retrieve a missing NSEC RR
   which the resolver needs to authenticate a NODATA response.  In
   general it is not possible for a resolver to retrieve missing NSEC
   RRs, since the resolver will have no way of knowing the owner name of
   the missing NSEC RR, but in the specific case of a NODATA response,
   the resolver may know the name of the missing NSEC RR, and in such
   cases must therefore attempt to retrieve it.

   When attempting to retrieve missing NSEC RRs which reside on the
   parental side at a zone cut, a security-aware iterative-mode resolver
   MUST query the name servers for the parent zone, not the child zone.

   When attempting to retrieve a missing DS, a security-aware
   iterative-mode resolver MUST query the name servers for the parent
   zone, not the child zone.  As explained in Section 3.1.4.1,
   security-aware name servers need to apply special processing rules to
   handle the DS RR, and in some situations the resolver may also need
   to apply special rules to locate the name servers for the parent zone
   if the resolver does not already have the parent's NS RRset.  To
   locate the parent NS RRset, the resolver can start with the
   delegation name, strip off the leftmost label, and query for an NS
   RRset by that name; if no NS RRset is present at that name, the
   resolver then strips of the leftmost remaining label and retries the
   query for that name, repeating this process of walking up the tree
   until it either finds the NS RRset or runs out of labels.

      Editors' note: This algorithm could easily be read as an
      invitation to careless implementors to hammer the root zone
      servers.  Better wording would be welcome.

4.3 Determining Security Status of Data

      Editors' note: This section is waiting for resolution of Q-28.

   A security-aware resolver MUST be able to determine whether or not it
   should expect a particular RRset to be signed.  More precisely, a
   security-aware resolver must be able to distinguish between three
   cases:

   1.  An RRset for which the resolver is able to build a chain of
       signed DNSKEY and DS RRs from a trusted security anchor to the
       RRset.  In this case, the RRset should be signed, and is subject
       to signature validation as described above.

   2.  An RRset for which the resolver knows that it has no chain of
       signed DNSKEY and DS RRs from any trusted starting point to the
       RRset.  This can occur when the target RRset lies in an unsigned

Arends, et al.          Expires August 16, 2004                [Page 21]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

       zone or in a descendent of an unsigned zone.  In this case, the
       RRset may or may not be signed, but the resolver will not be able
       to verify the signature.

   3.  An RRset for which the resolver is not able to determine whether
       or not the RRset should be signed, because the resolver is not
       able to obtain the necessary DNSSEC RRs. This can occur when the
       security-aware resolver is not able to contact security-aware
       name servers for the relevant zones.

4.4 Preconfigured Public Keys

   A security-aware resolver MUST be capable of being preconfigured with
   at least one trusted public key or DS RR, and SHOULD be capable of
   being preconfigured with multiple trusted public keys or DS RRs.
   Since a security-aware resolver will not be able to validate
   signatures without such a preconfigured trusted key, the resolver
   SHOULD have some reasonably robust mechanism for obtaining such keys
   when it boots; examples of such a mechanism would be some form of
   non-volatile storage (such as a disk drive) or some form of trusted
   local network configuration mechanism.

4.5 Response Caching

      Editors' note: RIPE "last call" workshop felt that the WG needs to
      reexamine and discuss this section.

   A security-aware resolver SHOULD cache each response as a single
   atomic entry containing the entire answer, including the named RRset
   and any associated DNSSEC RRs.  The resolver SHOULD discard the
   entire atomic entry when any of the RRs contained in it expire.  In
   most cases the appropriate cache index for the atomic entry will be
   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
   form described in Section 3.1.3.2 the appropriate cache index will be
   the double <QNAME,QCLASS>.

4.6 Handling of the CD and AD bits

   A security-aware resolver MAY set the CD bit in a query to one in
   order to indicate that the resolver takes responsibility for
   performing whatever authentication its local policy requires on the
   RRsets in the response.  See Section 3.2 for the effect this bit has
   on the behavior of security-aware recursive name servers.

   A security-aware resolver MUST zero the AD bit when composing query
   messages to protect against buggy name servers which blindly copy
   header bits which they do not understand from the query message to

Arends, et al.          Expires August 16, 2004                [Page 22]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   the response message.

   A resolver MUST disregard the meaning of the CD and AD bits in a
   response unless the response was obtained using a secure channel or
   the resolver was specifically configured to regard the message header
   bits without using a secure channel.

4.7 Rate Limiting

   A security-aware resolver SHOULD NOT cache data with invalid
   signatures under normal circumstances.  However, a security-aware
   resolver SHOULD take steps to rate limit the number of identical
   queries that it generates if signature validation of the responses
   fails repeatedly.

   Conceptually, this is similar in some respects to negative caching
   [RFC2308], but since the resolver has no way of obtaining an
   appropriate caching TTL from received data in this case, the TTL will
   have to be set by the implementation.  This document refers to the
   data retained as part of such a rate limiting mechanism as the "BAD
   cache".

   A security-aware resolver MAY chose to retain RRsets for which
   signature validation has failed in its BAD cache, but MUST NOT return
   such RRsets from its BAD cache unless both of the following
   conditions are met:

   o  The resolver has recently generated enough queries identical to
      this one that the resolver is suppressing queries for this <QNAME,
      QTYPE, QCLASS>; and

   o  The resolver is not required to validate the signatures of the
      RRsets in question under the rules given in Section 4 of this
      document.

   The intent of the above rule is to provide the raw data to clients
   which are capable of performing their own signature verification
   checks while protecting clients which depend on this resolver to
   perform such checks.  Several of the possible reasons why signature
   validation might fail involve conditions which may not apply equally
   to this resolver and the client which invoked it: for example, this
   resolver's clock may be set incorrectly, or the client may have
   knowledge of a relevant island of security which this resolver does
   not share.  In such cases, "protecting" a client which is capable of
   performing its own signature validation from ever seeing the "bad"
   data does not help the client.

Arends, et al.          Expires August 16, 2004                [Page 23]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

4.8 Stub resolvers

   A security-aware stub resolver MUST support the DNSSEC RR types, at
   least to the extent of not mishandling responses just because they
   contain DNSSEC RRs.

4.8.1 Handling of the DO Bit

   A non-validating security-aware stub resolver MAY include the DNSSEC
   RRs returned by a security-aware recursive name server as part of the
   data that the stub resolver hands back to the application which
   invoked it but is not required to do so.  A non-validating stub
   resolver that wishes to do this will need to set the DO bit in
   receive DNSSEC RRs from the recursive name server.

   A validating security-aware stub resolver MUST set the DO bit, since
   otherwise it will not receive the DNSSEC RRs it needs to perform
   signature validation.

4.8.2 Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless requested by the application layer,
   since by definition, a non-validating stub resolver depends on the
   security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD set the CD bit,
   since otherwise the security-aware recursive name server will answer
   the query using the name server's local policy, which may prevent the
   stub resolver from receiving data which would be acceptable to the
   stub resolver's local policy.

4.8.3 Handling of the AD Bit

   A non-validating security-aware stub resolver MAY chose to examine
   the setting of the AD bit in response messages that it receives in
   order to determine whether the security-aware recursive name server
   which sent the response claims to have cryptographically verified the
   data in the Answer and Authority sections of the response message.
   Note, however, that the responses received by a security-aware stub
   resolver are heavily dependent on the local policy of the
   security-aware recursive name server, so as a practical matter there
   may be little practical value to checking the status of the AD bit
   except perhaps as a debugging aid.  In any case, a security-aware
   stub resolver MUST NOT place any reliance on signature validation
   allegedly performed on its behalf except when the security-aware stub
   resolver obtained the data in question from a trusted security-aware

Arends, et al.          Expires August 16, 2004                [Page 24]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   recursive name server via a secure channel.

   A validating security-aware stub resolver SHOULD NOT examine the
   setting of the AD bit in response messages, since, by definition, the
   stub resolver performs its own signature validation regardless of the
   setting of the AD bit.

Arends, et al.          Expires August 16, 2004                [Page 25]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

5. Authenticating DNS Responses

   In order to use DNSSEC RRs for authentication, a security-aware
   resolver requires preconfigured knowledge of at least one
   authenticated DNSKEY or DS RR.  The process for obtaining and
   authenticating this initial DNSKEY or DS RR is achieved via some
   external mechanism.  For example, a resolver could use some off-line
   authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR
   that identifies and authenticates a zone's DNSKEY RR.  The remainder
   of this section assumes that the resolver has somehow obtained an
   initial set of authenticated DNSKEY RRs.

   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
   RRset.  To authenticate an apex DNSKEY RRset using an initial key,
   the resolver MUST:

   1.  Verify that the initial DNSKEY RR appears in the apex DNSKEY
       RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
       (DNSKEY RDATA bit 7) set to one.

   2.  Verify that there is some RRSIG RR that covers the apex DNSKEY
       RRset, and that the combination of the RRSIG RR and the initial
       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
       an RRSIG RR to authenticate an RRset is described in Section 5.3.

   Once the resolver has authenticated the apex DNSKEY RRset using an
   initial DNSKEY RR, delegations from that zone can be authenticated
   using DS RRs.  This allows a resolver to start from an initial key,
   and use DS RRsets to proceed recursively down the DNS tree obtaining
   other apex DNSKEY RRsets.  If the resolver were preconfigured with a
   root DNSKEY RR, and if every delegation had a DS RR associated with
   it, then the resolver could obtain and validate any apex DNSKEY
   RRset.  The process of using DS RRs to authenticate referrals is
   described in Section 5.2.

   Once the resolver has authenticated a zone's apex DNSKEY RRset,
   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
   RRsets in the zone.  Section 5.4 shows how the resolver can use
   authenticated NSEC RRsets from the zone to prove that an RRset is not
   present in the zone.

   When a resolver indicates support for DNSSEC (by setting the DO bit),
   a security-aware name server should attempt to provide the necessary
   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
   However, a security-aware resolver may still receive a response that
   that lacks the appropriate DNSSEC RRs, whether due to configuration
   issues such as a security-oblivious recursive name server that

Arends, et al.          Expires August 16, 2004                [Page 26]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   accidentally interfere with DNSSEC RRs or due to a deliberate attack
   in which an adversary forges a response, strips DNSSEC RRs from a
   response, or modifies a query so that DNSSEC RRs appear not to be
   requested.  The absence of DNSSEC data in a response MUST NOT by
   itself be taken as an indication that no authentication information
   exists.

   A resolver SHOULD expect authentication information from signed
   zones. A resolver SHOULD believe that a zone is signed if the
   resolver has been configured with public key information for the
   zone, or if the zone's parent is signed and the delegation from the
   parent contains a DS RRset.

5.1 Special Considerations for Islands of Security

   Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
   zones for which it is not possible to construct an authentication
   chain to the zone from its parent.  Validating signatures within an
   island of security requires the validator to have some other means of
   obtaining an initial authenticated zone key for the island.  If a
   validator cannot obtain such a key, it will have to choose whether to
   accept the unvalidated responses or not based on local policy.

   All the normal processes for validating responses apply to islands of
   security.  The only difference between normal validation and
   validation within an island of security is in how the validator
   obtains a starting point for the authentication chain.

5.2 Authenticating Referrals

   Once the apex DNSKEY RRset for a signed parent zone has been
   authenticated, DS RRsets can be used to authenticate the delegation
   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
   zone's apex DNSKEY RRset, and contains a cryptographic digest of the
   child zone's DNSKEY RR.  A strong cryptographic digest algorithm
   ensures that an adversary can not easily generate a DNSKEY RR that
   matches the digest.  Thus, authenticating the digest allows a
   resolver to authenticate the matching DNSKEY RR.  The resolver can
   then use this child DNSKEY RR to authenticate the entire child apex
   DNSKEY RRset.

   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
   can be authenticated if all of the following hold:

   o  The DS RR has been authenticated using some DNSKEY RR in the
      parent's apex DNSKEY RRset (see Section 5.3);

   o  The Algorithm and Key Tag in the DS RR match the Algorithm field

Arends, et al.          Expires August 16, 2004                [Page 27]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
      RRset that, when hashed using the digest algorithm specified in
      the DS RR's Digest Type field, results in a digest value that
      matches the Digest field of the DS RR; and

   o  The matching DNSKEY RR in the child zone has the Zone Flag bit set
      to one, the corresponding private key has signed the child zone's
      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
      child zone's apex DNSKEY RRset.

   If the referral from the parent zone did not contain a DS RRset, the
   response should have included a signed NSEC RRset proving that no DS
   RRset exists for the delegated name (see Section 3.1.4).  A
   security-aware resolver MUST query the name servers for the parent
   zone for the DS RRset if the referral includes neither a DS RRset nor
   a NSEC RRset proving that the DS RRset does not exist (see Section
   4).

   If the resolver authenticates an NSEC RRset that proves that no DS
   RRset is present for this zone, then there is no authentication path
   leading from the parent to the child.  If the resolver has an initial
   DNSKEY or DS RR that belongs to the child zone or to any delegation
   below the child zone, this initial DNSKEY or DS RR MAY be used to
   re-establish an authentication path.  If no such initial DNSKEY or DS
   RR exists, the resolver can not authenticate RRsets in or below the
   child zone.

   Note that, for a signed delegation, there are two NSEC RRs associated
   with the delegated name.  One NSEC RR resides in the parent zone, and
   can be used to prove whether a DS RRset exists for the delegated
   name.  The second NSEC RR resides in the child zone, and identifies
   which RRsets are present at the apex of the child zone.  The parent
   NSEC RR and child NSEC RR can always be distinguished, since the SOA
   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
   A security-aware resolver MUST use the parent NSEC RR when attempting
   to prove that a DS RRset does not exist.

   If the resolver does not support any of the algorithms listed in an
   authenticated DS RRset, then the resolver will not be able to verify
   the authentication path to the child zone.  In this case, the
   resolver SHOULD treat the child zone as if it were unsigned.

5.3 Authenticating an RRset Using an RRSIG RR

   A resolver can use an RRSIG RR and its corresponding DNSKEY RR to
   attempt to authenticate RRsets.  The resolver first checks the RRSIG
   RR to verify that it covers the RRset, has a valid time interval, and
   identifies a valid DNSKEY RR.  The resolver then constructs the

Arends, et al.          Expires August 16, 2004                [Page 28]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   canonical form of the signed data by appending the RRSIG RDATA
   (excluding the Signature Field) with the canonical form of the
   covered RRset.  Finally, resolver uses the public key and signature
   to authenticate the signed data.  Section 5.3.1, Section 5.3.2, and
   Section 5.3.3 describe each step in detail.

5.3.1 Checking the RRSIG RR Validity

   A security-aware resolver can use an RRSIG RR to authenticate an
   RRset if all of the following conditions hold:

   o  The RRSIG RR and the RRset MUST have the same owner name and the
      same class;

   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
      that contains the RRset;

   o  The RRSIG RR's Type Covered field MUST equal the RRset's type;

   o  The number of labels in the RRset owner name MUST be greater than
      or equal to the value in the RRSIG RR's Labels field;

   o  The resolver's notion of the current time MUST be less than or
      equal to the time listed in the RRSIG RR's Expiration field;

   o  The resolver's notion of the current time MUST be greater than or
      equal to the time listed in the RRSIG RR's Inception field;

   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
      match the owner name, algorithm, and key tag for some DNSKEY RR in
      the zone's apex DNSKEY RRset;

   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
      set to one.

   It is possible for more than one DNSKEY RR to match the conditions
   above.  In this case, the resolver can not predetermine which DNSKEY
   RR to use to authenticate the signature, MUST try each matching
   DNSKEY RR until the resolver has either validated the signature or
   has run out of matching public keys to try.

   Note that this authentication process is only meaningful if the
   resolver authenticates the DNSKEY RR before using it to validate
   signatures.  The matching DNSKEY RR is considered to be authentic if:

   o  The apex DNSKEY RRset containing the DNSKEY RR is considered
      authentic; or

Arends, et al.          Expires August 16, 2004                [Page 29]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   o  The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
      and the DNSKEY RR either matches an authenticated DS RR from the
      parent zone or matches a DS RR or DNSKEY RR that the resolver has
      been preconfigured to believe to be authentic.

5.3.2 Reconstructing the Signed Data

   Once the RRSIG RR has met the validity requirements described in
   Section 5.3.1, the resolver needs to reconstruct the original signed
   data.  The original signed data includes RRSIG RDATA (excluding the
   Signature field) and the canonical form of the RRset.  Aside from
   being ordered, the canonical form of the RRset might also differ from
   the received RRset due to DNS name compression, decremented TTLs, or
   wildcard expansion.  The resolver should use the following to
   reconstruct the original signed data:

         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where

            "|" denotes concatenation

            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
               with the Signature field excluded and the Signer's Name
               in canonical form.

            RR(i) = name | class | type | OrigTTL | RDATA length | RDATA

               name is calculated according to the function below

               class is the RRset's class

               type is the RRset type and all RRs in the class

               OrigTTL is the value from the RRSIG Original TTL field

               All names in the RDATA field are in canonical form

               The set of all RR(i) is sorted into canonical order.

            To calculate the name:
               let rrsig_labels = the value of the RRSIG Labels field

               let fqdn = RRset's fully qualified domain name in
                               canonical form

               let fqdn_labels = Label count of the fqdn above.

               if rrsig_labels = fqdn_labels,

Arends, et al.          Expires August 16, 2004                [Page 30]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                   name = fqdn

               if rrsig_labels < fqdn_labels,
                  name = "*." | the rightmost rrsig_label labels of the
                                fqdn

               if rrsig_labels > fqdn_labels
                  the RRSIG RR did not pass the necessary validation
                  checks and MUST NOT be used to authenticate this
                  RRset.

   The canonical forms for names and RRsets are defined in
   [I-D.ietf-dnsext-dnssec-records].

   NSEC RRsets at a delegation boundary require special processing.
   There are two distinct NSEC RRsets associated with a signed delegated
   name.  One NSEC RRset resides in the parent zone, and specifies which
   RRset are present at the parent zone.  The second NSEC RRset resides
   at the child zone, and identifies which RRsets are present at the
   apex in the child zone.  The parent NSEC RRset and child NSEC RRset
   can always be distinguished since only the child NSEC RRs will
   specify an SOA RRset exists at the name. When reconstructing the
   original NSEC RRset for the delegation from the parent zone, the NSEC
   RRs MUST NOT be combined with NSEC RRs from the child zone, and when
   reconstructing the original NSEC RRset for the apex of the child
   zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
   zone.

   Note also that each of the two NSEC RRsets at a delegation point has
   a corresponding RRSIG RR with an owner name matching the delegated
   name, and each of these RRSIG RRs is authoritative data associated
   with the same zone that contains the corresponding NSEC RRset.  If
   necessary, a resolver can tell these RRSIG RRs apart by checking the
   Signer's Name field.

5.3.3 Checking the Signature

   Once the resolver has validated the RRSIG RR as described in Section
   5.3.1 and reconstructed the original signed data as described in
   Section 5.3.2, the resolver can attempt to use the cryptographic
   signature to authenticate the signed data, and thus (finally!)
   authenticate the RRset.

   The Algorithm field in the RRSIG RR identifies the cryptographic
   algorithm used to generate the signature.  The signature itself is
   contained in the Signature field of the RRSIG RDATA, and the public
   key used to verify the signature is contained in the Public Key field
   of the matching DNSKEY RR(s) (found in Section 5.3.1).

Arends, et al.          Expires August 16, 2004                [Page 31]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
   and provides pointers to the documents that define each algorithm's
   use.

   Note that it is possible for more than one DNSKEY RR to match the
   conditions in Section 5.3.1.  In this case, the resolver can only
   determine which DNSKEY RR by trying each matching public key until
   the resolver either succeeds in validating the signature or runs out
   of keys to try.

   If the Labels field of the RRSIG RR is not equal to the number of
   labels in the RRset's fully qualified owner name, then the RRset is
   either invalid or the result of wildcard expansion.  The resolver
   MUST verify that wildcard expansion was applied properly before
   considering the RRset to be authentic.  Section 5.3.4 describes how
   to determine whether a wildcard was applied properly.

   If other RRSIG RRs also cover this RRset, the local resolver security
   policy determines whether the resolver also needs to test these RRSIG
   RRs, and determines how to resolve conflicts if these RRSIG RRs lead
   to differing results.

   If the resolver accepts the RRset as authentic, the resolver MUST set
   the TTL of the RRSIG RR and each RR in the authenticated RRset to a
   value no greater than the minimum of:

   o  The RRset's TTL as received in the response;

   o  The RRSIG RR's TTL as received in the response; and

   o  The value in the RRSIG RR's Original TTL field.

5.3.4 Authenticating A Wildcard Expanded RRset Positive Response

   If the number of labels in an RRset's owner name is greater than the
   Labels field of the covering RRSIG RR, then the RRset and its
   covering RRSIG RR were created as a result of wildcard expansion.
   Once the resolver has verified the signature as described in Section
   5.3, the resolver must take additional steps to verify the
   non-existence of an exact match or closer wildcard match for the
   query.  Section 5.4 discusses these steps.

   Note that the response received by the resolver should include all
   NSEC RRs needed to authenticate the response (see Section 3.1.3).

5.4 Authenticated Denial of Existence

Arends, et al.          Expires August 16, 2004                [Page 32]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   A resolver can use authenticated NSEC RRs to prove that an RRset is
   not present in a signed zone.  Security-aware name servers should
   automatically include any necessary NSEC RRs for signed zones in
   their responses to security-aware resolvers.

   Security-aware resolvers MUST first authenticate NSEC RRsets
   according to the standard RRset authentication rules described in
   Section 5.3, then apply the NSEC RRsets as follows:

   o  If the requested RR name matches the owner name of an
      authenticated NSEC RR, then the NSEC RR's type bit map field lists
      all RR types present at that owner name, and a resolver can prove
      that the requested RR type does not exist by checking for the RR
      type in the bit map.  If the number of labels in an authenticated
      NSEC RR's owner name equals the Labels field of the covering RRSIG
      RR, then the existence of the NSEC RR proves that wildcard
      expansion could not have been used to match the request.

   o  If the requested RR name would appear after an authenticated NSEC
      RR's owner name and before the name listed in that NSEC RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
      the requested name exist in the zone.  However, it is possible
      that a wildcard could be used to match the requested RR owner name
      and type, so proving that the requested RRset does not exist also
      requires proving that no possible wildcard RRset exists that could
      have been used to generate a positive response.

   To prove non-existence of an RRset, the resolver must be able to
   verify both that the queried RRset does not exist and that no
   relevant wildcard RRset exists.  Proving this may require more than
   one NSEC RRset from the zone.  If the complete set of necessary NSEC
   RRsets is not present in a response (perhaps due to message
   truncation), then a security-aware resolver MUST resend the query in
   order to attempt to obtain the full collection of NSEC RRs necessary
   to verify non-existence of the requested RRset.  As with all DNS
   operations, however, the resolver MUST bound the work it puts into
   answering any particular query.

   Since a verified NSEC RR proves the existence of both itself and its
   corresponding RRSIG RR, a verifier MUST ignore the settings of the
   NSEC and RRSIG bits in an NSEC RR.

5.5 Authentication Example

   Appendix C shows an example the authentication process.

Arends, et al.          Expires August 16, 2004                [Page 33]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

6. IANA Considerations

   [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
   considerations introduced by DNSSEC.  The additional IANA
   considerations discussed in this document:

   [RFC2535] reserved the CD and AD bits in the message header.  The
   meaning of the AD bit was redefined in [RFC3655] and the meaning of
   both the CD and AD bit are restated in this document.  No new bits in
   the DNS message header are defined in this document.

   [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
   and defined its use.  The use is restated but not altered in this
   document.

Arends, et al.          Expires August 16, 2004                [Page 34]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

7. Security Considerations

   This document describes how the DNS security extensions use public
   key cryptography to sign and authenticate DNS resource record sets.
   Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
   security considerations related to DNSSEC; see
   [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
   DNSSEC resource record types.

   An active attacker who can set the CD bit in a DNS query message or
   the AD bit in a DNS response message can use these bits to defeat the
   protection which DNSSEC attempts to provide to security-oblivious
   recursive-mode resolvers.  For this reason, use of these control bits
   by a security-aware recursive-mode resolver requires a secure
   channel.  See Section 3.2.2 and Section 4.8 for further discussion.

   The protocol described in this document attempts to extend the
   benefits of DNSSEC to security-oblivious stub resolvers. However,
   since recovery from validation failures is likely to be specific to
   particular applications, the facilities that DNSSEC provides for stub
   resolvers may prove inadequate.  Operators of security-aware
   recursive name servers will need to pay close attention to the
   behavior of the applications which use their services when choosing a
   local validation policy; failure to do so could easily result in the
   recursive name server accidently denying service to the clients it is
   intended to support.

Arends, et al.          Expires August 16, 2004                [Page 35]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

8. Acknowledgements

   This document was created from the input and ideas of the members of
   the DNS Extensions Working Group and working group mailing list.  The
   editors would like to express their thanks for the comments and
   suggestions received during the revision of these security extension
   specifications.  While explicitly listing everyone who has
   contributed during the decade during which DNSSEC has been under
   development would be an impossible task,
   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
   participants who were kind enough to comment on these documents.

Arends, et al.          Expires August 16, 2004                [Page 36]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
              3225, December 2001.

   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
              message size requirements", RFC 3226, December 2001.

   [I-D.ietf-dnsext-dnssec-intro]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "DNS Security Introduction and Requirements",
              draft-ietf-dnsext-dnssec-intro-09 (work in progress),
              February 2004.

   [I-D.ietf-dnsext-dnssec-records]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Resource Records for DNS Security Extensions",
              draft-ietf-dnsext-dnssec-records-07 (work in progress),
              February 2004.

Arends, et al.          Expires August 16, 2004                [Page 37]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

Informative References

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
              Authenticated Data (AD) bit", RFC 3655, November 2003.

   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
              (RR)", RFC 3658, December 2003.

   [I-D.ietf-dnsext-wcard-clarify]
              Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
              Domains in the Domain Name System",
              draft-ietf-dnsext-wcard-clarify-02 (work in progress),
              September 2003.

Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: roy.arends@telin.nl

   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: mlarson@verisign.com

Arends, et al.          Expires August 16, 2004                [Page 38]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   Rob Austein
   Internet Systems Consortium
   950 Charter Street
   Redwood City, CA  94063
   USA

   EMail: sra@isc.org

   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-8920
   USA

   EMail: scott.rose@nist.gov

Arends, et al.          Expires August 16, 2004                [Page 39]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

Appendix A. Signed Zone Example

   The following example shows a (small) complete signed zone.

   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1071609350
                              3600
                              300
                              3600000
                              3600
                              )
                  3600 RRSIG  SOA 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
                              hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
                              VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
                              CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
                              owLe/OV+Qqqic7ShV/S9l2YJF9I= )
                  3600 NS     ns1.example.
                  3600 NS     ns2.example.
                  3600 RRSIG  NS 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
                              +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
                              s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
                              eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
                              FTVyQbVkcaxQ6U2FbZtMbfo//go= )
                  3600 MX     1 xx.example.
                  3600 RRSIG  MX 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18
                              7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe
                              IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+
                              M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q
                              7wxkDWyzgasGiMNIKgYrm9vXz04= )
                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
                  3600 RRSIG  NSEC 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
                              vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
                              TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
                              Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
                              7T/nOEOVZujD8IN/Utv+KUg+P6U= )
                  3600 DNSKEY 256 3 5 (
                              AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH
                              UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV
                              fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv
                              BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO

Arends, et al.          Expires August 16, 2004                [Page 40]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q==
                              )
                  3600 DNSKEY 257 3 5 (
                              AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U
                              Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv
                              klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE
                              2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT
                              nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ==
                              )
                  3600 RRSIG  DNSKEY 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU
                              pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5
                              YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc
                              tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG
                              PjJstq6fvRq8kX7TPJcljUmDFKM= )
                  3600 RRSIG  DNSKEY 5 1 3600 20040115201552 (
                              20031216201552 60717 example.
                              EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/
                              C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK
                              L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY
                              J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34
                              Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= )
   a.example.     3600 IN NS  ns1.a.example.
                  3600 IN NS  ns2.a.example.
                  3600 DS     48327 5 1 (
                              DFEB5E00E71A4DED5CABBBD7F15F24871983
                              CAB7 )
                  3600 RRSIG  DS 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
                              hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
                              rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
                              ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
                              0yfe2uolEkeegjesDZuF+fC61Eg= )
                  3600 NSEC   ai.example. NS DS RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb
                              RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1
                              3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O
                              ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf
                              YgfAHJEJJj7K88QbKEK4/Je1hyk= )
   ns1.a.example. 3600 IN A   192.0.2.5
   ns2.a.example. 3600 IN A   192.0.2.6
   ai.example.    3600 IN A   192.0.2.9
                  3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.

Arends, et al.          Expires August 16, 2004                [Page 41]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
                              jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
                              Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
                              OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
                              sWifTxvcG5hv+A6TOd0O2xJYRik= )
                  3600 HINFO  "KLH-10" "ITS"
                  3600 RRSIG  HINFO 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C
                              hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2
                              KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2
                              Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92
                              xo9NLoltg0GuwggZM240pRoTwO8= )
                  3600 AAAA   2001:db8::f00:baa9
                  3600 RRSIG  AAAA 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
                              9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
                              G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
                              A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
                              zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE
                              ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y
                              ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU
                              4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR
                              ovChG5Ih3TOa8Qnch4IJQVfSFNU= )
   b.example.     3600 IN NS  ns1.b.example.
                  3600 IN NS  ns2.b.example.
                  3600 NSEC   ns1.example. NS RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
                              VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
                              VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
                              k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
                              GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
   ns1.b.example. 3600 IN A   192.0.2.7
   ns2.b.example. 3600 IN A   192.0.2.8
   ns1.example.   3600 IN A   192.0.2.1
                  3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
                              CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
                              RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
                              +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa

Arends, et al.          Expires August 16, 2004                [Page 42]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
                  3600 NSEC   ns2.example. A RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
                              sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
                              eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
                              s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
                              I2A5W86mMEbSgEF/pZHX/wi5FJI= )
   ns2.example.   3600 IN A   192.0.2.2
                  3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
                              xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
                              HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
                              sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
                              wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
                  3600 NSEC   *.w.example. A RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb
                              IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b
                              f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J
                              aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl
                              yCup5bk/Dr47eU2/6+lqrBTOV8Q= )
   *.w.example.   3600 IN MX  1 ai.example.
                  3600 RRSIG  MX 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
                              OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
                              Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
                              n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
                              91Ena87PA2MvoOE+A3ZpEk8MjEE= )
                  3600 NSEC   x.w.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
                              f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
                              9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
                              /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
                              ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
   x.w.example.   3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 5 3 3600 20040115201552 (
                              20031216201552 41681 example.
                              g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
                              ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
                              8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
                              MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv

Arends, et al.          Expires August 16, 2004                [Page 43]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              btznHMFDIbtuw/tAX7xXH2pDDHY= )
                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 5 3 3600 20040115201552 (
                              20031216201552 41681 example.
                              zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia
                              CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA
                              EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA
                              aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT
                              3lMXiX4KNWUhB87q/pT/5z+xrqY= )
   x.y.w.example. 3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 5 4 3600 20040115201552 (
                              20031216201552 41681 example.
                              slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD
                              v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE
                              unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK
                              Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk
                              Iykd5UmaTO5j4LlRnAvF8Z1m9/k= )
                  3600 NSEC   xx.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 5 4 3600 20040115201552 (
                              20031216201552 41681 example.
                              sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
                              VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
                              Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
                              AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
                              viOQHZ6I4xoZQP5G7r98/PhlrLM= )
   xx.example.    3600 IN A   192.0.2.10
                  3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
                              tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
                              iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
                              KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
                              0ToQVY81bPc3WXKZjRxQl3jiKtU= )
                  3600 HINFO  "KLH-10" "TOPS-20"
                  3600 RRSIG  HINFO 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw
                              p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA
                              gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/
                              pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp
                              EDXT07qFXtGntvBSpF9uQbEub6Y= )
                  3600 AAAA   2001:db8::f00:baaa
                  3600 RRSIG  AAAA 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
                              dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
                              mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
                              CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z

Arends, et al.          Expires August 16, 2004                [Page 44]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              D4ZubIon0XGe9fIjLnmb3pX/FUk= )
                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn
                              uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE
                              NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a
                              1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187
                              sSNF3PAC0HPadh7SdHmXlFQtQ44= )

   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
   these DNSKEY RRs also has the SEP flag set and has been used to sign
   the apex DNSKEY RRset; this is the key which should be hashed to
   generate a DS record to be inserted into the parent zone.  The other
   DNSKEY is used to sign all the other RRsets in the zone.

   The zone includes a wildcard entry "*.w.example".  Note that the name
   "*.w.example" is used in constructing NSEC chains, and that the RRSIG
   covering the "*.w.example" MX RRset has a label count of 2.

   The zone also includes two delegations.  The delegation to
   "b.example" includes an NS RRset, glue address records, and an NSEC
   RR; note that only the NSEC RRset is signed.  The delegation to
   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
   are signed.

Arends, et al.          Expires August 16, 2004                [Page 45]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

Appendix B. Example Responses

   The examples in this section show response messages using the signed
   zone example in Appendix A.

B.1 Answer

   A successful query to an authoritative server.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   x.w.example.        IN MX

   ;; Answer
   x.w.example.   3600 IN MX  1 xx.example.
   x.w.example.   3600 RRSIG  MX 5 3 3600 20040115201552 (
                              20031216201552 41681 example.
                              g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
                              ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
                              8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
                              MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
                              btznHMFDIbtuw/tAX7xXH2pDDHY= )

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
                              +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
                              s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
                              eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
                              FTVyQbVkcaxQ6U2FbZtMbfo//go= )

   ;; Additional
   xx.example.    3600 IN A   192.0.2.10
   xx.example.    3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
                              tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
                              iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
                              KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
                              0ToQVY81bPc3WXKZjRxQl3jiKtU= )
   xx.example.    3600 AAAA   2001:db8::f00:baaa
   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2

Arends, et al.          Expires August 16, 2004                [Page 46]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
                              mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
                              CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
                              D4ZubIon0XGe9fIjLnmb3pX/FUk= )
   ns1.example.   3600 IN A   192.0.2.1
   ns1.example.   3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
                              CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
                              RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
                              +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
                              WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
   ns2.example.   3600 IN A   192.0.2.2
   ns2.example.   3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
                              xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
                              HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
                              sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
                              wCbeY0Rl8MIRcAaiIkFos/8hd1g= )

B.2 Name Error

   An authoritative name error.  The NSEC RRs prove that the name does
   not exist and that no covering wildcard exists.

   ;; Header: QR AA DO RCODE=3
   ;;
   ;; Question
   ml.example.         IN A

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1071609350
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
                              hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
                              VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj

Arends, et al.          Expires August 16, 2004                [Page 47]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
                              owLe/OV+Qqqic7ShV/S9l2YJF9I= )
   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
   b.example.     3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
                              VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
                              VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
                              k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
                              GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
   example.       3600 RRSIG  NSEC 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
                              vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
                              TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
                              Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
                              7T/nOEOVZujD8IN/Utv+KUg+P6U= )

   ;; Additional
   ;; (empty)

B.3 No Data Error

   A "NODATA" response.  The NSEC RR proves that the name exists and
   that the requested RR type does not.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   ns1.example.        IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1071609350
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
                              hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0

Arends, et al.          Expires August 16, 2004                [Page 48]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
                              CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
                              owLe/OV+Qqqic7ShV/S9l2YJF9I= )
   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
                              sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
                              eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
                              s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
                              I2A5W86mMEbSgEF/pZHX/wi5FJI= )

   ;; Additional
   ;; (empty)

B.4 Referral to Signed Zone

   Referral to a signed zone.   The DS RR contains the data which the
   resolver will need to validate the corresponding DNSKEY RR in the
   child zone's apex.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.a.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   a.example.     3600 IN NS  ns1.a.example.
   a.example.     3600 IN NS  ns2.a.example.
   a.example.     3600 DS     48327 5 1 (
                              DFEB5E00E71A4DED5CABBBD7F15F24871983
                              CAB7 )
   a.example.     3600 RRSIG  DS 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
                              hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
                              rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
                              ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
                              0yfe2uolEkeegjesDZuF+fC61Eg= )

   ;; Additional
   ns1.a.example. 3600 IN A   192.0.2.5
   ns2.a.example. 3600 IN A   192.0.2.6

Arends, et al.          Expires August 16, 2004                [Page 49]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

B.5 Referral to Unsigned Zone

   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
   this delegation exists in the parent zone.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.b.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   b.example.     3600 IN NS  ns1.b.example.
   b.example.     3600 IN NS  ns2.b.example.
   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
   b.example.     3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
                              VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
                              VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
                              k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
                              GRIZP9W1bgeDHZRcCNz2hQ67SgY= )

   ;; Additional
   ns1.b.example. 3600 IN A   192.0.2.7
   ns2.b.example. 3600 IN A   192.0.2.8

B.6 Wildcard Expansion

   A successful query which was answered via wildcard expansion. The
   label count in the answer's RRSIG RR indicates that a wildcard RRset
   was expanded to produce this response, and the NSEC RR proves that no
   closer match exists in the zone.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   a.z.w.example.      IN MX

   ;; Answer
   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
                              OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns

Arends, et al.          Expires August 16, 2004                [Page 50]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

                              Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
                              n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
                              91Ena87PA2MvoOE+A3ZpEk8MjEE= )

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
                              +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
                              s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
                              eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
                              FTVyQbVkcaxQ6U2FbZtMbfo//go= )
   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040115201552 (
                              20031216201552 41681 example.
                              sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
                              VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
                              Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
                              AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
                              viOQHZ6I4xoZQP5G7r98/PhlrLM= )

   ;; Additional
   ai.example.    3600 IN A   192.0.2.9
   ai.example.    3600 RRSIG  A 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
                              jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
                              Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
                              OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
                              sWifTxvcG5hv+A6TOd0O2xJYRik= )
   ai.example.    3600 AAAA   2001:db8::f00:baa9
   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
                              9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
                              G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
                              A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
                              zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )

B.7 Wildcard No Data Error

   A "NODATA" response for a name covered by a wildcard.  The NSEC RRs
   prove that the matching wildcard name does not have any RRs of the
   requested type and that no closer match exists in the zone.

Arends, et al.          Expires August 16, 2004                [Page 51]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   a.z.w.example.      IN AAAA

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1071609350
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
                              hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
                              VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
                              CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
                              owLe/OV+Qqqic7ShV/S9l2YJF9I= )
   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040115201552 (
                              20031216201552 41681 example.
                              sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
                              VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
                              Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
                              AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
                              viOQHZ6I4xoZQP5G7r98/PhlrLM= )
   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040115201552 (
                              20031216201552 41681 example.
                              OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
                              f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
                              9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
                              /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
                              ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )

   ;; Additional
   ;; (empty)

B.8 DS Child Zone No Data Error

   A "NODATA" response for a QTYPE=DS query which was mistakenly sent to
   a name server for the child zone.

Arends, et al.          Expires August 16, 2004                [Page 52]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   example.            IN DS

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1071609350
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
                              hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
                              VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
                              CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
                              owLe/OV+Qqqic7ShV/S9l2YJF9I= )
   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
   example.       3600 RRSIG  NSEC 5 1 3600 20040115201552 (
                              20031216201552 41681 example.
                              kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
                              vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
                              TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
                              Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
                              7T/nOEOVZujD8IN/Utv+KUg+P6U= )

   ;; Additional
   ;; (empty)

Arends, et al.          Expires August 16, 2004                [Page 53]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

Appendix C. Authentication Examples

   The examples in this section show how the response messages in
   Appendix B are authenticated.

C.1 Authenticating An Answer

   The query in section Appendix B.1 returned an MX RRset for
   "x.w.example.com". The corresponding RRSIG indicates the MX RRset was
   signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
   The resolver needs the corresponding DNSKEY RR in order to
   authenticate this answer.   The discussion below describes how a
   resolver might obtain this DNSKEY RR.

   The RRSIG indicates the original TTL of the MX RRset was 3600 and,
   for the purpose of authentication, the current TTL is replaced by
   3600.   The RRSIG labels field value of 3 indicates the answer was
   not the result of wildcard expansion.  The "x.w.example.com" MX RRset
   is placed in canonical form and, assuming the current time falls
   between the signature inception and expiration dates, the signature
   is authenticated.

C.1.1 Authenticating the example DNSKEY RR

   This example shows the logical authentication process that starts
   from the a preconfigured root DNSKEY (or DS RR) and moves down the
   tree to authenticate the desired "example" DNSKEY RR.   Note the
   logical order is presented for clarity and an implementation may
   choose to construct the authentication as referrals are received or
   may choose to construct the authentication chain only after all
   RRsets have been obtained, or in any other combination it sees fit.
   The example here demonstrates only the logical process and does not
   dictate any implementation rules.

   We assume the resolver starts with an preconfigured DNSKEY RR for the
   root zone (or a preconfigured DS RR for the root zone).  The resolver
   checks this preconfigured DNSKEY RR is present in the root DNSKEY
   RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset),
   this DNSKEY RR has signed the root DNSKEY RRset and the signature
   lifetime is valid.  If all these conditions are met, all keys in the
   DNSKEY RRset are considered authenticated.   The resolver then uses
   one (or more) of the root DNSKEY RRs to authenticate the "example" DS
   RRset.  Note the resolver may need to query the root zone to obtain
   the root DNSKEY RRset and/or "example" DS RRset.

   Once the DS RRset has been authenticated using the root DNSKEY, the
   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
   RR that matches one of the authenticated "example" DS RRs.  If such a

Arends, et al.          Expires August 16, 2004                [Page 54]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   matching "example" DNSKEY is found, the resolver checks this DNSKEY
   RR has signed the "example" DNSKEY RRset and the signature lifetime
   is valid.  If all these conditions are met, all keys in the "example"
   DNSKEY RRset are considered authenticated.

   Finally the resolver checks that some DNSKEY RR in the "example"
   DNSKEY RRset uses algorithm 5 and has a key tag of 41681.  This
   DNSKEY is used to authenticated the RRSIG included in the response.
   If multiple "example" DNSKEY RRs have algorithm 5 and key tag of
   41681, then each DNSKEY RR is tried and the answer is authenticated
   if either DNSKEY RR validates the signature as described above.

C.2 Name Error

   The query in section Appendix B.2 returned NSEC RRs that prove the
   requested data does not exist and no wildcard applies.  The negative
   reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
   authenticated in a manner identical to that of the MX RRset discussed
   above.

C.3 No Data Error

   The query in section Appendix B.3 returned an NSEC RR that proves the
   requested name exists, but the requested RR type does not exist. The
   negative reply is authenticated by verifying the NSEC RR.  The NSEC
   RR is authenticated in a manner identical to that of the MX RRset
   discussed above.

C.4 Referral to Signed Zone

   The query in section Appendix B.4 returned a referral to the signed
   "a.example." zone.  The DS RR is authenticated in a manner identical
   to that of the MX RRset discussed above. This DS RR is used to
   authenticate the "a.example" DNSKEY RRset.

   Once the "a.example" DS RRset has been authenticated using the
   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
   matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
   RR has signed the "a.example" DNSKEY RRset and the signature lifetime
   is valid.  If all these conditions are met, all keys in the
   "a.example" DNSKEY RRset are considered authenticated.

C.5 Referral to Unsigned Zone

   The query in section Appendix B.5 returned a referral to an unsigned
   "b.example." zone.  The NSEC proves that no authentication leads from
   "example" to "b.example" and the NSEC RR is authenticated in a manner

Arends, et al.          Expires August 16, 2004                [Page 55]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   identical to that of the MX RRset discussed above.

C.6 Wildcard Expansion

   The query in section Appendix B.6 returned an answer that was
   produced as a result of wildcard expansion.   The RRset expanded as
   the similar to The corresponding RRSIG indicates the MX RRset was
   signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
   The RRSIG indicates the original TTL of the MX RRset was 3600 and,
   for the purpose of authentication, the current TTL is replaced by
   3600.   The RRSIG labels field value of 2 indicates the answer the
   result of wildcard expansion since the "a.z.w.example" name contains
   4 labels.  The name "a.z.w.w.example" is replaced by "*.w.example",
   the MX RRset is placed in canonical form and, assuming the current
   time falls between the signature inception and expiration dates, the
   signature is authenticated.

   The NSEC proves that no closer match (exact or closer wildcard) could
   have been used to answer this query and the NSEC RR must also be
   authenticated before the answer is considered valid.

C.7 Wildcard No Data Error

   The query in section Appendix B.7 returned NSEC RRs that prove the
   requested data does not exist and no wildcard applies.  The negative
   reply is authenticated by verifying both NSEC RRs.

C.8 DS Child Zone No Data Error

   The query in section Appendix B.8 returned NSEC RRs that shows the
   requested was answered by a child server ("example" server).   The
   NSEC RR indicates the presence of an SOA RR, showing the answer is
   from the child .  Queries for the "example" DS RRset should be sent
   to the parent servers ("root" servers).

Arends, et al.          Expires August 16, 2004                [Page 56]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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 assignees.

   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

Arends, et al.          Expires August 16, 2004                [Page 57]

Internet-Draft       DNSSEC Protocol Modifications         February 2004

   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 16, 2004                [Page 58]