Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)

DNS Security Working Group                       Donald E. Eastlake, 3rd
INTERNET-DRAFT                                                       DEC                                                 CyberCash
                                                      Charles W. Kaufman
                                                                    Iris
                 Domain Name System Protocol Security Extensions
                 ------ ---- ------ -------- -------- ----------

Status of This Document

   This draft, file name draft-ietf-dnssec-secext-03.txt, draft-ietf-dnssec-secext-04.txt, is intended to
   be become a proposed standard Proposed Standard RFC.  Distribution of this document is
   unlimited. Comments should be sent to the DNS Security Working Group
   mailing list <dns-security@tis.com> or to the authors.

   This document is an Internet-Draft.  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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu,
   munnari.oz.au, or ftp.is.co.za.

Abstract

   The Domain Name System (DNS) has become a critical operational part
   of the Internet infrastructure yet it has no strong security
   mechanisms to assure data integrity or authentication.  Extensions to
   the DNS are described that provide these services to security aware
   resolvers or applications through the use of cryptographic digital
   signatures.  These digital signatures are included in secured zones
   as resource records.  Security can still be provided even through
   non-security aware DNS servers. servers in many cases.

   The extensions also provide for the storage of authenticated public
   keys in the DNS.  This storage of keys can support a general public key
   distribution service as well as DNS security.  The stored keys enable
   security aware resolvers to learn the authenticating key of zones in
   addition to keys for which they are initially configured.  Keys
   associated with DNS names can be retrieved to support other
   protocols.  Provision is made for a variety of key types and
   algorithms.

   In addition, the security extensions provide for the optional
   authentication of DNS protocol transactions.

Acknowledgements

   The significant contributions of the following persons (in alphabetic
   order) to this draft are gratefully acknowledged:

        Madelyn Badger, Matt Crawford, James M. Galvin, Olafur
        Gudmundsson, Sandy Murphy, Masataka Ohta, Michael A. Patton,
        Jeffrey I. Schiller.

Table of Contents

      Status of This Document....................................1

      Abstract...................................................2
      Acknowledgements...........................................2

      Table of Contents..........................................3

      1. Introduction............................................5 Overview of Contents....................................5

      2.  Brief  Overview of the Extensions.......................6 Extensions.............................6
      2.1 Services Not Provided..................................6
      2.2 Key Distribution.......................................6
      2.3 Data Origin Authentication and Integrity...............7
      2.3.2
      2.3.1 The SIG Resource Record..............................7
      2.3.3
      2.3.2 Authenticating Name Non-existence....................8
      2.3.5 and Type Non-existence...........8
      2.3.3 Special Problems Considerations With Time-to-Live...................8 Time-to-Live.............8
      2.3.4 Special Considerations at Delegation Points..........9
      2.3.5 Special Considerations with CNAME RRs................9
      2.3.6 Signers Other Than The Zone..........................9
      2.4 DNS Transaction Authentication.........................9 Authentication........................10

      3. The KEY Resource Record................................10 Record................................11
      3.1 KEY RDATA format......................................10 format......................................11
      3.2 Object Types and Types, DNS Names Names, and Keys...................10 Keys.....................11
      3.3 The KEY RR Flag Octet.................................11 Field.................................12
      3.4 The Protocol Octet....................................14
      3.5 The KEY Algorithm Version Number and the MD5/RSA Algorithm.......12
      3.5 Algorithm....14
      3.6 Interaction of Flags, Algorithm, and Protocol Bytes...15
      3.7 KEY RRs in the Construction of Responses..............13
      3.6 Responses..............16
      3.8 File Representation of KEY RRs........................14 RRs........................16

      4. The SIG Resource Record................................15 Record................................18
      4.1 SIG RDATA Format......................................15 Format......................................18
      4.1.1 Signature Format....................................17 Data......................................20
      4.1.2 SIG RRs Covering Type ANY...........................18 MD5/RSA Algorithm Signature Calculation.............21
      4.1.3 Zone Transfer (AXFR) SIG............................18 SIG............................22
      4.1.4 Transaction SIGs....................................19 SIGs....................................22
      4.2 SIG RRs in the Construction of Responses..............19 Responses..............23
      4.3 Processing Responses with and SIG RRs.....................20 RRs......................23
      4.4 Signature Expiration, TTLs, and Validity..............24
      4.5 File Representation of SIG RRs........................21 RRs........................25

      5. Non-existent Names.....................................22 Names and Types...........................26
      5.1 The NXD NXT Resource Record...............................22 Record...............................26
      5.2 NXD NXT RDATA Format......................................23 Format......................................27
      5.3 Example...............................................23 Example...............................................27
      5.4 Interaction of NXD NXT RRs and Wildcard RRs...............23 RRs...............28
      5.5 Blocking NXD NXT Pseudo-Zone Transfers....................24 Transfers....................28
      5.6 Special Considerations at Delegation Points...........29

      6. The AD and CD Bits and How to Resolve Securely................................25 Securely.........30
      6.1 The AD and CD Header Bits.............................30
      6.2 Boot File Format......................................25
      6.2 Format......................................31
      6.3 Chaining Through Zones................................25
      6.3 Zones................................32
      6.4 Secure Time...........................................27 Time...........................................33

      7. Operational Considerations.............................28 Considerations.............................34
      7.1 Key Size Considerations...............................28 Considerations...............................34
      7.2 Key Storage...........................................28 Storage...........................................35
      7.3 Key Generation........................................29 Generation........................................35
      7.4 Key Lifetimes.........................................29 Lifetimes.........................................35
      7.5 Signature Lifetime....................................30 Lifetime....................................36
      7.6 Root..................................................30 Root..................................................36

      8. Conformance............................................31 Conformance............................................37
      8.1 Server Conformance....................................31 Conformance....................................37
      8.2 Resolver Conformance..................................31 Conformance..................................37

      9. Security Considerations................................32
      References................................................32 Considerations................................38
      References................................................38

      Authors Addresses.........................................33 Addresses.........................................39
      Expiration and File Name..................................33 Name..................................39

      Appendix: Base 64 Encoding................................34 Encoding................................40

1. Introduction Overview of Contents

   This draft describes extensions of the DNS Domain Name System (DNS)
   protocol to support DNS security and public key distribution.

   This draft  It
   assumes that the reader is familiar with the Domain Name System,
   particularly as described in RFCs 1034 and 1035.

2.  Brief Overview

   Section 2 provides an overview of the Extensions

   The DNS protocol extensions provide three distinct services: and the key
   distribution as described in section 2.2 below,
   distribution, data origin
   authentication as described in section 2.3 below, authentication, and transaction
   authentication, described security
   they provide.

   Section 3 discusses the KEY resource record, its structure, use in section 2.4 below.

2.1 Services Not Provided

   It is part of
   DNS responses, and file representation.  These resource records
   represent the design philosophy pubic keys of entities named in the DNS that and are used
   for key distribution.

   Section 4 discusses the data SIG digital signature resource record, its
   structure, use in it is
   public DNS responses, and that file representation.  These
   resource records are used to authenticate other resource records in
   the DNS gives the same answers to all inquirers.

   Following this philosophy, no attempt has been made and optionally to include any
   sort authenticate DNS transactions.

   Section 5 discusses the NXT resource record and its use in DNS
   responses.  The NXT RR permits authenticated denial in the DNS of access control lists the
   existence of a name or other means to differentiate
   inquirers.

   In addition, no effort has been made to provide of a particular type for any an existing name.

   Section 6 discusses how a resolver can be configured with a starting
   key or keys and proceed to securely resolve DNS requests.
   Interactions between resolvers and servers are discussed for all
   combinations of security aware and security non-aware.  Two
   additional query header bits are defined for signaling between
   resolvers and servers.

   Section 7 reviews a variety of operational considerations including
   key generation, lifetime, and storage.

   Section 8 defines levels of conformance for resolvers and servers.

   Section 9 provides a few paragraphs on overall security
   considerations.

   An Appendix is provided that gives some details of base64 encoding
   which is used in the file representation of some RR's defined in this
   draft.

2.  Overview of the Extensions

   The Domain Name System (DNS) protocol security extensions provide
   three distinct services: key distribution as described in Section 2.2
   below, data origin authentication as described in Section 2.3 below,
   and transaction authentication, described in Section 2.4 below.

   Special considerations related to time to live, CNAMEs, and
   delegation points are also discussed in Section 2.3.

2.1 Services Not Provided

   It is part of the design philosophy of the DNS that the data in it is
   public and that the DNS gives the same answers to all inquirers.

   Following this philosophy, no attempt has been made to include any
   sort of access control lists or other means to differentiate
   inquirers.

   In addition, no effort has been made to provide for any
   confidentiality for queries or responses.  (This service may be
   available via an IP other protocols such as a network level security
   protocol for which there
   is current an IETF working group.) providing confidentiality.)

2.2 Key Distribution

   The resource

   Resource records (RRs) are defined to associate keys with DNS names.
   This permits the DNS to be used as a general public key distribution
   mechanism in support of the data origin authentication and
   transaction authentication DNS services as well as other security
   services such as IP level security.
   services.

   The syntax of a KEY resource record (RR) is described in Section 3.
   It includes the name of the entity the key is associated with
   (frequently but not always the KEY resource record owner name), an algorithm identifier, flags indicating the type of
   entity the key is associated with and/or asserting that there is no
   key associated with that entity, and the actual public key
   parameters.

   Under conditions described in Section 3, security aware DNS servers
   will
   may automatically attempt to return KEY resources as additional
   information, along with those resource records actually requested, to
   minimize query
   traffic. the number of queries needed.

2.3 Data Origin Authentication and Integrity

   Security is provided by associating with resource records in the DNS
   cryptographically generated digital signatures.  Commonly, there will
   be a single private key that signs for an entire zone.  If a security
   aware resolver reliably learns the public key of the zone, it can
   verify that all the
   verify, for any data read from that zone, that it was properly
   authorized and is reasonably current.  The expected implementation is
   for the zone private key to be kept off-line and used to re-sign all
   of the records in the zone periodically.

   The data origin authentication key belongs to the zone and not to the
   servers that store copies of the data.  That means compromise of a
   server or even all servers for a zone will not necessarily affect the
   degree of assurance that a resolver has that the data is genuine.

   A resolver can learn the public key of a zone either by reading it
   from DNS or by having it staticly configured.  To reliably learn the
   public key by reading it from DNS, the key itself must be signed.
   Thus, to provide a reasonable degree of security, the resolver must
   be configured with at least the public key of one zone. zone that it can
   use to authenticate signatures.  From that, it can securely read the
   public keys of other zones if the intervening zones in the DNS tree
   are secure.  It  (It is in principle more secure to have the resolver
   manually configured with the public keys of multiple zones, since
   then the compromise of a single zone would not permit the faking of
   information from other zones.  It is also more administratively
   cumbersome, however, particularly when public keys change. change.)

   Adding origin authentication and integrity requires no change to the
   "on-the-wire" DNS protocol beyond the addition of the signature
   resource types (and, as a practical matter, the key resource type
   needed for key distribution).  This service can be supported by
   existing resolver and server implementations so long as they could can
   support the additional resource types. types (see Section 8) with the one
   exception that CNAME referals can not be authenticated if they are
   from non-security aware servers (see Section 2.3.5).

   If signatures are always separately retrieved and verified when
   retrieving the information they authenticate, there will be more
   trips to the server and performance will suffer.  To avoid this,
   security aware servers mitigate that degradation by automatically always sending exactly
   the signature(s) needed.

2.3.2

2.3.1 The SIG Resource Record

   The syntax of a SIG resource record (signature) is described in
   Section 4.  It includes the type of the RR(s) being signed, the name
   of the signer, the time at which the signature was created, the time
   it expires (when it is no longer to be believed), its original time
   to live (which may be longer than its current time to live but cannot
   be shorter), the cryptographic algorithm in use, and the actual
   signature.

   Every name in a zone supporting signed data will have associated with
   it at least one SIG resource record for each resource type under that
   name.  A security aware server supporting the performance enhanced
   version of the DNS protocol security extensions will attempt to
   return, with all records retrieved, the corresponding SIGs.  If a
   server does not support the protocol, the resolver must retrieve all
   the SIG records for a name and select the one or ones that sign the
   resource record(s) that resolver is interested in.

2.3.3

2.3.2 Authenticating Name and Type Non-existence

   The above security mechanism provides only a way to sign existing RRs
   in a zone.  Data origin  "Data origin" authentication is not obviously provided
   for the non-existence of a domain name in a zone. zone or the non-existence
   of a type for an existing name.  This gap is filled by the NXD NXT RR
   which authenticatably asserts a range of non-existent names in a zone.  The owner of the NXD RR is the start of such a
   ranger zone
   and its RDATA is the end of non-existence types for the range; however, there are
   additional complexities due to wildcards. initial name in that range.

   Section 6 5 below covers the NXD NXT RR.

2.3.5

2.3.3 Special Problems Considerations With Time-to-Live

   A digital signature will fail to verify if any change has occurred to
   the data between the time it was originally signed and the time the
   signature is verified.  This conflicts with our desire to have the
   time-to-live field tick down when resource records are cached.

   This could be avoided by leaving the time-to-live out of the digital
   signature, but that would allow unscrupulous secondaries servers to set
   arbitrarily long time to live values undetected.  Instead, we include
   the "original" time-to-live in the signature and communicate that
   data in addition to the current time-to-live.  Unscrupulous servers
   under this scheme can manipulate the time to live but a security
   aware resolver will bound the TTL value it uses at the original
   signed value.  Separately, signatures include a time signed and an
   expiration time.  A resolver that knows an the absolute time can
   determine securely whether a signature has expired.  It is not
   possible to rely solely on the signature expiration as a substitute
   for the TTL, however, singe since non-security aware servers must still be
   supported.

2.3.5 Signers Other Than The Zone

   There are two general cases where

2.3.4 Special Considerations at Delegation Points

   DNS security would like to view each zone as a SIG resource record is unit of data
   completely under the control of the zone owner and signed by
   other than the zone private
   zone's key.  One is for future support  But the operational DNS views the leaf nodes in a zone
   which are also the apex nodes of
   dynamic update where an entity is permitted a subzone (i.e., delegation points)
   as "really" belonging to authenticate/update
   its own records.  The public key of the entity must be present subzone.  These nodes occur in the
   DNS two
   master files and be appropriately will have RRs signed but by both the other RR(s) may upper and lower
   zone's keys.  A retrieval could get a mixture of these RRs and SIGs,
   especially since one server could be signed
   with serving both the entity's key.  The other is for support of transaction
   authentication as described in Section 2.3 below.

2.4 DNS Transaction Authentication

   The data origin authentication service described zone above protects
   resource records but provides no protection for DNS message headers.
   If header bits are falsely set by a server, there is little that can
   be done.  However, it is possible to add transaction authentication.
   Such authentication means that a resolver can be sure it is getting
   messages from the server it thinks it queried and that
   below a delegation point.

   In general, the response
   is KEY RR from the query it sent and that these messages have not been
   diddled in transit.

   This superzone is accomplished by optionally adding a special SIG resource
   record to authoritative while for
   all other RRs, the end of data from the reply which digitally signs subzone is more authoritative.  To
   avoid conflicts, only the
   concatenation of KEY RR in the server's response superzone should be signed
   and the resolver's query.  The
   private key used belongs to NS and any A (glue) RRs should only be signed in the host composing subzone
   along with the reply, not to SOA and any other RRs that have the zone being queried. name as
   owner.  The corresponding public key only exception is stored in and
   retrieved from the DNS.  Because replies are highly variable, message
   authentication SIGs can not be pre-calculated.  Thus it NXT RR type that will be
   necessary to keep the private key on-line, for example in software or always appear
   differently and authoritatively in a directly connected piece of hardware.

   DNS level transaction authentication would be unnecessary both the superzone and subzone, if
   both are secure, as described in Section 5.

2.3.5 Special Considerations with CNAME RRs

   There is a lower
   level (i.e., IP level) end-to-end significant problem with security protocol were available.
   However, such related RRs with the
   same owner name as a protocol is not yet standardized and CNAME RR when it is,
   there will be retrieved from a considerable time during which there non-security-
   aware server.  In particular, an initial retrieval for the CNAME or
   any other type will be systems
   on which not retrieve an associated signature, key, or NXT
   RR. For types other than CNAME it will be hard to add IPSEC but relatively easy to replace
   the DNS components.

3. The KEY Resource Record

   The KEY RR is used to document a key retrieve that is associated with a DNS
   name.  It will be a public key as only public keys are stored in the
   DNS.  This can be type at the public key
   target name of a zone owner, the CNAME (or chain of CNAMEs) and will return the
   CNAME as additional info.  In particular, a host or other
   end entity, or a user.  A KEY RR is, like any other RR, authenticated
   by a specific retrieval for
   type SIG RR.  Security will not get the SIG, if any, at the original domain name
   but rather an SIG at the target name.

   In general, security aware DNS implementations should servers must be designed used to handle at least two simultaneously valid keys securely CNAME in
   DNS.  Security aware servers must (1) allow KEY, SIG, and NXT RRs
   along with CNAME RRs, (2) suppress CNAME processing on retrieval of
   these types as well as on retrieval of the same type
   associated with a name.

   The type number for CNAME, and (3)
   automatically return SIG RRs authenticating the KEY RR is 25.

3.1 KEY RDATA format

   The RDATA for CNAME or CNAMEs
   encountered in resolving a KEY RR consists of an object name, flags, the
   algorithm version, and the public key itself.  The format is as
   follows:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-              object name     +---------------+---------------+
   /                               |    flags      |   algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   + -                        public key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ query.

2.3.6 Signers Other Than The object name, and the flags octets Zone

   There are described in Sections 3.2
   and 3.3 below respectively.  The flags must be examined before any
   following data as they control two cases where a SIG resource record is signed by other
   than the format and even whether there zone private key.  One is
   any following data.  The algorithm and public key fields are
   described in Section 3.4.  The format for future support of the public key dynamic
   update where an entity is algorithm
   dependent.

3.2 Object Types and DNS Names and Keys permitted to authenticate/update its own
   records.  The public key in a KEY RR belongs to the object named in the object
   name field.  Frequently this will also be the owner name of the KEY
   RR.  But they will entity must be different present in the case of the key or keys stored
   under a zone's name for DNS and
   be appropriately signed but the zone's superzone or keys that are stored
   for cross certification of other zones.

   The DNS object name RR(s) may refer to up to three different things.  For
   example, dee.lkg.dec.com could be (1) a zone, (2) a host or other end
   entity , and (3) the mapping into a DNS name of the user or account
   dee@lkg.dec.com .  Thus, there are flags in the KEY RR to indicate signed with which of these roles the object name and public key are
   associated
   entity's key.  The other is for support of transaction authentication
   as described in Section 2.4 below.

   Although the same name can be used

2.4 DNS Transaction Authentication

   The data origin authentication service described above protects
   resource records but provides no protection for up to all three of these
   contexts, such overloading of DNS message headers.
   If header bits are falsely set by a name server, there is discouraged.  It little that can
   be done.  However, it is also possible to use add transaction authentication.
   Such authentication means that a resolver can be sure it is at least
   getting messages from the same key for different things with server it thinks it queried, that the same name
   or even different names, but this
   response is strongly discouraged.  In
   particular, from the use of a zone key as a non-zone key will usually
   require query it sent, and that these messages have not
   been diddled in transit.

   This is accomplished by optionally adding a special SIG resource
   record to the end of the reply which digitally signs the
   concatenation of the server's response and the resolver's query.  The
   private key be kept on line and thereby become much
   more vulnerable.

   It would be desirable for used belongs to the growth of DNS host composing the reply, not to be managed so that
   additional possible simultaneous uses for names are NOT added.  New
   uses should be distinguished by exclusive domains.  For example, all
   IP autonomous system numbers have been mapped into the in-as.arpa
   domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers
   zone being queried.  The corresponding public key is stored in and
   retrieved from the world have been mapped into the tpc.int domain [RFC 1530].  This
   is much preferable DNS.  Because replies are highly variable, message
   authentication SIGs can not be pre-calculated.  Thus it will be
   necessary to having keep the same name possibly private key on-line, for example in software or
   in a directly connected piece of hardware.

   DNS level transaction authentication would be an autonomous
   system number, telephone number, and/or host as well as unnecessary if a zone lower
   level (i.e., IP level) end-to-end security protocol were available.
   However, such a protocol is not yet standardized and when it is,
   there will be a
   user.

   In addition to the name type bits, significant time during which there are three control bits, the
   "no key" bit, the "experimental" bit, and will be systems
   on which it will be hard to add such a protocol but relatively easy
   to replace the "signatory" bit, as
   described below.

3.3 DNS components.

3. The KEY RR Flag Octet

   In the "flags" field:

        Bit 0 is the "no key" bit.  If this bit Resource Record

   The KEY resource record (RR) is on, there used to document a key that is no
   associated with a Domain Name System (DNS) name.  It will be a public
   key
   information and as only public keys are stored in the RR stops with DNS.  This can be the flags octet.  By the use
   public key of
   this bit, a signed KEY RR can authenticatably assert that, for
   example, zone, of a zone is not secured.

        Bits 1 is the "experimental" bit.  Keys may be associated with
   zones, entities, or users for experimental, trial, host or optional use,
   in which case this bit will be one.  If this bit is a zero, it means
   that the use other end entity, or availability of security based on the key is
   "mandatory".  Thus, if this bit is off for a zone, the zone should be
   assumed secured user.  A
   KEY RR is, like any other RR, authenticated by a SIG RRs and any responses indicating the zone is
   not secured should RR. Security
   aware DNS implementations MUST be considered bogus.  Similarly, if this bit were
   off for a host key and attempts designed to negotiate IP-security with the
   host produced indications that IP-security was not supported, it
   should be assumed that handle at least two
   simultaneously valid keys of the host has been compromised or
   communications same type associated with it are being spoofed.  On the other hand, if this
   bit were a one, the host might very well sometimes operate in a
   secure mode and at other times operate without the availability of
   IP-security. name.

   The experimental bit, like all other aspects of the KEY
   RR, is only effective if type number for the KEY RR is appropriately signed by a SIG
   RR. 25.

3.1 KEY RDATA format

   The experimental bit must be zero RDATA for safe secure operation and
   should only be a one for KEY RR consists of flags, a minimal transition period.

        Bit 2 is protocol octet, the "signatory" bit.  It indicates that
   algorithm number, and the public key can
   validly sign RRs of the same name.  If the owner name is a wildcard,
   then RRs with any name which is in the wildcard's scope can be signed
   including NS and corresponding zone KEY RRs to carve out a subzone.
   This bit itself.  The format is meaningless for zone keys which always have authority to
   sign any RRs in the zone. as
   follows:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             flags             |    protocol   |   algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                          public key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

   The signatory bit, like all other aspects meaning of the KEY RR, is only effective if the KEY RR is appropriately
   signed by a SIG RR.

        Bits 3-4 owner name, flags, and protocol octet are reserved
   described in Sections 3.2, 3.3 and 3.4 below respectively.  The flags
   and protocol must be zero.  If they are found non-
   zero, they should be ignored and the KEY RR used examined before any following data as indicated by they
   control the
   other flags.

        Bit 5 on indicates that this format and even whether there is a any following data.  The
   algorithm and public key associated with a "user"
   or "account" at an end entity, usually a host. fields are described in Section 3.5.  The coding
   format of the
   owner name public key is that used for the responsible individual mailbox in the
   SOA record: The owner name is the user name as the name of a node
   under the entity name.  For example, "j.random_user" on
   host.subdomain.domain could have a algorithm dependent.

3.2 Object Types, DNS Names, and Keys

   The public key associated through in a KEY RR with belongs to the object named in the owner
   name.

   This DNS name j\.random_user.host.subdomain.domain.  It may refer to up to three different things.  For
   example, dee.cybercash.com could be
   used in an IP-security protocol where authentication of (1) a user was
   desired.  This key would be useful in IP zone, (2) a host or other security for a user
   level service such a telnet, ftp, rlogin, etc.

        Bit 6 on indicates that this is a key associated with the non-
   zone
   end entity whose name is , and (3) the RR owner name.  This will commonly be mapping into a
   host but could, in some parts DNS name of the DNS tree, be some other type user or
   account dee@cybercash.com .  Thus, there are flags in the KEY RR to
   indicate with which of
   entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt].
   This is these roles the owner name and public key used in connection with are
   associated as described below.

   Although the optional DNS
   transaction authentication service that same name can be used if the owner for up to all three of these
   contexts, such overloading of a name is a DNS server host. discouraged.  It could also be used in an IP-security
   protocol where authentication of a host was desired.

        Bit 7 on indicates that this is a zone also
   possible to use the same key for different things with the zone whose same name
   or even different names, but this is strongly discouraged.  In
   particular, the KEY RR owner name.  This is the fundamental type use of DNS
   data origin authentication public key.

3.4 The KEY Algorithm Version and MD5/RSA Algorithm

   This octet is the a zone key algorithm version parallel to the same field
   for as a non-zone key will usually
   require that the SIG resource.  The MD5/RSA algorithm described in this draft
   is number 1.  Version numbers 2 through 253 are available private key be kept on line and thereby become much
   more vulnerable.

   It would be desirable for
   assignment should sufficient reason arise.  However, the designation growth of a new version could have a major impact on interoperability and
   requires an IETF standards action.  Version 254 is reserved DNS to be managed so that
   additional possible simultaneous uses for
   private use and will never names are NOT added.  New
   uses should be assigned a specific algorithm. distinguished by exclusive domains.  For
   version 254, the public key area shown in the packet diagram above
   will actually begin with an Object Identifier (OID) indicating example, all
   IP autonomous system numbers have been mapped into the
   private algorithm in use in-as.arpa
   domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in
   the remainder of world have been mapped into the combined area is
   whatever tpc.int domain [RFC 1530].  This
   is required by that algorithm. Algorithm versions 0 and 255
   are reserved.

   If much preferable to having the no key bit is zero same name possibly be an autonomous
   system number, telephone number, and/or host as well as a zone and a
   user.

   In addition to the algorithm field is 1, indicating name type bits, there are additional control bits,
   the MD5/RSA algorithm, "no key" bit, the public key filed is structured as follows:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             public key exponent               |modulus length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-                           modulus                            /
   |                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "experimental" bit, the "signatory" field,
   etc., as described below.

3.3 The public key modulus field KEY RR Flag Field

   In the "flags" field:

        Bit 0 is a multiprecision unsigned integer.
   The "modulus length" the "no key" bit.  If this bit is an unsigned octet which on, there is the actual modulus
   length minus 64.  This limits keys to a maximum of 255+64 or 319
   octets no key
   information and a minimum of 64 octets.  Although moduluses of less than
   512 significant bits are not permitted, due to the weak security they
   provide, they can be represented by using leading zeros.

3.5 KEY RRs in RR stops after the Construction algorithm octet.  By the use
   of Responses

   An explicit request for this bit, a signed KEY RRs does not cause any special additional
   information processing except, of course, for the corresponding SIG RR from can authenticatably assert that, for
   example, a security aware server.

   Security aware DNS servers will include KEY RRs as additional
   information in responses where  appropriate including zone is not secured.

        Bit 1 is the following:

        On "experimental" bit.  It is ignored if the retrieval of NS RRs, "no key"
   bit is on and the zone key KEY RR(s) for following description assumes the zone
   served by these name servers will "no key" bit to
   be included.  If not all additional
   info will fit, the KEY RR(s) have lower priority than type A or AAAA
   glue RRs.

        On retrieval of type A or AAAA RRs, the end entity KEY RR(s)
   will off.  Keys may be included.  On inclusion of A associated with zones, entities, or AAAA RRs as additional
   information, their KEY RRs users for
   experimental, trial, or optional use, in which case this bit will also be included but with lower
   priority than
   one.  If this bit is a zero, it means that the relevant A use or AAAA RRs.

3.6 File Representation availability of KEY RRs

   KEY RRs may appear as lines in
   security based on the key is "mandatory".  Thus, if this bit is off
   for a zone data file.

   In the RDATA portion, key, the object name appears first.

   The flag octet zone should be assumed secured by SIG RRs and algorithm version octets are then represented as
   unsigned integers; however, if any
   responses indicating the "no key" flag zone is on in the flags,
   nothing appears after the flag octet. not secured should be considered
   bogus.  If the algorithm specified this bit is the MD5/RSA algorithm, then the
   exponent a one for a host or end entity, it might
   sometimes operate in a secure mode and modulus appear.  The public key exponent is an unsigned
   integer from 3 to 16777215. at other times operate without
   security.  The public key modulus can be quite
   large, up to 319 octets.  It experimental bit, like all other aspects of the KEY
   RR, is only effective if the last data field and KEY RR is
   represented in base 64 (see Appendix) and may appropriately signed by a SIG
   RR.  The experimental bit must be divided up into any
   number of white space separated substrings, down to single base 64
   digits, which zero for safe secure operation and
   should only be a one for a minimal transition period.

        Bits 2-4 are concatenated to obtain the full signature.  These
   substrings can span lines using the standard parenthesis.

   If an algorithm from 2 through 253 is specified, the public key
   parameters required by reserved and must be zero.

        Bit 5 on indicates that algorithm are given.  If the algorithm
   specified is number 254, then an OID appears followed by whatever this is
   required for the private algorithm.  An implementation that does not
   understand a particular standard key associated with a "user"
   or private algorithm should attempt
   to parse the rest "account" at an end entity, usually a host.  The coding of the line as one or more base 64 substrings to be
   concatenated to yield the key parameters.  Algorithm versions 0 and
   255 are reserved.

4. The SIG Resource Record

   The SIG or "signature" resource record (RR)
   owner name is the fundamental way that data is authenticated in the secure DNS.  As such it is used for the
   heart of responsible individual mailbox in the security provided.
   SOA record: The SIG RR unforgably authenticates other RRs of a particular type,
   class, and owner name and binds them to a time interval and the signer's
   fully qualified domain name.  This is done using cryptographic
   techniques and the signer's private key.  The signer is frequently user name as the owner name of a node
   under the zone from which the RR originated.

4.1 SIG RDATA Format

   The RDATA portion of entity name.  For example, "j.random_user" on
   host.subdomain.domain could have a SIG public key associated through a
   KEY RR with name j\.random_user.host.subdomain.domain.  It could be
   used in an security protocol where authentication of a user was
   desired.  This key would be useful in IP or other security for a user
   level service such a telnet, ftp, rlogin, etc.

        Bit 6 on indicates that this is a key associated with the non-
   zone "entity" whose name is the RR owner name.  This will commonly be
   a host but could, in some parts of the DNS tree, be some other type
   of entity such as an Autonomous System [draft-ietf-dnssec-as-map-
   *.txt].  This is the public key used in connection with the optional
   DNS transaction authentication service that can be used if the owner
   name is a DNS server host.  It could also be used in an IP-security
   protocol where authentication of a host was desired such as routing,
   NTP, etc.

        Bit 7 is the "zone" bit and indicates that this is a zone key
   for the zone whose name is the KEY RR owner name.  This is the
   fundamental type of DNS data origin authentication public key.

        Bits 8 is reserved to be the "IPSEC" bit and indicate that this
   key is valid for use in a future IP level security protocol.  This
   key could be used in connection with secured communication on behalf
   of an end entity or user whose name is the owner name of the KEY RR
   if the entity or user bits are on.  The presence of a KEY resource
   with the IPSEC and entity bits on and experimental and no-key bits
   off is a guarantee that the host speaks IPSEC.

        Bits 9-11 are reserved and must be zero.

        Bits 12-15 are the "signatory" field.  If non-zero, it indicates
   that the key can validly sign RRs of the same name.  If the owner
   name is a wildcard, then RRs with any name which is in the wildcard's
   scope can be signed.  Fifteen different non-zero values are possible
   for this field and any differences in their meaning are reserved for
   definition in connection with possible future DNS dynamic update or
   other new DNS commands.  This field is meaningless for zone keys
   which always have authority to sign any RRs in the zone.  The
   signatory field, like all other aspects of the KEY RR, is only
   effective if the KEY RR is appropriately signed by a SIG RR.

3.4 The Protocol Octet

   It is anticipated that keys stored in DNS will be used in conjunction
   with Internet protocols other than DNS (keys with zone bit or
   signatory field non-zero) and IPSEC (keys with IPSEC bit set).  The
   protocol octet is provided to indicate that a key is valid for such
   use and, for end entity keys or the host part of user keys, that the
   secure version of that protocol is implemented on that entity or
   host.

   Values between 1 and 191 decimal inclusive are available for
   assignment by IANA for such protocols.  The 63 values between 192 and
   254 inclusive will not be assigned to a specific protocol and are
   available for experimental use under bilateral agreement. Value 0
   indicates, for a particular key, that it is not valid for any
   particular additional protocol beyond those indicated in the flag
   field. And value 255 indicates that the key is valid for all assigned
   protocols (those in the 1 to 191 range).

   It is intended that new uses of DNS stored keys would initially be
   implemented, and operational experience gained, using the
   experimental range of the protocol octet.  If demand for widespread
   deployment for the indefinite future warrants, a value in the
   assigned range would then be designated for the protocol.  Finally,
   (1) should the protocol become so widespread in conjunction with
   other protocols which are indicated via the protocol octet and with
   which it shares key values that duplicate RRs are a serious burden
   and (2) should the protocol provide substantial facilities not
   available in any protocol for which a flags field bit has been
   allocated, then a flag field bit may be allocated to the protocol.
   Then a key can be simultaneously indicated as valid for that protocol
   and the entity or host can be simultaneously flagged as implementing
   the secure version of that protocol, along with other protocols for
   which flag field bits have been assigned.

   Note that the IPSEC protocol being developed may provide facilities
   adequate for all point to point IP communication meaning that
   additional flag field bits would only be assigned, when appropriate
   as indicated above, to protocols with a store-and-forward nature
   (other than DNS) or otherwise not subsumed into a point-to-point
   paradigm.

3.5 The KEY Algorithm Number and the MD5/RSA Algorithm

   This octet is the key algorithm parallel to the same field for the
   SIG resource.  The MD5/RSA algorithm described in this draft is
   number 1.  Numbers 2 through 253 are available for assignment should
   sufficient reason arise.  However, the designation of a new algorithm
   could have a major impact on interoperability and requires an IETF
   standards action.  Number 254 is reserved for private use and will
   never be assigned a specific algorithm.  For number 254, the public
   key area shown in the packet diagram above will actually begin with
   an Object Identifier (OID) indicating the private algorithm in use
   and the remainder of the area is whatever is required by that
   algorithm. Values 0 and 255 are reserved.

   If the no key bit is zero and the algorithm field is 1, indicating
   the MD5/RSA algorithm, the public key field is structured as follows:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | pub exp length|        public key exponent                    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-                           modulus                            /
   |                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/

   To promote interoperability, the exponent and modulus are limited to
   2552 bits in length.  The public key exponent is a variable length
   unsigned integer.  Its length in octets is represented as one octet
   if it is in the range of 1 to 255 and by a zero octet followed by a
   two octet unsigned length if it is longer than 255 bytes.  The public
   key modulus field is a multiprecision unsigned integer.  The length
   of the modulus can be determined from the RDLENGTH and the preceding
   RDATA fields including the exponent.  Leading zero bytes are
   prohibited in the exponent and modulus.

3.6 Interaction of Flags, Algorithm, and Protocol Bytes

   Various combinations of the no-key bit, algorithm byte, protocol
   byte, and any protocol indicating flags (such as the reserved IPSEC
   flag) are possible.  (Not that the zone flag bit being on or the
   signatory field being non-zero is effectively a DNS protocol flag
   on.)  The meaning of these combinations is indicated below:

      NK = no key flag
      AL = alogrithm byte
      PR = protocols indicated by protocol byte or protocol flags

      x represents any valid non-zero value.

       AL  PR   NK  Meaning
        0   0   0   Illegal, claims key but has bad algorithm field.
        0   0   1   Authenticates total lack of security for owner.

        0   x   0   Illegal, claims key but has bad algorithm field.
        0   x   1   Specified protocols insecure, others may be secure.
        x   0   0   Useless.  Gives key but no protocols to use it.
        x   0   1   Useless.  Denies key but for no protocols.
        x   x   0   Authenticates key for protocols and certifies
                      that those protocols are implemented with
                      security.
        x   x   1   Algorithm not understood for protocol.

      (remember, in reference to the above table, that a protocol
       byte of 255 means all protocols with protocol bytes assigned)

3.7 KEY RRs in the Construction of Responses

   An explicit request for KEY RRs does not cause any special additional
   information processing except, of course, for the corresponding SIG
   RR from a security aware server.

   Security aware DNS servers will include KEY RRs as additional
   information in responses where appropriate including the following:

   (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone
   served by these name servers will be included as additional
   information.  If not all additional info will fit, the KEY RR(s) have
   higher priority than type A (or AAAA) glue RRs.

   (2) On retrieval of type A (or AAAA) RRs, the end entity KEY RR(s)
   will be included.  On inclusion of A (or AAAA) RRs as additional
   information, their KEY RRs will also be included but with lower
   priority than the relevant A (or AAAA) RRs.

3.8 File Representation of KEY RRs

   KEY RRs may appear as lines in a zone data file.

   The flag field, protocol,  and algorithm number octets are then
   represented as unsigned integers.  Note that if the "no key" flag is
   on in the flags, nothing appears after the algorithm octet.

   The remaining public key portion is represented in base 64 (see
   Appendix) and may be divided up into any number of white space
   separated substrings, down to single base 64 digits, which are
   concatenated to obtain the full signature.  These substrings can span
   lines using the standard parenthesis.

   Note that the public key may have internal sub-fields but these do
   not appear in the master file representation.  For example, with
   algorithm 1 there is a public exponent and then a modulus and with
   algorithm 254, there will be an OID followed by algorithm dependent
   information.

4. The SIG Resource Record

   The SIG or "signature" resource record (RR) is the fundamental way
   that data is authenticated in the secure Domain Name System (DNS). As
   such it is the heart of the security provided.

   The SIG RR unforgably authenticates other RRs of a particular type,
   class, and name and binds them to a time interval and the signer's
   domain name.  This is done using cryptographic techniques and the
   signer's private key.  The signer is frequently the owner of the zone
   from which the RR originated.

4.1 SIG RDATA Format

   The RDATA portion of a SIG RR is as shown below.  The integrity of
   the RDATA information is protected by the signature field.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        type covered           |  algorithm    |     labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      signature expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         time signed                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         key footprint         |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         signer's name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-                          signature                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value of the SIG RR type is 24.

   The "type covered" is the type of the other RRs covered by this SIG.

   The algorithm number is an octet specifying the digital signature
   algorithm used parallel to the algorithm octet for the KEY RR.  The
   MD5/RSA algorithm described in this draft is number 1.  Numbers 2
   through 253 are available for assignment should sufficient reason
   arise to allocate them.  However, the designation of a new algorithm
   could have a major impact on the interoperability of the global DNS
   systems and requires an IETF standards action.  Number 254 is
   reserved for private use and will not be assigned a specific
   algorithm.  For number 254, the "signature" area shown above will
   actually begin with an Object Identifier (OID) indicating the private
   algorithm in use and the remainder of the signature area is whatever
   is required by that algorithm.  Values 0 and 255 are reserved.

   The "labels" octet is an unsigned count of how many labels there are
   in the original SIG RR owner name not counting the null label for
   root and not counting any initial "*" for a wildcard.  If a secured
   retrieval is the result of wild card substitution, it is necessary
   for the resolver to use the original form of the name in verifying
   the digital signature.  This field helps optimize the determination
   of the original form reducing the effort in authenticating signed
   data.

   If, on retrieval, the RR appears to have a longer name than indicated
   by "labels", the resolver can tell it is the result of wildcard
   substitution.  If the RR owner name appears to be shorter than the
   labels count, the SIG RR should be considered corrupt and ignored.
   The maximum number of labels possible in the current DNS is 127 but
   the entire octet is reserved and would be required should DNS names
   ever be expanded to 255 labels.  The following table give some
   examples.  The value of "labels" is at the top, the retrieved owner
   name on the left, and the table entry is the name to use in signature
   verification except that "bad" means the RR is corrupt.

        labels= |  0  |   1  |    2   |      3   |      4   |
        --------+-----+------+--------+----------+----------+
               .|   . | bad  |  bad   |    bad   |    bad   |
              d.|  *. |   d. |  bad   |    bad   |    bad   |
            c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
          b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
        a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |

   The "original TTL" field is included in the RDATA portion to avoid
   (1) authentication problems that caching servers would otherwise
   cause by decrementing the real TTL field and (2) security problems
   that unscrupulous servers could otherwise cause by manipulating the
   real TTL field.  This original TTL is protected by the signature
   while the current TTL field is not.

   NOTE:  The "original TTL" must be restored into the covered RRs when
   the signature is verified.  This implies that the RRs for a
   particular type need to all have the same TTL to start with.

   The SIG is valid until the "signature expiration" time which is an
   unsigned number of seconds since the start of 1 January 1970, GMT,
   ignoring leap seconds.  (See also Section 4.4.)

   The "time signed" field is an unsigned number of seconds since the
   start of 1 January 1970, GMT, ignoring leap seconds.

   The "key footprint" is a 16 bit quantity that is used to help
   efficiently select between multiple keys which may be applicable and
   as shown below. a quick check that a public key about to be used for the
   computationally expensive effort to check the signature is possibly
   valid.  Its exact meaning is algorithm dependent.  For the MD5/RSA
   algorithm, it is the next to the bottom two octets of the public key
   modulus needed to decode the signature field.  That is to say, the
   most significant 16 of the lest significant 24 bits of this quantity
   in network order.

   The integrity "signer's name" field is the domain name of the RDATA information signer generating
   the SIG RR.  This is protected by frequently the signature field.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        type covered           |  algorithm    |     labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      signature expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         time signed                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         key footprint         |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ zone which contained the RR(s)
   being authenticated.  The signer's name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-                          signature                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ may be compressed with
   standard DNS name compression when being transmitted over the
   network.

   The value structure of the SIG RR type "signature" field  is 24. described below.

4.1.1 Signature Data

   The "type covered" is the type actual signature portion of the SIG RR binds the other RDATA
   fields to all of the "type covered" RRs with that owner name.  These
   covered by this SIG.

   The algorithm version number RRs are thereby authenticated.  To accomplish this, a data
   sequence is an octet specifying constructed as follows:

        data = RDATA | RR(s)...

   where | is concatenation, RDATA is all the digital
   signature algorithm used.  The MD5/RSA algorithm described RDATA fields in this
   draft is version 1.  Version numbers 2 through 253 are available for
   assignment should sufficient reason arise to allocate them.  However, the designation of a new version could have a major impact on SIG RR
   itself before the signature, and RR(s) are all the
   interoperability RR(s) of the global DNS systems type
   covered with the same owner name and requires an IETF
   standards action.  Version 254 is reserved for private use class as the SIG RR in canonical
   form and will
   never be assigned a specific algorithm. order.

   For version 254, purposes of DNS security, the
   "signature" area shown above will actually begin with canonical form for an Object
   Identified (OID) indicating RR is the private algorithm in use RR
   with domain names (1) fully expanded (no name compression via
   pointers) and the
   remainder (2) all domain name letters set to lower case.  For
   purposes of DNS security, the signature area is whatever canonical order for RRs is required to sort them
   in ascending order by that
   algorithm.  Version numbers 0 name, then by type, as left justified unsigned
   octet sequences in network (transmission) order where a missing octet
   sorts before a zero octet.  (See also ordering discussion in Section
   5.1.)  Within any particular name and 255 type they are reserved.

   The "labels" octet is an similarly sorted
   by RDATA as a left justified unsigned count of how many labels there are
   in octet sequence. EXCEPT that the original
   type SIG RR owner name not counting RR(s) covering any particular type appear immediately after
   the null label for
   root other RRs of that type.  Thus if at name a.b there is one A RR
   and not counting any initial "*" one KEY RR, their order with SIGs for a wildcard.  If, concatenating the "data" to
   be signed would be as follows:

        a.b.  A ....
        a.b.  SIG A ...
        a.b.  KEY ...
        a.b.  SIG KEY ...

   (SIGs on
   retrieval, type ANY should not be included in a zone.)

   How this data sequence is processed into the signature is algorithm
   dependent.

4.1.2 MD5/RSA Algorithm Signature Calculation

   For the MD5/RSA algorithm, the RR appears to have a longer name, signature is as follows

        hash = MD5 ( data )

        signature = ( 01 | FF* | 00 | hash ) ** e (mod n)

   where MD5 is the resolver can
   tell it message digest algorithm documented in RFC 1321, "|"
   is concatenation, "e" is the result secret key exponent of wildcard substitution.  If the RR owner name
   appears to be shorter than signer, and
   "n" is the labels count, public modulus of the SIG RR should be
   considered corrupt signer's public key.  01, FF, and ignored. 00
   are fixed octets of the corresponding hexadecimal value.  The FF
   octet is repeated the maximum number of labels
   possible in times such that the current DNS is 127 but value of
   the entire octet quantity being exponentiated is reserved one octet shorter than the value
   of n.

   The size of n, including most and would least significant bits (which will
   be required should DNS names ever 1) SHALL be expanded to 255
   labels.  If a secured retrieval is not less than 512 bits and not more than 2552 bits.  n
   and e SHOULD be chosen such that the result of wild card
   substitution, it public exponent is necessary for small.

   Leading zeros bytes are not permitted in the resolver MD5/RSA algorithm
   signature.

   The above specifications are similar to use Public Key Cryptographic
   Standard #1 [PKCS1].

   A public exponent of 3 minimizes the original
   form effort needed to decode a
   signature.  Use of 3 as the name in verifying public exponent may be weak for
   confidentiality uses since, if the digital signature.  The field helps
   optimize same data can be collected
   encrypted under three different keys with an exponent of 3 then,
   using the determination of Chinese Remainder Theorem, the original form reducing plain text can be
   easily recovered.  This weakness is not significant for DNS because
   we seek only authentication, not confidentiality.

4.1.3 Zone Transfer (AXFR) SIG

   The above SIG mechanisms assure the effort
   in authentication of all zone signed data.  The following table give some
   examples.  The value
   RRs of "labels" is at the top, the retrieved owner
   name on the left, a particular name, class and the table entry is the name type.  However, to use in signature
   verification except that "bad" means the efficiently
   secure complete zone transfers, a SIG RR is corrupt.

      labels= |  0  |   1  |    2   |      3   |      4   |
      --------+-----+------+--------+----------+----------+
             .|   . | bad  |  bad   |    bad   |    bad   |
            d.|  *. |   d. |  bad   |    bad   |    bad   |
          c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
        b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
      a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |

   The "original TTL" field is included in the RDATA portion to avoid
   authentication problems that caching servers would otherwise cause owned by
   decrementing the real TTL field and security problems zone name must
   be created with a type covered of AXFR that
   unscrupulous servers could otherwise cause by manipulating covers all zone signed
   RRs other than the real
   TTL field.  This original TTL is protected SIG AXFR itself.  It will be calculated by the signature while the
   current TTL field is not.

   NOTE: hashing
   together all other static zone RRs, including SIGs.  The RRs are
   ordered and concatenated for hashing as described in Section 4.1.1.
   (See also ordering discussion in Section 5.1.)

   The "original TTL" AXFR SIG must be restored into the covered RRs when
   the signature is verified.  This implies that calculated last of all zone key signed SIGs in
   the RRs need zone.  It really belongs to all
   have the same TTL zone as a whole, not to start with. the zone
   name.  The AXFR SIG is valid until the "signature expiration" time which is an
   unsigned number of seconds since the start only retrieved as part of 1 January 1970, GMT.

   The "time signed" field is an unsigned number a zone transfer.
   After validation of seconds since the
   start AXFR SIG, the zone may be considered valid
   without verification of 1 January 1970, GMT. all the internal zone SIGs in the zone;
   however, any SIGs signed by entity keys or the like must still be
   validated.  The "key footprint" AXFR SIG is transmitted first in a 16 bit quantity zone transfer so
   the receiver can tell immediately that is used they may be able to help
   efficiently select between multiple keys avoid
   verifying other zone signed SIGs.

   Dynamic zone RRs which may might be applicable added by some future dynamic zone
   update protocol and
   as a quick check that a public signed by an end entity or user key about to be used for the
   computationally expensive effort to check the signature is possibly
   valid.  Its exact meaning is algorithm dependent.  For the MD5/RSA
   algorithm, it is the next to the bottom two octets of the public rather than a
   zone key
   modulus needed to decode the signature field.  That is to say, the
   most significant 16 of the lest significant 24 bits of this quantity (see Section 3.2) are not included.  They originate in network order.

   The "signer's name" field is the fully qualified domain name of the
   signer generating the SIG RR.  This is frequently
   network and will not, in general, be migrated to the recommended off
   line zone which
   contained the RR(s) being authenticated.

   The structured of signing procedure (see Section 8.2).  Thus such dynamic RRs
   are not directly signed by the "signature" field depends on zone, are not included in the algorithm
   chosen AXFR
   SIG, and is described below for are not generally protected against omission during zone
   transfers.

4.1.4 Transaction SIGs

   A response message from a security aware server may optionally
   contain a special SIG as the MD5/RSA algorithm.

4.1.1 Signature Format

   The actual signature portion of last item in the SIG RR binds RDATA additional information
   section to all of authenticate the transaction.

   This SIG has a "type covered" RRs with that owner name.  These covered RRs are
   thereby authenticated.  To accomplish this, a data sequence field of zero, which is
   constructed as follows:

        data = RDATA | RR(s)...

   where | not a valid RR
   type.  It is concatenation and RR(s) are all the expanded (no name
   abbreviation) RR(s) calculated by using a "data" (see Section 4.1.2) of the type covered
   entire preceding DNS reply message, including DNS header,
   concatenated with the same owner name and
   class as the SIG RR in canonical order.  The canonical order for RRs
   is to sort them in ascending order as left justified unsigned octet
   sequences where a missing octet sorts before a zero octet.

   How entire DNS query message that produced this data sequence is processed into the signature is algorithm
   dependent.

   For the MD5/RSA algorithm,
   response, including the signature query's DNS header.  That is as follows

        hash = MD5 (

        data )

        signature = ( 01 | FF* | 00 full response (less trailing message SIG) | hash ) ** e (mod n)

   where "|" is concatenation, "e" is the secret key exponent full query

   Verification of the
   signer, and "n" transaction SIG (which is signed by the public modulus server
   host key, not the zone key) by the requesting resolver shows that is the signer's public
   key.  01, FF,
   query and 00 are fixed octets of response were not tampered with in transit, that the corresponding
   hexadecimal value.  The FF octet is repeated
   response corresponds to the maximum number of
   times such intended query, and that the value of response
   comes from the quantity being exponentiated is one
   octet shorter than queried server.

4.2 SIG RRs in the value Construction of n. Responses

   Security aware servers MUST, for every authoritative RR the query
   will return, attempt to send the available SIG RRs which authenticate
   the requested RR.  The size following rules apply to the inclusion of n, including most and least significant bits (which will SIG
   RRs in responses:

   1. when an RR is placed in a response, its SIG RR has a higher
      priority for inclusion than other RRs that may need to be 1) SHALL
      included.  If space does not permit its inclusion, the response
      MUST be considered truncated.

   2. when a SIG RR is present for an RR to be included in the
      additional information section, the response MUST not be
      considered truncated if space does not less than 512 bits permit the inclusion of the
      SIG RR.

   Sending SIGs to authenticate non-authoritative data (glue records and not more than 2552 bits.  n
   NS RRs for subzones) is unnecessary and e must be avoided.  Note that
   KEYs for subzones are authoritative.

   If a SIG covers any RR that would be in the answer section of the
   response, its automatic inclusion MUST be chosen such the answer section.  If it
   covers an RR that would appear in the public exponent is less than or
   equal to 2**24 - 1 and SHOULD authority section, its
   automatic inclusion MUST be chosen such in the authority section.  If it covers
   an RR that would appear in the public exponent
   is small.

   The above specifications are similar to Public Key Cryptographic
   Standard #1 [PKCS1].

   (A public exponent of 3 minimizes additional information section it MUST
   appear in the effort needed to decode additional information section.

   Optionally, DNS transactions may be authenticated by a
   signature.  Use SIG RR at the
   end of 3 as the public exponent may be weak for
   confidentiality uses since, if response in the same data can additional information section (Section
   4.1.4).  Such SIG RRs are signed by the DNS server originating the
   response.  Although the signer field must be collected
   encrypted under three different keys with an exponent the name of 3 then,
   using the Chinese Remainder Theorem,
   originating server host, the owner name, class, TTL, and original plain text
   TTL, are meaningless.  The class and TTL fields can be
   easily recovered.  This weakness zero.  To
   conserve space, the owner name SHOULD be root (a single zero octet).
   If transaction authentication is not significant for DNS because
   we seek only authentication, not confidentiality.)

4.1.2 SIG RRs Covering Type ANY

   The desired, that SIG RR described above protects all must be
   considered higher priority than any other RR in the answer.

4.3 Processing Responses and SIG RRs

   The following rules apply to the processing of SIG RRs with included in a particular
   owner name, class, and type.  Thus
   response:

   1. a server must supply them all security aware resolver that receives a response from what it
      believes to
   convince be a security aware resolver.  However, an unscrupulous server
   could claim there were no RRs of via a particular type and class under an
   owner name while presenting signed communication path
      that it believes to be secure with the AD bit (see Section 6.1)
      set, MAY choose to accept the RRs of as received
       without verifying the SIG RRs.

   2. in other types.  To provide cases, a
   means of protection against this, one or more security aware resolver SHOULD verify the SIG RR is added
      RRs for
   each owner name that covers the type ANY.  It is calculated as
   indicated above except that all RRs of interest.  This may involve initiating
      additional queries for that owner name and SIG key,
   except or KEY RRs, at least in the SIG RR covering type ANY itself, are included case of
      getting a response from an insecure server.  (As explained in 4.2
      above, it will not be possible to secure CNAMEs being served up by
      old resolvers.)

      NOTE: Implementors might expect the data
   string which is processed into SHOULD to be a MUST.  However,
      local policy or the signature.

   To allow for dynamic update, calling application may not require the zone key signed ANY SIG RR covers
   only zone signed RRs.
      security services.

   3. If SIG RRs are added received in response to a zone authenticated by an
   entity or user key, then an ANY SIG RR signed by that key covering query explicitly
      specifying the RRs signed by that key should be added.

4.1.3 Zone Transfer (AXFR) SIG

   The above type, no special processing is required.

   If the message does not pass reasonable checks or the SIG mechanisms assure does not
   check against the authentication of all signed RRs, the RRs of
   a particular name, class and type SIG RR is invalid and should be
   ignored.  If all the RRs of a particular
   name, class and any type.  However, the SIG RR(s) purporting to secure complete zone
   transfers, authenticate a set of
   RRs are invalid, then the set of RR(s) is not authenticated.

   If the SIG RR owned by is the zone name must be created with last RR in a response in the additional
   information section and has a type covered of AXFR zero, it is a
   transaction signature of the response and the query that covers all other zone signed RRs. produced the
   response.  It will MAY be calculated by hashing together all other static zone RRs,
   including SIGs.  The RRs are ordered optionally checked and concatenated for hashing as
   described in Section 4.1.1.  This SIG, other than having to be
   calculated last of all zone key signed SIGs in the zone, is message rejected if
   the same
   as checks fail.  But even if the checks succeed, such a transaction
   authentication SIG does NOT authenticate any other SIG.

   Dynamic zone RRs which might be added by some future dynamic zone
   update protocol and in the message.
   Only a proper SIG RR signed by an end entity or user key rather than a the zone key (see Section 3.2) are can authenticate RRs.  If a
   resolver does not included.  They originate in implement transaction SIGs, it MUST at least ignore
   them without error.

   If all reasonable checks indicate that the
   network SIG RR is valid then RRs
   verified by it should be considered authenticated.

4.4 Signature Expiration, TTLs, and Validity

   Security aware servers must not consider SIG RRs to be authentic
   after their expiration time and will not, in general, not consider any RR to be migrated
   authenticated after its signatures have expired.  Within that
   constraint, servers should continue to the recommended off
   line zone signing procedure (see Section 8.2). follow DNS TTL aging.  Thus such dynamic RRs
   are not directly signed by
   authoritative servers should continue to follow the zone refresh and
   expire parameters and are not generally protected
   against omission during zone transfers.

4.1.4 Transaction SIGs

   A response message from a security aware non-authoritative server may optionally
   contain a special SIG as should count down
   the last item TTL and discard RRs when the TTL is zero.  In addition, when RRs
   are transmitted in a query response, the additional information
   section to authenticate TTL should be trimmed so
   that current time plus the transaction.

   This TTL does not extend beyond the signature
   expiration time.  Thus, in general, the TTL on an transmitted RR
   would be

      min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))

4.5 File Representation of SIG has RRs

   A SIG RR can be represented as a "type covered" field of zero, which is single logical line in a zone data
   file [RFC1033] but there are some special problems as described
   below.  (It does not make sense to include a valid transaction
   authenticating SIG RR
   type.  It in a file as it is calculated by using a "data" (see section 4.1.1) of the
   entire preceding DNS reply message, including DNS header,
   concatenated with the entire DNS query message transient authentication
   that produced this
   response, including the query's DNS header.  That is covers data = full response (less trailing message SIG) | full query

   Verification of the message SIG (which is signed by the server host
   key, not the zone key) including an ephemeral transaction number so it must
   be calculated in real time by the requesting resolver shows that DNS server.)

   There is no particular problem with the
   query signer, covered type, and response were not tampered with
   times.  The time fields appears in transit and that the
   response corresponds to form YYYYMMDDHHMMSS where YYYY
   is the intended query.

4.2 SIG RRs in year, the Construction of Responses

   Security aware servers MUST, for every authoritative RR first MM is the query
   will return, attempt to send month number (01-12), DD is the available SIG RRs which authenticate day
   of the requested RR.  If multiple such SIGs are available, there may be
   insufficient space month (01-31), HH is the hour in 24 hours notation (00-23),
   the response to include them all.  In this
   case, SIGs whose signer second MM is the zone containing the RR MUST be given
   highest priority and retained even if SIGs with other signers must be
   dropped.

   Sending SIGs to authenticate non-authoritative data (glue records minute (00-59), and
   NS RRs for subzones) SS is optional the second (00-59).

   The original TTL and should be avoided if algorithm fields appear as unsigned integers.

   The "labels" field does not appear in the file representation as it will
   lead to UDP DNS response truncation.

   If a SIG covers any RR that would
   can be in calculated from the answer section of owner name.

   The key footprint appears as an unsigned decimal number.

   However, the
   response, its automatic inclusion MUST signature itself can be very long.  It is the answer section.  If it
   covers an RR that would appear last data
   field and is represented in base 64 (see Appendix) and may be divided
   up into any number of white space separated substrings, down to
   single base 64 digits, which are concatenated to obtain the authority section, its
   automatic inclusion MUST full
   signature.  These substrings can be in split between lines using the authority section.  If it covers
   an
   standard parenthesis.

5. Non-existent Names and Types

   The SIG RR mechanism described in Section 4 above provides strong
   authentication of RRs that would appear exist in the additional information section a zone.  But is it MUST
   appear in not
   immediately clear how to authenticatably deny the additional information section.

   Optionally, DNS transactions may be authenticated by existence of a SIG RR at the
   end name
   in a zone or a type for an existent name.

   The nonexistence of the response a name in the additional information section (section
   4.1.4).  Such SIG RRs are signed a zone is indicated by the DNS server originating NXT ("next")
   RR for a name interval containing the
   response.  Although nonexistent name. An NXT RR and
   its SIG are returned in the signer field must be authority section, along with the name of error,
   if the
   originating server host, the owner name, class, TTL, and original
   TTL, are meaningless. is security aware.  The class and TTL fields can same is true for a non-existent
   type under an existing name.  NXT RRs will also be zero.  To save
   space, returned if an
   explicit query is made for the name should be root (a single zero octet).

   [There may be a problem with SIG and NXD RR's associated with domain
   names that are CNAMEs. NXT type.

   The DNS RFCs prohibit other types existence of RRs
   appearing with a CNAME RR.  This problem is being ignored until it is
   clear if DNS servers will really have a problem with this.]

4.3 Processing Responses with SIG RRs

   If SIG RRs are received complete set of NXT records in response to a zone means that
   any query explicitly specifying
   the SIG type, no special processing is required but for any name and type to a security aware
   client MAY wish to authenticate them by checking server serving
   the signature and
   applying consistency checks.

   If SIG zone should result in an reply containing at least one signed RR.

   NXT RRs are received do not appear in any other response, a security aware
   client should check them using zone master files since they can be derived
   from the public key rest of the signer. zone.

5.1 The
   result should then be verified against the appropriate other NXT Resource Record

   The NXT resource record is used to securely indicate that RRs
   retrieved.

   If the message does not pass reasonable checks or the SIG does with an
   owner name in a certain name interval do not
   check against the signed RRs, the SIG RR is invalid exist in a zone and should be
   ignored. to
   indicate what zone signed type RRs are present for an existing name.

   The time of receipt owner name of the SIG NXT RR must be is an existing name in the inclusive
   range of the time signed and the signature expiration but the SIG can
   be retained zone.  It's
   RDATA is a "next" name and remains locally valid until the expiration time plus
   the authenticated TTL.

   If a type bit map. The presence of the SIG NXT RR is
   means that generally no name between its owner name and the last RR name in
   its RDATA area exists and that no other types exist under its owner
   name.  This implies a response canonical ordering of all domain names in the additional
   information section and has a type covered
   zone.

   The ordering is to sort labels as unsigned left justified octet
   strings where the absence of zero, it is a
   transaction signature of the the response and the query that produced octet sorts before a zero octet.
   Names are then sorted by sorting on the response.  It may be optionally checked highest level label and then,
   within those names with the message rejected
   if the checks fail.  But even it the checks succeed, such a
   transaction authentication SIG does NOT authenticate any RRs in the
   message.  Only a proper SIG RR signets signed same highest level label by the zone can
   authenticate RRs.  If next
   lower label, etc.  Since we are talking about a resolver does not implement transaction SIGs,
   it MUST at least ignore them without error.

   If all reasonable checks indicate that zone, the SIG RR is valid then RRs
   verified by it should be considered authenticated zone name
   itself always exists and all other RRs
   in names are the response should be considered with suspicion.

4.4 File Representation of SIG RRs

   A SIG RR can be represented as a single logical line in a zone data
   file [RFC1033] but there are name with some special problems as described
   below.  (It does not make sense to include a transaction
   authenticating SIG RR in a file as it is a transient authentication
   that must be calculated in real time by
   prefix of lower level labels.  Thus the DNS server.) zone name itself always sorts
   first.

   There is no particular a problem with the signer, covered type, and
   times.  The time fields appears last NXT in the form YYYYMMDDHHMMSS where YYYY a zone as it wants to have an
   owner name which is the year, the first MM last existing name in sort order, which is the month number (01-12), DD
   easy, but it is not obvious what name to put in its RDATA to indicate
   the day entire remainder of the month (01-31), HH name space.  This is handled by treating
   the hour name space as circular and putting the zone name in 24 hours notation (00-23), the second MM is RDATA of
   the minute (00-59), last NXT.

   There are special considerations due to interaction with wildcards as
   explained below.

   The NXT RRs for a zone should be automatically calculated and SS is added
   to the second (00-59). zone by the same recommended off-line process that signs the
   zone.  The original NXT RR's TTL and algorithm fields appears as unsigned integers.

   The "labels" field does should not appear in the file representation as it
   can be calculated from exceed the owner name. zone minimum TTL.

5.2 NXT RDATA Format

   The key footprint appears as RDATA for an eight digit unsigned hexadecimal
   number.

   However, the signature itself can be very long.  It is NXT RR consists simply of a domain name followed by
   a bit map.

   The type number for the last data
   field and NXT RR is represented in base 64 (see Appendix) and may be divided
   up into any number of white space separated substrings, down to
   single base 64 digits, which are concatenated to obtain 30.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     next domain name                                          /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        type bit map                           /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The size of the full
   signature.  These substrings bit map can be split between lines using inferred from the
   standard parenthesis.

5. Non-existent Names

   The SIG RR mechanism described in section 4 above provides strong
   authentication of RRs that exist in a zone.  But is it not
   immediately clear how to authenticatably deny RDLENGTH and the existence
   length of the next domain name.

5.3 Example

   Assume zone foo.bar has entries for

               big.foo.bar,
               medium.foo.bar.
               small.foo.bar.
               tiny.foo.bar.

   Then a name
   in a zone.

   The nonexistence of query to a security aware server for huge.foo.bar would
   produce an error reply with the authority section data including the
   following:

        big.foo.bar. NXT medium.foo.bar. 130
        big.foo.bar. SIG NXT ...

   Note that this response implies that big.foo.bar is an existing name
   in a the zone is indicated by and thus has other RR types associated with it than NXT.
   However, only the NXD NXT (and its SIG) RR appear in the response to this
   query for huge.foo.bar, which is a
   name interval containing the nonexistent non-existent name.  An NXD RR

5.4 Interaction of NXT RRs and its SIG
   are returned Wildcard RRs

   Since, in the additional information section, along some sense, a wildcard RR causes all possible names in an
   interval to exist, there should not be an NXT RR that would cover any
   part of this interval.  Thus if *.X.ZONE exists you would expect an
   NXT RR that ends at X.ZONE and one that starts with the
   error, if last name
   covered by *.X.ZONE.  However, this "last name covered" is something
   very ugly and long like \255\255\255....X.zone.  So the resolver NXT for the
   interval following is security aware.  NXD RRs can also be
   returned if an explicit query simply given the owner name *.X.ZONE.  This "*"
   type name is made for not expanded when the NXD type.

   The existence of a complete set of NXD records NXT is returned as authority
   information in connection with a zone means that
   any query for a non-existent name.

   If there could be any name to wildcard RRs in a security aware server serving the zone
   should result and thus wildcard NXTs,
   care must be taken in an reply containing at least one signed RR.

5.1 The NXD Resource Record

   The NXD resource record is used to securely indicate that no RRs with
   an interpreting the results of explicit NXT
   retrievals as the owner name in a certain name interval exist in may be a zone. wildcard expansion.

   The owner name existence of the NXD RR is an existing name in the zone.  It's
   RDATA is another existing one or more wildcard RRs covering a name interval
   makes it possible for a malicious server to hide any more specificly
   named RRs in the zone. internal.  The presence server can just falsely return the
   wildcard match NXT instead of the NXD more specificly named RRs.  If
   there is a zone wide wildcard, there will be an NXT RR means that no name between its whose owner
   name and is the name in its wild card and whose RDATA area exists.  This implies is the zone name.  In this case
   a canonical ordering server could conceal the existence of all domain
   names any more specific RRs in a the
   zone.

   The ordering is  (It would be possible to sort labels design a more strict NXT feature
   which would eliminate this possibility.  But it would be more complex
   and might be so constraining as unsigned left justified octet
   strings where to make any future dynamic update
   feature that could create new names very difficult (see Section
   3.2).)

   What name should be put into the absence RDATA of an RR with a byte sorts before name that is
   within a zero byte.  Names
   are then sorted by sorting on wild card scope?  Since the highest level label and then,
   within those names with "next" existing name will be one
   that matches the same highest level label by wild card, the next
   lower label, etc.  Since we are talking about wild card name should be used.

5.5 Blocking NXT Pseudo-Zone Transfers

   In a secure zone, a resolver can query for the zone name
   itself always exists and all other names are the zone name initial NXT associated
   with some
   prefix of lower level labels.  Thus the zone name.  Using the next domain name itself always sorts
   first.

   There is a slight problem with RDATA field from that
   RR, it can query for the last NXD next NXT RR.  By repeating this, it can walk
   through all the NXTs in a zone as the zone.  If there are no wildcards, it wants can
   use this technique to
   have an owner name which is the last existing name find all names in sort order,
   which is easy, but a zone. If it is not obvious what name does type ANY
   queries, it can incrementally get all information in the zone and
   perhaps defeat attempts to put administratively block zone transfers.

   If there are any wildcards, this NXT walking technique will not find
   any more specific RR names in its RDATA the part of the name space the wildcard
   covers.  By doing explicit retrievals for wildcard names, a resolver
   could determine what intervals are covered by wildcards but still
   could not, with these techniques, find any names inside such
   intervals except by trying every name.

   If it is desired to
   indicate the entire remainder of block NXT walking, the name space.  This recommended method is handled by
   treating the name space as circular and putting the to
   add a zone name in the
   RDATA wide wildcard of the last NXD.

   There are additional complexities due to interaction KEY type with wildcards
   as explained below.

   The NXD RRs for a zone can be automatically calculated the no key bit on and added
   with no type (zone, entity, or user) bit on.  This will cause there
   to
   the be one zone by the same recommended off-line process that signs covering NXT RR and leak no information about what
   real names exist in the zone.  The NXD RR's TTL should not exceed the zone minimum TTL.

   The type number for the NXD RR  This protection from pseudo-zone
   transfers is xxx.

5.2 NXD RDATA Format

   The RDATA for an NXD RR consists simply of a domain name.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     next domain name                                          /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3 Example

   Assume a zone has entries for

               big.foo.bar,
               medium.foo.bar.
               small.foo.bar.
               tiny.foo.bar.

   Then a query to a security aware server for huge.foo.bar would
   produce an error reply with the additional information section
   containing

        big.foo.bar. NXD medium.foo.bar.

   and bought at the corresponding SIG RR.

5.4 Interaction expense of eliminating the data origin
   authentication of the non-existence of NXD RRs and Wildcard RRs

   As a wildcard RR causes all possible names in an interval to exist,
   there should not be an NXD record that would cover any part of this
   interval.  Thus if *.X.ZONE exists you would expect NXT RRs can
   provide.  If an entire zone is covered by a wildcard, a malicious
   server can return an NXD RR that
   ends at X.ZONE produced by matching the resulting wildcard
   NXT and one that starts can thus hide all the real data and delegations with more
   specific names in the last name covered by
   *.X.ZONE.  However, this "last zone.

5.6 Special Considerations at Delegation Points

   A name covered" other than root which is something very ugly
   and long like \255\255\255....X.zone.  So the NXD for head of a zone also appears as
   the interval
   following is simply given leaf in a superzone.  If both are secure, there will always be
   two different NXT RRs with the owner name *.X.zone.  This "*" type same name.  They can be distinguished
   by their signers and next domain name is not expanded fields.  Security aware servers
   should return the correct NXT automatically when required to
   authenticate the NXD is returned as additional
   information in connection with non-existence of a name and both NXTs, if available,
   on explicit query for a non-existent name type NXT.

   Insecure servers will never automatically return an NXT and
   type.

   If there could may only
   return the NXT from the subzone on explicit queries.

6. The AD and CD Bits and How to Resolve Securely

   Retrieving or resolving authentic data from the Domain Name System
   (DNS) involves starting with one or more trusted public keys. With
   trusted keys, a browser willing to perform cryptography can progress
   securely through the secure DNS zone structure to the zone of
   interest as described in Section 6.3. Such trusted public keys would
   normally be any wildcard RRs configured in a manner similar to that described in
   Section 6.2.  However, as a zone and thus wildcard NXDs,
   care must be taken practical matter, a security aware
   resolver would still gain some confidence in interpreting the results of explicit NXD
   retrievals it returns
   even if it was not configured with any keys but trusted what it got
   from a local well known server as the owner name may be a wildcard expansion.

   The existence starting point.

   Data stored at a server needs security labels of one Authenticated,
   Pending, or more wildcard RRs covering a name interval
   makes it possible for Insecure. There is also a malicious server to hide any more specificly
   named RRs in the internal.  The server can just falsely return the
   wildcard match NXD instead fourth transient state of Bad
   which indicates that SIG checks have explicitly failed on the more specificly named RRs.  If
   there data.
   Such data is not retained at a zone wide wildcard, there will be only one NXD RR whose
   owner name and RDATA are both security aware server. Authenticated
   means that the zone name.  In this case data has a server
   could conceal the existence valid SIG under a KEY traceable via a chain
   of any zero or more specific SIG and KEY RRs in the zone.
   (It would be possible to make a more complex NXD feature, taking into
   account KEY configured at the types resolver
   via its boot file.  Pending data has no authenticated SIGs and at
   least one additional SIG the browser is still trying to authenticate.
   Insecure data is data which it is known can never be either
   authenticated or found bad because it is in a zone with no key or an
   experimental key.  Behavior in terms of RRs that did not exist control of and flagging based
   on such data labels is described in Section 6.1.

   The proper validation of signatures requires a name interval, and reasonably secure
   shared opinion of the like, which would eliminate this possibility.  But it would be
   more complex absolute time between resolvers and would be so constraining servers as to make any future
   dynamic update feature that could create new names very difficult
   (see
   described in Section 3.2).)

5.5 Blocking NXD Pseudo-Zone Transfers 6.4.

   In getting to the data of interest to respond to a secure zone, query, a secure
   resolver can query for the initial NXD associated
   with the zone name.  Using the RDATA field from that RR, it can query
   for the next NXD RR.  By repeating this, it can walk may encounter genuine non-secure zones.  It may proceed
   through all the
   NXDs in the zone.  If there are no wildcards, it can use such zones but should report this
   technique to find all names in a zone. If it does type ANY queries,
   it can incrementally get all information as described in the zone Section
   6.5.

6.1 The AD and perhaps
   defeat attempts to administratively block zone transfers.

   If there CD Header Bits

   Two unused bits are any wildcards, this NXD walking technique will not find
   any more specific RR names in the part allocated out of the name space DNS query/response format
   header.  The AD (authentic data) bit indicates in a response that the wildcard
   covers.  By doing explicit retrievals for wildcard names,
   data included has been verified by the server providing it.  The CD
   (checking disabled) bit indicates in a query that non-verified data
   is acceptable to the resolver
   could determine what intervals sending the query.

   These bits are allocated from the must-be-zero Z field as follows:

                                          1  1  1  1  1  1
            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                      ID                       |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                    QDCOUNT                    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                    ANCOUNT                    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                    NSCOUNT                    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                    ARCOUNT                    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   These bits are covered by wildcards but still
   could not, with these techniques, find any names inside such
   intervals except by trying every name.

   If it is desired to block NXD walking, zero in old servers and resolvers.  Thus the recommended method is to
   add a zone wide wildcard responses
   of old servers are not flagged as authenticated to security aware
   resolvers and queries from non-security aware resolvers do not assert
   the KEY type with the no key checking disabled bit on and
   with no type (zone, entity, or user) bit on.  This thus will cause there
   to be answered by security aware
   servers only one NXD RR in with authenticated data.  Of course security aware
   resolvers can not trust the zone for AD bit unless they trust the zone name server they
   are talking to and leak no
   information about what real names exist in the zone.  This protection
   from pseudo-zone transfers is bought at the expense of eliminating have a secure path to it.

   Any security aware resolver willing to do cryptography should assert
   the data origin authentication of CD bit on all queries to reduce DNS latency time by allowing
   security aware servers to answer before they have resolved the non-existence
   validity of names that NXD
   RRs can provide.  If an entire zone is covered by a wildcard, a
   malicious server can data.

   Security aware servers never return an RR produced bad data.  For non-security aware
   resolvers or security aware resolvers requesting service by matching the resulting
   wildcard NXD and can thus hide all the real data and delegations with
   more specific names in having
   the zone.

6. How to Resolve Securely

   Retrieving CD bit clear, security aware servers return only authenticated or resolving authentic
   insecure data from the DNS involves starting with one or more trusted public keys and, the AD bit set in general, progressing
   securely from them through the DNS zone structure to response.  Security aware
   resolvers will know that if data is insecure versus authentic by the zone
   absence of
   interest.  Such trusted public keys would normally be configured in a
   manner similar SIG RRs.  Security aware servers may return pending data
   to that described in section 6.1.  However, as a
   practical matter, a security aware resolver would still gain some
   confidence resolvers requesting the service by clearing the AD
   bit in the results it returns even if it was not configured
   with any keys but trusted what it got from a local well known server
   as response.  The AD bit may only be set on a starting point.

6.1 response if the
   RRs in the response are either authenticated or insecure.

6.2 Boot File Format

   The recommended format for a boot file line directive to configure a starting
   keys zone key
   is as follows:

        pubkey name object flags protocol algorithm [exponent modulus] key-data

   for a public key.  "object" is the domain name of the thing the key
   is associated with and  "name" is the owner name if (if the line is
   translated into a KEY RR).  Flags indicates the type of key and is
   the same as the flag byte octet in the KEY RR.  In particular, if the "no
   key" bit is on in flags, then all fields after flags algorithm  may be
   omitted.  Algorithm is the algorithm in use where one is the MD5/RSA
   algorithm and 254 indicates a private algorithm.  The material after
   the algorithm is algorithm dependent and, for private algorithms,
   starts with the algorithm's identifying OID.  For the RSA algorithm, it  It is
   the public key exponent as a decimal number between 3 and 16777215,
   and the modulus encoded in base
   64 (see Appendix).

   A file of keys for cross certification or other purposes can be
   configured though the keyfile directive as follows:

        keyfile filename

   The file looks like a master file except that it can only contain KEY
   and SIG RRs with the SIGs signed under a key configured with the
   pubkey directive.

   While it might seem logical for everyone to start with the key for
   the root zone, this has problems.  The logistics of updating every
   DNS resolver in the world when the root key changes would be
   excessive.  It may be some time before there even is a root key.
   Furthermore, many organizations will explicitly wish their "interior"
   DNS implementations to completely trust only their own zone.  These
   interior resolvers can then go through the organization's zone server
   to access data outsize the organization's domain.

6.2

6.3 Chaining Through Zones

   Starting with one or more trusted zone key, keys for a zone, it is should be
   possible to retrieve signed keys for its subzones which have a key. key
   and, if the zone is not root, for some superzone. Every authoritative
   secure zone (except root) server should also include the KEY RR for its a super-zone
   signed by the secure zone and with the owner name of the secure zone and object
   name of the super-zone. via a keyfile directive. This makes it
   possible to climb the tree of zones if one starts below root.  A
   secure sub-zone is indicated by a KEY RR appearing with the NS RRs
   for the sub-zone and with the same
   owner and object names. sub-zone.  These make it possible to descend within the tree
   of zones.

   A resolver should keep track of the number of successive secure zones
   traversed from a starting point to any secure zone it can reach.  In
   general, the lower such a distance number is, the greater the
   confidence in the data.  Data configured via a boot file directive
   should be given a distance number of zero.  Should a query encounter
   different data for the same query with different distance values,
   that with a larger value should be ignored.

   A security conscious resolver should completely refuse to step from a
   secure zone into a non-secure zone unless the non-secure zone is
   certified to be non-secure or only experimentally secure by the
   presence of an authenticated KEY RR for the non-secure zone with a no
   key flag or the presence of a KEY RR with the experimental bit set.
   Otherwise the resolver is probably getting completely bogus or
   spoofed data.

   If legitimate non-secure zones are encountered in traversing the DNS
   tree, then no zone can be trusted as secure that can be reached only
   via information from such non-secure zones. Since the non-secure zone
   data could have been spoofed, the "secure" zone reach via it could be
   counterfeit.  The "distance" to data in such zones or zones reached
   via such zones could be set to 512 or more as this exceeds the
   largest possible distance through secure zones in the DNS.
   Nevertheless, continuing to apply secure checks within "secure" zones
   reached via non-secure zones will, as a practical matter, provide
   some increase in security.

   The syntax of KEY RRs, with an arbitrary object name, provides for
   cross-certification.  Although the syntax permits the owner name of a
   cross-certification KEY RR to be any name, by convention and to avoid
   an undue concentration of such KEY RRs under any particular name,
   their owner name should be the zone name prefixed with the
   destination object name (truncated an integral number of labels from
   the front if necessary due to DNS name restrictions).  Thus a key for
   isoc.org would appear in the mit.edu zone with the owner name
   isoc.org.mit.edu and object name isoc.org.

   The existence of cross certifications adds further policy questions.
   Assume we have a zone B.A and a zone Y.X.  Many possibilities exist
   for a secure resolver configured with the B.A key to get to Y.X.  If
   all the zones along the way are secure, it could climb to root and
   then descend the other side, a total of four hops (B.A -> A -> . -> X
   -> Y.X).  If the B.A administrator had installed a cross certified
   key for Y.X in the B.A zone, using that would be a shorter and
   presumably more secure way to find Y.X's key which would be immune to
   the non-security or even compromise of the servers for A or root or
   X.  But what if some less trusted subzone of B.A, say flakey.B.A
   installed a cross certified key for Y.X?  If there is a conflict,
   should this be preferred to a hierarhically derived key obtained by
   climbing to root and descending?  Such questions are entirely a
   matter of local resolver policy.

6.3

6.4 Secure Time

   Coordinated interpretation of the time fields in SIG RRs requires
   that reasonably consistent time be available to the hosts
   implementing the DNS security extensions.

   A variety of time synchronization protocols exist including the
   Network Time Protocol (NTP, RFC1305).  If such protocols are used,
   they should be used securely so that time can not be spoofed.
   Otherwise, for example, a host could get its clock turned back and
   might then believe old SIG and KEY RRs which were valid but no longer
   are.

7. Operational Considerations

   This section discusses a variety of considerations in secure
   operation of DNS the Domain Name System (DNS) using these proposed
   protocol extensions.

7.1 Key Size Considerations

   There are a number of factors that effect public key size choice for
   use in the DNS security extension.  Unfortunately, these factors
   usually do not all point in the same direction.  Choice of a zone key
   size should generally be made by the zone administrator depending on
   their local conditions.

   For most schemes, larger keys are more secure but slower.
   Verification  Given a
   small public exponent, verification (the most common operation) for
   the MD5/RSA algorithm will vary roughly with the square of the
   modulus length, signing will vary with the cube of the modulus
   length, and key generation (the least common operation) will vary
   with the fourth power of the modulus length.  The current best
   algorithms for factoring a modulus and breaking RSA security vary
   roughly with the square of the modulus itself.  Thus going from a 640
   bit modulus to a 1280 bit modulus only increases the verification
   time by a factor of 4 but vastly increases the work factor of breaking the key.  [RSA FAQ]
   key by over 2^3000.  [RSA FAQ] An upper bound of 2552 bit has been
   established for the MD4/RSA DNS security algorithm for
   interoperability purposes.

   However, larger keys increase size of the KEY and SIG RRs.  This
   increases the chance of DNS UDP packet overflow and the possible
   necessity for using higher overhead TCP. TCP in responses.

   The recommended minimum RSA algorithm modulus size, 640 bits, is
   believed by the authors to be secure at this time and for some years
   but high level zones in the DNS tree may wish to set a higher
   minimum, perhaps 1000 bits, for security reasons.  (Since the United
   States National Security Agency generally permits export of
   encryption systems using an RSA modulus of up to 512 bits, use of
   that small a modulus, i.e. n, must be considered weak.)

   For a key used only to secure data and not to secure other keys, 640
   bits should be entirely adequate.

7.2 Key Storage

   It is strongly recommended that zone private keys and the zone file
   master copy be kept and used in off-line non-network connected
   physically secure machines only.  Periodically an application can be
   run to re-sign the RRs in a zone by adding NXD NXT and SIG RRs.  Then the
   augmented file can be transferred, perhaps by sneaker-net, to the
   networked zone primary server machine.

   The idea is to have a one way information flow to the network to
   avoid the possibility of tampering from the network.  Keeping the
   zone master file on-line on the network and simply cycling it through
   an off-line signer does not do this.  The on-line version could still
   be tampered with if the host it resides on is compromised.  The  For
   maximum security, the master copy of the zone file should be off net
   and should not be updated based on an unsecured network mediated
   communication.

   Note, however, that secure resolvers need to be configured with some
   trusted on-line public key information (or a secure path to such a
   resolver).

   Non-zone private keys, such as host or user keys, may have to be kept
   on line to be used for real-time purposes such a IP secure IPSEC session set-up
   or secure mail.

7.3 Key Generation

   Careful key generation is a sometimes over looked but absolutely
   essential element in any cryptographically secure system.  The
   strongest algorithms used with the longest keys are still of no use
   if an adversary can guess enough to lower the size of the likely key
   space so that it can be exhaustively searched.  Suggestions will be
   found in draft-ietf-security-randomness-*.txt. RFC 1750.

   It is strongly recommended that key generation also occur off-line,
   perhaps on the machine used to sign zones (see Section 7.2).

7.4 Key Lifetimes

   No key should be used forever.  The longer a key is in use, the
   greater the probability that it will have been compromised through
   carelessness, accident, espionage, or cryptanalysis.

   No  Furthermore, if
   key rollover is a rare event, there is an increased risk that, when
   the time does come up change the key, no one at the site will
   remember how to do it or other problems will have developed in the
   procedures.

   While key lifetime is a matter of local policy, these considerations
   suggest that no zone key should have a lifetime significantly over five
   four years.
   The recommended  A reasonable maximum lifetime for zone keys that are
   kept off-line and carefully guarded is 13 months with the intent that
   they be replaced every year.  The recommended  A reasonable maximum lifetime for end
   entity keys that are used for IP-security or the like and are kept on
   line is 36 days with the intent that they be replaced monthly or more
   often.  In some cases, an entity key lifetime of a little somewhat over a day
   may be reasonable.

   Key lifetimes significantly over a year increase the risk that, when
   the time comes up change the key, no one at the site will remember
   how to do it.

7.5 Signature Lifetime

   Signature expiration times must be set far enought enough in the future that
   it is quite certain that new signatures can be generated before the
   old ones expire.  However, setting expiration too far into the future
   could, if bad data or signatures were ever generated, mean a long
   time to flush such badness.

   It is recommended that signature lifetime be a small multiple of the
   TTL but not less than a reasonable re-signing interval.

7.6 Root

   It should be noted that in DNS the root is a zone unto itself.  Thus
   the root zone key should only be see seen signing itself or signing RRs
   with names one level below root, such as .aq, .edu, or .arpa.
   Implementations MAY reject as bogus any purported root signature of
   records with a name more than one level below root.

8. Conformance

   Several levels of server and resolver conformance are defined.

8.1 Server Conformance

   Three

   Two levels of server conformance are defined as follows:

        Basic

        Minimal server compliance is the ability to store and retrieve
   (including zone transfer) SIG, KEY, and NXD NXT RRs.  Secondaries  Any secondary,
   caching, or other server for a secure zone must be at least basicly compliant.

        Medium minimally
   compliant and even then some things, such as secure CNAMEs, will not
   work.

        Full server compliance adds the following to basic compliance:
   (1) ability to read SIG, KEY, and NXD NXT RRs in zone files and (2)
   ability, given a zone file and private key, to add appropriate SIG
   and NXD NXT RRs, possibly via a separate application.  Primary servers
   for secure zones must be at least minimally compliant.

        Full server compliance is ability to automatically include application, (3) proper
   automatic inclusion of SIG, KEY, and NXD NXT RRs in responses responses, (4)
   suppression of CNAME following on retrieval of the security type RRs,
   (5) recognize the CD query header bit and set the AD query header
   bit, as appropriate, and (6) proper handling of the two NXT RRs at
   delegation points.  Primary servers for secure zones MUST be fully
   compliant and for completely successful secure operation, all
   secondary, caching, and other servers handling the zone should be
   fully compliant as well as meeting
   medium compliance. well.

8.2 Resolver Conformance

   Two levels of resolver compliance are defined:

        A basic compliance resolver can handle SIG, KEY, and NXD NXT RRs
   when they are explicitly requested.

        A fully compliant resolver (1) understands KEY, SIG, and NXD NXT
   RRs, (2) maintains appropriate information in its local caches and
   database to indicate which RRs have been authenticated and to what
   extent they have been authenticated, and (3) performs additional queries
   as necessary to attempt to obtain KEY, SIG, or NXD NXT RRs from non-security non-
   security aware servers. servers, (4) normally sets the CD query header bit on
   its queries.

9. Security Considerations

   This document concerns technical details of extensions to the Domain
   Name System (DNS) protocol to provide data integrity and data origin
   authentication, public key distribution, and optional transaction
   security.

   If should be noted that, at most, these extensions guarantee the
   validity of resource records, including KEY resource records,
   retrieved from the DNS.  They do not magically solve other security
   problems.  For example, using secure DNS you can have high confidence
   in the IP address you retrieve for a host; however, this does not
   stop someone for substituting an unauthorized host at that address or
   capturing packets sent to that address and responding with packets
   apparently from that address.  Any reasonably complete security
   system will require the protection of many other facets of the
   Internet.

References

   [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc.,
   3 June 1991, Version 1.4.

   [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987

   [RFC1033] - Domain Administrators Operations Guide, M. Lottor,
   November 1987

   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
   November 1987

   [RFC1035] - Domain Names - Implementation and Specifications

   [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992.

   [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16
   1992.

   [RFC1750] - Randomness Requirements for Security, D. Eastlake, S.
   Crocker, J. Schiller, December 1994.

   [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.

Authors Addresses

   Donald E. Eastlake, 3rd
   Digital Equipment Corporation
   550 King Street, LKG2-1/BB3
   Littleton,
   CyberCash, Inc.
   318 Acton Street
   Carlisle, MA 01460 01741 USA

   Telephone:   +1 508 486 6577(w)  +1 508 287 4877(h) 4877
   EMail:       dee@lkg.dec.com       dee@cybercash.com

   Charles W. Kaufman
   Iris Associates
   1 Technology Park Drive
   Westford, MA 01886 USA

   Telephone:   +1 508-392-5276
   EMail:       charlie_kaufman@iris.com

Expiration and File Name

   This draft expires 1 July 24 December 1995.

   Its file name is draft-ietf-dnssec-secext-03.txt. draft-ietf-dnssec-secext-04.txt.

Appendix: Base 64 Encoding

   The following encoding technique is taken from RFC 1521 by Borenstein
   and Freed.  It is reproduced here in a slightly an edited form for convenience.

   A 65-character subset of US-ASCII is used, enabling 6 bits to be
   represented per printable character. (The extra 65th character, "=",
   is used to signify a special processing function.)

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters. Proceeding from left to right, a
   24-bit input group is formed by concatenating 3 8-bit input groups.
   These 24 bits are then treated as 4 concatenated 6-bit groups, each
   of which is translated into a single digit in the base64 alphabet.

   Each 6-bit group is used as an index into an array of 64 printable
   characters. The character referenced by the index is placed in the
   output string.

                         Table 1: The Base64 Alphabet

      Value Encoding  Value Encoding  Value Encoding  Value Encoding
          0 A            17 R            34 i            51 z
          1 B            18 S            35 j            52 0
          2 C            19 T            36 k            53 1
          3 D            20 U            37 l            54 2
          4 E            21 V            38 m            55 3
          5 F            22 W            39 n            56 4
          6 G            23 X            40 o            57 5
          7 H            24 Y            41 p            58 6
          8 I            25 Z            42 q            59 7
          9 J            26 a            43 r            60 8
         10 K            27 b            44 s            61 9
         11 L            28 c            45 t            62 +
         12 M            29 d            46 u            63 /
         13 N            30 e            47 v
         14 O            31 f            48 w         (pad) =
         15 P            32 g            49 x
         16 Q            33 h            50 y

   Special processing is performed if fewer than 24 bits are available
   at the end of the data being encoded.  A full encoding quantum is
   always completed at the end of a quantity.  When fewer than 24 input
   bits are available in an input group, zero bits are added (on the
   right) to form an integral number of 6-bit groups.  Padding at the
   end of the data is performed using the '=' character.  Since all
   base64 input is an integral number of octets, only the following
   cases can arise: (1) the final quantum of encoding input is an
   integral multiple of 24 bits; here, the final unit of encoded output
   will be an integral multiple of 4 characters with no "=" padding, (2)
   the final quantum of encoding input is exactly 8 bits; here, the
   final unit of encoded output will be two characters followed by two
   "=" padding characters, or (3) the final quantum of encoding input is
   exactly 16 bits; here, the final unit of encoded output will be three
   characters followed by one "=" padding character.