DNSEXT Working Group                                Olafur Gudmundsson

  Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.

                   Delegation Signer Resource Record

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   Comments should be sent to the authors or the DNSEXT WG mailing list

   This draft expires on July 5, September 1, 2002.

   Copyright Notice

   Copyright (C) The Internet Society (2002).  All rights reserved.


   The Delegation Signer Resource Record delegation signer (DS) resource record is inserted at a zone cut point
   (i.e., a delegation point) to indicate tha that the delegated zone is
   digitally signed and that the
   delegation delegated zone recognizes the indicated
   key as a valid zone key for the delegated zone. The DS RR is an a
   modification to the DNS Security Extensions definition, motivated by
   operational considerations. The intent is to use the this resource record
   as an explicit statement about the delegation, rather than relying on

   This document defines the DS RR, gives examples of how it is used and
   the implications of this record on resolvers. This change is not
   backwards compatible with RFC 2535.
   This document updates RFC1035, RFC2535, RFC3008 and RFC3090.

1 - Introduction

   Familiarity with the DNS system [RFC1035], DNS security extensions
   [RFC2535] and DNSSEC terminology [RFC3090] is important.

   Experience shows that when the same data can reside in two
   administratively different DNS zones, the data frequently gets out of
   sync. The presence of an NS record RRset in a zone anywhere other than at
   the apex indicates that this name is a delegation
   and zone cut or delegation.  The RDATA of the NS  record lists
   RRset specifies the authorative authoritative servers for the real delegated or
   "child" zone. Based on actual measurements measurements, 10-30% of all delegations in
   on the Internet have differing NS sets RRsets at parent and child. There
   are a number of reasons for this, including a lack of communication
   between parent and child and bogus name-servers name servers being listed to meet
   registrar requirements.

   DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child must zone needs to
   have its KEY set RRset signed by the its parent to create a verifiable chain
   of KEYs. There has been some debate on where the signed KEY set RRset
   should reside, whether at the child[RFC2535] child [RFC2535] or at the parent. If
   the KEY set RRset resides at the child, maintaining the signed KEY set RRset
   in the child, child requires frequent
   two way two-way communication is needed between the two
   parties. First the child needs to transmit transmits the key set KEY RRset to the parent and
   then the parent sends the signed set or signatures signature(s) to the child. Storing the KEY
   RRset at the parent simplifies the communication.


   DNSSEC [RFC2535] requires that the parent store a NULL key set KEY record for
   an unsecure children, this is intended child zone to be a signal indicate that the child is unsecure. A NULL Key RRset
   KEY record is a waste as a whole waste: an entire signed RRset is used to effectively communicate
   effectively one bit of information, information--that the child is unsecure.
   Chasing down NULL key records KEY RRsets complicates the resolution process in
   cases as cases, because servers for both parent and child need to be
   queried for the KEY
   set RRset if the child server does not return a KEY set. it.
   Storing the KEY
   record RRset only in the parent zone simplifies this and
   would allow the elimination of the NULL key set. KEY RRsets entirely. For
   large delegation zones the cost of NULL keys is a significant barrier
   to deployment.

   Another complication of the DNSSEC KEY key model is that the KEY record is
   can be used to store DNS zone keys and public keys for other protocols. protocols in addition to
   DNSSEC keys.  There are number of potential problems with this this,
     1. The KEY set RRset can become quite large if many applications/protocols applications and
     protocols store their keys at the zone apex. Possible protocols are
     IPSEC, HTTP, SMTP, SSH and others that use public key cryptography.
     2. Key set The KEY RRset may require frequent updates.
     3. Probability The probability of compromised/lost keys increases and triggers compromised or lost keys, which trigger
     emergency key rollover procedures. procedures, increases.
     4. Parent The parent may refuse sign key sets KEY RRsets with NON DNS non-DNSSEC zone keys.
     5. Parent The parent may not meet the child's expectations in turnaround
     in for resigning the key set. KEY RRset.

   Given these and other reasons reasons, there is good reason to explore
   alternatives to using only KEY records to create a chain of trust.

   Some of these problems can be reduced or eliminated by operational
   rules or protocol changes. To reduce the number of keys at the zone
   apex, a rule to require applications to store their KEY records at
   the SRV name for that application is one possibility. Another is to
   restrict the KEY record to DNS keys only DNSSEC keys and create a new record
   type for all non DNS non-DNSSEC keys. Third A third possible solution is to ban
   prohibit the storage of non DNS
   related non-DNSSEC keys at the zone apex. There are
   other possible solutions solutions, but they are outside the scope of this

1.2 - Reserved words Words

   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
   interpreted as described in RFC2119.

2 - DS (Delegation KEY Signer)

2.1 - Delegation Signer Record model Model

   This document presents a replacement of for the DNSSEC KEY record chain
   trust[RFC2535], trust [RFC2535] that uses a new RR that resides only reside at the
   parent.  This record will identify identifies the key(s) that the child uses to self sign
   self-sign its own KEY set. RRset.

   The chain of trust is now established by verifying the parent KEY
   RRset, the DS set RRset from the parent and the KEY set RRset at the child.
   This is cryptographically equivalent to just using just KEY records.

   Communication between the parent and child is greatly reduced, since
   the child only needs to notify the parent about changes in keys that
   sign its apex KEY RRset.  Parent  The parent is ignorant of all other keys in
   the child's apex KEY RRset, furthermore RRset. Furthermore, the child maintains full
   control over the apex KEY set RRset and its content.  Child  The child can
   maintain any policies over regarding its DNS and other KEY usage for DNSSEC and other
   applications and protocols with minimal impact on the parent. Thus if
   the child wants to have frequent key rollover for its DNS zone keys keys,
   the parent does not need to be aware of it as it: the child can use one key
   to only sign only its apex KEY set RRset and other keys to sign the other record sets
   RRsets in the zone.

   This model fits well with a slow roll out rollout of DNSSEC and the islands of
   security model. In the islands of security model this model, someone that who trusts "good.example." can
   preconfigure a key from "good.example." as a trusted keys key, and from
   then on trusts any data that is signed by that key or that has a chain of
   trust to that key.  If "example." starts advertising DS records,
   "good.example." does not have to change
   operations, operations by suspending
   self-signing. DS records can also be used to identify trusted keys
   instead of KEY records.  Another significant advantage is that the
   amount of information stored in the large delegation zones
   reduced, as only signed keying records for secure delegations are
   needed, unlike is reduced:
   rather than the NULL KEY record at every unsecure delegation. delegation required
   by RFC 2535, only secure delegations require additional information
   in the form of a signed DS RRset.

   The main disadvantage of this approach is that verifying delegations a zone's KEY
   RRset requires two signature verification operations instead of the
   one in required by RFC 2535.  There is no impact on the number of
   signatures verified for other RR sets. types of RRsets.

2.2 Protocol change Change

   All DNS servers and resolvers that support DS MUST support the OK bit
   [RFC3225] and support a larger message size[RFC3226]. size [RFC3226].  Each secure
   delegation in a secure zone MUST contain a DS RR set. RRset.  If a query
   contains the OK bit, a server returning a referral for the delegation
   MUST include the following RR sets RRsets in the authority section in this
        parent NS
        DS and SIG(DS)  (if present)
        parent NXT and SIG(NXT/parent) SIG(parent NXT)
   This increases the size of referral messages and may cause some or
   all glue to be omitted. If the DS or NXT RR RRsets or their signatures
   do not fit inside in the DNS message message, the TC bit must MUST be set.  Additional
   section processing is not changed.

   If a

   A DS RR set accompanies the RRset accompanying an NS RR set, this states RRset indicates that the child zone is secured.
   secure. If an NS RR set RRset exists without a DS RR set the
   intent is to state that RRset, the child zone is
   unsecure.  DS sets RRsets MUST NOT appear at non delegations non-delegation points or at zone APEX.

   Following a
   zone's apex.

   The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4,
   section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are
   in section 2.2.3.

2.2.1 RFC2535 2.3.4 and 3.4: Special considerations Considerations at delegation points Delegation Points

   DNS security would like to view views each zone as a unit of data completely under the
   control of the zone owner with each entry (RRset) signed by a special
   private key held by the zone manager.  But the DNS protocol views the
   leaf nodes in a zone, which zone that are also the apex nodes of a subzone child zone
   (i.e., delegation points), points) as "really" belonging to the subzone.  These nodes occur child zone.
   The corresponding domain names appear in two master files and might
   have RRs RRsets signed by both the upper parent and lower zone's child zones' keys. A
   retrieval could get a mixture of these RRs RRsets and SIGs, especially
   since one server could be serving both the zone above and below a
   delegation point[RFC point [RFC 2181].

   For every secure delegation there MUST be a DS record RRset stored in the
   parent zone signed by the parent zone zone's private key. Parent The parent zone
   MUST NOT contain a KEY record RRset at any delegation points. Delegations in
   the parent MAY only contain only the following RR types types: NS, DS, NXT and
   SIG. The NS RR set RRset MUST NOT be signed.  The NXT RR type RRset is the
   exceptional case that case: it will always appear differently and
   authoritatively in both the super-zone parent and
   subzone, child zones if both are


   A secure zones MUST contain a self signed self-signed KEY RR set RRset at its apex.
   Upon verifying the DS set RRset from the parent, the a resolver MAY trust any
   KEY identified in the DS set RRset as a valid signer of the childs child's apex
   set. RRset. Resolvers configured to trust one of the KEY's keys signing the
   set RRset MAY now treat any data signed by the zone keys in the KEY set
   RRset as secure.  In all other cases resolvers MUST consider consider the zone
   unsecure. A DS RRset MUST NOT appear at a zone's apex.

   An authoritative server queried for type DS MUST return the DS RRset
   in the answer section along with the corresponding NXT RRset in the
   authority section.  If the server is authoritative for both parent
   and child zones, the answer MUST be from the zone
   insecure. DS RR parent.  A caching
   server MUST NOT appear at zone APEX. behave the same way, returning the DS RRset and the
   parent's NXT RRset, if records are available.

2.2.2 Signers name Signer's Name (replaces RFC3008 section 2.7)

   The signer's name field of a data SIG 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

   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.4 changes Changes to RFC3090


   A number of sections of RFC3090 need to be updated to reflect the DS
   record. 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 set''. RRset''. In section 1.3 the last three
   paragraphs discuss the confusion in sections of RFC 2535, 2535 that are
   replaced in section 2.2.1 above, thus above. Therefore, these paragraphs are now
   obsolete. RFC3090 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 KEY RR set MUST be self signed self-signed by a
   private key in the KEY RR set. The private key's whose public companion counterpart MUST be appear in a zone signing
   KEY RR (2.a) of a mandatory to implement algorithm and owned by the parent's apex. zone's apex and specifying a mandatory-to-
   implement algorithm.  This KEY must RR MUST be identified by a signed DS RR in a
   signed DS RRset in the parent zone.

   If a zone cannot get a 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 zone. RFC3090 section 3: Experimental Status.

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

2.3 - Comments on protocol changes Protocol Changes

   Over the years there has have been various discussions on that surrounding the
   delegation model in
   DNS is delegation model, declaring it to be broken as because there is no real
   good way to assert if a delegation exists. In the RFC2535 version of DNSSEC
   DNSSEC, the
   authentication presence of a delegation is the NS bit in the NXT bitmap at the bit map proves there is
   a delegation point. 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 as DNS: it is the first DNS resource
   record that can only appear only on the upper side of a delegation. Adding
   it will cause interoperabilty interoperability 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 authorative authoritative
   for zones with DS records but will not add the NXT and DS records to
   the authority section.  Same
   goes  The same is true for caching servers, servers; in
   fact, some may even refuse to pass on the DS and NXT records.

2.4 Wire format Format of the DS record

   The DS (type=TDB) record consists of algorithm, contains these fields: key tag tag, algorithm,
   digest type, and SHA-1 the digest of a public key KEY record that is allowed/used
   allowed and/or used to sign the child's delegation. apex KEY RRset. Other keys
   MAY sign the child's apex KEY set. 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  |
      |                SHA-1 digest                                   |
      |                (20 bytes)                                     |
      |                                                               |
      |                                                               |
      |                                                               |

   The key tag is calculated as specified in RFC2535, 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 delegation delegated domain name followed by the whole
   RDATA of the KEY record.

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

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

   The size of the DS RDATA for type 1(SHA-1) 1 (SHA-1) is 24 bytes, regardless
   of key size.

2.4.1 Justifications for fields Fields

   The algorithm and key tag fields are here present to allow resolvers to
   quickly identify the candidate KEY records to examine.  The key tag
   adds some greater assurance than SHA-1 digest on its own.  SHA-1 is a
   strong cryptographic checksum, checksum: it is real hard 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 data 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

   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 packet DNS message overflow. The
   SHA-1 hash is strong enough to uniquely identify the key. This key and is
   similar to the PGP key footprint. The digest type field is there present
   for possible future expansion.

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

2.5 Presentation format Format of the DS record Record

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

2.6 Transition issues Issues for installed base Installed Base

   No backwards compatibility with RFC2535 compliant resolver is provided.

   RFC2535-compliant resolvers will assume that all DS secured DS-secured
   delegations are locally secure. This is a bad thing, bad, but the DNSEXT
   working group Working
   Group has determined that rather than having to have to deal dealing with both RFC2535 secured zone
   RFC2535-secured zones and DS secured zone, DS-secured zones, a rapid adaption 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 RFC2535 and RFC1035

   This section documents how a resolver determines the type of
   RFC1035 delegation (in parent) has:

   RFC1035           NS

   RFC2535 adds the following two cases:

   Secure RFC2535:   NS + NXT + SIG(NXT)
                     NXT bit map contains: NS SIG NXT
   Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
                     NXT bit map contains: NS SIG KEY NXT
                     KEY must be null-key. a NULL key.

   DS has the following two states:

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

   It is hard difficult for a resolver to determine if a delegation is Secure secure
   RFC 2535 or Insecure unsecure DS. This can could be overcome by adding a flag to
   the NXT bit
   map map, but only upgraded resolvers will would understand this flag.
   flag, anyway. Having both parent and child signatures on the keyset may 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 outlaw Sig@Child prohibiting RFC
   2535-style signatures at child zone apexes and force forcing rapid
   deployment of DS enabled DS-enabled servers and resolvers.

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

3 Resolver Example

   To create a chain of trust trust, a resolver goes from trusted KEY to DS to

   Assume the key for domain "example." is trusted.  Zone "example."
   contains at least the following records:
   example.    SOA     <soa stuff>
   example.    NS   ns.example.
   example.          KEY     <stuff>
   example.          NXT      NS SOA KEY SIG NXT
   example.    SIG(SOA)
   example.    SIG(NS)
   example.    SIG(NXT)
   example.    SIG(KEY)
   secure.example.   NS      ns1.secure.example.
   secure.example.   DS      tag=10243 alg=3 digest_type=1 <foofoo>
   secure.example.   NXT     NS SIG NXT DS unsecure.example.
   secure.example.   SIG(NXT)
   secure.example.   SIG(DS)
   unsecure.example  NS      ns1.unsecure.example.
   unsecure.example. NXT     NS SIG NXT .example.
   unsecure.example. SIG(NXT)

   In zone "secure.example." following records exist:
   secure.example. SOA      <soa stuff>
   secure.example. NS       ns1.secure.example.
   secure.example. KEY      <tag=12345 alg=3>
   secure.example. SIG(KEY) <key-tag=12345 alg=3>
   secure.example. SIG(SOA) <key-tag=12345 alg=3>
   secure.example. SIG(NS)  <key-tag=12345 alg=5>

   In this example the trusted private key for "example." signs the DS record
   for "secure.example.", making that a trusted record. secure delegation. The DS record
   states what which key is expected to sign the KEY RRset at
   "secure.example.".  Here "secure.example." signs its KEY set RRset with
   the KEY identified in the DS set, RRset, thus the KEY set RRset is validated
   and trusted.

   This example has only one DS record for the child, but parents MUST
   allow multiple DS records to facilitate key rollover.  It is strongly
   recommended that the DS set RRset be kept small, 2 small: two or 3 three DS records
   SHOULD be sufficient in all cases.


   The resolver determines the security status of "unsecure.example." by
   examining the parent zone's NXT record for this name.  The absence of
   the DS bit indicates an unsecure delegation.

3.1 Resolver cost estimates Cost Estimates for DS records Records

   From a RFC2535 resolver point of view view, for each delegation followed
   to chase down an answer answer, one KEY record RRset has to be verified.
   Additional RRsets might also need to be verified and possibly
   some other records based on policy, for example local
   policy (e.g., the contents of the NS set. RRset). Once the resolver gets
   to the appropriate delegation delegation, validating the answer may might require
   verifying one or more signatures.  A simple A record lookup requires
   at least N delegations to be verified and 1 one RRset. For a DS enabled resolver DS-enabled
   resolver, the cost is 2N+1.  For an MX record the cost record, where the target of
   the MX record is in the same zone as the MX record record, the costs are N+2
   and 2N+2. 2N+2, for RFC 2535 and DS, respectively. In the case of
   negative negatives
   answer the same ratios hold true.


   The resolver may require an extra query to get the DS record and this
   may add to the overall cost of the query, but this is never worse
   than chasing down NULL KEY records from the parent in RFC2535 DNSSEC.

   DS adds processing overhead on resolvers, resolvers and increases the size of
   delegation answers answers, but much less than SIG@Parent. storing signatures in the
   parent zone.

4 - Security Considerations:

   This document proposes a change to the validation chain of KEY
   records in DNS. DNSSEC. The change in is not believed to reduce security in
   the overall system, in system. In RFC2535 DNSSEC DNSSEC, the child must zone has to
   communicate keys to its parent and prudent parents will require some
   authentication on with that
   handshake. transaction. The modified protocol will
   require the same authentication authentication, but allows the child to exert more
   local control over its own KEY set. RRset.

   There is a remote possibility that an attacker can could generate an a valid
   KEY that matches all the DS fields and thus starting to forge data from the
   child. This possibility is considered impractical impractical, as on average more
   than 2^80 keys must would have to be generated before one is found that will match. a match would be

   The DS record is represents a change to the DNSSEC protocol and there is some
   an installed base of implementations, as well as text books textbooks on how to
   set up
   secured secure delegations. Implementations that do not understand the
   DS record will not be able to follow the KEY to DS to KEY chain and
   will consider all zone zones secured that way insecure. as unsecure.

5 - IANA Considerations:

   IANA needs to allocate an RR type code for DS from the standard RR
   type space.

   IANA needs to open a new registry for the DS type for Digest
   algorithms, digest
   algorithms. Defined types are, are: 0 is Reserved, 1 is SHA-1. Adding new
   reservations requires IETF standards action.

4 Acknowledgments

   Number of people have over

   Over the last few years contributed a number of people have contributed ideas
   that are captured in this document. The core idea of using one key to only
   sign key set, only the KEY RRset comes from discussions with Bill Manning and
   Perry Metzger on how to put in a single root key in all resolvers.
   Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott
   Rosen, Edward Lewis, Dan Massey, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan
   Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard
   Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve
   Bellovin, Rob Austein, Derek Atkins, Roy Arends, Harald Alvestrand,
   and others have provided useful comments.


[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
           Specification'', STD 13, RFC 1035, November 1987.

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

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

[RFC3008]  B. Wellington, ``Domain Name System Security (DNSSEC) Signing
           Authority'', RFC 3008, November 2000.

[RFC3090]  E. Lewis `` DNS Security Extension Clarification on Zone
           Status'', RFC 3090, March 2001.

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

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

Author Address

      Olafur Gudmundsson
      3826 Legation Street, NW
      Washington, DC,  20015

Appendix A: Changes from Prior versions

Changes from version 05
   Major wording changes for clarity contributed by Matt Larson.
   Added explicit rule that query for type DS MUST be answered from the
   upper side of delegation.

Changes from version 04
   Reworded document to obsolete RFC2535 chain of trust, no backwards
   compatibility.  Require DS and NXT records in referrals in authority
   section.  Removed the NODS bit.
   Added the requirement for OK bit and Message size.
   Rewrote Abstract to better express what is in the document.
   Removed size field from examples and simplified them.

Changes from version 03
   Added strict rules on what KEY records can be pointed to by DS.

Changes from version 02
   Added text outlawing DS at non delegations.
   Added table showing the contents of DS, SIG@child, and RFC1034
   Added the NODS type/bit definition to distinguish insecure DS
   delegation from secure SIG@child one.
   Added the requirement that NXT be returned with referral answers.
   Minor text edits.

Changes from version 01
   Deleted KEY size field as it did not contribute anything but
   Number of wordsmith changes to make document more readable.
   The word CAN was used when SHOULD was intended.
   Deleted section 2.4 "Justifications for compact format" moved
   relevant text to section 2.2.
   Reverse alphabetized the acknowledgments section.
   Reorganized sections 1 and 2 for readability.

Changes from version 00
   Changed name from DK to DS based on working group comments.
   Dropped verbose format based on WG comments.
   Added text about TTL issue/problem in caching servers.
   Added text about islands of security and clarified the cost impact.
   Major editing of arguments and some reordering of text for clarity.
   Added section on transition issues.

Full Copyright Statement

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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an