Network Working Group
`
`Request for Comments: 2535
`Obsoletes: 2065
`
`Updates: 2181, 1035, 1034
`
`Category: Standards Track
`
`D. Eastlake
`
`IBM
`March 1999
`
`Domain Name System Security Extensions
`
`Status of this Memo
`
`This document specifies an Internet standards track protocol for the
`
`Internet community, and requests discussion and suggestions for
`improvements. Please refer to the current edition of the "Internet
`Official Protocol Standards" (STD 1) for the standardization state
`
`and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
`Copyright
`
`(C) The Internet Society (1999). All Rights Reserved.
`
`Abstract
`
`Extensions to the Domain Name System (DNS) are described that provide
`data integrity and authentication to security aware resolvers and
`
`applications through the use of cryptographic digital signatures.
`
`These digital signatures are included in secured zones as resource
`
`records. Security can also be provided through non—security aware
`DNS servers in some cases.
`
`The extensions provide for the storage of authenticated public keys
`
`in the DNS. This storage of keys can support general public key
`
`distribution services as well as DNS security.
`
`The stored keys
`
`enable security aware resolvers to learn the authenticating key of
`
`zones in addition to those 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 and requests.
`
`This document incorporates feedback on RFC 2065 from early
`
`implementers and potential users.
`
`Page1 of94
`
`VIRNETX EXHIBIT 2011
`
`Apple v. Virnetx
`Case |PR2013-00354
`
`VIRNETX EXHIBIT 2011
`Apple v. Virnetx
`Case IPR2013-00354
`
`

`

`Eastlake Standards Track [Page 1]
`
`Page 2 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
`Acknowledgments
` The significant contributions and suggestions of the following
` persons (in alphabetic order) to DNS security are gratefully
` acknowledged:
` James M. Galvin
` John Gilmore
` Olafur Gudmundsson
` Charlie Kaufman
` Edward Lewis
` Thomas Narten
` Radia J. Perlman
` Jeffrey I. Schiller
` Steven (Xunhua) Wang
` Brian Wellington
`Table of Contents
` Abstract...................................................1
` Acknowledgments............................................2
` 1. Overview of Contents....................................4
` 2. Overview of the DNS Extensions..........................5
` 2.1 Services Not Provided..................................5
` 2.2 Key Distribution.......................................5
` 2.3 Data Origin Authentication and Integrity...............6
` 2.3.1 The SIG Resource Record..............................7
` 2.3.2 Authenticating Name and Type Non-existence...........7
` 2.3.3 Special Considerations With Time-to-Live.............7
` 2.3.4 Special Considerations at Delegation Points..........8
` 2.3.5 Special Considerations with CNAME....................8
` 2.3.6 Signers Other Than The Zone..........................9
` 2.4 DNS Transaction and Request Authentication.............9
` 3. The KEY Resource Record................................10
` 3.1 KEY RDATA format......................................10
` 3.1.1 Object Types, DNS Names, and Keys...................11
` 3.1.2 The KEY RR Flag Field...............................11
` 3.1.3 The Protocol Octet..................................13
` 3.2 The KEY Algorithm Number Specification................14
` 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
` 3.4 Determination of Zone Secure/Unsecured Status.........15
` 3.5 KEY RRs in the Construction of Responses..............17
` 4. The SIG Resource Record................................17
` 4.1 SIG RDATA Format......................................17
` 4.1.1 Type Covered Field..................................18
` 4.1.2 Algorithm Number Field..............................18
` 4.1.3 Labels Field........................................18
` 4.1.4 Original TTL Field..................................19
`
`Page 3 of 94
`
`

`

`Eastlake Standards Track [Page 2]
`
`Page 4 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` 4.1.5 Signature Expiration and Inception Fields...........19
` 4.1.6 Key Tag Field.......................................20
` 4.1.7 Signer's Name Field.................................20
` 4.1.8 Signature Field.....................................20
` 4.1.8.1 Calculating Transaction and Request SIGs..........21
` 4.2 SIG RRs in the Construction of Responses..............21
` 4.3 Processing Responses and SIG RRs......................22
` 4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
` 5. Non-existent Names and Types...........................24
` 5.1 The NXT Resource Record...............................24
` 5.2 NXT RDATA Format......................................25
` 5.3 Additional Complexity Due to Wildcards................26
` 5.4 Example...............................................26
` 5.5 Special Considerations at Delegation Points...........27
` 5.6 Zone Transfers........................................27
` 5.6.1 Full Zone Transfers.................................28
` 5.6.2 Incremental Zone Transfers..........................28
` 6. How to Resolve Securely and the AD and CD Bits.........29
` 6.1 The AD and CD Header Bits.............................29
` 6.2 Staticly Configured Keys..............................31
` 6.3 Chaining Through The DNS..............................31
` 6.3.1 Chaining Through KEYs...............................31
` 6.3.2 Conflicting Data....................................33
` 6.4 Secure Time...........................................33
` 7. ASCII Representation of Security RRs...................34
` 7.1 Presentation of KEY RRs...............................34
` 7.2 Presentation of SIG RRs...............................35
` 7.3 Presentation of NXT RRs...............................36
` 8. Canonical Form and Order of Resource Records...........36
` 8.1 Canonical RR Form.....................................36
` 8.2 Canonical DNS Name Order..............................37
` 8.3 Canonical RR Ordering Within An RRset.................37
` 8.4 Canonical Ordering of RR Types........................37
` 9. Conformance............................................37
` 9.1 Server Conformance....................................37
` 9.2 Resolver Conformance..................................38
` 10. Security Considerations...............................38
` 11. IANA Considerations...................................39
` References................................................39
` Author's Address..........................................41
` Appendix A: Base 64 Encoding..............................42
` Appendix B: Changes from RFC 2065.........................44
` Appendix C: Key Tag Calculation...........................46
` Full Copyright Statement..................................47
`
`Page 5 of 94
`
`

`

`Eastlake Standards Track [Page 3]
`
`Page 6 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
`1. Overview of Contents
` This document standardizes extensions of the Domain Name System (DNS)
` protocol to support DNS security and public key distribution. It
` assumes that the reader is familiar with the Domain Name System,
` particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
` earlier version of these extensions appears in RFC 2065. This
` replacement for that RFC incorporates early implementation experience
` and requests from potential users.
` Section 2 provides an overview of the extensions and the key
` distribution, data origin authentication, and transaction and request
` security they provide.
` Section 3 discusses the KEY resource record, its structure, and use
` in DNS responses. These resource records represent the public keys
` of entities named in the DNS and are used for key distribution.
` Section 4 discusses the SIG digital signature resource record, its
` structure, and use in DNS responses. These resource records are used
` to authenticate other resource records in the DNS and optionally to
` authenticate DNS transactions and requests.
` Section 5 discusses the NXT resource record (RR) and its use in DNS
` responses including full and incremental zone transfers. The NXT RR
` permits authenticated denial of the existence of a name or of an RR
` type for 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 various
` combinations of security aware and security non-aware. Two
` additional DNS header bits are defined for signaling between
` resolvers and servers.
` Section 7 describes the ASCII representation of the security resource
` records for use in master files and elsewhere.
` Section 8 defines the canonical form and order of RRs for DNS
` security purposes.
` Section 9 defines levels of conformance for resolvers and servers.
` Section 10 provides a few paragraphs on overall security
` considerations.
` Section 11 specified IANA considerations for allocation of additional
` values of paramters defined in this document.
`
`Page 7 of 94
`
`

`

`Eastlake Standards Track [Page 4]
`
`Page 8 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` Appendix A gives details of base 64 encoding which is used in the
` file representation of some RRs defined in this document.
` Appendix B summarizes changes between this memo and RFC 2065.
` Appendix C specified how to calculate the simple checksum used as a
` key tag in most SIG RRs.
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in [RFC2119].
`2. Overview of the DNS 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 and request 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.
` No effort has been made to provide for any confidentiality for
` queries or responses. (This service may be available via IPSEC [RFC
` 2401], TLS, or other security protocols.)
` Protection is not provided against denial of service.
`2.2 Key Distribution
` A resource record format is defined to associate keys with DNS names.
` This permits the DNS to be used as a public key distribution
` mechanism in support of DNS security itself and other protocols.
` The syntax of a KEY resource record (RR) is described in Section 3.
` It includes an algorithm identifier, the actual public key
` parameter(s), and a variety of flags including those indicating the
` type of entity the key is associated with and/or asserting that there
` is no key associated with that entity.
`
`Page 9 of 94
`
`

`

`Eastlake Standards Track [Page 5]
`
`Page 10 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` Under conditions described in Section 3.5, security aware DNS servers
` will automatically attempt to return KEY resources as additional
` information, along with those resource records actually requested, to
` minimize the number of queries needed.
`2.3 Data Origin Authentication and Integrity
` Authentication is provided by associating with resource record sets
` (RRsets [RFC 2181]) in the DNS cryptographically generated digital
` signatures. Commonly, there will be a single private key that
` authenticates an entire zone but there might be multiple keys for
` different algorithms, signers, etc. If a security aware resolver
` reliably learns a public key of the zone, it can authenticate, for
` signed data read from that zone, that it is properly authorized. The
` most secure implementation is for the zone private key(s) to be kept
` off-line and used to re-sign all of the records in the zone
` periodically. However, there are cases, for example dynamic update
` [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
` 2541].
` The data origin authentication key(s) are associated with the zone
` and not with the servers that store copies of the data. That means
` compromise of a secondary server or, if the key(s) are kept off line,
` even the primary server for a zone, will not necessarily affect the
` degree of assurance that a resolver has that it can determine whether
` data is genuine.
` A resolver could learn a public key of a zone either by reading it
` from the DNS or by having it staticly configured. To reliably learn
` a public key by reading it from the DNS, the key itself must be
` signed with a key the resolver trusts. The resolver must be
` configured with at least a public key which authenticates one zone as
` a starting point. From there, it can securely read public keys of
` other zones, if the intervening zones in the DNS tree are secure and
` their signed keys accessible.
` Adding data origin authentication and integrity requires no change to
` the "on-the-wire" DNS protocol beyond the addition of the signature
` resource type and the key resource type needed for key distribution.
` (Data non-existence authentication also requires the NXT RR as
` described in 2.3.2.) This service can be supported by existing
` resolver and caching server implementations so long as they can
` support the additional resource types (see Section 9). The one
` exception is that CNAME referrals in a secure zone can not be
` authenticated if they are from non-security aware servers (see
` Section 2.3.5).
`
`Page 11 of 94
`
`

`

`Eastlake Standards Track [Page 6]
`
`Page 12 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` If signatures are separately retrieved and verified when retrieving
` the information they authenticate, there will be more trips to the
` server and performance will suffer. Security aware servers mitigate
` that degradation by attempting to send the signature(s) needed (see
` Section 4.2).
`2.3.1 The SIG Resource Record
` The syntax of a SIG resource record (signature) is described in
` Section 4. It cryptographicly binds the RRset being signed to the
` signer and a validity interval.
` Every name in a secured zone will have associated with it at least
` one SIG resource record for each resource type under that name except
` for glue address RRs and delegation point NS RRs. A security aware
` server will attempt to return, with RRs retrieved, the corresponding
` SIGs. If a server is not security aware, the resolver must retrieve
` all the SIG records for a name and select the one or ones that sign
` the resource record set(s) that resolver is interested in.
`2.3.2 Authenticating Name and Type Non-existence
` The above security mechanism only provides a way to sign existing
` RRsets in a zone. "Data origin" authentication is not obviously
` provided for the non-existence of a domain name in a zone or the
` non-existence of a type for an existing name. This gap is filled by
` the NXT RR which authenticatably asserts a range of non-existent
` names in a zone and the non-existence of types for the existing name
` just before that range.
` Section 5 below covers the NXT RR.
`2.3.3 Special 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 (TTL) field of resource records tick down while they are
` cached.
` This could be avoided by leaving the time-to-live out of the digital
` signature, but that would allow unscrupulous servers to set
` arbitrarily long TTL values undetected. Instead, we include the
` "original" TTL in the signature and communicate that data along with
` the current TTL. Unscrupulous servers under this scheme can
` manipulate the TTL but a security aware resolver will bound the TTL
` value it uses at the original signed value. Separately, signatures
` include a signature inception time and a signature expiration time. A
`
`Page 13 of 94
`
`

`

`Eastlake Standards Track [Page 7]
`
`Page 14 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` resolver that knows the absolute time can determine securely whether
` a signature is in effect. It is not possible to rely solely on the
` signature expiration as a substitute for the TTL, however, since the
` TTL is primarily a database consistency mechanism and non-security
` aware servers that depend on TTL must still be supported.
`2.3.4 Special Considerations at Delegation Points
` DNS security would like to view each zone as a unit of data
` completely under the control of the zone owner with each entry
` (RRset) signed by a special private key held by the zone manager.
` But the DNS protocol views the leaf nodes in a zone, which are also
` the apex nodes of a subzone (i.e., delegation points), as "really"
` belonging to the subzone. These nodes occur in two master files and
` might have RRs signed by both the upper and lower zone's keys. A
` retrieval could get a mixture of these RRs and SIGs, especially since
` one server could be serving both the zone above and below a
` delegation point. [RFC 2181]
` There MUST be a zone KEY RR, signed by its superzone, for every
` subzone if the superzone is secure. This will normally appear in the
` subzone and may also be included in the superzone. But, in the case
` of an unsecured subzone which can not or will not be modified to add
` any security RRs, a KEY declaring the subzone to be unsecured MUST
` appear with the superzone signature in the superzone, if the
` superzone is secure. For all but one other RR type the data from the
` subzone is more authoritative so only the subzone KEY RR should be
` signed in the superzone if it appears there. The NS and any glue
` address RRs SHOULD only be signed in the subzone. The SOA and any
` other RRs that have the zone name as owner should appear only in the
` subzone and thus are signed only there. The NXT RR type is the
` exceptional case that will always appear differently and
` authoritatively in both the superzone and subzone, if both are
` secure, as described in Section 5.
`2.3.5 Special Considerations with CNAME
` There is a problem when security related RRs with the same owner name
` as a CNAME RR are retrieved from a non-security-aware server. In
` particular, an initial retrieval for the CNAME or any other type may
` not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
` other than CNAME, it will retrieve that type at the target name of
` the CNAME (or chain of CNAMEs) and will also return the CNAME. In
` particular, a specific retrieval for type SIG will not get the SIG,
` if any, at the original CNAME domain name but rather a SIG at the
` target name.
`
`Page 15 of 94
`
`

`

`Eastlake Standards Track [Page 8]
`
`Page 16 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` Security aware servers must be used to 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 type CNAME, and (3)
` automatically return SIG RRs authenticating the CNAME or CNAMEs
` encountered in resolving a query. This is a change from the previous
` DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
` node where a CNAME RR was present.
`2.3.6 Signers Other Than The Zone
` There are cases where the signer in a SIG resource record is other
` than one of the private key(s) used to authenticate a zone.
` One is for support of dynamic update [RFC 2136] (or future requests
` which require secure authentication) where an entity is permitted to
` authenticate/update its records [RFC 2137] and the zone is operating
` in a mode where the zone key is not on line. The public key of the
` entity must be present in the DNS and be signed by a zone level key
` but the other RR(s) may be signed with the entity's key.
` A second case is support of transaction and request authentication as
` described in Section 2.4.
` In additions, signatures can be included on resource records within
` the DNS for use by applications other than DNS. DNS related
` signatures authenticate that data originated with the authority of a
` zone owner or that a request or transaction originated with the
` relevant entity. Other signatures can provide other types of
` assurances.
`2.4 DNS Transaction and Request Authentication
` The data origin authentication service described above protects
` retrieved resource records and the non-existence of resource records
` but provides no protection for DNS requests or for message headers.
` If header bits are falsely set by a bad 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 at least getting messages from the server it thinks it
` queried and that the response is from the query it sent (i.e., that
` these messages have not been diddled in transit). This is
` accomplished by optionally adding a special SIG resource record at
` the end of the reply which digitally signs the concatenation of the
` server's response and the resolver's query.
`
`Page 17 of 94
`
`

`

`Eastlake Standards Track [Page 9]
`
`Page 18 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` Requests can also be authenticated by including a special SIG RR at
` the end of the request. Authenticating requests serves no function
` in older DNS servers and requests with a non-empty additional
` information section produce error returns or may even be ignored by
` many of them. However, this syntax for signing requests is defined as
` a way of authenticating secure dynamic update requests [RFC 2137] or
` future requests requiring authentication.
` The private keys used in transaction security belong to the entity
` composing the reply, not to the zone involved. Request
` authentication may also involve the private key of the host or other
` entity composing the request or other private keys depending on the
` request authority it is sought to establish. The corresponding public
` key(s) are normally stored in and retrieved from the DNS for
` verification.
` Because requests and replies are highly variable, message
` authentication SIGs can not be pre-calculated. Thus it will be
` necessary to keep the private key on-line, for example in software or
` in a directly connected piece of hardware.
`3. The KEY Resource Record
` The KEY resource record (RR) is used to store a public key that is
` associated with a Domain Name System (DNS) name. This can be the
` public key of a zone, a user, or a host or other end entity. Security
` aware DNS implementations MUST be designed to handle at least two
` simultaneously valid keys of the same type associated with the same
` name.
` The type number for the KEY RR is 25.
` A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs
` must be signed by a zone level key.
`3.1 KEY RDATA format
` The RDATA for a KEY RR consists of flags, a protocol octet, the
` algorithm number octet, and the public key itself. The format is as
` follows:
`
`Page 19 of 94
`
`

`

`Eastlake Standards Track [Page 10]
`
`Page 20 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` 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 KEY RR is not intended for storage of certificates and a separate
` certificate RR has been developed for that purpose, defined in [RFC
` 2538].
` The meaning of the KEY RR owner name, flags, and protocol octet are
` described in Sections 3.1.1 through 3.1.5 below. The flags and
` algorithm must be examined before any data following the algorithm
` octet as they control the existence and format of any following data.
` The algorithm and public key fields are described in Section 3.2.
` The format of the public key is algorithm dependent.
` KEY RRs do not specify their validity period but their authenticating
` SIG RR(s) do as described in Section 4 below.
`3.1.1 Object Types, DNS Names, and Keys
` The public key in a KEY RR is for the object named in the owner name.
` A DNS name may refer to three different categories of things. For
` example, foo.host.example could be (1) a zone, (2) a host or other
` end entity , or (3) the mapping into a DNS name of the user or
` account foo@host.example. Thus, there are flag bits, as described
` below, in the KEY RR to indicate with which of these roles the owner
` name and public key are associated. Note that an appropriate zone
` KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
` occur only at delegation points.
`3.1.2 The KEY RR Flag Field
` In the "flags" field:
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
` | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
` +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
` Bit 0 and 1 are the key "type" bits whose values have the following
` meanings:
`
`Page 21 of 94
`
`

`

`Eastlake Standards Track [Page 11]
`
`Page 22 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` 10: Use of the key is prohibited for authentication.
` 01: Use of the key is prohibited for confidentiality.
` 00: Use of the key for authentication and/or confidentiality
` is permitted. Note that DNS security makes use of keys
` for authentication only. Confidentiality use flagging is
` provided for use of keys in other protocols.
` Implementations not intended to support key distribution
` for confidentiality MAY require that the confidentiality
` use prohibited bit be on for keys they serve.
` 11: If both bits are one, the "no key" value, there is no key
` information and the RR stops after the algorithm octet.
` By the use of this "no key" value, a signed KEY RR can
` authenticatably assert that, for example, a zone is not
` secured. See section 3.4 below.
` Bits 2 is reserved and must be zero.
` Bits 3 is reserved as a flag extension bit. If it is a one, a second
` 16 bit flag field is added after the algorithm octet and
` before the key data. This bit MUST NOT be set unless one or
` more such additional bits have been defined and are non-zero.
` Bits 4-5 are reserved and must be zero.
` Bits 6 and 7 form a field that encodes the name type. Field values
` have the following meanings:
` 00: indicates that this is a key associated with a "user" or
` "account" at an end entity, usually a host. The coding
` of the owner name is that used for the responsible
` individual mailbox in the SOA and RP RRs: 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.example could have a public key associated
` through a KEY RR with name
` j_random_user.host.subdomain.example. It could be used
` in a security protocol where authentication of a user was
` desired. This key might be useful in IP or other
` security for a user level service such a telnet, ftp,
` rlogin, etc.
` 01: indicates that this is a zone key for the zone whose name
` is the KEY RR owner name. This is the public key used
` for the primary DNS security feature of data origin
` authentication. Zone KEY RRs occur only at delegation
` points.
` 10: 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
`
`Page 23 of 94
`
`

`

`Eastlake Standards Track [Page 12]
`
`Page 24 of 94
`
`

`

`
`RFC 2535 DNS Security Extensions March 1999
`
` tree, be some other type of entity such as a telephone
` number [RFC 1530] or numeric IP address. This is the
` public key used in connection with DNS request and
` transaction authentication services. It could also be
` used in an IP-security protocol where authentication at
` the host, rather than user, level was desired, such as
` routing, NTP, etc.
` 11: reserved.
` Bits 8-11 are reserved and must be zero.
` Bits 12-15 are the "signatory" field. If non-zero, they indicate
` that the key can validly sign things as specified in DNS
` dynamic update [RFC 2137]. Note that zone keys (see bits
` 6 and 7 above) always have authority to sign any RRs in
` the zone regardless of the value of the signatory field.
`3.1.3 The Protocol Octet
` It is anticipated that keys stored in DNS will be used in conjunction
` with a variety of Internet protocols. It is intended that the
` protocol octet and possibly some of the currently unused (must be
` zero) bits in the KEY RR flags as specified in the future will be
` used to indicate a key's validity for different protocols.
` The following values of the Protocol Octet are reserved as indicated:
` VALUE Protocol
` 0 -reserved
` 1 TLS
` 2 email
` 3 dnssec
` 4 IPSEC
` 5-254 - available for assignment by IANA
` 255 All
` In more detail:
` 1 is reserved for use in connection with TLS.
` 2 is reserved for use in connection with email.
` 3 is used for DNS security. The protocol field SHOULD be set to
` this value for zone keys and other keys used in DNS security.
` Implementations that can determine that a key is a DNS
` security key by the fact that flags label it a zone key or the
` signatory flag field is non-zero are NOT REQUIRED to check the
` protocol field.
` 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
` and indicates that this key is valid for use in conjunction
`
`Page 25 of 94
`
`

`

`Eastlake Standards Track [Page 13]
`
`Page 26 of 94
`
`

`

`
`RFC 2535