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

bind-3.2.

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


   A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A
   would result in a referral to an unsigned zone.  The resolver knows
   not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS
   bit in the NXT RR bitmap in the referral is not set.  Even if DNSSEC
   RRs are present in responses from "sub-nosig.example.com" name
   servers, the resolver will not be able to construct a authentication
   chain, since there is a break between "sub-nosig.example.com" and its
   delegating parent zone.

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

   A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name
   error, because the name does not exist and is not covered by wildcard
   expansion.  Therefore, the name server must present proof that the
   name does not exist, and that no wildcard expansion is present which
   could have been used to answer the query.

      Flags:  QR=1, AA=1, RCODE=3 (NXDOMAIN)
      EDNS:   DO=1, size=4000
      QUERY:
         f.example.com.        IN  A
      ANSWER:
         ;; empty
      AUTHORITY:
         example.com.          IN  SOA ...
                               IN  SIG SOA ...
         c.example.com.        IN  NXT sub.example.com. ...
                               IN  SIG NXT ...
         *.example.com.        IN  NXT a.example.com. ...
                               IN  SIG NXT ...
      ADDITIONAL:
         example.com.          IN  KEY ...
                               IN  SIG KEY ...







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


   A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
   RR synthesized via wildcard expansion.  The name server must prove
   that no exact match exists.

      Flags:  QR=1, AA=1, RCODE=0 (NOERROR)
      EDNS:   DO=1, size=4000
      QUERY:
         f.example.com.        IN  MX
      ANSWER:
         f.example.com.        IN  MX  10 a.example.com.
                               IN  SIG MX ...
      AUTHORITY:
         example.com.          IN  NS  a.example.com.
                               IN  NS  b.example.com.
                               IN  SIG NS ...
         c.example.com.        IN  NXT sub.example.com.
                               IN  SIG NXT ...
      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 ...

   If these responses came from a recursive name server which had all of
   the necessary RRsets in its cache instead of from an authoritative
   server, the only differences would be the TTLs and the header flags.
   The AA bit would not be set, and the AD bit would be set if (and only
   if) all the RRsets in a response passed the security policy checks of
   the recursive name server.




















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


4. Resolving

      Editors' note: This section is still very rough, and some of the
      text here duplicates text from other portions of this document.
      This needs to be fixed (one way or another) during final editing.
      Suggestions for better text would be welcome.

   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 a
   separate subsection.

   A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with
   the DO [7] 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 [8] for discussion of these requirements.

   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.

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

   A security-aware resolver MUST attempt to retrieve missing a NXT RR
   which the resolver needs to authenticate a NODATA response.  In



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


   general it is not possible for a resolver to retrieve missing NXT
   RRs, since the resolver will have no way of knowing the owner name of
   the missing NXT RR, but in the specific case of a NODATA response,
   the resolver does know the name of the missing NXT RR, and must
   therefore attempt to retrieve it.

   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 KEY and DS RRs from a trusted starting point 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 KEY and DS RRs from any trusted starting point to the
       RRset.  This can occur when the target RRset lies in an unsigned
       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 due when
       the security-aware resolver is not able to contact security-aware
       name servers for the relevant zones.

   A security-aware resolver MUST be capable of being preconfigured with
   at least one trusted public key, and SHOULD be capable of being
   preconfigured with multiple trusted public keys.  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.

      Editors' note: Should support for multiple public keys be a MUST
      rather than a SHOULD?

   A security-aware resolver SHOULD cache each response as a single
   atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
   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.

      Editors' note: This is implementation advice which came out of
      discussions at various workshops and investigations into possible
      implementation issues with the (as yet unsettled) opt-in proposal.



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


      All of this advice has been discussed in WG meetings, and as far
      as the editors know these recommendations are not controversial,
      but it is up to the WG to decide whether this sort of
      implementation advice belongs in this document.


4.1 Recursive Name Servers

   As explained in [9], 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 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 initiating request does not have the DO bit set, the name server
   side MUST remove any DNSSEC RRs from the response sent to the
   initiating resolver, but the resolver side MUST follow the usual
   rules for caching which would apply to any security-aware resolver.

   A security-aware recursive name server SHOULD NOT attempt to answer a
   query by piecing together cached data it received in response to
   previous queries that requested different QNAMEs, QTYPEs, or
   QCLASSes.  A security-aware recursive name server SHOULD NOT use NXT
   RRs from one negative response to synthesize a response for a
   different query.  A security-aware recursive name server SHOULD NOT
   use a previous wildcard expansion to generate a response to a
   different query.

      Editors' note: Should any of the SHOULD NOTs in this paragraph be
      MUST NOTs instead?

   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
   whether or not it is required to verify the response data it returns
   to the name server side.

      Editors' note: What should a security-aware recursive name server
      do if it receives a query with CD=1 and DO=0?







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


4.2 Stub resolvers

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

   A security-aware stub 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 stub
   resolver MUST handle fragmented UDP packets correctly regardless of
   whether any such fragmented packets were received via IPv4 or IPv6.
   Please see [8] for discussion of these requirements.

   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.   A security-aware stub resolver MAY include the
   DNSSEC RRs returned by a security-aware recursive name server as part
   of the data that it the stub resolver hands back to the application
   which invoked it, but is not required to do so.

   A security-aware stub resolver SHOULD NOT set the CD bit when sending
   queries, since, by definition, a security-aware stub resolver does
   not validate signatures and thus depends on the security-aware
   recursive name server to perform validation on its behalf.

      Editors' note: Should this SHOULD NOT be a MUST NOT?

   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 recursive name server via a secure channel.