throbber
Network Working Group D. Eastlake
`Request for Comments: 2535 IBM
`Obsoletes: 2065 March 1999
`Updates: 2181, 1035, 1034
`Category: Standards Track
`
` 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.
`
`Eastlake Standards Track [Page 1]
`
`MANGROVE 1016
`
`

`
`
`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
`
`Eastlake Standards Track [Page 2]
`
`MANGROVE 1016
`
`

`
`
`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
`
`Eastlake Standards Track [Page 3]
`
`MANGROVE 1016
`
`

`
`
`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.
`
`Eastlake Standards Track [Page 4]
`
`MANGROVE 1016
`
`

`
`
`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.
`
`Eastlake Standards Track [Page 5]
`
`MANGROVE 1016
`
`

`
`
`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).
`
`Eastlake Standards Track [Page 6]
`
`MANGROVE 1016
`
`

`
`
`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
`
`Eastlake Standards Track [Page 7]
`
`MANGROVE 1016
`
`

`
`
`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.
`
`Eastlake Standards Track [Page 8]
`
`MANGROVE 1016
`
`

`
`
`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.
`
`Eastlake Standards Track [Page 9]
`
`MANGROVE 1016
`
`

`
`
`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:
`
`Eastlake Standards Track [Page 10]
`
`MANGROVE 1016
`
`

`
`
`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:
`
`Eastlake Standards Track [Page 11]
`
`MANGROVE 1016
`
`

`
`
`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
`
`Eastlake Standards Track [Page 12]
`
`MANGROVE 1016
`
`

`
`
`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
`
`Eastlake Standards Track [Page 13]
`
`MANGROVE 1016
`
`

`
`
`RFC 2535 DNS Security Extensions March 1999
`
` with that security standard

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket