draft-ietf-dnssec-secext2-00.txt   draft-ietf-dnssec-secext2-01.txt 
DNS Security Working Group Donald E. Eastlake 3rd DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT CyberCash
OBSOLETES RFC 2065 OBSOLETES RFC 2065
UPDATES RFC 1034, 1035 UPDATES RFC 1034, 1035
Expires: 22 February 1998 23 August 1997
Domain Name System Security Extensions Domain Name System Security Extensions
------ ---- ------ -------- ---------- ------ ---- ------ -------- ----------
Status of This Document Status of This Document
This draft, file name draft-ietf-dnssec-secext2-00.txt, is intended This draft, file name draft-ietf-dnssec-secext2-01.txt, is intended
to become a Proposed Standard RFC obsoleting Proposed Standard RFC to become a Draft Standard RFC obsoleting Proposed Standard RFC 2065.
2065. Distribution of this document is unlimited. Comments should be Distribution of this document is unlimited. Comments should be sent
sent to the DNS Security Working Group mailing list <dns- to the DNS Security Working Group mailing list <dns-security@tis.com>
security@tis.com> or to the author. or to the author.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet- other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
skipping to change at page 2, line 11 skipping to change at page 2, line 11
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Abstract Abstract
Extensions to the Domain Name System (DNS) are described that provide Extensions to the Domain Name System (DNS) are described that provide
data integrity and authentication to security aware resolvers or data integrity and authentication to security aware resolvers or
applications through the use of cryptographic digital signatures. applications through the use of cryptographic digital signatures.
These digital signatures are included in secured zones as resource These digital signatures are included in secured zones as resource
records. Security can still be provided even through non-security records. Security can also be provided even through non-security
aware DNS servers in many cases. aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public The extensions provide for the storage of authenticated public keys
keys in the DNS. This storage of keys can support general public key in the DNS. This storage of keys can support general public key
distribution services as well as DNS security. The stored keys distribution services as well as DNS security. The stored keys
enable security aware resolvers to learn the authenticating key of enable security aware resolvers to learn the authenticating key of
zones in addition to those for which they are initially configured. zones in addition to those for which they are initially configured.
Keys associated with DNS names can be retrieved to support other Keys associated with DNS names can be retrieved to support other
protocols. Provision is made for a variety of key types and protocols. Provision is made for a variety of key types and
algorithms. algorithms.
In addition, the security extensions provide for the optional In addition, the security extensions provide for the optional
authentication of DNS protocol transactions and requests. authentication of DNS protocol transactions and requests.
This document incorporates feedback from implementors and potential This document incorporates feedback from implementors and potential
users to the existing Proposed Standard in RFC 2065. users to RFC 2065.
Acknowledgments Acknowledgments
The significant contributions of the following persons (in alphabetic The significant contributions of the following persons (in alphabetic
order) to DNS security are gratefully acknowledged: order) to DNS security are gratefully acknowledged:
Jim Galvin James M. Galvin
John Gilmore John Gilmore
Olafur Gudmundsson Olafur Gudmundsson
Charlie Kaufman Charlie Kaufman
Edward Lewis Edward Lewis
Radia J. Perlman
Jeffrey I. Schiller Jeffrey I. Schiller
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................2 Abstract...................................................2
Acknowledgments............................................2 Acknowledgments............................................2
Table of Contents..........................................3 Table of Contents..........................................3
1. Overview of Contents....................................5 1. Overview of Contents....................................5
2. Overview of the DNS Extensions..........................6
2. Overview of the DNS Extensions.........................6
2.1 Services Not Provided..................................6 2.1 Services Not Provided..................................6
2.2 Key Distribution.......................................6 2.2 Key Distribution.......................................6
2.3 Data Origin Authentication and Integrity...............7 2.3 Data Origin Authentication and Integrity...............7
2.3.1 The SIG Resource Record..............................7 2.3.1 The SIG Resource Record..............................8
2.3.2 Authenticating Name and Type Non-existence...........8 2.3.2 Authenticating Name and Type Non-existence...........8
2.3.3 Special Considerations With Time-to-Live.............8 2.3.3 Special Considerations With Time-to-Live.............8
2.3.4 Special Considerations at Delegation Points..........9 2.3.4 Special Considerations at Delegation Points..........9
2.3.5 Special Considerations with CNAME....................9 2.3.5 Special Considerations with CNAME....................9
2.3.6 Signers Other Than The Zone.........................10 2.3.6 Signers Other Than The Zone.........................10
2.4 DNS Transaction and Request Authentication............10 2.4 DNS Transaction and Request Authentication............10
3. The KEY Resource Record................................11 3. The KEY Resource Record................................12
3.1 KEY RDATA format......................................11 3.1 KEY RDATA format......................................12
3.1.1 Object Types, DNS Names, and Keys...................12 3.1.1 Object Types, DNS Names, and Keys...................12
3.1.2 The KEY RR Flag Field...............................12 3.1.2 The KEY RR Flag Field...............................13
3.1.3 Preference Field....................................14 3.1.3 The Protocol Octet..................................15
3.1.4 Key Identifier Field................................14
3.1.5 The Protocol Octet..................................14
3.2 The KEY Algorithm Number Specification................15 3.2 The KEY Algorithm Number Specification................15
3.2.1 The MD5/RSA Algorithm...............................15 3.2.1 The MD5/RSA Algorithm...............................15
3.3 Interaction of Flags, Algorithm, and Protocol Bytes...16 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...16
3.4 Determination of Zone Secure/Unsecured Status.........17 3.4 Determination of Zone Secure/Unsecured Status.........16
3.5 KEY RRs in the Construction of Responses..............18 3.5 KEY RRs in the Construction of Responses..............18
4. The SIG Resource Record................................19 4. The SIG Resource Record................................19
4.1 SIG RDATA Format......................................19 4.1 SIG RDATA Format......................................19
4.1.1 ....................................................19 4.1.1 ....................................................19
4.1.2 Algorithm Number Field..............................20 4.1.2 Algorithm Number Field..............................20
4.1.3 Labels Field........................................20 4.1.3 Labels Field........................................20
4.1.4 Original TTL Field..................................20 4.1.4 Original TTL Field..................................20
4.1.5 Signature Expiration and Time Signed Fields.........21 4.1.5 Signature Expiration and Time Signed Fields.........21
4.1.6 Key Identifier Field................................21 4.1.6 Key Tag Field.......................................21
4.1.7 Signer's Name Field.................................21 4.1.7 Signer's Name Field.................................21
4.1.8 Signature Field.....................................22 4.1.8 Signature Field.....................................22
4.1.8.1 Signature Data....................................22 4.1.8.1 Signature Data....................................22
4.1.8.2 MD5/RSA Algorithm Signature Calculation...........22 4.1.8.2 MD5/RSA Algorithm Signature Calculation...........22
4.1.8.3 Transaction and Request SIGs......................23 4.1.8.3 Transaction and Request SIGs......................23
4.2 SIG RRs in the Construction of Responses..............24 4.2 SIG RRs in the Construction of Responses..............24
4.3 Processing Responses and SIG RRs......................25 4.3 Processing Responses and SIG RRs......................25
4.4 Signature Lifetime, Expiration, TTLs, and Validity....26 4.4 Signature Lifetime, Expiration, TTLs, and Validity....26
4.5 The Root Zone as Signer and Zone Skipping.............26 4.5 The Root Zone as Signer...............................26
5. Non-existent Names and Types...........................27 5. Non-existent Names and Types...........................27
5.1 The NXT Resource Record...............................27 5.1 The NXT Resource Record...............................27
5.2 NXT RDATA Format......................................28 5.2 NXT RDATA Format......................................28
5.3 Example...............................................28 5.3 Example...............................................28
5.4 Special Considerations at Delegation Points...........29 5.4 Special Considerations at Delegation Points...........29
5.5 Zone Transfers........................................29 5.5 Zone Transfers........................................29
5.5.1 Full Zone Transfers.................................30 5.5.1 Incremental Zone Transfers..........................30
5.5.2 Incremental Zone Transfers..........................30
6. How to Resolve Securely and The AD and CD Bits.........32 6. How to Resolve Securely and the AD and CD Bits.........31
6.1 The AD and CD Header Bits.............................32 6.1 The AD and CD Header Bits.............................31
6.2 Staticly Configured Keys..............................33 6.2 Staticly Configured Keys..............................32
6.3 Chaining Through Zones................................34 6.3 Chaining Through The DNS..............................33
6.3.1 Chaining Through KEYs...............................33
6.3.2 Conflicting Data....................................34
6.4 Secure Time...........................................35 6.4 Secure Time...........................................35
7. ASCII Representation of Security RRs...................36 7. ASCII Representation of Security RRs...................36
7.1 Presentation of KEY RRs...............................36 7.1 Presentation of KEY RRs...............................36
7.2 Presentation of SIG RRs...............................37 7.2 Presentation of SIG RRs...............................37
7.3 Presentation of NXT RRs...............................38 7.3 Presentation of NXT RRs...............................38
8. Canonical Form and Order of Resource Records...........39 8. Canonical Form and Order of Resource Records...........39
8.1 Canonical RR Form.....................................39 8.1 Canonical RR Form.....................................39
8.2 Canonical DNS Name Order..............................39 8.2 Canonical DNS Name Order..............................39
skipping to change at page 5, line 5 skipping to change at page 4, line 45
References................................................42 References................................................42
Author's Addresses........................................44 Author's Addresses........................................44
Expiration and File Name..................................44 Expiration and File Name..................................44
Appendix A: Base 64 Encoding..............................45 Appendix A: Base 64 Encoding..............................45
Appendix B: Changes from RFC 2065.........................47 Appendix B: Changes from RFC 2065.........................47
Appendix C: Key Tag Calculation...........................48
1. Overview of Contents 1. Overview of Contents
This document standardizes extensions of the Domain Name System (DNS) This document standardizes extensions of the Domain Name System (DNS)
protocol to support DNS security and public key distribution. It protocol to support DNS security and public key distribution. It
assumes that the reader is familiar with the Domain Name System, assumes that the reader is familiar with the Domain Name System,
particularly as described in RFCs 1033, 1034, and 1035. An earlier particularly as described in RFCs 1033, 1034, and 1035. An earlier
version of these extensions appears in RFC 2065. This replacement version of these extensions appears in RFC 2065. This replacement
incorporates implementation experience and requests from potential for that RFC incorporates implementation experience and requests from
users. potential users.
Section 2 provides an overview of the extensions and the key Section 2 provides an overview of the extensions and the key
distribution, data origin authentication, and transaction and request distribution, data origin authentication, and transaction and request
security they provide. security they provide.
Section 3 discusses the KEY resource record, its structure, and use Section 3 discusses the KEY resource record, its structure, and use
in DNS responses. These resource records represent the public keys in DNS responses. These resource records represent the public keys
of entities named in the DNS and are used for key distribution. of entities named in the DNS and are used for key distribution.
Section 4 discusses the SIG digital signature resource record, its Section 4 discusses the SIG digital signature resource record, its
structure, and use in DNS responses. These resource records are used structure, and use in DNS responses. These resource records are used
to authenticate other resource records in the DNS and optionally to to authenticate other resource records in the DNS and optionally to
authenticate DNS transactions and requests. authenticate DNS transactions and requests.
Section 5 discusses the NXT resource record (RR) and its use in DNS Section 5 discusses the NXT resource record (RR) and its use in DNS
responses. The NXT RR permits authenticated denial in the DNS of the responses including full and incremental zone transfers. The NXT RR
existence of a name or of a particular type for an existing name. permits authenticated denial of the existence of a name or of a
particular type for an existing name.
Section 6 discusses how a resolver can be configured with a starting Section 6 discusses how a resolver can be configured with a starting
key or keys and proceed to securely resolve DNS requests. key or keys and proceed to securely resolve DNS requests.
Interactions between resolvers and servers are discussed for Interactions between resolvers and servers are discussed for
combinations of security aware and security non-aware. Two combinations of security aware and security non-aware. Two
additional DNS header bits are defined for signaling between additional DNS header bits are defined for signaling between
resolvers and servers. resolvers and servers.
Section 7 describes the ASCII representation of the security resource Section 7 describes the ASCII representation of the security resource
records for use in master files and elsewhere. records for use in master files and elsewhere.
Section 8 defines the canonical form and order of RRs for DNS Section 8 defines the canonical form and order of RRs for DNS
security puposes. security purposes.
Section 9 defines levels of conformance for resolvers and servers. Section 9 defines levels of conformance for resolvers and servers.
Section 10 provides a few paragraphs on overall security Section 10 provides a few paragraphs on overall security
considerations. considerations.
Appendix A gives details of base 64 encoding which is used in the Appendix A gives details of base 64 encoding which is used in the
file representation of some RR's defined in this document. file representation of some RR's defined in this document.
Appendix B summarizes changes between this draft and RFC 2065. Appendix B summarizes changes between this draft and RFC 2065.
Appendix C specified how to calculate the simple checksum used as a
key tag in the SIG RR.
2. Overview of the DNS Extensions 2. Overview of the DNS Extensions
The Domain Name System (DNS) protocol security extensions provide The Domain Name System (DNS) protocol security extensions provide
three distinct services: key distribution as described in Section 2.2 three distinct services: key distribution as described in Section 2.2
below, data origin authentication as described in Section 2.3 below, below, data origin authentication as described in Section 2.3 below,
and transaction and request authentication, described in Section 2.4 and transaction and request authentication, described in Section 2.4
below. below.
Special considerations related to "time to live", CNAMEs, and Special considerations related to "time to live", CNAMEs, and
delegation points are also discussed in Section 2.3. delegation points are also discussed in Section 2.3.
skipping to change at page 7, line 45 skipping to change at page 7, line 46
described in 2.3.2.) This service can be supported by existing described in 2.3.2.) This service can be supported by existing
resolver and caching server implementations so long as they can resolver and caching server implementations so long as they can
support the additional resource types (see Section 9). The one support the additional resource types (see Section 9). The one
exception is that CNAME referrals from a secure zone can not be exception is that CNAME referrals from a secure zone can not be
authenticated if they are from non-security aware servers (see authenticated if they are from non-security aware servers (see
Section 2.3.5). Section 2.3.5).
If signatures are separately retrieved and verified when retrieving If signatures are separately retrieved and verified when retrieving
the information they authenticate, there will be more trips to the the information they authenticate, there will be more trips to the
server and performance will suffer. Security aware servers mitigate server and performance will suffer. Security aware servers mitigate
that degradation by always attempting to send the signature(s) that degradation by attempting to send the signature(s) needed.
needed.
2.3.1 The SIG Resource Record 2.3.1 The SIG Resource Record
The syntax of a SIG resource record (signature) is described in The syntax of a SIG resource record (signature) is described in
Section 4. It cryptographically binds the RR set being signed to the Section 4. It cryptographically binds the RR set being signed to the
signer and a validity interval. signer and a validity interval.
Every name in a secured zone will have associated with it at least 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 one SIG resource record for each resource type under that name except
for glue address RRs and delgation point NS RRs. A security aware for glue address RRs and delegation point NS RRs. A security aware
server will attempt to return, with RRs retrieved, the corresponding server will attempt to return, with RRs retrieved, the corresponding
SIGs. If a server is not security aware, the resolver must retrieve 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 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. the resource record set(s) that resolver is interested in.
2.3.2 Authenticating Name and Type Non-existence 2.3.2 Authenticating Name and Type Non-existence
The above security mechanism provides only a way to sign existing RR The above security mechanism only provides a way to sign existing RR
sets in a zone. "Data origin" authentication is not obviously sets in a zone. "Data origin" authentication is not obviously
provided for the non-existence of a domain name in a zone or the 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 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 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 names in a zone and the non-existence of types for the existing name
just before that range. just before that range.
Section 5 below covers the NXT RR. Section 5 below covers the NXT RR.
2.3.3 Special Considerations With Time-to-Live 2.3.3 Special Considerations With Time-to-Live
skipping to change at page 8, line 41 skipping to change at page 8, line 47
cached. cached.
This could be avoided by leaving the time-to-live out of the digital This could be avoided by leaving the time-to-live out of the digital
signature, but that would allow unscrupulous servers to set signature, but that would allow unscrupulous servers to set
arbitrarily long TTL values undetected. Instead, we include the arbitrarily long TTL values undetected. Instead, we include the
"original" TTL in the signature and communicate that data along with "original" TTL in the signature and communicate that data along with
the current TTL. Unscrupulous servers under this scheme can the current TTL. Unscrupulous servers under this scheme can
manipulate the TTL but a security aware resolver will bound the TTL manipulate the TTL but a security aware resolver will bound the TTL
value it uses at the original signed value. Separately, signatures value it uses at the original signed value. Separately, signatures
include a time signed and an expiration time. A resolver that knows include a time signed and an expiration time. A resolver that knows
the absolute time can determine securely whether a signature has the absolute time can determine securely whether a signature is in
expired. It is not possible to rely solely on the signature effect. It is not possible to rely solely on the signature
expiration as a substitute for the TTL, however, since the TTL is expiration as a substitute for the TTL, however, since the TTL is
primarily a database consistency mechanism and non-security aware primarily a database consistency mechanism and non-security aware
servers that depend on TTL must still be supported. servers that depend on TTL must still be supported.
2.3.4 Special Considerations at Delegation Points 2.3.4 Special Considerations at Delegation Points
DNS security would like to view each zone as a unit of data DNS security would like to view each zone as a unit of data
completely under the control of the zone owner with each entry completely under the control of the zone owner with each entry
(RRset) signed by a special private key held by the zone. But the (RRset) signed by a special private key held by the zone. But the
DNS protocol views the leaf nodes in a zone, which are also the apex DNS protocol views the leaf nodes in a zone, which are also the apex
skipping to change at page 9, line 44 skipping to change at page 9, line 45
There is a problem when security related RRs with the same owner name 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 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 particular, an initial retrieval for the CNAME or any other type may
not retrieve any associated signature, KEY, or NXT RR. For retrieved not retrieve any associated signature, KEY, or NXT RR. For retrieved
types other than CNAME, it will retrieve that type at the target name 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 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, 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 if any, at the original CNAME domain name but rather a SIG at the
target name. target name.
Security aware servers MUST be used to securely CNAME in DNS. Security aware servers must be used to securely CNAME in DNS.
Security aware servers must (1) allow KEY, SIG, and NXT RRs along Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
with CNAME RRs, (2) suppress CNAME processing on retrieval of these with CNAME RRs, (2) suppress CNAME processing on retrieval of these
types as well as on retrieval of the type CNAME, and (3) types as well as on retrieval of the type CNAME, and (3)
automatically return SIG RRs authenticating the CNAME or CNAMEs automatically return SIG RRs authenticating the CNAME or CNAMEs
encountered in resolving a query. This is a change from the previous 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 DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
node where a CNAME RR was present. node where a CNAME RR was present.
2.3.6 Signers Other Than The Zone 2.3.6 Signers Other Than The Zone
There are two cases where a SIG resource record is signed by other There are two cases where a SIG resource record is signed by other
than the zone private key. than the zone private key.
One is for support of dynamic update [RFC 2136], or future requests One is for support of dynamic update [RFC 2136], or future requests
which require authentication, where an entity is permitted to which require authentication, where an entity is permitted to
authenticate/update its records [RFC 2137]. The public key of the authenticate/update its records [RFC tbd]. The public key of the
entity must be present in the DNS and be appropriately signed but the entity must be present in the DNS and be appropriately signed but the
other RR(s) may be signed with the entity's key. other RR(s) may be signed with the entity's key.
The other is for support of transaction and request authentication as The second case is support of transaction and request authentication
described in Section 2.4 immediately below. as described in Section 2.4 immediately below.
2.4 DNS Transaction and Request Authentication 2.4 DNS Transaction and Request Authentication
The data origin authentication service described above protects The data origin authentication service described above protects
retrieved resource records but provides no protection for DNS retrieved resource records but provides no protection for DNS
requests or for message headers. requests or for message headers.
If header bits are falsely set by a bad server, there is little that If header bits are falsely set by a bad server, there is little that
can be done. However, it is possible to add transaction can be done. However, it is possible to add transaction
authentication. Such authentication means that a resolver can be authentication. Such authentication means that a resolver can be
skipping to change at page 10, line 41 skipping to change at page 10, line 44
accomplished by optionally adding a special SIG resource record at accomplished by optionally adding a special SIG resource record at
the end of the reply which digitally signs the concatenation of the the end of the reply which digitally signs the concatenation of the
server's response and the resolver's query. server's response and the resolver's query.
Requests can also be authenticated by including a special SIG RR at Requests can also be authenticated by including a special SIG RR at
the end of the request. Authenticating requests serves no function the end of the request. Authenticating requests serves no function
in older DNS servers and requests with a non-empty additional in older DNS servers and requests with a non-empty additional
information section are ignored by many older and current DNS information section are ignored by many older and current DNS
servers. However, this syntax for signing requests is defined in servers. However, this syntax for signing requests is defined in
connection with authenticating secure dynamic update requests [RFC connection with authenticating secure dynamic update requests [RFC
2137] or future requests requiring authentication. tbd] or future requests requiring authentication.
The private keys used in transaction and request security belong to The private keys used in transaction and request security belong to
the host composing the request or reply, not to the zone involved. the host composing the request or reply, not to the zone involved.
The corresponding public key is normally stored in and retrieved from The corresponding public key is normally stored in and retrieved from
the DNS for verification. the DNS for verification.
Because requests and replies are highly variable, message Because requests and replies are highly variable, message
authentication SIGs can not be pre-calculated. Thus it will be authentication SIGs can not be pre-calculated. Thus it will be
necessary to keep the private key on-line, for example in software or necessary to keep the private key on-line, for example in software or
in a directly connected piece of hardware. in a directly connected piece of hardware.
3. The KEY Resource Record 3. The KEY Resource Record
The KEY resource record (RR) is used to store a key that is The KEY resource record (RR) is used to store a public key that is
associated with a Domain Name System (DNS) name. It will be a public associated with a Domain Name System (DNS) name. This can be the
key as only public keys are stored in the DNS. This can be the
public key of a zone, a host or other end entity, or a user. A KEY public key of a zone, a host or other end entity, or a user. A KEY
RR is, like any other RR, authenticated by a SIG RR. Security aware RR is, like any other RR, authenticated by a SIG RR. Security aware
DNS implementations MUST be designed to handle at least two DNS implementations MUST be designed to handle at least two
simultaneously valid keys of the same type associated with a name. simultaneously valid keys of the same type associated with the same
name.
The type number for the KEY RR is TBD [was 25 in RFC 2065 but may The type number for the KEY RR is 25.
need to change due to changes in KEY RR].
3.1 KEY RDATA format 3.1 KEY RDATA format
The RDATA for a KEY RR consists of flags, preference, key identifier, The RDATA for a KEY RR consists of flags, a protocol octet, the
a protocol octet, the algorithm number, and the public key itself. algorithm number, and the public key itself. The format is as
The format is as follows: follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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 | | flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preference | key identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | / | /
+---------------+---------------+ public key data / / public key /
/ (optional depending on flags/algorithm) / / |
/ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
/-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The KEY RR is not intended for storage of certificates and a separate The KEY RR is not intended for storage of certificates and a separate
certificate RR is being considered, to be defined in a separate certificate RR is being considered, to be defined in a separate
document. document.
The meaning of the KEY RR owner name, flags, preference, key The meaning of the KEY RR owner name, flags, and protocol octet are
identifier, and protocol octet are described in Sections 3.1.1 described in Sections 3.1.1 through 3.1.5 below. The flags and
through 3.1.5 below. The flags and algorithm must be examined before algorithm must be examined before any data following the algorithm
any data following the algorithm octet as they control the existence octet as they control the existence and format of any following data.
and format of any following data. The algorithm and public key The algorithm and public key fields are described in Section 3.2.
fields are described in Section 3.2. The format of the public key is The format of the public key is algorithm dependent.
algorithm dependent.
KEY RRs do not expire but their authenticating SIG RR does as KEY RRs do not expire but their authenticating SIG RR does as
described in Section 4 below. described in Section 4 below.
3.1.1 Object Types, DNS Names, and Keys 3.1.1 Object Types, DNS Names, and Keys
The public key in a KEY RR belongs to the object named in the owner The public key in a KEY RR is for the object named in the owner name.
name.
This DNS name may refer to up to three different categories of This DNS name may refer to up to three different categories of
things. For example, foo.host.example could be (1) a zone, (2) a 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 host or other end entity , or (3) the mapping into a DNS name of the
user or account foo@host.example. Thus, there are flags, as 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 described below, in the KEY RR to indicate with which of these roles
the owner name and public key are associated. Note that an 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. appropriate zone KEY RR MUST occur at the apex node of a secure zone.
Although the same name can be used for up to all three of these
categories, in which case there would normally be three KEY RRs at
that name with different flags, such overloading of a name is
discouraged. It is also possible to use the same key for different
things with the same name or even different names, but this is
strongly discouraged. In particular, the use of a zone key as a
non-zone key will usually require that the corresponding private key
be kept on line and thereby become more vulnerable than if it were
kept off line.
In addition to the name type bits, there are additional flag bits,
all described below.
3.1.2 The KEY RR Flag Field 3.1.2 The KEY RR Flag Field
In the "flags" field: In the "flags" field:
Bit 0 and 1 are the key "type" field. Bit 0 a one indicates that 1 1 1 1 1 1
use of the key is prohibited for authentication. Bit 1 a one 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
indicates that use of the key is prohibited for confidentiality. If +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
this field is zero, then use of the key for authentication and/or | A/C | Z | XT| Z | Z | NAMTYP| IP| Z | Z | Z | SIG |
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. If both bits of this field 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-4 are reserved and must be zero.
Bit 5 on indicates that this is a key associated with a "user" or Bit 0 and 1 are the key "type" bits. Bit 0 a one indicates that use
"account" at an end entity, usually a host. The coding of the owner of the key is prohibited for authentication. Bit 1 a one
name is that used for the responsible individual mailbox in the SOA indicates that use of the key is prohibited for confidentiality.
and RP RRs: The owner name is the user name as the name of a node If this field is zero, then use of the key for authentication
under the entity name. For example, "j_random_user" on and/or confidentiality is permitted. Note that DNS security makes
host.subdomain.example could have a public key associated through a use of keys for authentication only. Confidentiality use flagging
KEY RR with name j_random_user.host.subdomain.example and the user is provided for use of keys in other protocols. Implementations
bit a one. It could be used in a security protocol where not intended to support key distribution for confidentiality MAY
authentication of a user was desired. This key might be useful in IP require that the confidentiality use prohibited bit be on for keys
or other security for a user level service such a telnet, ftp, they serve. If both bits are one, the "no key" value, there is no
rlogin, etc. 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.
Bit 6 on indicates that this is a key associated with the non-zone Bits 2 is reserved and must be zero.
"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 a telephone number [RFC 1530] or numeric IP address.
This is the public key used in connection with DNS request and
transaction authentication services if the owner name designates a
DNS resolver or server host. 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.
Bit 7 is the "zone" bit and indicates that this is a zone key for Bits 3 is reserved as a flag extension bit. If it is a one, a second
the zone whose name is the KEY RR owner name. This is the public key 16 bit flag field is added after the algorithm octet and before
used for the primary DNS security feature of data origin the key data. This bit MUST NOT be set unless one or more such
authentication. additional bits have been defined and are non-zero.
Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicates that Bits 4-5 are reserved and must be zero.
this key is valid for use in conjunction with that security standard.
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 the key type field
(bits 0 and 1) set to indicate a key is present is an assertion that
the host speaks IPSEC.
Bit 9 is reserved to be the "email" bit and indicate that this key Bits 6 and 7 form a field that encodes the name type.
is valid for use in conjunction with MIME security multiparts. This A value of 0 indicates that this is a key associated with a
key could be used in connection with secured communication on behalf "user" or "account" at an end entity, usually a host. The coding
of an end entity or user whose name is the owner name of the KEY RR of the owner name is that used for the responsible individual
if the entity or user bits are on. 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.
A value of 1 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.
A value of 2 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 a telephone number [RFC 1530] or
numeric IP address. This is the public key used in connection
with DNS request and transaction authentication services if the
owner name designates a DNS resolver or server host. 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.
The value of 3 is reserved.
Bit 10 is reserved to be the TLS bit [draft-ietf-tls-*.txt] and Bit 8 is reserved to be the Oakley/IPSEC [RFC 1825] bit and indicates
indicates that this key is valid for use in conjunction with that that this key is valid for use in conjunction with that security
security standard. This key could be used in connection with secured standard. This key could be used in connection with secured
communication on behalf of an end entity or user whose name is the 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 owner name of the KEY RR if the entity or user bits are on. The
presence of a KEY resource with the TLS and entity bits on and the presence of a KEY resource with the Oakley/IPSEC bit on is an
key type field (bits 0 and 1) set to indicate a key is present is an assertion that the host speaks Oakley/IPSEC.
assertion that the host speaks TLS.
Bit 11 is reserved and must be zero. Bits 9 through 11 are reserved and must be zero.
Bits 12-15 are the "signatory" field. If non-zero, they indicate Bits 12-15 are the "signatory" field. If non-zero, they indicate
that the key can validly sign RRs or updates of the same name. If that the key can validly sign RRs or updates of the same name. If
the owner name is a wildcard, then RRs or updates with any name which the owner name is a wildcard, then RRs or updates with any name
is in the wildcard's scope can, in some cases, be signed. Fifteen which is in the wildcard's scope can, in some cases, be signed.
different non-zero values are possible for this field and any Fifteen different non-zero values are possible for this field and
differences in their meaning are reserved for definition in any differences in their meaning are reserved for definition in
connection with DNS dynamic update [RFC 2137] or other new DNS connection with DNS dynamic update [RFC tbd] or other new DNS
commands. Zone keys always have authority to sign any RRs in the commands. Zone keys (see bits 6 and 7 above) always have
zone regardless of the value of this field. The signatory field, authority to sign any RRs in the zone regardless of the value of
like all other aspects of the KEY RR, is only effective if the KEY RR the signatory field. The signatory field, like all other aspects
is appropriately signed by a SIG RR. of the KEY RR, is only effective if the KEY RR is appropriately
signed by a SIG RR.
Bits 16-31 are reserved and must be zero.
3.1.3 Preference Field
The "preference" field is an unsigned sixteen bit integer with octets
in network order that is used to indicate the relative preference of
different KEY RRs used for the same purpose. A smaller value is
preferred to a larger value. (It is not generally significant for
DNS origin authentication use, as zones SHOULD be signed by all the
applicable zone keys, but is intended for use in keys retrieved for
other protocols.)
3.1.4 Key Identifier Field
The "key identifier" field is assigned to the key and matches the key
identifier field in SIG RRs (1) whose signer name is the KEY RR owner
name and (2) that were signed by the private key corresponding to the
public key in the KEY RR.
3.1.5 The Protocol Octet 3.1.3 The Protocol Octet
It is anticipated that some keys stored in DNS will be used in It is anticipated that some keys stored in DNS will be used in
conjunction with Internet protocols other than DNS (keys with zone conjunction with Internet protocols other than DNS (keys with the
bit or signatory field non-zero) and IPSEC/email/TLS (keys with zone name type or with their signatory field non-zero). It is
IPSEC, email and/or TLS bit set). The protocol octet is provided to intended that the protocol octet and possibly some of the unused
indicate that a key is valid for such use and, for end entity keys or (must be zero) bits in the KEY RR flags will be used for this
the host part of user keys, that the secure version of that protocol purpose.
is implemented on that entity or host.
Values between 1 and 223 decimal inclusive are available for The following values of the Protocol Octet are reserved as indicated:
assignment by IANA for such protocols. The 31 values between 224 and
254 inclusive will not be assigned to a specific protocol and are
available for experimental use under private 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 223 range).
It is intended that new uses of DNS stored keys would initially be VALUE Protocol
implemented, and limited operational experience gained, using the 1 TLS
experimental range of the protocol octet. If demand for widespread 2 Email
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 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 one of the remaining flag
field bits may be allocated to the protocol. When such a bit has been
allocated, 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.
3.2 The KEY Algorithm Number Specification 3.2 The KEY Algorithm Number Specification
This octet is the key algorithm parallel to the same field for the This octet is the key algorithm parallel to the same field for the
SIG resource. The MD5/RSA algorithm described in this document is SIG resource. The MD5/RSA algorithm described in this document is
number 1. Numbers 2 through 253 are available for assignment should number 1. Numbers 2 through 253 are available for assignment should
sufficient reason arise. However, the designation of a new algorithm sufficient reason arise. However, the designation of a new algorithm
could have a major impact on interoperability and requires an IETF could have a major impact on interoperability and requires an IETF
standards action. Number 254 is reserved for private use and will standards action. Number 254 is reserved for private use and will
never be assigned a specific algorithm. For number 254, the public never be assigned a specific algorithm. For number 254, the public
key area for the KEY RR and the signature are in the SIG RR will key area for the KEY RR and the signature will actually begin with a
actually begin with a length byte followed by an Object Identifier length byte followed by an Object Identifier (ISO OID) of that
(ISO OID) of that length. The OID indicates the private algorithm in length. The OID indicates the private algorithm in use and the
use and the remainder of the area is whatever is required by that remainder of the area is whatever is required by that algorithm.
algorithm. Values 0 and 255 are reserved. Values 0 and 255 are reserved.
3.2.1 The MD5/RSA Algorithm 3.2.1 The MD5/RSA Algorithm
If the type field does not have the "no key" value and the algorithm If the type field does not have the "no key" value and the algorithm
field is 1, indicating the MD5/RSA algorithm, the public key field is field is 1, indicating the MD5/RSA algorithm, the public key field is
structured as follows: 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 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 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 / | pub exp length | public key exponent /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
+- modulus / +- modulus /
| / | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
For interoperability, the exponent and modulus are each currently
To promote interoperability, the exponent and modulus are each limited to 4096 bits in length. The public key exponent is a
currently limited to 4096 bits in length. The public key exponent is variable length unsigned integer. Its length in octets 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
represented as a two octet unsigned integer. The public key modulus zero octet followed by a two octet unsigned length if it is longer
field is a multiprecision unsigned integer. The length of the than 255 bytes. The public key modulus field is a multiprecision
modulus can be determined from the RDLENGTH and the preceding RDATA unsigned integer. The length of the modulus can be determined from
fields including the exponent. Leading zero octets are permitted in the RDLENGTH and the preceding RDATA fields including the exponent.
the exponent and modulus. Leading zero octets are prohibited in the exponent and modulus.
3.3 Interaction of Flags, Algorithm, and Protocol Bytes 3.3 Interaction of Flags, Algorithm, and Protocol Bytes
Various combinations of the no-key type value, algorithm byte, Various combinations of the no-key type flags, algorithm byte,
protocol byte, and any protocol indicating flags (such as the protocol byte, and any future assigned protocol indicating flags are
reserved IPSEC flag) are possible. (Note that the zone flag bit possible. (Note that the zone value of the name type flags or the
being on or the signatory field being non-zero is effectively a DNS signatory field being non-zero means usability in the DNS protocol.)
protocol flag on.) The meaning of these combinations is indicated The meaning of these combinations is indicated below:
below:
NK = no key type value NK = no key type flags (bits 0 and 1 on)
AL = algorithm byte AL = algorithm byte
PR = protocols indicated by protocol byte or protocol flags PR = protocols indicated by protocol byte or future assigned flags
x represents any valid non-zero value(s). x represents any valid non-zero value(s).
AL PR NK Meaning AL PR NK Meaning
0 0 0 Illegal, claims key but has bad algorithm field. 0 0 0 Illegal, claims key but has bad algorithm field.
0 0 1 Specifies total lack of security for owner. 0 0 1 Specifies total lack of security for owner.
0 x 0 Illegal, claims key but has bad algorithm field. 0 x 0 Illegal, claims key but has bad algorithm field.
0 x 1 Specified protocols unsecured, others may be secure. 0 x 1 Specified protocols unsecured, others may be secure.
x 0 0 Useless. Gives key but no protocols to use it. x 0 0 Useless. Gives key but no protocols to use it.
x 0 1 Useless. Denies key but for no protocols. x 0 1 Useless. Denies key but for no protocols.
x x 0 Specifies key for protocols and asserts that x x 0 Specifies key for protocols.
those protocols are implemented with security.
x x 1 Algorithm not understood for protocol. 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 byte values assigned)
3.4 Determination of Zone Secure/Unsecured Status 3.4 Determination of Zone Secure/Unsecured Status
A zone KEY RR with the "no-key" type field value (both bits 0 and 1 A zone KEY RR with the "no-key" type field value (both bits 0 and 1
on) indicates that the zone named is unsecured while a zone KEY RR on) indicates that the zone named is unsecured while a zone KEY RR
with a key present indicates that the zone named is secure. It is with a key present indicates that the zone named is secure. It is
possible for conflicting zone KEY RRs to be present. possible for conflicting zone KEY RRs to be present.
Zone KEY RRs, like all RRs, are only trusted if they are Zone KEY RRs, like all RRs, are only trusted if they are
authenticated by a SIG RR whose signer field is a signer for which authenticated by a SIG RR whose signer field is a signer for which
the resolver has a public key they trust. Untrusted zone KEY RRs can the resolver has a public key they trust and where resolver policy
be ignored in determining the security status of the zone. There can permits that signer to sign for the KEY owner name. Untrusted zone
be multiple sets of trusted zone KEY RRs for a zone with each set KEY RRs can be ignored in determining the security status of the
having a different signer. zone. There can be multiple sets of trusted zone KEY RRs for a zone
with each set having a different signer.
Zones can be (1) secure, indicating that any retrieved RR must be Zones can be (1) secure, indicating that any retrieved RR must be
authenticated by a SIG RR or it will be discarded as bogus, (2) authenticated by a SIG RR or it will be discarded as bogus, (2)
unsecured, indicating that SIG RRs are not expected or required for unsecured, indicating that SIG RRs are not expected or required for
RRs retrieved from the zone, or (3) experimentally secure, which RRs retrieved from the zone, or (3) experimentally secure, which
indicates that SIG RRs might or might not be present but must be indicates that SIG RRs might or might not be present but must be
checked if found. The status of a zone is determined as follows: checked if found. The status of a zone is determined as follows:
1. If, for a zone, every zone KEY RR signed by a signer trusted by 1. If, for a zone, every zone KEY RR signed by a signer trusted by
the resolver says there is no key for that zone, it is unsecured. the resolver and authorized by resolver policy to sign says there
is no key for that zone, it is unsecured.
2. If, for every trusted zone KEY RR signer for a zone, there is at 2. If, for every trusted and resolver policy authorized zone KEY RR
least one no-key KEY RR and for at least one trusted zone KEY RR signer for a zone, there is at least one no-key KEY RR and at
signer there are one or more key specifying KEY RR(s), then that least one key specifying KEY RR(s), then that zone is only
zone is only experimentally secure. Both authenticated and non- experimentally secure. Both authenticated and non-authenticated
authenticated RRs for it should be accepted by the resolver. RRs for it should be accepted by the resolver.
3. If any trusted zone KEY RR signer for the zone has only key 3. If every trusted and resolver policy authorized zone KEY RR signer
specifying KEY RR(s) for the zone, then it is secure and only for the zone has only key specifying KEY RR(s) for the zone, then
authenticated RRs from it will be accepted. it is secure and only authenticated RRs from it will be accepted.
Examples: Examples:
(1) A resolver only trusts signatures by the superzone within the (1) A resolver only trusts signatures by the superzone within the
DNS hierarcy so it will look only at the KEY RRs that are signed by DNS hierarchy so it will look only at the KEY RRs that are signed by
the superzone. If it finds only no-key KEY RRs, it will assume the the superzone. If it finds only no-key KEY RRs, it will assume the
zone is not secure. If it finds only key specifying KEY RRs, it will zone is not secure. If it finds only key specifying KEY RRs, it will
assume the zone is secure and reject any unsigned responses. If it assume the zone is secure and reject any unsigned responses. If it
finds both, it will assume the zone is experimentally secure finds both, it will assume the zone is experimentally secure
(2) A resolver trusts the superzone of zone Z (to which it got (2) A resolver trusts the superzone of zone Z (to which it got
securely from its local zone) and a third party, cert-auth.xx. When securely from its local zone) and a third party, cert-auth.xx. When
considering data from zone Z, it may be signed by the superzone of Z, considering data from zone Z, it may be signed by the superzone of Z,
by cert-auth.xx, by both, or by neither. The following table by cert-auth.xx, by both, or by neither. The following table
indicates whether zone Z will be considered secure, experimentally indicates whether zone Z will be considered secure, experimentally
skipping to change at page 18, line 23 skipping to change at page 18, line 13
o +-----------+-----------+----------+----------+ o +-----------+-----------+----------+----------+
n Keys | secure | secure | secure | secure | n Keys | secure | secure | secure | secure |
e +-----------+-----------+----------+----------+ e +-----------+-----------+----------+----------+
3.5 KEY RRs in the Construction of Responses 3.5 KEY RRs in the Construction of Responses
An explicit request for KEY RRs does not cause any special additional An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG information processing except, of course, for the corresponding SIG
RR from a security aware server. RR from a security aware server.
Security aware DNS servers MUST include KEY RRs as additional Security aware DNS servers include KEY RRs as additional information
information in responses, where a KEY is available, in the following in responses, where a KEY is available, in the following cases:
cases:
(1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone
served by these name servers MUST be included as additional served by these name servers must be included as additional
information if space is available. There will always be at least one information if space is available. There will always be at least one
such KEY RR in a secure zone, even if it has the no-key type value to such KEY RR in a secure zone, even if it has the no-key type value to
indicate that the subzone is unsecured. If not all additional indicate that the subzone is unsecured. If not all additional
information will fit, the KEY RR(s) have higher priority than type A information will fit, the KEY RR(s) have higher priority than type A
or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the
retrieval must be considered truncated. retrieval must be considered truncated.
(2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST
be included if space is available. On inclusion of A or AAAA RRs as be included if space is available. On inclusion of A or AAAA RRs as
additional information, KEY RRs with the same name will also be additional information, KEY RRs with the same name will also be
skipping to change at page 19, line 36 skipping to change at page 19, line 36
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 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 | | type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL | | original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration | | signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time signed | | time signed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key identifier | | | key tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| / | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ / / /
/ signature / / signature /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1 4.1.1
skipping to change at page 20, line 48 skipping to change at page 20, line 48
4.1.4 Original TTL Field 4.1.4 Original TTL Field
The "original TTL" field is included in the RDATA portion to avoid The "original TTL" field is included in the RDATA portion to avoid
(1) authentication problems that caching servers would otherwise (1) authentication problems that caching servers would otherwise
cause by decrementing the real TTL field and (2) security problems cause by decrementing the real TTL field and (2) security problems
that unscrupulous servers could otherwise cause by manipulating the that unscrupulous servers could otherwise cause by manipulating the
real TTL field. This original TTL is protected by the signature real TTL field. This original TTL is protected by the signature
while the current TTL field is not. while the current TTL field is not.
NOTE: The "original TTL" must be restored into the covered RRs when NOTE: The "original TTL" must be restored into the covered RRs when
the signature is verified. This implies that all RRs for a the signature is verified (see Section 8). This implies that all RRs
particular type, name, and class must have the same TTL to start for a particular type, name, and class must have the same TTL to
with. start with.
4.1.5 Signature Expiration and Time Signed Fields 4.1.5 Signature Expiration and Time Signed Fields
The SIG is valid until the "signature expiration" time which is an The SIG is valid until the "signature expiration" time which is an
unsigned number of seconds since the start of 1 January 1970, GMT, unsigned number of seconds since the start of 1 January 1970, GMT,
ignoring leap seconds. (See also Section 4.4.) Ring arithmetic is ignoring leap seconds. (See also Section 4.4.) Ring arithmetic is
used as for DNS SOA serial numbers [RFC 1982] which means that the used as for DNS SOA serial numbers [RFC 1982] which means that the
expiration date can never be much more than 130 years in the future. expiration date can never be more than ~136.09 years in the future.
The "time signed" field is an unsigned number of seconds since the The "time signed" field is an unsigned number of seconds since the
start of 1 January 1970, GMT, ignoring leap seconds. SIG RRs SHOULD start of 1 January 1970, GMT, ignoring leap seconds. SIG RRs SHOULD
NOT have a date signed more than a few days in the future. To NOT have a date signed more than a few days in the future. To
prevent misordering of network requests to update a zone dynamically, prevent misordering of network requests to update a zone dynamically,
monotonically increasing "time signed" dates may be necessary. monotonically increasing "time signed" dates may be necessary.
SOA serial numbers for secure zones MUST not only be advanced when SOA serial numbers for secure zones MUST not only be advanced when
their data is updated but also when new SIG RRs are inserted (ie, the their data is updated but also when new SIG RRs are inserted (ie, the
zone or any part of it is re-signed). zone or any part of it is re-signed).
A SIG RR may have an expiration date numerically less than the time A SIG RR may have an expiration date numerically less than the time
signed if time is near the 32 bit wrap around point and/or the signed if time is near the 32 bit wrap around point and/or the
signature is long lived. signature is long lived.
4.1.6 Key Identifier Field 4.1.6 Key Tag Field
The "key identifier" is a two octet quantity that is used to The "key Tag" is a two octet quantity that is used to efficiently
efficiently select between multiple keys which may be applicable and select between multiple keys which may be applicable and thus check
thus check that a public key about to be used for the computationally that a public key about to be used for the computationally expensive
expensive effort to check the signature is possibly valid. It is effort to check the signature is possibly valid. For algorithm 1
assigned by the entity creating the KEY RRs, appears in the (MD5/RSA) as defined below, it is the next to the bottom two octets
corresponding KEY RR, and MUST be unique among valid KEY RRs of the of the public key modulus needed to decode the signature field. That
same name and algorithm. is to say, the most significant 16 of the lest significant 24 bits of
the modulus in network order. For all other algorithms, including
private algorithms, it is calculated as a simple checksum of the KEY
RR as described in Appendix C.
4.1.7 Signer's Name Field 4.1.7 Signer's Name Field
The "signer's name" field is the domain name of the signer generating The "signer's name" field is the domain name of the signer generating
the SIG RR. This is the owner of the public KEY RR that can be used the SIG RR. This is the owner of the public KEY RR that can be used
to verify the signature. It is frequently the zone which contained to verify the signature. It is frequently the zone which contained
the RRset being authenticated. The signer's name may be compressed the RRset being authenticated. What signers signers should be
with standard DNS name compression when being transmitted over the authorized to sign what is a significant resolver policy question as
discussed in Section 6. The signer's name may be compressed with
standard DNS name compression when being transmitted over the
network. network.
4.1.8 Signature Field 4.1.8 Signature Field
The structure of the "signature" field is described below. The structure of the "signature" field is described below.
4.1.8.1 Signature Data 4.1.8.1 Signature Data
The actual signature portion of the SIG RR binds the other RDATA The actual signature portion of the SIG RR binds the other RDATA
fields to all of the "type covered" RRs with that owner name and fields to all of the "type covered" RRs with that owner name and
skipping to change at page 23, line 23 skipping to change at page 23, line 23
signature. Use of 3 as the public exponent may be weak for signature. Use of 3 as the public exponent may be weak for
confidentiality uses since, if the same data can be collected confidentiality uses since, if the same data can be collected
encrypted under three different keys with an exponent of 3 then, encrypted under three different keys with an exponent of 3 then,
using the Chinese Remainder Theorem [NETSEC], the original plain text using the Chinese Remainder Theorem [NETSEC], the original plain text
can be easily recovered. This weakness is not significant for DNS can be easily recovered. This weakness is not significant for DNS
security because we seek only authentication, not confidentiality. security because we seek only authentication, not confidentiality.
4.1.8.3 Transaction and Request SIGs 4.1.8.3 Transaction and Request SIGs
A response message from a security aware server may optionally A response message from a security aware server may optionally
contain a special SIG as the last item in the additional information contain a special SIG at the end of the additional information
section to authenticate the transaction. section to authenticate the transaction.
This SIG has a "type covered" field of zero, which is not a valid RR This SIG has a "type covered" field of zero, which is not a valid RR
type. It is calculated by using a "data" (see Section 4.1.8.1) of type. It is calculated by using a "data" (see Section 4.1.8.1) of
the entire preceding DNS reply message, including DNS header but not the entire preceding DNS reply message, including DNS header but not
the IP header and before the reply RR counts have been adjusted for the IP header and before the reply RR counts have been adjusted for
the inclusion of any transaction SIG, concatenated with the entire the inclusion of any transaction SIG, concatenated with the entire
DNS query message that produced this response, including the query's DNS query message that produced this response, including the query's
DNS header and any request SIGs but not its IP header. That is DNS header and any request SIGs but not its IP header. That is
skipping to change at page 23, line 47 skipping to change at page 23, line 47
host key, not the zone key) by the requesting resolver shows that the host key, not the zone key) by the requesting resolver shows that the
query and response were not tampered with in transit, that the query and response were not tampered with in transit, that the
response corresponds to the intended query, and that the response response corresponds to the intended query, and that the response
comes from the queried server. comes from the queried server.
A DNS request may be optionally signed by including one or more SIGs A DNS request may be optionally signed by including one or more SIGs
at the end of the query. Such SIGs are identified by having a "type at the end of the query. Such SIGs are identified by having a "type
covered" field of zero. They sign the preceding DNS request message covered" field of zero. They sign the preceding DNS request message
including DNS header but not including the IP header or any request including DNS header but not including the IP header or any request
SIGs at the end and before the request RR counts have been adjusted SIGs at the end and before the request RR counts have been adjusted
for the inclusions of any request SIG. for the inclusions of any request SIG(s).
WARNING: Request SIGs are unnecessary for currently defined queries WARNING: Request SIGs are unnecessary for currently defined queries
and will cause almost all existing DNS servers to completely ignore a and will cause almost all existing DNS servers to completely ignore a
query. However, such SIGs are needed to authenticate some DNS secure query. However, such SIGs are needed to authenticate some DNS secure
dynamic update requests [RFC 2137] and may in the future been needed dynamic update requests [RFC tbd] and may in the future been needed
for other requests. for other requests.
Except where needed to authenticate an update or similar privileged Except where needed to authenticate an update or similar privileged
request, servers are not required to check request SIGs. request, servers are not required to check request SIGs.
4.2 SIG RRs in the Construction of Responses 4.2 SIG RRs in the Construction of Responses
Security aware DNS servers MUST, for every authenticated RR the query Security aware DNS servers SHOULD, for every authenticated RR the
will return, attempt to send the available SIG RRs which authenticate query will return, attempt to send the available SIG RRs which
the requested RR. The following rules apply to the inclusion of SIG authenticate the requested RR. The following rules apply to the
RRs in responses: inclusion of SIG RRs in responses:
1. when an RRset is placed in a response, its SIG RR has a higher 1. when an RRset is placed in a response, its SIG RR has a higher
priority for inclusion than other additional RRs that may need priority for inclusion than additional RRs that may need to be
to be included. If space does not permit its inclusion, the included. If space does not permit its inclusion, the response
response MUST be considered truncated except as provided in 2 MUST be considered truncated except as provided in 2 below.
below.
2. when a SIG RR is present in the zone for an additional 2. when a SIG RR is present in the zone for an additional
information section RR, the response MUST NOT be considered information section RR, the response MUST NOT be considered
truncated merely because space does not permit the inclusion of truncated merely because space does not permit the inclusion of
its SIG RR. its SIG RR.
3. SIGs to authenticate non-authoritative data (glue records and NS 3. SIGs to authenticate non-authoritative data (glue records and NS
RRs for subzones) are unnecessary and MUST NOT be sent. (Note RRs for subzones) are unnecessary and MUST NOT be sent. (Note
that KEYs given for a subzone in that subzone's superzone is that KEYs given for a subzone in that subzone's superzone is
controlling so the superzone's signature on the KEY MUST be controlling so the superzone's signature on the KEY MUST be
skipping to change at page 25, line 13 skipping to change at page 25, line 12
SHOULD be zero. To conserve space, the owner name SHOULD be SHOULD be zero. To conserve space, the owner name SHOULD be
root (a single zero octet). If transaction authentication is root (a single zero octet). If transaction authentication is
desired, that SIG RR must be considered the highest priority for desired, that SIG RR must be considered the highest priority for
inclusion. inclusion.
4.3 Processing Responses and SIG RRs 4.3 Processing Responses and SIG RRs
The following rules apply to the processing of SIG RRs included in a The following rules apply to the processing of SIG RRs included in a
response: response:
1. a security aware resolver that receives a response from what it 1. a security aware resolver that receives a response from a
believes to be a security aware server via a secure security aware server via a secure communication with the AD bit
communication with the AD bit (see Section 6.1) set, MAY choose (see Section 6.1) set, MAY choose to accept the RRs as received
to accept the RRs as received without verifying the zone SIG without verifying the zone SIG RRs.
RRs.
2. in other cases, a security aware resolver SHOULD verify the SIG 2. in other cases, a security aware resolver SHOULD verify the SIG
RRs for the RRs of interest. This may involve initiating RRs for the RRs of interest. This may involve initiating
additional queries for SIG or KEY RRs, especially in the case of additional queries for SIG or KEY RRs, especially in the case of
getting a response from an server that does not implement getting a response from an server that does not implement
security. (As explained in 2.3.5 above, it will not be possible security. (As explained in 2.3.5 above, it will not be possible
to secure CNAMEs being served up by non-secure resolvers.) to secure CNAMEs being served up by non-secure resolvers.)
NOTE: Implementers might expect the above SHOULD to be a MUST. NOTE: Implementers might expect the above SHOULD to be a MUST.
However, local policy or the calling application may not require However, local policy or the calling application may not require
skipping to change at page 25, line 46 skipping to change at page 25, line 44
are invalid, then the RRset is not authenticated. are invalid, then the RRset is not authenticated.
If the SIG RR is the last RR in a response in the additional If the SIG RR is the last RR in a response in the additional
information section and has a type covered of zero, it is a information section and has a type covered of zero, it is a
transaction signature of the response and the query that produced the transaction signature of the response and the query that produced the
response. It MAY be optionally checked and the message rejected if response. It MAY be optionally checked and the message rejected if
the checks fail. But even if the checks succeed, such a transaction the checks fail. But even if the checks succeed, such a transaction
authentication SIG does NOT authenticate any RRs in the message. authentication SIG does NOT authenticate any RRs in the message.
Only a proper SIG RR signed by the zone or a key tracing its Only a proper SIG RR signed by the zone or a key tracing its
authority to the zone or to static resolver configuration can authority to the zone or to static resolver configuration can
authenticate RRs. If a resolver does not implement transaction authenticate RRs depending on resolver policy (see Section 6). If a
and/or request SIGs, it MUST ignore them without error. resolver does not implement transaction and/or request SIGs, it MUST
ignore them without error.
If all checks indicate that the SIG RR is valid then RRs verified by If all checks indicate that the SIG RR is valid then RRs verified by
it should be considered authenticated. it should be considered authenticated.
4.4 Signature Lifetime, Expiration, TTLs, and Validity 4.4 Signature Lifetime, Expiration, TTLs, and Validity
Security aware servers must not consider SIG RRs to authenticate Security aware servers MUST NOT consider SIG RRs to authenticate
anything after their expiration time and not consider any RR to be anything after their expiration time and NOT consider any RR to be
authenticated after all its signatures have expired. Within that authenticated after all its signatures have expired. Within that
constraint, servers should continue to follow DNS TTL aging. Thus constraint, servers should continue to follow DNS TTL aging. Thus
authoritative servers should continue to follow the zone refresh and authoritative servers should continue to follow the zone refresh and
expire parameters and a non-authoritative server should count down expire parameters and a non-authoritative server should count down
the TTL and discard RRs when the TTL is zero. In addition, when RRs the TTL and discard RRs when the TTL is zero. In addition, when RRs
are transmitted in a query response, the TTL should be trimmed so are transmitted in a query response, the TTL should be trimmed so
that current time plus the TTL does not extend beyond the signature that current time plus the TTL does not extend beyond the signature
expiration time. Thus, in general, the TTL on a transmitted RR would expiration time. Thus, in general, the TTL on a transmitted RR would
be be
min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
When signatures are generated, signature expiration times must be set When signatures are generated, signature expiration times should be
far enough in the future that it is quite certain that new signatures set far enough in the future that it is quite certain that new
can be generated before the old ones expire. However, setting signatures can be generated before the old ones expire. However,
expiration too far into the future could, if bad data or signatures setting expiration too far into the future could, if bad data or
were ever generated, mean a long time to flush such badness. signatures were ever generated, mean a long time to flush such
badness.
It is recommended that signature lifetime be a small multiple of the It is recommended that signature lifetime be a small multiple of the
TTL (ie, 4 to 16 times the TTL) but not less than a reasonable TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
maximum re-signing interval and not less than the zone expiry time. maximum re-signing interval and not less than the zone expiry time.
4.5 The Root Zone as Signer and Zone Skipping 4.5 The Root Zone as Signer
It should be noted that in DNS the root is a zone unto itself. Thus It should be noted that in DNS the root is a zone unto itself. Thus
the root zone key should only be seen signing itself or signing RRs the root zone key should only be seen signing itself or signing RRs
with names one level below root, such as .aq, .edu, or .arpa. with names one level below root, such as .aq, .edu, or .arpa.
Implementations SHOULD reject as bogus any purported root signature Implementations SHOULD reject as bogus any purported root signature
of records with a name more than one level below root. The root zone of records with a name more than one level below root. The root zone
contains the root KEY RR signed by a SIG RR under the root key contains the root KEY RR signed by a SIG RR under the root key
itself. itself.
The signing authority of a zone key ends with the delegation points
within that zone. Implementations SHOULD reject purported signatures
on data below the apex of a subzone (or even lower level data) by the
superzone's key.
5. Non-existent Names and Types 5. Non-existent Names and Types
The SIG RR mechanism described in Section 4 above provides strong The SIG RR mechanism described in Section 4 above provides strong
authentication of RRs that exist in a zone. But is it not clear authentication of RRs that exist in a zone. But is it not clear
above how to authenticatably deny the existence of a name in a zone above how to authenticatably deny the existence of a name in a zone
or a type for an existent name. or a type for an existent name.
The nonexistence of a name in a zone is indicated by the NXT ("next") The nonexistence of a name in a zone is indicated by the NXT ("next")
RR for a name interval containing the nonexistent name. A NXT RR and RR for a name interval containing the nonexistent name. A NXT RR and
its SIG are returned in the authority section, along with the error, its SIG are returned in the authority section, along with the error,
skipping to change at page 28, line 18 skipping to change at page 28, line 18
a bit map, as shown below. a bit map, as shown below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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 / | next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type bit map / | type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NXT RR type bit map is one bit per RR type present for the owner The NXT RR type bit map format currently defined is one bit per RR
name similar to the WKS RR socket bit map. The first bit represents type present for the owner name similar to the WKS RR socket bit map.
RR type zero (an illegal type which should not be present.) A one bit The first bit represents RR type zero (an illegal type which can not
indicates that at least one RR of that type is present for the owner be present.) A one bit indicates that at least one RR of that type
name. A zero indicates that no such RR is present. All bits not is present for the owner name. A zero indicates that no such RR is
specified because they are beyond the end of the bit map are assumed present. All bits not specified because they are beyond the end of
to be zero. Note that bit 30, for NXT, will always be on so the the bit map are assumed to be zero. Note that bit 30, for NXT, will
minimum bit map length is actually four octets. The NXT bit map always be on so the minimum bit map length is actually four octets.
should be printed as a list of RR type mnemonics or decimal numbers Trailing zero octets are prohibited in this format. This format must
similar to the WKS RR. be used unless there are RRs with a type number greater than 127. If
the zero bit of the type bit map is a one, it indicates that a
different format is in use which is to be defined.
The NXT bit map should be printed as a list of RR type mnemonics or
decimal numbers similar to the WKS RR.
The domain name may be compressed with standard DNS name compression The domain name may be compressed with standard DNS name compression
when being transmitted over the network. The size of the bit map can when being transmitted over the network. The size of the bit map can
be inferred from the RDLENGTH and the length of the next domain name. be inferred from the RDLENGTH and the length of the next domain name.
5.3 Example 5.3 Example
Assume zone foo.nil has entries for Assume zone foo.nil has entries for
big.foo.nil, big.foo.nil,
medium.foo.nil. medium.foo.nil.
small.foo.nil. small.foo.nil.
tiny.foo.nil. tiny.foo.nil.
Then a query to a security aware server for huge.foo.nil would Then a query to a security aware server for huge.foo.nil would
produce an error reply with an RCODE of NXDOMAIN and the authority produce an error reply with an RCODE of NXDOMAIN and the authority
section data including something like the following: section data including something like the following:
big.foo.nil. NXT medium.foo.nil. A MX SIG NXT big.foo.nil. NXT medium.foo.nil. A MX SIG NXT
big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
19960102030405 ;signature expiration 19970102030405 ;signature expiration
19951211100908 ;time signed 19961211100908 ;time signed
21435 ;key identifier 2143 ;key identifier
foo.nil. ;signer foo.nil. ;signer
MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
) )
Note that this response implies that big.foo.nil is an existing name Note that this response implies that big.foo.nil is an existing name
in the zone and thus has other RR types associated with it than NXT. in the zone and thus has other RR types associated with it than NXT.
However, only the NXT (and its SIG) RR appear in the response to this However, only the NXT (and its SIG) RR appear in the response to this
query for huge.foo.nil, which is a non-existent name. query for huge.foo.nil, which is a non-existent name.
5.4 Special Considerations at Delegation Points 5.4 Special Considerations at Delegation Points
A name (other than root) which is the head of a zone also appears as A name (other than root) which is the head of a zone also appears as
the leaf in a superzone. If both are secure, there will always be the leaf in a superzone. If both are secure, there will always be
two different NXT RRs with the same name. They can be distinguished two different NXT RRs with the same name. They can be distinguished
by their signers and next domain name fields. Security aware servers by their signers and next domain name fields. Security aware servers
should return the correct NXT automatically when required to should return the correct NXT automatically when required to
authenticate the non-existence of a name and both NXTs, if available, authenticate the non-existence of a name and both NXTs, if available,
on explicit query for type NXT. on explicit query for type NXT.
Non-security aware servers will never automatically return an NXT and some old Non-security aware servers will never automatically return an NXT and
implementations may only return the NXT from the subzone on explicit some old implementations may only return the NXT from the subzone on
queries. explicit queries.
5.5 Zone Transfers 5.5 Zone Transfers
The sections below descrie how full and incremental zone transfers are secured. The sections below describe how full and incremental zone transfers
are secured.
SIG RRs secure
all authoritative RRs transferred for both full and incremental [RFC 1995]
zone transfers. NXT RRs are an essential elements in secure zone transfers
and assure that every authoritative name and type will be present;
however, if there
are multiple SIGs with the same name and type covered a subset of the
SIGs could
be sent as long as at least one is present and, in the case of
unsigned delegation point NS or glue A or AAAA RRs a subset of these
RRs could be sent as long as at least one of each type is included.
When an incremental or full zone transfer request is received with
the same or newer version number than that of
the server's copy of the zone is received, it is replied to with just
the SOA RR of
the server's current version and the SIG(s) verifying that SOA RR.
5.5.1 Full Zone Transfers SIG RRs secure all authoritative RRs transferred for both full and
incremental [RFC 1995] zone transfers. NXT RRs are an essential
elements in secure zone transfers and assure that every authoritative
name and type will be present; however, if there are multiple SIGs
with the same name and type covered a subset of the SIGs could be
sent as long as at least one is present and, in the case of unsigned
delegation point NS or glue A or AAAA RRs a subset of these RRs could
be sent as long as at least one of each type is included.
Even if all SIGs in a transfer verify, this does not To provide server authentication that a complete transfer has
indicate that the entire zone has been transfered. However the NXT name chain occurred, transaction authentication SHOULD be used on all full zone
can be used to verify that RRs for all authoritative transfers. This provides strong protection for the entire zone in
names have been transfered and the transit.
NXT type bit map can be used to verify that at least one of
all RR types for those names
have been transfered.
In combination, the above checks provide security checking for all
signed RRs in a full zone
transfer of a secure zone.
To provide server authentication that a complete transfer has occured, When an incremental or full zone transfer request is received with
transaction authentication SHOULD be used on all full zone transfers. This the same or newer version number than that of the server's copy of
provides strong protection for the entire zone in transit. the zone, it is replied to with just the SOA RR of the server's
current version and the SIG(s) verifying that SOA RR.
5.5.2 Incremental Zone Transfers 5.5.1 Incremental Zone Transfers
Individual RRs in an incremental (IXFR) transfer [RFC 1995] Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
can be verified in the same way as for a full zone transfer and verified in the same way as for a full zone transfer and the
the integrity of the NXT name chain and correctness of the NXT type bits integrity of the NXT name chain and correctness of the NXT type bits
for the zone after the incremental RR deletes and adds can check each for the zone after the incremental RR deletes and adds can check each
disjoint area of the zone updated. disjoint area of the zone updated. But the completeness of an
But the completeness of an incremental transfer can not because usually incremental transfer can not be confirmed because usually neither the
neither the deleted RR section nor the added RR section deleted RR section nor the added RR section has a compete NXT chain.
has a compete NXT chain. As a result, a server which securely supports As a result, a server which securely supports IXFR must handle IXFR
IXFR must handle IXFR SIG RRs for each incremental transfer set SIG RRs for each incremental transfer set that it maintains.
that it maintains.
The IXFR SIG is calculated over the incremental zone update collection of The IXFR SIG is calculated over the incremental zone update
RRs in the order in which it is tranmitted: old SOA, then deleted RRs, then collection of RRs in the order in which it is transmitted: old SOA,
new SOA and added RRs. It is recommended that, within each section, RRs then deleted RRs, then new SOA and added RRs. It is recommended
be ordered as specified in Section 8. If condensation of adjacent that, within each section, RRs be ordered as specified in Section 8.
incremental update sets is done by the zone owner, If condensation of adjacent incremental update sets is done by the
the original IXFR SIG for each set included zone owner, the original IXFR SIG for each set included in the
in the condensation must be discarded condensation must be discarded and a new on IXFR SIG calculated to
and a new on IXFR SIG calculated to cover the resulting condensed set. cover the resulting condensed set.
The IXFR SIG really belongs to the zone as a whole, not to the zone The IXFR SIG really belongs to the zone as a whole, not to the zone
name. Although it should be correct for the zone name, the labels name. Although it should be correct for the zone name, the labels
field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only
sent as part of an incremental zone transfer. After validation of the IXFR sent as part of an incremental zone transfer. After validation of
SIG, the transfered RRs MAY be considered valid without verification of the the IXFR SIG, the transferred RRs MAY be considered valid without
internal SIGs. verification of the internal SIGs.
6. How to Resolve Securely and The AD and CD Bits 6. How to Resolve Securely and the AD and CD Bits
Retrieving or resolving secure data from the Domain Name System Retrieving or resolving secure data from the Domain Name System (DNS)
(DNS) involves starting with one or more trusted public keys for one involves starting with one or more trusted public keys that have been
or more zones. With trusted keys, a resolver willing to perform staticly configured at the resolver. With starting trusted keys, a
cryptography can progress securely through the secure DNS zone resolver willing to perform cryptography can progress securely
structure to the zone of interest as described in Section 6.3. Such through the secure DNS zone structure to the zone of interest as
trusted public keys would normally be configured in a manner similar described in Section 6.3. Such trusted public keys would normally be
to that described in Section 6.2. However, as a practical matter, a configured in a manner similar to that described in Section 6.2.
security aware resolver would still gain some confidence in the However, as a practical matter, a security aware resolver would still
results it returns even if it was not configured with any keys but gain some confidence in the results it returns even if it was not
trusted what it got from a local well known server as a starting configured with any keys but trusted what it got from a local well
point. known server as a starting point.
Data stored at a security aware server needs to be internally Data stored at a security aware server needs to be internally
categorized as Authenticated, Pending, or Insecure. There is also a categorized as Authenticated, Pending, or Insecure. There is also a
fourth transient state of Bad which indicates that all SIG checks fourth transient state of Bad which indicates that all SIG checks
have explicitly failed on the data. Such Bad data is not retained at have explicitly failed on the data. Such Bad data is not retained at
a security aware server. Authenticated means that the data has a a security aware server. Authenticated means that the data has a
valid SIG under a KEY traceable via a chain of zero or more SIG and valid SIG under a KEY traceable via a chain of zero or more SIG and
KEY RRs to a KEY staticly configured at the resolver. KEY RRs allowed by the resolvers policies to a KEY staticly
Pending data has no authenticated SIGs and at least one additional configured at the resolver. Pending data has no authenticated SIGs
SIG the resolver is still trying to authenticate. Insecure data is and at least one additional SIG the resolver is still trying to
data which it is known can never be either Authenticated or found Bad authenticate. Insecure data is data which it is known can never be
because it is in or has been reached via a unsecured zone. Behavior either Authenticated or found Bad because it is in or has been
in terms of control of and flagging based on such data labels is reached via a unsecured zone. Behavior in terms of control of and
described in Section 6.1. flagging based on such data labels is described in Section 6.1.
The proper validation of signatures requires a reasonably secure The proper validation of signatures requires a reasonably secure
shared opinion of the absolute time between resolvers and servers as shared opinion of the absolute time between resolvers and servers as
described in Section 6.4. described in Section 6.4.
6.1 The AD and CD Header Bits 6.1 The AD and CD Header Bits
Two previously unused bits are allocated out of the DNS Two previously unused bits are allocated out of the DNS
query/response format header. The AD (authentic data) bit indicates query/response format header. The AD (authentic data) bit indicates
in a response that the data included has been verified by the server in a response that the data included has been verified by the server
providing it. The CD (checking disabled) bit indicates in a query providing it according to the policies of that server. The CD
that non-verified data is acceptable to the resolver sending the (checking disabled) bit indicates in a query that Pending (non-
query. verified) data is acceptable to the resolver sending the query.
These bits are allocated from the must-be-zero Z field as follows: These bits are allocated from the previously must-be-zero Z field as
follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | | QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 33, line 25 skipping to change at page 32, line 25
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | | NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These bits are zero in old servers and resolvers. Thus the responses These bits are zero in old servers and resolvers. Thus the responses
of old servers are not flagged as authenticated to security aware of old servers are not flagged as authenticated to security aware
resolvers and queries from non-security aware resolvers do not assert resolvers and queries from non-security aware resolvers do not assert
the checking disabled bit and thus will be answered by security aware the checking disabled bit and thus will be answered by security aware
servers only with valid data. Aware resolvers MUST NOT trust the AD servers only with Authenticated or Insecure data. Aware resolvers
bit unless they trust the server they are talking to and either have MUST NOT trust the AD bit unless they trust the server they are
a secure path to it or use DNS transaction security. talking to and either have a secure path to it or use DNS transaction
security.
Any security aware resolver willing to do cryptography SHOULD assert Any security aware resolver willing to do cryptography SHOULD assert
the CD bit on all queries to reduce DNS latency time by allowing the CD bit on all queries to permit it to impose its own policies and
security aware servers to answer before they have resolved the to reduce DNS latency time by allowing security aware servers to
validity of data. answer with Pending data.
Security aware servers NEVER return Bad data. For non-security aware Security aware servers NEVER return Bad data. For non-security aware
resolvers or security aware resolvers requesting service by having resolvers or security aware resolvers requesting service by having
the CD bit clear, security aware servers MUST return only the CD bit clear, security aware servers MUST return only
Authenticated or Insecure data with the AD bit set in the response. Authenticated or Insecure data with the AD bit set in the response.
Security aware resolvers will know if data is Insecure versus Security aware servers SHOULD return Pending data, with the AD bit
Authentic by the absence of SIG RRs. Security aware servers MAY clear in the response, to security aware resolvers requesting the
return Pending data to security aware resolvers requesting the service by asserting the CD bit in their request. The AD bit MUST
service by clearing the AD bit in the response. The AD bit MUST NOT NOT be set on a response unless all of the RRs in the response are
be set on a response unless all of the RRs in the response are either either Authenticated or Insecure.
Authenticated or Insecure.
6.2 Staticly Configured Keys 6.2 Staticly Configured Keys
The public key to authenticate a zone MUST be defined in local The public key to authenticate a zone SHOULD be defined in local
configuration files before that zone is loaded at the primary server. configuration files before that zone is loaded at the primary server
so the zone can be authenticated.
While it might seem logical for everyone to start with a key for the While it might seem logical for everyone to start with a key for the
root zone and staticly configure this in every resolver, this has root zone and staticly configure this in every resolver, this has
problems. The logistics of updating every DNS resolver in the world problems. The logistics of updating every DNS resolver in the world
when the root key changes would be excessive. It may be some time when the root key changes would be excessive. Furthermore, many
before there even is a root key. Furthermore, many organizations organizations will explicitly wish their "interior" DNS
will explicitly wish their "interior" DNS implementations to implementations to completely trust only their own zone. Such
completely trust only their own zone. Such interior resolvers can interior resolvers can then go through the organization's zone
then go through the organization's zone servers to access data servers to access data outsize the organization's domain and should
outsize the organization's domain and should only be configured with not be configured with keys above the organization's DNS apex.
the key for the organization's DNS apex.
Host resolvers that are not part of a larger organization will likely Host resolvers that are not part of a larger organization will likely
be configures with a key for the domain of their local ISP whose be configures with a key for the domain of their local ISP whose
recursive secure DNS caching server they use. recursive secure DNS caching server they use.
6.3 Chaining Through Zones 6.3 Chaining Through The DNS
Starting with one or more trusted keys for any zone, it should be Starting with one or more trusted keys for any zone, it should be
possible to retrieve signed keys for its subzones which have a key possible to retrieve signed keys for its subzones which have a key
and, if the zone is not root, for its superzone. Every authoritative and, if the zone is not root, for its superzone. Every authoritative
secure zone server MUST also include the KEY RR for a super-zone secure zone server MUST also include the KEY RR for one or more
signed by the secure zone via static configuration. This makes it super-zones (possibly including root) signed by the secure zone via
possible to climb the tree of zones if one starts below root. A static configuration. This makes it possible to climb the tree of
secure sub-zone is indicated by a KEY RR with non-null key zones if one starts below root. A secure sub-zone is indicated by a
information appearing with the NS RRs for the sub-zone. These make KEY RR with non-null key information appearing with the NS RRs for
it possible to descend within the tree of zones. the sub-zone. These make it possible to descend within the tree of
zones.
6.3.1 Chaining Through KEYs
In general, some RRset in the secure DNS will be signed by one or
more SIG RRs. Each of these SIG RRs has a signer under whose name is
stored the public KEY to use in verifying the SIG. Each of those
KEYs will, generally, also be signed with a SIG. And those SIGs will
also refer to KEYs. And so on. As a result, verifying leads to
chains of alternating SIG and KEY RRs with the first SIG signing the
original data whose validity is to be shown and the final KEY being
some key staticly configured at the resolver performing the
verification.
In testing such a chain, the validation of a SIG over some data with
reference to a KEY is an objective cryptographic test; however, the
judgement that a SIG with a particular signer name can authenticate
data (possibly a KEY RRset) with a particular owner name is a policy
question. Ultimately, this is a policy local to the resolver and any
clients that depend on that resolver's decisions. It is, however,
strongly recommended, that the following policy be adopted:
Let A < B mean that A is a shorter domain name than B formed by
dropping one or more whole labels from the left end of B. Let A
= B mean that A and B are the same domain name (i.e., are
identical after letter case canonicalization). Let A > B mean
that A is a longer domain name than B formed by adding one or
more whole labels on the left end of B.
Let K be the owner names of the set of staticly configured
trusted keys at a resolver.
Then SG is a valid signer name for a SIG authenticating data
(possibly a KEY RRset) with owner name OW at a resolver if any
of the following three rules apply:
(1) OW > SG except that if SG is root (.), OW must be a top
level domain name.
(2) ( OW < or = SG ) and ( SG > some K ).
(3) SG = some K.
Rule 1 is the rule for descending the DNS tree and includes a special
prohibition on the root zone key due to the restriction that the root
zone be only one label deep.
Rule 2 is the rule for ascending the DNS tree from one or more
staticly configured keys. Rule 2 has no effect if only root keys are
staticly configured.
Rule 3 is a rule permitting direct cross certification.
Great care should be taken that the consequences have been fully
considered before making any local policy adjustments to these rules.
6.3.2 Conflicting Data
It is possible that there will be multiple SIG-KEY chains that appear
to authenticate conflicting RRset answers to the same query. A
resolver should choose only the most reliable answer to return and
discard other data. This choice of most reliable is a matter of
local policy which could take into account differing trust in
algorithms, key sizes, staticly configured keys, zones traversed,
etc. The technique given below is recommended for taking into
account SIG-KEY chain length.
A resolver should keep track of the number of successive secure 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 traversed from a staticly configured zone key starting point to any
general, the lower such a distance number is, the greater the secure zone it can reach. In general, the lower such a distance
confidence in the data. Data configured via a boot file directive number is, the greater the confidence in the data. Staticly
should be given a distance number of zero. If a query encounters configured data should be given a distance number of zero. If a
different data for the same query with different distance values, query encounters different Authenticated data for the same query with
that with a larger value should be ignored unless some other local different distance values, that with a larger value should be ignored
policy covers the case and requires a different trust model. unless some other local policy covers the case.
A security conscious resolver should completely refuse to step from a A security conscious resolver should completely refuse to step from a
secure zone into a unsecured zone unless the unsecured zone is secure zone into a unsecured zone unless the unsecured zone is
certified to be non-secure by the presence of an authenticated KEY RR certified to be non-secure by the presence of an authenticated KEY RR
for the unsecured zone with the no-key type value. Otherwise the for the unsecured zone with the no-key type value. Otherwise the
resolver is getting bogus or spoofed data. resolver is getting bogus or spoofed data.
If legitimate unsecured zones are encountered in traversing the DNS If legitimate unsecured zones are encountered in traversing the DNS
tree, then no zone can be trusted as secure that can be reached only tree, then no zone can be trusted as secure that can be reached only
via information from such non-secure zones. Since the unsecured zone via information from such non-secure zones. Since the unsecured zone
data could have been spoofed, the "secure" zone reach via it could be data could have been spoofed, the "secure" zone reach via it could be
counterfeit. The "distance" to data in such zones or zones reached counterfeit. The "distance" to data in such zones or zones reached
via such zones could be set to 256 or more as this exceeds the via such zones could be set to 256 or more as this exceeds the
largest possible distance through secure zones in the DNS. largest possible distance through secure zones in the DNS.
Nevertheless, continuing to apply secure checks within "secure" zones Nevertheless, continuing to apply secure checks within "secure" zones
reached via unsecured zones is a good practice and will, as a reached via unsecured zones is a good practice and will, as a
practical matter, provide some small increase in security. practical matter, provide some small increase in confidence.
6.4 Secure Time 6.4 Secure Time
Coordinated interpretation of the time fields in SIG RRs requires Coordinated interpretation of the time fields in SIG RRs requires
that reasonably consistent time be available to the hosts that reasonably consistent time be available to the hosts
implementing the DNS security extensions. implementing the DNS security extensions.
A variety of time synchronization protocols exist including the A variety of time synchronization protocols exist including the
Network Time Protocol (NTP, RFC 1305). If such protocols are used, Network Time Protocol (NTP, RFC 1305). If such protocols are used,
they MUST be used securely so that time can not be spoofed. they MUST be used securely so that time can not be spoofed.
Otherwise, for example, a host could get its clock turned back and 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 might then believe old SIG RRs, and the data they authenticate, which
are. were valid but are no longer.
7. ASCII Representation of Security RRs 7. ASCII Representation of Security RRs
This section discusses the format for master file and other ASCII This section discusses the format for master file and other ASCII
presentation of the three DNS security resource records. presentation of the three DNS security resource records.
The algorithm field in KEY and SIG RRs can be represented as either The algorithm field in KEY and SIG RRs can be represented as either
an unsigned integer or symbolicly. The following initial symbols are an unsigned integer or symbolicly. The following initial symbols are
defined as indicated: defined as indicated:
value symbol
001 RSAMD5 001 RSAMD5
253 NULL (obsolete, see RFC 2065) 253 NULL (obsolete, see RFC 2065)
254 PRIVATE 254 PRIVATE
The key identifier field in KEY and SIG PRs is represented as an
unsigned integer.
7.1 Presentation of KEY RRs 7.1 Presentation of KEY RRs
KEY RRs may appear as single logical lines in a zone data master file KEY RRs may appear as single logical lines in a zone data master file
[RFC 1033]. [RFC 1033].
The flag field is represented as an unsigned integer or a sequence of The flag field is represented as an unsigned integer or a sequence of
mnemonics as follows: mnemonics as follows:
BIT Mnemonic Explanation BIT Mnemonic Explanation
0 NOAUTH authentication use prohibited 0 NOAUTH authentication use prohibited
1 NOCONF confidentiality use prohibited 1 NOCONF confidentiality use prohibited
5 USERK user key 2 FLAG2 - reserved
6 ENTITYK end entity key 3 EXTEND flags extension
7 ZONEK zone key 4 FLAG4 - reserved
8 IPSECK IPSEC key 5 FLAG5 -reserved
9 MAILK email key 6-7 name type
10 TLSK TLS key USER =0
ZONE =1
HOST =2 (host or other end entity)
NTYP3 - reserved
8 OAKLEY key usable for Oakley/IPSEC
9 FLAG9 - reserved
10 FLAG10 - reserved
11 FLAG11 - reserved
12-15 signatory field, values 0 to 15 12-15 signatory field, values 0 to 15
can be represented by SIG0, SIG1, ... SIG15 can be represented by SIG0, SIG1, ... SIG15
The preference field appear as unsigned integers.
The protocol octet can be represented as either an unsigned integer The protocol octet can be represented as either an unsigned integer
or symbolicly. The following initial symbols are defined: or symbolicly. The following initial symbols are defined:
000 NONE 000 NONE
255 ALL 001 TLS 002 EMAIL
Note that if the type field has the "no key" value (ie, both NOAUTH
Note that if the type field has the "no key" value, nothing appears and NOCONF are on), nothing appears after the algorithm octet.
after the algorithm octet.
The remaining public key portion is represented in base 64 (see The remaining public key portion is represented in base 64 (see
Appendix A) and may be divided up into any number of white space Appendix A) and may be divided up into any number of white space
separated substrings, down to single base 64 digits, which are separated substrings, down to single base 64 digits, which are
concatenated to obtain the full signature. These substrings can span concatenated to obtain the full signature. These substrings can span
lines using the standard parenthesis. lines using the standard parenthesis.
Note that the public key may have internal sub-fields but these do Note that the public key may have internal sub-fields but these do
not appear in the master file representation. For example, with not appear in the master file representation. For example, with
algorithm 1 there is a public exponent size, then a public exponent, algorithm 1 there is a public exponent size, then a public exponent,
skipping to change at page 37, line 40 skipping to change at page 37, line 44
The original TTL field appears as an unsigned integer. The original TTL field appears as an unsigned integer.
If the original TTL, which applies to the type signed, is the same as If the original TTL, which applies to the type signed, is the same as
the TTL of the SIG RR itself, it may be omitted. The date field the TTL of the SIG RR itself, it may be omitted. The date field
which follows it is larger than the maximum possible TTL so there is which follows it is larger than the maximum possible TTL so there is
no ambiguity. no ambiguity.
The "labels" field appears as an unsigned integer. The "labels" field appears as an unsigned integer.
The key identifier appears as unsigned decimal numbers. The key tag appears as an unsigned number.
However, the signature itself can be very long. It is the last data However, the signature itself can be very long. It is the last data
field and is represented in base 64 (see Appendix A) and may be field and is represented in base 64 (see Appendix A) and may be
divided up into any number of white space separated substrings, down divided up into any number of white space separated substrings, down
to single base 64 digits, which are concatenated to obtain the full to single base 64 digits, which are concatenated to obtain the full
signature. These substrings can be split between lines using the signature. These substrings can be split between lines using the
standard parenthesis. standard parenthesis.
7.3 Presentation of NXT RRs 7.3 Presentation of NXT RRs
NXT RRs do not appear in original unsigned zone master files since NXT RRs do not appear in original unsigned zone master files since
they should be derived from the zone as it is being siged. If a they should be derived from the zone as it is being signed. If a
signed file with NXTs added is printed, they appear as the next signed file with NXTs added is printed or NXTs are printed by
domain name followed by the RR type present bits in the same format debugging code, they appear as the next domain name followed by the
as the WKS RR. RR type present bits in the same format as the WKS RR.
8. Canonical Form and Order of Resource Records 8. Canonical Form and Order of Resource Records
This section describes the canonical form of resource records (RRs), This section describes the canonical form of resource records (RRs),
their default name order, and their intra-RRset order, for purposes their default name order, and their intra-RRset order, for purposes
of domain name system (DNS) security. A canonical name order is of domain name system (DNS) security. A canonical name order is
necessary to construct the NXT name chain. A canonical form and necessary to construct the NXT name chain. A canonical form and
ordering within an RRset is necessary in construsting SIG RRs. There ordering within an RRset is necessary in constructing SIG RRs. There
is no requirement in DNS security for a canonical ordering of types is no requirement in DNS security for a canonical ordering of types
within a name so none is defined. within a name so none is defined.
8.1 Canonical RR Form 8.1 Canonical RR Form
For purposes of DNS security, the canonical form for an RR is the For purposes of DNS security, the canonical form for an RR is the
wire format of the RR with domain names (1) fully expanded (no name wire format of the RR with domain names (1) fully expanded (no name
compression via pointers), (2) all domain name letters set to lower compression via pointers), (2) all domain name letters set to lower
case, and (3) the original TTL substituted for the current TTL. case, and (3) the original TTL substituted for the current TTL.
skipping to change at page 40, line 15 skipping to change at page 40, line 15
9. Conformance 9. Conformance
Levels of server and resolver conformance are defined below. Levels of server and resolver conformance are defined below.
9.1 Server Conformance 9.1 Server Conformance
Two levels of server conformance for DNS security are defined as Two levels of server conformance for DNS security are defined as
follows: follows:
BASIC: Basic server compliance is the ability to store and retrieve BASIC: Basic server compliance is the ability to store and retrieve
(including zone transfer) SIG, KEY, and NXT RRs. Any secondary, (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or
caching, or other server for a secure zone MUST have at least basic caching server for a secure zone MUST have at least basic compliance
compliance and even then some things, such as secure CNAMEs, will not and even then some things, such as secure CNAMEs, will not work
work without full compliance. without full compliance.
FULL: Full server compliance adds the following to basic compliance: FULL: Full server compliance adds the following to basic compliance:
(1) ability to read SIG, KEY, and NXT RRs in zone files and (2) (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
ability, given a zone file and private key, to add appropriate SIG ability, given a zone file and private key, to add appropriate SIG
and NXT RRs, possibly via a separate application, (3) proper and NXT RRs, possibly via a separate application, (3) proper
automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
suppression of CNAME following on retrieval of the security type RRs, suppression of CNAME following on retrieval of the security type RRs,
(5) recognize the CD query header bit and set the AD query header (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 bit, as appropriate, and (6) proper handling of the two NXT RRs at
delegation points. Primary servers for secure zones MUST be fully delegation points. Primary servers for secure zones MUST be fully
skipping to change at page 44, line 19 skipping to change at page 44, line 19
318 Acton Street 318 Acton Street
Carlisle, MA 01741 USA Carlisle, MA 01741 USA
Telephone: +1 508-287-4877 Telephone: +1 508-287-4877
+1 508-371-7148(fax) +1 508-371-7148(fax)
+1 703-620-4200(main office, Reston, Virginia, USA) +1 703-620-4200(main office, Reston, Virginia, USA)
EMail: dee@cybercash.com EMail: dee@cybercash.com
Expiration and File Name Expiration and File Name
This draft expires January 1998. This draft expires 19 February 1998.
Its file name is draft-ietf-dnssec-secext2-00.txt. Its file name is draft-ietf-dnssec-secext2-01.txt.
Appendix A: Base 64 Encoding Appendix A: Base 64 Encoding
The following encoding technique is taken from RFC 1521 by N. The following encoding technique is taken from RFC 1521 by N.
Borenstein and N. Freed. It is reproduced here in an edited form for Borenstein and N. Freed. It is reproduced here in an edited form for
convenience. convenience.
A 65-character subset of US-ASCII is used, enabling 6 bits to be A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=", represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.) is used to signify a special processing function.)
skipping to change at page 47, line 7 skipping to change at page 47, line 7
multiple of 24 bits; here, the final unit of encoded output will be multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "=" unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character. characters followed by one "=" padding character.
Appendix B: Changes from RFC 2065 Appendix B: Changes from RFC 2065
This section sumarizes the most important changes that have been made This section summarizes the most important changes that have been
since RFC 2065. made since RFC 2065.
1. Most of Section 7 of RFC 2065 called "Operational Considerations", 1. Most of Section 7 of RFC 2065 called "Operational Considerations",
has been split off into a separate document. has been split off into a separate document.
2. The KEY RR has been changed by (2a) expanding the flags field to 2. The KEY RR has been changed by (2a) eliminating the "experimental"
32 bits, (2b) eliminating the "experimental" flag as unnecessary, flag as unnecessary, (2b) reserving a flag bit for flags
(2c) defining a number of additional flags, (2d) adding the expansion, (2c) more compactly encoding a number of bit fields in
preference and key identifier fields, and (2e) for the RSA MD5 such a way as to leave unchanged bits actually used by the limited
algorithm, fixing the exponent size at two octets and increasing code currently deployed, and (2d) for the RSA MD5 algorithm
the maximum required key modulus size implementation to 4096 bits. increasing the maximum required key modulus size implementation to
Section 3.4 describing the meaning of various combintions of "no- 4096 bits. Section 3.4 describing the meaning of various
key" and key present KEY RRs has been added. combinations of "no-key" and key present KEY RRs has been added.
3. The SIG RR has been changed by (3a) claifying that signature 3. The SIG RR has been changed by (3a) clarifying that signature
expiration and date signed used serial number ring arithmetic, and expiration and date signed used serial number ring arithmetic, and
(3b) changing the definition of the key footprint/identifier. In (3b) changing the definition of the key footprint/tag for
addition, the SIG AXFR has been eliminated. algorithms other than 1 (i.e., algorithms to be defined in the
future) and adding Appendix C to document its calculation. In
4. The key footprint has been changed from algorithm specific to user addition, the SIG covering type AXFR has been eliminated.
determined and renamed the "key identifier", due to implementors
requests for assured "footprint" uniqueness. It now occurs in
both the SIG and KEY RRs.
5. Both the KEY and SIG RR definitions have been simplified by 5. Both the KEY and SIG RR definitions have been simplified by
eliminating the "null" algorithm 253 as defined in RFC 2065. That eliminating the "null" algorithm 253 as defined in RFC 2065. That
algorithm had been included because at the time it was thought it algorithm had been included because at the time it was thought it
might be useful in DNS dynamic update. It was in fact not so used might be useful in DNS dynamic update [RFC 2136]. It was in fact
and it is dropped to simplify DNS security. not so used and it is dropped to simplify DNS security.
6. The NXT RRs in a zone have been extended to cover all names, 6. The NXT RR has been changed so that (6a) the NXT RRs in a zone
including wildcards as literal names without expansion. cover all names, including wildcards as literal names without
expansion and (6b) all NXT bit map areas whose first octet has bit
zero set have been reserved for future definition, and (6c)
additional minor changes made to assure a unique encoding of RR
type combinations currently existing int he DNS.
7. Information on the canonical form and ordering of RRs has been 7. Information on the canonical form and ordering of RRs has been
moved into a separate section, number 8. moved into a separate section, number 8.
8. A subsection covering incremental and full zone transfer has been 8. A subsection covering incremental and full zone transfer has been
added. added in Section 5.
9. Further specification and policy recommendations on secure
resolution have been added, primarily in section 6.3.1.
Appendix C: Key Tag Calculation
The key tag field in the SIG RR is just a means of more efficiently
selecting the correct KEY RR to use in verifying the signature when
there is more than one KEY RR candidate. It is possible for more
than one candidate key to have the same tag, in which case each must
be tried in verifying the signature until one works or all fail. The
following reference implementation is in ANSI C.
void keytag (
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */
unsigned char tag[2] /* return calculated tag */
)
{
long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFF;
tag[0] = ac>>8;
tag[1] = ac;
}
 End of changes. 129 change blocks. 
474 lines changed or deleted 477 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/