DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-05.txt><draft-ietf-dnsext-delegation-signer-06.txt> 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Comments should be sent to the authors or the DNSEXT WG mailing list firstname.lastname@example.org This draft expires on July 5,September 1, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All rights reserved. Abstract The Delegation Signer Resource Recorddelegation signer (DS) resource record is inserted at a zone cut point(i.e., a delegation point) to indicate thathat the delegated zone is digitally signed and that the delegationdelegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is ana modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use thethis resource record as an explicit statement about the delegation, rather than relying on inference. 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 recordRRset in a zone anywhere other than at the apex indicates that this name isa delegation andzone cut or delegation. The RDATA of the NS record listsRRset specifies the authorativeauthoritative servers for the realdelegated or "child" zone. Based on actual measurementsmeasurements, 10-30% of all delegations inon the Internet have differing NS setsRRsets at parent and child. There are a number of reasons for this, including a lack of communication between parent and child and bogus name-serversname servers being listed to meet registrar requirements. DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child mustzone needs to have its KEY setRRset signed by theits parent to create a verifiable chain of KEYs. There has been some debate on where the signed KEY setRRset should reside, whether at the child[RFC2535]child [RFC2535] or at the parent. If the KEY setRRset resides at the child, maintaining the signed KEY setRRset in the child,child requires frequent two waytwo-way communication is neededbetween the two parties. First the child needs to transmittransmits the key setKEY RRset to the parent and then the parent sends the signed set or signaturessignature(s) to the child. Storing the KEY RRset at the parent simplifies the communication. DNSSEC[RFC2535]DNSSEC [RFC2535] requires that the parent store a NULL key setKEY record for an unsecure children, this is intendedchild zone to be a signalindicate that the child is unsecure. A NULL Key RRsetKEY record is a waste as a wholewaste: an entire signed RRset is used to effectivelycommunicate effectively one bit of information,information--that the child is unsecure. Chasing down NULL key recordsKEY RRsets complicates the resolution process in many cases ascases, because servers for both parent and child need to be queried for the KEY setRRset if the child server does not return a KEY set.it. Storing the KEY recordRRset 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 KEYkey model is that the KEY record iscan be used to store DNS zone keys andpublic keys for other protocols.protocols in addition to DNSSEC keys. There are number of potential problems with thisthis, including: 1. The KEY setRRset can become quite large if many applications/protocolsapplications 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 setThe KEY RRset may require frequent updates. 3. ProbabilityThe probability of compromised/lost keys increases and triggerscompromised or lost keys, which trigger emergency key rollover procedures.procedures, increases. 4. ParentThe parent may refuse sign key setsKEY RRsets with NON DNSnon-DNSSEC zone keys. 5. ParentThe parent may not meet the child's expectations in turnaround time infor resigning the key set.KEY RRset. Given these and other reasonsreasons, 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 keysonly DNSSEC keys and create a new record type for all non DNSnon-DNSSEC keys. ThirdA third possible solution is to banprohibit the storage of non DNS relatednon-DNSSEC keys at the zone apex. There are other possible solutionssolutions, but they are outside the scope of this document. 1.2 -Reserved wordsWords 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 modelModel This document presents a replacement offor the DNSSEC KEY record chain of trust[RFC2535],trust [RFC2535] that uses a new RR that resides only resideat the parent. This record will identifyidentifies the key(s) that the child uses to self signself-sign its own KEY set.RRset. The chain of trust is now established by verifying the parent KEY set,RRset, the DS setRRset from the parent and the KEY setRRset at the child. This is cryptographically equivalent to justusing 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. ParentThe parent is ignorant of all other keys in the child's apex KEY RRset, furthermoreRRset. Furthermore, the child maintains full control over the apex KEY setRRset and its content. ChildThe child can maintain any policies overregarding its DNS and otherKEY 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 keyskeys, the parent does not need to be aware of it asit: the child can use one key to onlysign only its apex KEY setRRset and other keys to sign the other record setsRRsets in the zone. This model fits well with a slow roll outrollout of DNSSEC and the islands of security model. In the islands of security modelthis model, someone thatwho trusts "good.example." can preconfigure a key from "good.example." as a trusted keyskey, and from then on trusts any data that issigned 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 thelarge delegation zones reduced, as only signed keying records for secure delegations are needed, unlikeis 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 delegationsa zone's KEY setRRset requires two signature verification operations instead of the one inrequired by RFC 2535. There is no impact on the number of signatures verified for other RR sets.types of RRsets. 2.2 Protocol changeChange All DNS servers and resolvers that support DS MUST support the OK bit [RFC3225] and supporta 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 setsRRsets in the authority section in this order: 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 RRRRsets or their signatures do not fit insidein the DNS messagemessage, the TC bit mustMUST be set. Additional section processing is not changed. If aA DS RR set accompanies theRRset accompanying an NS RR set, this statesRRset indicates that the child zone is secured.secure. If an NS RR setRRset exists without a DS RR set the intent is to state thatRRset, the child zone is unsecure. DS setsRRsets MUST NOT appear at non delegationsnon-delegation points or at zone APEX. Followinga 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 considerationsConsiderations at delegation pointsDelegation Points DNS security would like to viewviews 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, whichzone that are also the apex nodes of a subzonechild zone (i.e., delegation points),points) as "really" belonging to the subzone. These nodes occurchild zone. The corresponding domain names appear in two master files and might have RRsRRsets signed by both the upperparent and lower zone'schild zones' keys. A retrieval could get a mixture of these RRsRRsets and SIGs, especially since one server could be serving both the zone above and below a delegation point[RFCpoint [RFC 2181]. For every secure delegation there MUST be a DS recordRRset stored in the parent zone signed by the parent zonezone's private key. ParentThe parent zone MUST NOT contain a KEY recordRRset at any delegation points. Delegations in the parent MAY onlycontain only the following RR typestypes: NS, DS, NXT and SIG. The NS RR setRRset MUST NOT be signed. The NXT RR typeRRset is the exceptional case thatcase: it will always appear differently and authoritatively in both the super-zoneparent and subzone,child zones if both are secure. AllA secure zones MUST contain a self signedself-signed KEY RR setRRset at its apex. Upon verifying the DS setRRset from the parent, thea resolver MAY trust any KEY identified in the DS setRRset as a valid signer of the childschild's apex KEY set.RRset. Resolvers configured to trust one of the KEY'skeys signing the KEY setRRset MAY now treat any data signed by the zone keys in the KEY setRRset as secure. In all other cases resolvers MUST considerconsider 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 RRparent. 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 nameSigner'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 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.4 changesChanges to RFC3090 NumberA number of sections of RFC3090 need to be updated to reflect the DS record. 220.127.116.11 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, thusabove. Therefore, these paragraphs are now obsolete. 18.104.22.168 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 setMUST be self signedself-signed by a private key in the KEY RR set. The private key'swhose public companioncounterpart MUST beappear in a zone signing KEY RR (2.a) of a mandatory to implement algorithm andowned by the parent's apex.zone's apex and specifying a mandatory-to- implement algorithm. This KEY mustRR MUST be identified by a signedDS RR in a signed DS RRset in the parent zone. If a zone cannot get aits 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 zonezone. 22.214.171.124 RFC3090 section 3: Experimental Status. The only difference between Experimentalexperimental status and globally secured is the missing DS RRset in the parent.parent zone. All Locally Securedlocally secured zones are Experimental.experimental. 2.3 -Comments on protocol changesProtocol Changes Over the years there hashave been various discussions on thatsurrounding the delegation model inDNS isdelegation model, declaring it to be broken asbecause there is no realgood way to assert if a delegation exists. In the RFC2535 version of DNSSECDNSSEC, the authenticationpresence of a delegation isthe NS bit in the NXT bitmap at thebit 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 asDNS: it is the first DNSresource record that can onlyappear only on the upper side of a delegation. Adding it will cause interoperabiltyinteroperability 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 authorativeauthoritative for zones with DS records but will not add the NXT and DS records to the authority section. Same goesThe same is true for caching servers,servers; in fact, some may even refuse to pass on the DS and NXT records. 2.4 Wire formatFormat of the DS record The DS (type=TDB) record consists of algorithm,contains these fields: key tagtag, algorithm, digest type, and SHA-1the digest of a public key KEY record that is allowed/usedallowed 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 delegationdelegated 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 reasonsinteroperability reasons, as few digest typealgorithms as possible should be reserved, thereserved. The only reason to reserve anotheradditional digest typetypes is to increase security. DS records MUST point to zone KEY records that are allowed to authenticate DNS data. ProtocolThe indicated KEY record's protocol field MUST be set to 3. Flag3; flag field bits 0 and 6 MUST be set to 0,0; bit 7 MUST be set to 1. ValueThe 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 fieldsFields The algorithm and key tag fields are herepresent 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 hardcomputationally 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 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 packetDNS message overflow. The SHA-1 hash is strong enough to uniquely identify the key. Thiskey and is similar to the PGP key footprint. The digest type field is therepresent for possible future expansion. The DS record is well suited to listslisting trusted keys for islands of security in configuration files. 2.5 Presentation formatFormat of the DS recordRecord The presentation format of the DS record consists of 2three numbers (key tag, algorithm and digest type) followed by the digest itself presented in hex. foo.examplehex: foo.example. DS 12345 3 1 123456789abcdef67890 2.6 Transition issuesIssues for installed baseInstalled Base No backwards compatibility with RFC2535 compliant resolveris provided. RFC2535-compliant resolvers will assume that all DS securedDS-secured delegations are locally secure. This is a bad thing,bad, but the DNSEXT working groupWorking Group has determined that rather than having to have to dealdealing with both RFC2535 secured zoneRFC2535-secured zones and DS secured zone,DS-secured zones, a rapid adaptionadoption 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 delegation. 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 InsecureUnsecure 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 InsecureUnsecure DS: NS + NXT + SIG(NXT) NXT bit map contains: NS SIG KEYNXT It is harddifficult for a resolver to determine if a delegation is Securesecure RFC 2535 or Insecureunsecure DS. This cancould be overcome by adding a flag to the NXT bit mapmap, but only upgraded resolvers willwould understand this flag.flag, anyway. Having both parent and child signatures on the keyset mayfor 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@Childprohibiting RFC 2535-style signatures at child zone apexes and forceforcing rapid deployment of DS enabledDS-enabled servers and resolvers. RFC 2535 and DS can in theory be deployed in parallel, but this willwould require resolvers to deal with RFC 2535 configurations forever. This document obsoletes the NULL KEY in parent zones, thatwhich is a difficult enough change that a flag day is required. 3 Resolver Example To create a chain of trusttrust, a resolver goes from trusted KEY to DS to KEY. 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 trustedprivate key for "example." signs the DS record for "secure.example.", making that a trusted record.secure delegation. The DS record states whatwhich key is expected to sign the KEY RRset at "secure.example"."secure.example.". Here "secure.example." signs its KEY setRRset with the KEY identified in the DS set,RRset, thus the KEY setRRset 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 setRRset be kept small, 2small: two or 3three DS records SHOULD be sufficient in all cases. ResolverThe 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 estimatesCost Estimates for DS recordsRecords From a RFC2535 resolver point of viewview, for each delegation followed to chase down an answeranswer, one KEY recordRRset has to be verified. Additional RRsets might also need to be verified and possibly some other recordsbased on policy, for examplelocal policy (e.g., the contents of the NS set.RRset). Once the resolver gets to the appropriate delegationdelegation, validating the answer maymight require verifying one or more signatures. A simple A record lookup requires at least N delegations to be verified and 1one RRset. For a DS enabled resolverDS-enabled resolver, the cost is 2N+1. For an MX record the costrecord, where the target of the MX record is in the same zone as the MX recordrecord, the costs are N+2 and 2N+2.2N+2, for RFC 2535 and DS, respectively. In the case of negativenegatives answer the same ratios hold true. ResolverThe 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 answersanswers, 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 inis not believed to reduce security in the overall system, insystem. In RFC2535 DNSSECDNSSEC, the child mustzone has to communicate keys to its parent and prudent parents will require some authentication onwith that handshake.transaction. The modified protocol will require the same authenticationauthentication, but allows the child to exert more local control over its own KEY set.RRset. There is a remote possibility that an attacker cancould generate ana valid KEY that matches all the DS fields and thus starting toforge data from the child. This possibility is considered impracticalimpractical, as on average more than 2^80 keys mustwould have to be generated before one is found that will match.a match would be found. The DS record isrepresents a change to the DNSSEC protocol and there is somean installed base of implementations, as well as text bookstextbooks on how to set up securedsecure 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 zonezones 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 overOver the last few years contributeda number of people have contributed ideas that are captured in this document. The core idea of using one key to onlysign 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. References: [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 USA <email@example.com> 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 delegations. 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 complexity. 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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."