draft-ietf-dnsext-delegation-signer-14.txt

bind-3.2.

   A server authoritative for only the child zone at a delegation point
   that is also a caching server MAY (if the RD bit is set in the query)
   perform recursion to find the DS record at the delegation point, and
   may return the DS record from its cache.  In this case, the AA bit
   MUST not be set in the response.


2.2.1.2 Special processing when child and an ancestor share server"

   Special rules are needed to permit DS RR aware servers to gracefully
   interact with older caches which otherwise might falsely label a
   server as lame because of the new placement of the DS RR set.

   Such a situation might arise when a server is authoritative for both
   a zone and it's grandparent, but not the parent.  This sounds like an
   obscure example, but it is very real.  The root zone is currently
   served on 13 machines, and "root-servers.net." is served on 4 of the
   same 13, but "net." is served elsewhere.

   When a server receives a query for (<QNAME>, DS, IN), the response
   MUST be determined from reading these rules in order:


   1) If the server is authoritative for the zone that holds the DS RR
   set (i.e., the zone that delegates <QNAME> away, aka the "parent"
   zone), the response contains the DS RR set as an authoritative
   answer.

   2) If the server is offering recursive service and the RD bit is set
   in the query, the server performs the query itself (according to the
   rules for resolvers described below) and returns it's findings.

   3) If the server is authoritative for the zone that holds the
   <QNAME>'s SOA RR set, the response is an authoritative negative



Gudmundsson               Expires December 2003                 [Page 6]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   answer as described in 2.2.1.1.

   4) If the server is authoritative for a zone or zones above the
   QNAME, a referral to the most enclosing zone's servers is made.

   5) If the server is not authoritative for any part of the QNAME, a
   response indicating a lame server for QNAME is given.

   Using these rules will require some special processing on the part of
   a DS RR aware resolver.  To illustrate this, an example is used.

   Assuming a server is authoritative for roots.example.net. and for the
   root zone but not the intervening two zones (or the intervening two
   label deep zone).  Assume that QNAME=roots.example.net., QTYPE=DS,
   and QCLASS=IN.

   The resolver will issue this request (assuming no cached data)
   expecting a referral to a net. server.  Instead, rule number 3 above
   applies and a negative answer is returned by the server.  The
   reaction by the resolver is not to accept this answer as final as it
   can determine from the SOA RR in the negative answer the context
   within which the server has answered.

   A solution to this is to instruct the resolver to hunt for the
   authoritative zone of the data in a brute force manner.

   This can be accomplished by taking the owner name of the returned SOA
   RR and strip off enough left-hand labels until a successful NS
   response is obtained.  A successful response here means that the
   answer has NS records in it.  (Entertaining the possibility that a
   cut point may be two labels down in a zone.)

   Returning to the example, the response will include a negative answer
   with either the SOA RR for "roots.example.net." or "example.net."
   depending on whether roots.example.net is a delegated domain.  In
   either case, removing the least significant label of the SOA owner
   name will lead to the location of the desired data.


2.2.1.3 Modification on KEY RR in the construction of Responses

   This section updates RFC2535 section 3.5 by replacing it with the
   following:

   An query for KEY RR MUST NOT trigger any additional section
   processing.  Security aware resolver will include corresponding SIG
   records in the answer section.





Gudmundsson               Expires December 2003                 [Page 7]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   KEY records SHOULD NOT be added to additional records section in
   response to any query.

   RFC2535 included rules to in add KEY records to additional section
   when SOA or NS records where included in an answer. The is was done
   to reduce round trips (in the case of SOA) and to force out NULL
   KEY's (in the NS case), as this document obsoletes NULL keys there is
   no need for the second case, the first case causes redundant
   transfers of KEY RRset as SOA is included in the authority section of
   negative answers.

   RFC2535 section 3.5 also included rule for adding KEY RRset to query
   for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by
   all applications therfore the rule is not needed anymore.


2.2.2 Signer's Name (replaces RFC3008 section 2.7)

   The signer's name field of a SIG RR MUST contain the name of the zone
   to which the data and signature belong.  The combination of signer's
   name, key tag, and algorithm MUST identify a zone key if the SIG is
   to be considered material.  This document defines a standard policy
   for DNSSEC validation; local policy may override the standard policy.

   There are no restrictions on the signer field of a SIG(0) record.
   The combination of signer's name, key tag, and algorithm MUST
   identify a key if this SIG(0) is to be processed.


2.2.3 Changes to RFC3090

   A number of sections of RFC3090 need to be updated to reflect the DS
   record.


2.2.3.1 RFC3090: Updates to section 1: Introduction

   Most of the text is still relevant but the words ``NULL key'' are to
   be replaced with ``missing DS RRset''. In section 1.3 the last three
   paragraphs discuss the confusion in sections of RFC 2535 that are
   replaced in section 2.2.1 above. Therefore, these paragraphs are now
   obsolete.


2.2.3.2 RFC3090 section 2.1: Globally Secured

   Rule 2.1.b is replaced by the following rule:





Gudmundsson               Expires December 2003                 [Page 8]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
   private key whose public counterpart MUST appear in a zone signing
   KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
   implement algorithm.  This KEY RR MUST be identified by a DS RR in a
   signed DS RRset in the parent zone.

   If a zone cannot get its parent to advertise a DS record for it, the
   child zone cannot be considered globally secured.  The only exception
   to this is the root zone, for which there is no parent zone.


2.2.3.3 RFC3090 section 3: Experimental Status.

   The only difference between experimental status and globally secured
   is the missing DS RRset in the parent zone. All locally secured zones
   are experimental.


2.2.4 NULL KEY elimination

   RFC3445 section 3 elminates the top two bits in the flags field of
   KEY RR. These two bits where used to indicate NULL KEY or NO KEY.
   RFC3090 defines that zone that defines that zone is either secure or
   not, eliminates the possible need to put NULL keys in the zone apex
   to indicate that the zone is not secured for a algorithm.  Along with
   this document these other two elminate all uses for the NULL KEY,
   Thus this document obsoletes NULL KEY.

2.3 Comments on Protocol Changes

   Over the years there have been various discussions surrounding the
   DNS delegation model, declaring it to be broken because there is no
   good way to assert if a delegation exists. In the RFC2535 version of
   DNSSEC, the presence of the NS bit in the NXT bit map proves there is
   a delegation at this name.  Something more explicit is needed and the
   DS record addresses this need for secure delegations.

   The DS record is a major change to DNS: it is the first resource
   record that can appear only on the upper side of a delegation. Adding
   it will cause interoperabilty problems and requires a flag day for
   DNSSEC. Many old servers and resolvers MUST be upgraded to take
   advantage of DS.  Some old servers will be able to be authoritative
   for zones with DS records but will not add the NXT or DS records to
   the authority section.  The same is true for caching servers; in
   fact, some may even refuse to pass on the DS or NXT records.







Gudmundsson               Expires December 2003                 [Page 9]

INTERNET-DRAFT          Delegation Signer Record           February 2003


2.4 Wire Format of the DS record

   The DS (type=TDB) record contains these fields: key tag, algorithm,
   digest type, and the digest of a public key KEY record that is
   allowed and/or used to sign the child's apex KEY RRset. Other keys
   MAY sign the child's apex KEY RRset.

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           key tag             |  algorithm    |  Digest type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                digest  (length depends on type)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                (SHA-1 digest is 20 bytes)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The key tag is calculated as specified in RFC2535. Algorithm MUST be
   an algorithm number assigned in the range 1..251 and the algorithm
   MUST be allowed to sign DNS data.  The digest type is an identifier
   for the digest algorithm used. The digest is calculated over the
   canonical name of the delegated domain name followed by the whole
   RDATA of the KEY record (all four fields).

      digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)

      KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key

   Digest type value 0 is reserved, value 1 is SHA-1, and reserving
   other types requires IETF standards action. For interoperabilty
   reasons, as few digest algorithms as possible should be reserved. The
   only reason to reserve additional digest types is to increase
   security.

   DS records MUST point to zone KEY records that are allowed to
   authenticate DNS data.  The indicated KEY record's protocol field
   MUST be set to 3; flag field bit 7 MUST be set to 1.  The value of
   other flag bits is not significant for the purposes of this document.

   The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
   of key size, new digest types probably will have larger digests.





Gudmundsson               Expires December 2003                [Page 10]

INTERNET-DRAFT          Delegation Signer Record           February 2003


2.4.1 Justifications for Fields

   The algorithm and key tag fields are present to allow resolvers to
   quickly identify the candidate KEY records to examine.  SHA-1 is a
   strong cryptographic checksum: it is computationally infeasible for
   an attacker to generate a KEY record that has the same SHA-1 digest.
   Combining the name of the key and the key rdata as input to the
   digest provides stronger assurance of the binding.  Having the key
   tag in the DS record adds greater assurance than the SHA-1 digest
   alone, as there are now two different mapping functions that a KEY RR
   must match.

   This format allows concise representation of the keys that the child
   will use, thus keeping down the size of the answer for the
   delegation, reducing the probability of DNS message overflow. The
   SHA-1 hash is strong enough to uniquely identify the key and is
   similar to the PGP key footprint. The digest type field is present
   for possible future expansion.

   The DS record is well suited to listing trusted keys for islands of
   security in configuration files.

2.5 Presentation Format of the DS Record

   The presentation format of the DS record consists of three numbers
   (key tag, algorithm and digest type) followed by the digest itself
   presented in hex:
      example.   DS  12345 3 1 123456789abcdef67890123456789abcdef67890

2.6 Transition Issues for Installed Base

   No backwards compatibility with RFC2535 is provided.

   RFC2535-compliant resolvers will assume that all DS-secured