[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 4033

Network Working Group                                          R. Arends
Internet-Draft                                                   Nominum
Expires: August 30, 2002                                       M. Larson
                                                                VeriSign
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                           March 1, 2002


               DNS Security Introduction and Requirements
                   draft-ietf-dnsext-dnssec-intro-01

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.

   This Internet-Draft will expire on August 30, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The Domain Name System Security Extensions (DNSSEC) provide data
   origin authentication and data integrity.  This document introduces
   these extensions and describes their capabilities and limitations.
   The services that the security extensions provide and do not provide
   are discussed.  Lastly, the group of documents that describe the DNS
   security extensions and their interrelationships is discussed.



Arends, et al.           Expires August 30, 2002                [Page 1]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Threat Model . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1   Packet Interception and/or Modification  . . . . . . . . . .  4
   2.2   Name Based Attacks (a.k.a. Cache Poisoning)  . . . . . . . .  4
   2.3   Attacks Not Covered by DNSSEC  . . . . . . . . . . . . . . .  5
   3.    Services Provided by DNS Security  . . . . . . . . . . . . .  6
   3.1   Data Origin Authentication and Data Integrity  . . . . . . .  6
   3.1.1 Authenticating Name and Type Non-Existence . . . . . . . . .  7
   3.2   Key Distribution . . . . . . . . . . . . . . . . . . . . . .  7
   3.3   Transaction Security . . . . . . . . . . . . . . . . . . . .  7
   4.    Services Not Provided by DNS Security  . . . . . . . . . . .  9
   5.    Resolver Considerations  . . . . . . . . . . . . . . . . . . 10
   6.    Zone Considerations  . . . . . . . . . . . . . . . . . . . . 11
   7.    Server Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.    DNS Security Document Family . . . . . . . . . . . . . . . . 13
   8.1   DNS Security Document Roadmap  . . . . . . . . . . . . . . . 13
   8.2   Categories of DNS Security Documents . . . . . . . . . . . . 13
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 16
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
         References . . . . . . . . . . . . . . . . . . . . . . . . . 18
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
   A.    Definitions of Important DNSSEC Terms  . . . . . . . . . . . 20
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 21





















Arends, et al.           Expires August 30, 2002                [Page 2]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


1. Introduction

   This document introduces the Domain Name System Security Extensions
   (DNSSEC).  This document and a collection of related documents update
   RFC 2535 [2] and its related documents to further clarify and refine
   the security extensions defined in RFC 2535.  These security
   extensions consist of a set of new resource record types and
   modifications to the existing DNS protocol [3].  The new records and
   protocol modifications are not fully described in this document, but
   in a family of documents outlined in Section 8.  The threat model
   that the security extensions are designed to protect against is
   described in Section 2.  The capabilities and limitations of the
   security extensions are described in greater detail in Section 3 and
   Section 4, respectively.  Lastly, the effect that these security
   extensions will have on resolvers, zones and servers is discussed in
   Section 5, Section 6 and Section 7, respectively.

   Appendix A provides definitions for important DNSSEC terms.  A term
   that appears in Appendix A is followed by an asterisk (*) upon first
   use in the body of the document.

   The DNS security extensions provide data origin authentication and
   data integrity protection as well as a means of public key
   distribution.  The security extensions do not provide protection
   against other types of attack, nor do they provide confidentiality.


























Arends, et al.           Expires August 30, 2002                [Page 3]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


2. Threat Model

   The Domain Name System (DNS) protocol has been the target of several
   well-publicized attacks since its creation.  A more detailed threat
   model for DNS is the subject of [4].  A brief description of the
   major attacks that the DNS security extensions were designed to
   protect against is given below.

2.1 Packet Interception and/or Modification

   The attacker has access to the network and observes (and possibly
   modifies) DNS message data.  This is a form of the "man in the
   middle" attack and can be either passive (observation only) or active
   (interception and modification).  It is also possible that the
   attacker responds to a resolver's query with bogus information before
   the queried name server's reply reaches the resolver.  Message
   modification could lead to incorrect information being returned to a
   resolver, or a different query being sent to a name server.

   DNSSEC uses a digital signature scheme for DNS RRsets (defined in
   [5]) or entire DNS messages to provide integrity checks and source
   authentication.  Any modifications made by an attacker would result
   in a signature verification error at the resolver.  DNSSEC also
   provices a means for authenticating the non-existence of DNS data.

   A conscious DNSSEC design decision was keeping DNS information in
   plaintext.  DNSSEC does use any cryptographic techniques to provide
   confidentiality for any DNS information.

2.2 Name Based Attacks (a.k.a. Cache Poisoning)

   This type of attack allows the attacker to hijack a DNS zone by
   injecting false data into a response in the form of resource records
   (RRs) in the authority and additional sections, usually pointing to a
   false authoritative server.  This attack depends on the targeted
   resolver caching these records and using them to answer future
   queries from other resolvers.  This attack allows the attacker to
   subvert a single recursive server and redirect all queries for the
   targeted domain name to the attacker's name server, essentially
   hijacking the DNS zone from its legitimate servers.

   Since this attack modifies the contents of DNS messages, the
   signature scheme in DNSSEC protects against it.  The keys that
   resolvers use to verify DNS data must either be configured as a
   trusted key*, or be part of a chain of trust* back to a trusted key.
   The DNSSEC trust model ensures that as long as zone administrators
   follow reasonable key-signing policies, the key used by an attacker
   to sign malicious DNS data would not be trusted.



Arends, et al.           Expires August 30, 2002                [Page 4]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


   Note, however, that referrals are not signed in DNSSEC.  It is
   expected that the a zone's authoritative servers will provide digital
   signatures for RRsets in the answer, authority and additional
   sections, as necessary.

2.3 Attacks Not Covered by DNSSEC

   Denial of Service (DoS) attacks are not addressed by DNSSEC.  DoS
   attacks are easy to detect, but difficult to protect against, in a
   protocol like DNS.  Name server and resolver implementations can
   protect against some DoS attacks (by providing system security), but
   there are no protocol features in DNSSEC to defend against DoS
   attacks.






































Arends, et al.           Expires August 30, 2002                [Page 5]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


3. Services Provided by DNS Security

   The Domain Name System (DNS) protocol security extensions provide
   three distinct services: Data origin authentication and data
   integrity, key distribution, and transaction security, as described
   below.

3.1 Data Origin Authentication and Data Integrity

   Authentication is provided by cryptographically generated digital
   signatures associated with DNS RRsets.  These digital signatures are
   stored in a new resource record, the SIG record.  Typically, there
   will be a single private key that signs a zone's data, but multiple
   keys are possible; e.g., for different digital signature algorithms.
   If a security-aware resolver* reliably learns a zone's public key, it
   can authenticate that zone's signed data.  An important DNSSEC
   concept is that the key pair(s) that sign a zone's data are
   associated with the zone itself and not with the zone's authoritative
   servers (although hosts can also have key pairs in DNSSEC; see the
   reference to SIG(0) in Section 3.3 below).  Security-aware servers*
   attempt to send the signature(s) needed to authenticate an RRset in
   the DNS reply message along with the RRset itself, provided there is
   space available in the message.

   A resolver could learn a zone's public key by having the key
   statically configured or by normal DNS resolution.  To allow the
   latter, public keys are stored in a new resource record, the KEY
   record (see Section 3.2 below).  (Note that the private keys used to
   sign zone data must be kept secure and best practices call for them
   to be stored offline.) To reliably discover a public key by DNS
   resolution, the key itself needs to be signed by another key that the
   resolver trusts.  Zone information is authenticated by forming a
   chain of trust from a newly learned public key back to a trusted
   public key (which is either statically configured or previously
   learned and verified).  Therefore, the resolver must be configured
   with at least one public key that authenticates one zone as a
   starting point.  To establish this chain of trust, security-aware
   servers attempt to send the signature(s) needed to authenticate a
   zone's public key in the DNS reply message along with the public key
   itself, provided there is space available in the message.

   The chain of trust specified in the original DNS security extentions
   proceeded from signed KEY record to signed KEY record, as necessary,
   and finally to the queried RRset.  A new record, the delegation
   signer (DS), has been added for additional flexibility.  The DS
   record is stored at a delegation point in a parent zone and specifies
   the keys used by the child zone to self-sign its KEY records.  The
   child, in turn, uses one of these keys to sign its zone data.  The



Arends, et al.           Expires August 30, 2002                [Page 6]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


   chain of trust is therefore DS->KEY->[DS->KEY->...]->RRset.

   Adding data origin authentication and data integrity requires minor
   changes to the on-the-wire DNS protocol.  Several new resource record
   types are required, including the aforementioned SIG, KEY and DS.
   EDNS0 support [6] for larger message sizes [7] is required, as is
   support for the OK bit [8].

3.1.1 Authenticating Name and Type Non-Existence

   The above security mechanism only provides a way to sign existing
   RRsets in a zone.  The problem of providing negative responses with
   the same level of authentication and integrity requires the use of
   another new resource record, the non-existence (NXT) record.  The NXT
   record allows a negative reply (either for name or type non-
   existence) to be authenticated the same way as other DNS replies.
   NXT records require a canonical representation and order for domain
   names in zones.  NXT records exist to cover the gaps, or "empty
   space", between domain names in a zone, as well as non-existent
   record types for existing names.  Each NXT record is signed and
   authenticated in the same way as any other RRset.

3.2 Key Distribution

   The KEY resource record is defined to associate public keys with DNS
   names.  This record permits the DNS to be used as a public key
   distribution mechanism in support of DNSSEC.  Security-aware
   resolvers can query for a zone's (or another entity's) public key
   when establishing a chain of trust.

   The syntax of a KEY resource record (and the other additional
   resource records required for DNSSEC) is described in [9].  It
   includes identifiers for the algorithm the key is used for and
   information on the entity the key is associated with.

   The original DNSSEC specification allowed other protocols and
   applications to use the KEY record as a general-purpose mechanism to
   store public keys.  For reasons documented in [10], the KEY record is
   now restricted for use with DNSSEC only.  Work is in progress on
   storing public keys [11] and certificates [12] used by other
   protocols and applications in the DNS.  A secure DNS tree could then
   be used as a lightweight trust mechanism.  Some administrators and
   users may consider a validated DNSSEC signature to be sufficient to
   trust a public key stored in the DNS.

3.3 Transaction Security

   The data origin authentication and data integrity service described



Arends, et al.           Expires August 30, 2002                [Page 7]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


   above authenticates retrieved RRsets and the non-existence of RRsets,
   but provides no protection for complete DNS messages, e.g., when they
   occur in zone transfers and dynamic updates.

   A DNS message can be authenticated by including a special signature
   RR at the end of the message, either a transaction signature (TSIG)
   [13] or SIG record with a type covered field of zero (a "SIG(0)", see
   [14]).  Such a signature can be used to verify the integrity of the
   DNS message.  (The signature record in the additional section of a
   query may produce an error or simply be ignored by older name servers
   that don't support transaction security.)  Unlike the mechanism
   described in Section 3.1, transaction security is specific to the
   individual hosts exchanging DNS messages.  The cryptographic keys
   used with transaction security are associated with individual hosts
   and not DNS zones.

   In addition to transaction signatures, there is also support for key
   agreement protocols to support transaction security using symmetric
   encryption keys.  This service uses the transaction key (TKEY) [15]
   resource record.  The use of the TKEY record in a key agreement
   transaction depends on the algorithm used, and each key agreement
   protocol is described in a separate document specific to each
   algorithm.




























Arends, et al.           Expires August 30, 2002                [Page 8]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


4. Services Not Provided by DNS Security

   The DNS design philosophy calls for all DNS data to be public and
   uniform answers to all inquirers.  Accordingly, confidentiality for
   queries or responses is not provided, nor are any sort of access
   control lists or other means to differentiate inquirers.

   Denial of service is not protected against.

   Signed zone data and/or the use of transaction signatures will not
   protect against errors in DNS zone information or servers incorrectly
   interpreting and/or setting DNS message headers.







































Arends, et al.           Expires August 30, 2002                [Page 9]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


5. Resolver Considerations

   A security-aware resolver needs to be able to perform necessary
   cryptographic functions to verify digital signatures using at least
   the mandatory-to-implement algorithms.  Also, security-aware
   resolvers must be capable of forming a chain of trust from a newly
   learned zone back to a trusted key.  This might require additional
   queries to intermediate DNS zones for necessary KEY, DS and SIG
   records.  It is assumed that a security-aware resolver will be
   configured with at least one trusted key to aid this process.

   The stub resolver found in many hosts may be augmented to provide a
   different set of security features instead of the full security
   awareness found in a complete resolver.  The use of transaction
   security could help secure the final message passing between a
   recursive DNS server and a stub resolver.  This a matter of local
   security policy.

   A security-aware resolver needs to communicate with only security-
   aware servers.  If an unsecure server* or an unsigned zone* is part
   of the DNS resolution path, the resolver cannot ensure security.  If
   a security-aware resolver must rely on an unsecure server (or
   unsigned zone), the resolver cannot verify DNS responses and should
   rely on local policy when trusting responses.



























Arends, et al.           Expires August 30, 2002               [Page 10]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


6. Zone Considerations

   A secure zone* will have several differences from an unsigned zone.
   A secure zone will contain additional security-related records (SIG,
   KEY, DS and NXT records).  SIG and NXT records may be generated by a
   signing process prior to serving the zone.  If SIG and NXT records
   are not present in the zone, an authoritative server needs to
   generate them before serving the zone.  Zone data is only valid and
   considered secure for a definable time period.  The SIG records that
   accompany zone data have defined inception and expiration times.
   These times establish a validity period for the signatures and the
   zone data the signatures cover.







































Arends, et al.           Expires August 30, 2002               [Page 11]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


7. Server Considerations

   A security-aware server must be capable of performing the following
   operations in addition to the normal operations of a DNS zone server
   described in [3]:

      A security-aware server should make all attempts to include
      necessary security related records (SIG, KEY, DS and NXT) in
      responses as DNS message space permits.

      A caching security-aware server must also take a signature's
      validation period into consideration when determining the time to
      live (TTL) of cached data: signed data should not be cached beyond
      the signature validity period.

      A security-aware server should have a means of employing
      transaction security, such as transaction signatures (TSIG) or
      SIG(0).  Transaction security is primarily used when performing
      other DNS operations such as zone transfers and dynamic updates
      (if they are permitted using the server's local policy).

      All other means of restricting query, zone transfer, dynamic
      update and administrative access to a security-aware server fall
      under the category of operational security and are not addressed
      by the DNS security extensions.


























Arends, et al.           Expires August 30, 2002               [Page 12]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


8. DNS Security Document Family

   The DNSSEC set of documents can be partitioned into five main groups
   as depicted in Figure 1.  All these documents are in turn under the
   larger umbrella of the DNS base protocol documents described in [16].

8.1 DNS Security Document Roadmap

   ---------------------------------------------------------------------


                    +--------------------------------+
                    |                                |
                    |    Base DNS Protocol Docs      |
                    |   [RFC1035, RFC2181, etc.]     |
                    |                                |
                    +--------------------------------+
                                    |
                                    |
                              +-----------+          +-------------+
                              |  DNSSEC   |          |  New        |
                              | Protocol  |<-------->|  Security   |
                              | Documents |          |  Uses       |
                              +-----------+          +-------------+
                                    |
                                    |
                     +------------------------------+
                     |                              |
                     |                              |
               +------------+               +---------------+
               |  Dig. Sig. |               |               |
               |  Algorithm |               |  Transaction  |
               |  Impl.     |               |  Impl.        |
               |            |               |               |
               +------------+               +---------------+

                   Figure 1: DNSSEC Document Roadmap

   ---------------------------------------------------------------------


8.2 Categories of DNS Security Documents

   The "DNSSEC protocol" document set refers to the three documents that
   form the core of the DNS security extensions:

   1.  DNS Security Introduction and Requirements (this document)




Arends, et al.           Expires August 30, 2002               [Page 13]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


   2.  Resource Records for DNS Security Extensions [9]

   3.  Protocol Modifications for the DNS Security Extensions (not yet
       published) [14]

   The "Dig.  Sig.  Algorithm Impl." document set refers to the group of
   documents that describe how a specific digital signature algorithm is
   implemented to fit the DNSSEC resource record format.  Each of these
   documents deals with a specific digital signature algorithm.

   The "Transaction Impl." document set refers to the group of documents
   that deal with DNS message transaction security, including secret key
   establishment and verification.

   The final document set, "New Security Uses", refers to documents that
   seek to use proposed DNS Security extensions for other security
   related purposes.  Documents that fall in this category include the
   use of DNS in the storage and distribution of certificates [12] and
   individual user public keys (PGP, e-mail, etc.) [11].
































Arends, et al.           Expires August 30, 2002               [Page 14]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


9. IANA Considerations

   This document introduces no new IANA considerations.
















































Arends, et al.           Expires August 30, 2002               [Page 15]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


10. Security Considerations

   This document introduces the DNS security extensions and describes
   the document set that contains the new security records and DNS
   protocol modifications.  The capabilities and limitations of these
   extensions are discussed.  The extensions provide data origin
   authentication and data integrity using digital signatures over
   resource records and (optionally) DNS messages.  The DNS security
   extensions can also be used to support key distribution for other
   security protocols.

   In order for a secure resolver to validate a DNS response, all the
   intermediate zones and servers must be capable of DNS security
   processing.  A security-aware resolver cannot verify responses sent
   by an non-security-aware server.

   The DNS security extensions do not protect against denial of service
   (DoS) attacks or provide confidentiality.

































Arends, et al.           Expires August 30, 2002               [Page 16]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


11. Acknowledgements

   This document was created from the input and ideas of several members
   of the DNS Extensions Working Group.  The authors would like to
   acknowledge (in alphabetical order) the following people for their
   contributions and comments on this document:

     Derek Atkins
     Rob Austein
     Donald Eastlake
     Miek Gieben
     Olafur Gudmundsson
     Olaf Kolkman
     Ed Lewis
     Ted Lindgreen
     Bill Manning
     Brian Wellington


































Arends, et al.           Expires August 30, 2002               [Page 17]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [3]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [4]   Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
         System", draft-ietf-dnsext-dns-threats-00 (work in progress),
         November 2001.

   [5]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
         RFC 2181, July 1997.

   [6]   Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
         August 1999.

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

   [8]   Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
         December 2001.

   [9]   Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
         Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-
         records-00 (work in progress), March 2002.

   [10]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
         Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in
         progress), January 2002.

   [11]  Schlyter, J., "Storing application public keys in the DNS",
         draft-schlyter-appkey-02 (work in progress), February 2002.

   [12]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
         Domain Name System (DNS)", RFC 2538, March 1999.

   [13]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
         2845, May 2000.

   [14]  Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
         Modifications for the DNS Security Extensions (Not yet
         published)", draft-ietf-dnsext-dnssec-protocol-00 (work in



Arends, et al.           Expires August 30, 2002               [Page 18]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


         progress), to be published in 2002.

   [15]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
         2930, September 2000.

   [16]  Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext-
         dnssec-roadmap-05 (work in progress), November 2001.

   [17]  Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.


Authors' Addresses

   Roy Arends
   Nominum, Inc.
   2385 Bay Street
   Redwood City, CA  94063
   USA

   EMail: roy.arends@nominum.com


   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: mlarson@verisign.com


   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

   EMail: masseyd@isi.edu


   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-3460
   USA

   EMail: scott.rose@nist.gov



Arends, et al.           Expires August 30, 2002               [Page 19]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


Appendix A. Definitions of Important DNSSEC Terms

   trusted key: A public key, for a zone or a host, that a resolver
      trusts and that can therefore be used to verify data.  A key can
      become trusted in two ways.  First, it can be statically
      configured and declared as trusted in the resolver's
      configuration.  Second, if a new key is referenced by a DS record
      that is signed by an already trusted key, and the signature
      verifies, the new key becomes trusted.

   chain of trust: In DNSSEC, a key signs a DS record, which points to
      another key, which in turn signs another DS record, which points
      to yet another key, etc.  This alternating succession of KEY and
      DS records forms a chain of signed data, with each link in the
      chain vouching for the next.  A resolver starting at a piece of
      data in the chain signed by a trusted key can verify all
      subsequent signatures.  Thus all subsequent data in the chain is
      trusted.

   security-aware resolver: A resolver (defined in section 2.4 of [17])
      that understands the DNS security extensions.  In particular, a
      security-aware resolver uses trusted keys to verify signatures
      over RRsets and (optionally) DNS messages.

   security-aware server: A name server (also defined in section 2.4 of
      [17]) that understands the DNS security extensions.  In
      particular, it supports the KEY, SIG, DS and NXT record types, a
      larger DNS message size via EDNS0, and other protocol changes such
      as support for the OK bit.  Also called a "secure server".

   unsecure server: The proper temr for the opposite of a security-aware
      server.

   unsigned zone: The proper term for the opposite of a secure zone.

   secure zone: A zone whose RRsets are signed and which contains
      properly constructed KEY, SIG, NXT and (optionally) DS records.














Arends, et al.           Expires August 30, 2002               [Page 20]


Internet-Draft       DNSSEC Intro. and Requirements           March 2002


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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Arends, et al.           Expires August 30, 2002               [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/