rfc3658.txt

非常好的dns解析软件

   at delegation points, so will not be affected by this.

   A nameserver authoritative for only the child zone, 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, or 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
          nameserver

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

   Such a situation might arise when a nameserver 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 13, but "net." is severed on different nameservers.

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

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

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




Gudmundsson                 Standards Track                     [Page 7]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


   3) If the nameserver is authoritative for the zone that holds the
      <QNAME>'s SOA RR set, the response is an authoritative negative
      answer as described in 2.2.1.1.

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

   5) If the nameserver is not authoritative for any part of the QNAME,
      a response indicating a lame nameserver 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 nameserver 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 nameserver for .net.  Instead, rule number
   3 above applies and a negative answer is returned by the nameserver.
   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 nameserver has answered.

   A solution would be 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 striping 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 can 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 left most label of the SOA owner name will
   lead to the location of the desired data.

2.2.1.3.  Modification on use of KEY RR in the construction of Responses

   This section updates RFC 2535 section 3.5 by replacing it with the
   following:






Gudmundsson                 Standards Track                     [Page 8]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


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

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

   RFC 2535 specified that KEY records be added to the additional
   section when SOA or NS records were included in an answer.  This was
   done to reduce round trips (in the case of SOA) and to force out NULL
   KEYs (in the NS case).  As this document obsoletes NULL keys, there
   is no need for the inclusion of KEYs with NSs.  Furthermore, as SOAs
   are included in the authority section of negative answers, including
   the KEYs each time will cause redundant transfers of KEYs.

   RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
   the response for a query for A and AAAA types.  As Restrict KEY
   [RFC3445] eliminated use of KEY RR by all applications, this rule is
   no longer needed.

2.2.2.  Signer's Name (replaces RFC 3008 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 RFC 3090

   A number of sections in RFC 3090 need to be updated to reflect the DS
   record.

2.2.3.1.  RFC 3090: 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.







Gudmundsson                 Standards Track                     [Page 9]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


2.2.3.2.  RFC 3090 section 2.1: Globally Secured

   Rule 2.1.b is replaced by the following rule:

   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.  RFC 3090 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

   RFC 3445 section 3 eliminates the top two bits in the flags field of
   KEY RR.  These two bits were used to indicate NULL KEY or NO KEY. RFC
   3090 defines that zone as either secure or not and these rules
   eliminate the 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 eliminate all uses for the NULL KEY.  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 RFC 2535 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 required
   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 interoperability problems and requires a flag
   day for DNSSEC.  Many old nameservers and resolvers MUST be upgraded
   to take advantage of DS.  Some old nameservers 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
   nameservers; in fact, some might even refuse to pass on the DS or NXT
   records.



Gudmundsson                 Standards Track                    [Page 10]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


2.4.  Wire Format of the DS record

   The DS (type=43) 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 RFC 2535.  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 interoperability
   reasons, keeping number of digest algorithms low is strongly
   RECOMMENDED.  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 records 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                 Standards Track                    [Page 11]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 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.

   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 RFC 2535 is provided.

   RFC 2535-compliant resolvers will assume that all DS-secured
   delegations are locally secure.  This is bad, but the DNSEXT Working
   Group has determined that rather than dealing with both RFC 2535-
   secured zones and DS-secured zones, a rapid adoption of DS is
   preferable.  Thus, the only option for early adopters is to upgrade
   to DS as soon as possible.

2.6.1.  Backwards compatibility with RFC 2535 and RFC 1035

   This section documents how a resolver determines the type of
   delegation.







Gudmundsson                 Standards Track                    [Page 12]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


   RFC 1035 delegation (in parent) has:

   RFC 1035           NS

   RFC 2535 adds the following two cases:

   Secure RFC 2535:   NS + NXT + SIG(NXT)
                      NXT bit map contains: NS SIG NXT
   Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
                      NXT bit map contains: NS SIG KEY NXT
                      KEY must be a NULL key.

   DNSSEC with DS has the following two states:

   Secure DS:         NS + DS + SIG(DS)
                      NXT bit map contains: NS SIG NXT DS
   Unsecure DS:       NS + NXT + SIG(NXT)
                      NXT bit map contains: NS SIG NXT

   It is difficult for a resolver to determine if a delegation is secure
   RFC 2535 or unsecure DS.  This could be overcome by adding a flag to
   the NXT bit map, but only upgraded resolvers would understand this
   flag, anyway.  Having both parent and child signatures for a KEY
   RRset might allow old resolvers to accept a zone as secure, but the
   cost of doing this for a long time is much higher than just
   prohibiting RFC 2535-style signatures at child zone apexes and
   forcing rapid deployment of DS-enabled nameservers and resolvers.

   RFC 2535 and DS can, in theory, be deployed in parallel, but this
   would require resolvers to deal with RFC 2535 configurations forever.
   This document obsoletes the NULL KEY in parent zones, which is a
   difficult enough change that to cause a flag day.

2.7.  KEY and corresponding DS record example