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

bind-3.2.

   RRs to prove that no wildcard matches a given query name.



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


3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches

   If the query name does not exist, but a wildcard expansion can be
   used to return a positive match to the query, then the wildcard-
   expanded answer and any SIG RRs associated with the wildcard RR MUST
   be returned in the Answer section.  The Authority section of the
   response MUST include the following NXT RRs:

   o  An NXT RR which proves that there were no exact matches for the
      QNAME and QTYPE; and

   o  An NXT RR which proves that there are no closer wildcard entries
      which could have been expanded to match the query.

   If space does not permit inclusion of these NXT RRs, the response
   MUST be considered truncated, and the TC bit MUST be set.  Any SIG
   RRs associated with the NXT RRsets MUST also be included in the
   response.

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

   Appendix A provides an algorithm which computes the appropriate NXT
   RRs to prove that no closer wildcard matches the query name.

3.4 Including DS RRs In a Response

   When a query has the DO bit set to one, and a DS RR exists at the
   query name, an authoritative security-aware name server returning a
   referral for the delegation MUST include both the NS RRset and also
   the DS RRset and its associated SIG RR(s).  The NS RRset MUST be
   placed before the DS RRset and its associated SIG RRs.

   When a query has the DO bit set to one, and no DS RR exists at the
   query name, an authoritative security-aware name server returning a
   referral for the delegation MUST include both the NS RRset and also
   the NXT RR and associated SIG RR(s) which proves that the DS RRset
   does not exist.  The NS RRset MUST be placed before the NXT RRset and
   its associated SIG RR(s).

   This increases the size of referral messages, and may cause some or
   all glue RRs to be omitted.  If space does not permit the inclusion
   of the DS or NXT RRset and associated SIG RRs, the response MUST be
   considered truncated, and the TC bit MUST be set.

3.5 Responding to Queries for DS RRs

   The DS record is the first resource record type which appears only on



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


   the parent zone's side of a zone cut.  In other words, the DS record
   for the delegation of "example.com" is only stored in the "com" zone.
   This introduces novel name server behavior, since the name server for
   the child zone is authoritative for the name by the normal DNS rules
   but the child zone does not contain the DS RR.  A name server's
   response to a DS query depends on whether the name server is
   authoritative for the parent zone, the child zone, or both, as
   described below.

   If a name server is authoritative for the parent zone, and receives a
   query for the DS record at the delegated name, then the name server
   MUST return the DS RRset from the parent zone.  This rule applies
   regardless of whether or not the name server is also authoritative
   for the child zone.

   If the name server is authoritative for the child zone, is not
   authoritative for the parent zone, and receives a query for the DS
   record at the delegated name, there is no obvious response, because
   the child zone is not authoritative for the DS record at the child
   zone's apex, and the authoritative DS RR is only stored at the
   parent.

   If the name server allows recursion, and the RD bit is set in the
   query, the name server MAY perform recursion to find the DS record
   for the delegated name from the parent zone, and MAY return the DS
   record from its cache.  In this case, the AA bit MUST NOT be set in
   the response.

   If the name server does not perform recursion to find the DS RR,  the
   name server MUST reply with:

         RCODE:             NOERROR
         AA bit:            set
         Answer Section:    Empty
         Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]

   In other words, a name server which is authoritative for the child
   zone but not for the parent zone answers as if the DS record does not
   exist.  Note that security-aware resolvers will query the parent zone
   at delegation points, and thus will not be affected by this behavior.

   For example, suppose that "example.com" is a delegation point, and a
   name server receives a query for the "example.com" DS RRset.

   o  If the name server is authoritative for "com", the name server
      MUST reply with the "example.com" DS RRset from the "com" zone.

   o  If the name server is authoritative for "example.com", is not



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


      authoritative for "com", and the RD bit is set to one in the
      query, the name server MAY perform recursion to find the
      "example.com" DS record.  If the name server does not use
      recursion to obtain the DS RR, the name server MUST reply as
      though the DS RR did not exist:

            RCODE:             NOERROR
            AA bit:            set
            Answer Section:    Empty
            Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]


3.6 Responding to Queries for Type AXFR or IXFR

   DNSSEC does not change the DNS zone transfer process.  A signed zone
   will contain SIG, KEY, NXT, 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 Section 2.  The primary objective of a zone
   transfer 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.

   Note that the DS RR appears only in the parental side of a
   delegation, and is authoritative data in the parent zone.  For
   example, the DS RR for "example.com" is stored in the "com" zone (the
   parent zone) rather than in the "example.com" zone (the child zone).
   As with any other authoritative RRset, the "example.com" DS RR MUST
   be included the "com" zone transfer.

   Note that authoritative NXT RRs appear in both the parent and child
   zones at a delegated name, and that the NXT RRs for the delegated
   name in the parent and child zones are never identical to each other.
   As with any other authoritative RRset, the parental NXT RR at a
   delegated name MUST be included zone transfers of the parent zone,
   while the NXT at the zone apex of the child zone MUST be included in
   zone transfers of the child zone.

3.7 Setting the AD and CD Bits in a Response

      Editors' note: This section seems a little lost here.  Perhaps we



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


      should rearrange the section ordering slightly, or provide a
      pointer to this subsection at the beginning of Section 3.

   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 set in query messages by the resolver, and MUST be
   copied into the response.  If the CD bit is set to one, it indicates
   that the resolver is willing to perform authentication, and thus that
   the name server need not perform authentication on the RRsets in the
   response.

   Regardless of the setting of the CD bit, the name server MAY choose
   whether or not to perform authentication according to the local name
   server policy.  The CD bit MAY be used in constructing the local name
   server policy.  If local name server policy does perform
   authentication, any RRsets rejected by the local authentication
   policy MUST NOT be returned in a response (regardless of the CD bit).

   The AD bit is set by name servers, and indicates the data in the
   response has been authenticated by the name server, according to the
   local name server policy.  The AD bit MUST NOT be set on a response
   unless all of the RRsets in the Answer and Authority sections have
   met the name server's local authentication policy.  A resolver MUST
   NOT trust the AD bit unless it communicates with the name server over
   a secure transport mechanism and is explicitly configured to trust
   the name server's policy.

3.8 Example DNSSEC Responses

   The examples in this section use the following example zone to
   demonstrate the formation of replies by an authoritative name server.
   The zone has two name servers, a single child, and a wildcard MX RR.
   The zone is completely signed and has a full NXT chain.

















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


      example.com.    SOA     (...)
                      SIG     SOA ...
                      NS      a.example.com.
                      NS      b.example.com.
                      SIG     NS ...
                      MX      10 a.example.com
                      SIG     MX ...
                      KEY     ...
                      SIG     KEY ...
                      NXT     *.example.com.
      *               MX      10 a.example.com.
                      SIG     MX ...
                      NXT     a.example.com.
      a               A       10.10.10.1
                      SIG     A ...
                      NXT     b.example.com.
      b               A       10.10.10.2
                      SIG     A ...
                      NXT     c.example.com.
      c               CNAME   a.example.com.
                      SIG     CNAME
                      NXT     sub.example.com.
      sub             NS      ns.sub.example.com.
                      SIG     NS
                      DS      ...
                      SIG     DS
                      NXT     *.example.com.
      ns.sub          A       10.10.10.3
      sub-nosig       NS      ns.sub-nosig.example.com.
                      NXT     example.com.
      ns.sub-nosig    A       10.10.10.4




















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


   A query to the authoritative name server for this zone for
   QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         c.example.com.         IN A
      ANSWER:
         c.example.com.         IN A   a.example.com
                                IN SIG CNAME
         a.example.com.         IN A   10.10.10.1
                                IN SIG A
      AUTHORITY:
         example.com.           IN NS  a.example.com.
                                IN NS  b.example.com.
                                IN SIG NS ...
      ADDITIONAL:
         a.example.com.         IN A   10.10.10.1
                                IN SIG A ...
         b.example.com.         IN A   10.10.10.2
                                IN SIG A ...
         example.com.           IN KEY ...
                                IN SIG KEY ...

   A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
   results in a referral to a signed zone.  The resolver can determine
   that "sub.example.com" is signed because of the presence of the DS RR
   with the hash of the "sub.example.com" zone key.

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         www.sub.example.com.  IN   A
      ANSWER:
         ;; empty
      AUTHORITY:
         sub.example.com.      IN  NS  ns.sub.example.com.
                               IN  DS  ...
                               IN  SIG DS ...
      ADDITIONAL:
         ns.sub.example.com.   IN  A   10.10.10.3