draft-ietf-dnssec-secext2-05.txt   draft-ietf-dnssec-secext2-06.txt 
DNS Security Working Group Donald E. Eastlake 3rd DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT IBM
OBSOLETES RFC 2065 OBSOLETES RFC 2065
UPDATES RFC 1034, 1035 UPDATES RFCs 1034, 1035, and 2181
Expires: May 1999 November 1998
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-05.txt, is intended This draft, file name draft-ietf-dnssec-secext2-06.txt, is intended
to become a Proposed Standard RFC obsoleting Proposed Standard RFC to become a Proposed Standard RFC obsoleting Proposed Standard RFC
2065. Distribution of this document is unlimited. Comments should be 2065. Distribution of this document is unlimited. Comments should be
sent to the DNS Security Working Group mailing list <dns- sent to the DNS Security Working Group mailing list <dns-
security@tis.com> or to the author. security@tis.com> 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.
skipping to change at page 2, line 5 skipping to change at page 1, line 37
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
``working draft'' or ``work in progress.'' ``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
[[changed from previous draft: add IANA Considerations section,
update dates and file name, update author info, update references
where new documents have superceded those previously referenced, add
reference to RFC 2119, clarify wording, minor change at 4.1.5 to
explain why modular time does not induce a security flaw, clarify
that the zone key for a secure subzone need not be included at the
leaf node in the superzone, specify that algorithm 254 OIDs are BER
encoded, add algorithm 253 for domain name encoded private
algorithm]]
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 and data integrity and authentication to security aware resolvers and
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 also be provided through non-security aware records. Security can also be provided through non-security aware
DNS servers in some cases. DNS servers in some cases.
The extensions provide for the storage of authenticated public keys The extensions provide for the storage of authenticated public keys
skipping to change at page 2, line 40 skipping to change at page 2, line 40
The significant contributions and suggestions of the following The significant contributions and suggestions of the following
persons (in alphabetic order) to DNS security are gratefully persons (in alphabetic order) to DNS security are gratefully
acknowledged: acknowledged:
James M. Galvin James M. Galvin
John Gilmore John Gilmore
Olafur Gudmundsson Olafur Gudmundsson
Charlie Kaufman Charlie Kaufman
Edward Lewis Edward Lewis
Thomas Narten
Radia J. Perlman Radia J. Perlman
Jeffrey I. Schiller Jeffrey I. Schiller
Steven (Xunhua) Wang Steven (Xunhua) Wang
Brian Wellington Brian Wellington
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................2 Abstract...................................................2
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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..............................8 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......................................12 3.1 KEY RDATA format......................................12
3.1.1 Object Types, DNS Names, and Keys...................13 3.1.1 Object Types, DNS Names, and Keys...................12
3.1.2 The KEY RR Flag Field...............................13 3.1.2 The KEY RR Flag Field...............................13
3.1.3 The Protocol Octet..................................14 3.1.3 The Protocol Octet..................................14
3.2 The KEY Algorithm Number Specification................15 3.2 The KEY Algorithm Number Specification................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................................18
4.1 SIG RDATA Format......................................19
4.1.1 Type Covered Field..................................19
4.1.2 Algorithm Number Field..............................19
4.1.3 Labels Field........................................19
4.1.4 Original TTL Field..................................20
4.1.5 Signature Expiration and Inception Fields...........20
4.1.6 Key Tag Field.......................................21
4.1.7 Signer's Name Field.................................21
4.1.8 Signature Field.....................................22
4.1.8.1 Calculating Transaction and Request SIGs..........22
4.2 SIG RRs in the Construction of Responses..............23
4.3 Processing Responses and SIG RRs......................24
4.4 Signature Lifetime, Expiration, TTLs, and Validity....25
5. Non-existent Names and Types...........................25
5.1 The NXT Resource Record...............................26
5.2 NXT RDATA Format......................................27
5.3 Additional Complexity Due to Wildcards................27
5.4 Example...............................................28
5.5 Special Considerations at Delegation Points...........28
5.6 Zone Transfers........................................29
5.6.1 Full Zone Transfers.................................29
5.6.2 Incremental Zone Transfers..........................30
6. How to Resolve Securely and the AD and CD Bits.........30
6.1 The AD and CD Header Bits.............................31
6.2 Staticly Configured Keys..............................32
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
7. ASCII Representation of Security RRs...................35
7.1 Presentation of KEY RRs...............................36
7.2 Presentation of SIG RRs...............................37
7.3 Presentation of NXT RRs...............................38
8. Canonical Form and Order of Resource Records...........38
8.1 Canonical RR Form.....................................38
8.2 Canonical DNS Name Order..............................38
8.3 Canonical RR Ordering Within An RRset.................39
8.4 Canonical Ordering of RR Types........................39
9. Conformance............................................39
9.1 Server Conformance....................................39
9.2 Resolver Conformance..................................40
10. Security Considerations...............................40
11. IANA Considerations...................................41
4. The SIG Resource Record................................20 References................................................42
4.1 SIG RDATA Format......................................20
4.1.1 ....................................................20
4.1.2 Algorithm Number Field..............................21
4.1.3 Labels Field........................................21
4.1.4 Original TTL Field..................................21
4.1.5 Signature Expiration and Inception Fields...........22
4.1.6 Key Tag Field.......................................22
4.1.7 Signer's Name Field.................................22
4.1.8 Signature Field.....................................23
4.1.8.1 Calculating Transaction and Request SIGs..........23
4.2 SIG RRs in the Construction of Responses..............24
4.3 Processing Responses and SIG RRs......................25
4.4 Signature Lifetime, Expiration, TTLs, and Validity....26
5. Non-existent Names and Types...........................27
5.1 The NXT Resource Record...............................27
5.2 NXT RDATA Format......................................28
5.3 Additional Complexity Due to Wildcards................28
5.4 Example...............................................29
5.5 Special Considerations at Delegation Points...........30
5.6 Zone Transfers........................................30
5.6.1 Full Zone Transfers.................................30
5.6.2 Incremental Zone Transfers..........................31
6. How to Resolve Securely and the AD and CD Bits.........32
6.1 The AD and CD Header Bits.............................32
6.2 Staticly Configured Keys..............................33
6.3 Chaining Through The DNS..............................34
6.3.1 Chaining Through KEYs...............................34
6.3.2 Conflicting Data....................................36
6.4 Secure Time...........................................36
7. ASCII Representation of Security RRs...................37
7.1 Presentation of KEY RRs...............................37
7.2 Presentation of SIG RRs...............................38
7.3 Presentation of NXT RRs...............................39
8. Canonical Form and Order of Resource Records...........40
8.1 Canonical RR Form.....................................40
8.2 Canonical DNS Name Order..............................40
8.3 Canonical RR Ordering Within An RRset.................41
8.4 Canonical Ordering of RR Types........................41
9. Conformance............................................42
9.1 Server Conformance....................................42
9.2 Resolver Conformance..................................42
10. Security Considerations...............................43
References................................................44
Author's Address..........................................46 Author's Address..........................................44
Expiration and File Name..................................46 Expiration and File Name..................................44
Appendix A: Base 64 Encoding..............................47 Appendix A: Base 64 Encoding..............................45
Appendix B: Changes from RFC 2065.........................49 Appendix B: Changes from RFC 2065.........................47
Appendix C: Key Tag Calculation...........................51 Appendix C: Key Tag Calculation...........................49
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, 1035 and later RFCs. An particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
earlier version of these extensions appears in RFC 2065. This earlier version of these extensions appears in RFC 2065. This
replacement for that RFC incorporates early implementation experience replacement for that RFC incorporates early implementation experience
and requests from potential users. and requests from potential users.
skipping to change at page 5, line 51 skipping to change at page 5, line 51
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 purposes. 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.
Sectuion 11 specified IANA considerations for allocation of
additional values of paramters defined in this document.
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 RRs defined in this document. file representation of some RRs 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 Appendix C specified how to calculate the simple checksum used as a
key tag in the SIG RR. key tag in most SIG RRs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Overview of the DNS Extensions 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
skipping to change at page 6, line 29 skipping to change at page 6, line 36
2.1 Services Not Provided 2.1 Services Not Provided
It is part of the design philosophy of the DNS that the data in it is It is part of the design philosophy of the DNS that the data in it is
public and that the DNS gives the same answers to all inquirers. public and that the DNS gives the same answers to all inquirers.
Following this philosophy, no attempt has been made to include any Following this philosophy, no attempt has been made to include any
sort of access control lists or other means to differentiate sort of access control lists or other means to differentiate
inquirers. inquirers.
No effort has been made to provide for any confidentiality for No effort has been made to provide for any confidentiality for
queries or responses. (This service may be available via IPSEC [RFC queries or responses. (This service may be available via IPSEC [RFC
1825], TLS [draft-ietf-tls-*], or other security protocols.) 1825], TLS, or other security protocols.)
Protection is not provided against denial of service. Protection is not provided against denial of service.
2.2 Key Distribution 2.2 Key Distribution
A resource record format is defined to associate keys with DNS names. A resource record format is defined to associate keys with DNS names.
This permits the DNS to be used as a public key distribution This permits the DNS to be used as a public key distribution
mechanism in support of DNS security itself and other protocols. mechanism in support of DNS security itself and other protocols.
The syntax of a KEY resource record (RR) is described in Section 3. The syntax of a KEY resource record (RR) is described in Section 3.
skipping to change at page 7, line 13 skipping to change at page 7, line 21
minimize the number of queries needed. minimize the number of queries needed.
2.3 Data Origin Authentication and Integrity 2.3 Data Origin Authentication and Integrity
Authentication is provided by associating with resource record sets Authentication is provided by associating with resource record sets
(RRsets [RFC 2181]) in the DNS cryptographically generated digital (RRsets [RFC 2181]) in the DNS cryptographically generated digital
signatures. Commonly, there will be a single private key that signatures. Commonly, there will be a single private key that
authenticates an entire zone but there might be multiple keys for authenticates an entire zone but there might be multiple keys for
different algorithms, signers, etc. If a security aware resolver different algorithms, signers, etc. If a security aware resolver
reliably learns a public key of the zone, it can authenticate, for reliably learns a public key of the zone, it can authenticate, for
signed data read from that zone, that it was properly authorized and signed data read from that zone, that it is properly authorized. The
is current. The most secure implementation is for the zone private most secure implementation is for the zone private key(s) to be kept
key(s) to be kept off-line and used to re-sign all of the records in off-line and used to re-sign all of the records in the zone
the zone periodically. However, there are cases, for example dynamic periodically. However, there are cases, for example dynamic update
update [RFCs 2136, 2137], where DNS private keys need to be on-line. [RFCs 2136, 2137], where DNS private keys need to be on-line.
[draft-ietf-dnssec-secops-*.txt] [draft-ietf-dnssec-secops-*.txt]
This data origin authentication key(s) are associated with the zone The data origin authentication key(s) are associated with the zone
and not with the servers that store copies of the data. That means and not with the servers that store copies of the data. That means
compromise of a secondary server or, if the key(s) are kept off line, compromise of a secondary server or, if the key(s) are kept off line,
even the primary server for a zone, will not necessarily affect the even the primary server for a zone, will not necessarily affect the
degree of assurance that a resolver has that it can determine whether degree of assurance that a resolver has that it can determine whether
data is genuine. data is genuine.
A resolver could learn a public key of a zone either by reading it A resolver could learn a public key of a zone either by reading it
from the DNS or by having it or a key which authenticates it staticly from the DNS or by having it staticly configured. To reliably learn
configured. To reliably learn a public key by reading it from the a public key by reading it from the DNS, the key itself must be
DNS, the key itself must be signed with a key the resolver trusts. signed with a key the resolver trusts. The resolver must be
The resolver must be configured with at least a public key which configured with at least a public key which authenticates one zone as
authenticates one zone as a starting point. From there, it can a starting point. From there, it can securely read public keys of
securely read public keys of other zones, if the intervening zones in other zones, if the intervening zones in the DNS tree are secure and
the DNS tree are secure and their signed keys accessible. their signed keys accessible.
Adding data origin authentication and integrity requires no change to Adding data origin authentication and integrity requires no change to
the "on-the-wire" DNS protocol beyond the addition of the signature the "on-the-wire" DNS protocol beyond the addition of the signature
resource type and the key resource type needed for key distribution. resource type and the key resource type needed for key distribution.
(Data non-existence authentication also requires the NXT RR as (Data non-existence authentication also requires the NXT RR as
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 in a secure zone can not be exception is that CNAME referrals in 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
skipping to change at page 8, line 8 skipping to change at page 8, line 16
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 attempting to send the signature(s) needed (see that degradation by attempting to send the signature(s) needed (see
Section 4.2). Section 4.2).
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 RRset being signed to the Section 4. It cryptographicly binds the RRset 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 delegation 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.
skipping to change at page 9, line 20 skipping to change at page 9, line 31
(RRset) signed by a special private key held by the zone manager. (RRset) signed by a special private key held by the zone manager.
But the DNS protocol views the leaf nodes in a zone, which are also But the DNS protocol views the leaf nodes in a zone, which are also
the apex nodes of a subzone (i.e., delegation points), as "really" the apex nodes of a subzone (i.e., delegation points), as "really"
belonging to the subzone. These nodes occur in two master files and belonging to the subzone. These nodes occur in two master files and
might have RRs signed by both the upper and lower zone's keys. A might have RRs signed by both the upper and lower zone's keys. A
retrieval could get a mixture of these RRs and SIGs, especially since retrieval could get a mixture of these RRs and SIGs, especially since
one server could be serving both the zone above and below a one server could be serving both the zone above and below a
delegation point. [RFC 2181] delegation point. [RFC 2181]
There MUST be a zone KEY RR, signed by its superzone, for every There MUST be a zone KEY RR, signed by its superzone, for every
subzone if the superzone is secure. In the case of an unsecured subzone if the superzone is secure. This will normally appear in the
subzone which can not or will not be modified to add any security subzone and may also be included in the superzone. But, in the case
RRs, a KEY declaring the subzone to be unsecured MUST appear in and of an unsecured subzone which can not or will not be modified to add
be signed by the superzone, if the superzone is secure. For all but any security RRs, a KEY declaring the subzone to be unsecured MUST
one other RR type the data from the subzone is more authoritative so appear with the superzone signature in the superzone, if the
only the KEY RR in the superzone should be signed. The NS and any superzone is secure. For all but one other RR type the data from the
glue address RRs should only be signed in the subzone. The SOA and subzone is more authoritative so only the subzone KEY RR should be
any other RRs that have the zone name as owner should appear only in signed in the superzone if it appears there. The NS and any glue
the subzone and thus are signed only there. The NXT RR type is the address RRs SHOULD only be signed in the subzone. The SOA and any
other RRs that have the zone name as owner should appear only in the
subzone and thus are signed only there. The NXT RR type is the
exceptional case that will always appear differently and exceptional case that will always appear differently and
authoritatively in both the superzone and subzone, if both are authoritatively in both the superzone and subzone, if both are
secure, as described in Section 5. secure, as described in Section 5.
2.3.5 Special Considerations with CNAME 2.3.5 Special Considerations with CNAME
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 SIG, KEY, or NXT RR. For retrieved types not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
skipping to change at page 10, line 10 skipping to change at page 10, line 23
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 cases where a SIG resource record is signed by other than There are cases where the signer in a SIG resource record is other
one of the private key(s) used to authenticate a zone. than one of the private key(s) used to authenticate a zone.
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 secure authentication) where an entity is permitted to which require secure authentication) where an entity is permitted to
authenticate/update its records [RFC 2137]. The public key of the authenticate/update its records [RFC 2137] and the zone is operating
in a mode where the zone key is not on line. The public key of the
entity must be present in the DNS and be signed by a zone level key entity must be present in the DNS and be signed by a zone level key
but the other RR(s) may be signed with the entity's key. but the other RR(s) may be signed with the entity's key.
A second case is support of transaction and request authentication as A second case is support of transaction and request authentication as
described in Section 2.4. described in Section 2.4.
In additions, signatures can be included on resource records within In additions, signatures can be included on resource records within
the DNS for use by applications other than DNS. DNS related the DNS for use by applications other than DNS. DNS related
signatures authenticate that data originated with the zone owner or signatures authenticate that data originated with the authority of a
that a request or transaction originated with the relevant host. zone owner or that a request or transaction originated with the
Other signatures can provide other types of assurances. relevant entity. Other signatures can provide other types of
assurances.
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 and the non-existence of resource records retrieved resource records and the non-existence of resource records
but provides no protection for DNS requests or for message headers. but provides no protection for DNS requests or for message headers.
If header bits are falsely set by a bad server, there is little that 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 48 skipping to change at page 11, line 17
queried and that the response is from the query it sent (i.e., that queried and that the response is from the query it sent (i.e., that
these messages have not been diddled in transit). This is these messages have not been diddled in transit). This is
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 produce error returns or may even be ignored by information section produce error returns or may even be ignored by
many of them. However, this syntax for signing requests is defined in many of them. However, this syntax for signing requests is defined as
connection with authenticating secure dynamic update requests [RFC a way of authenticating secure dynamic update requests [RFC 2137] or
2137] or future requests requiring authentication. future requests requiring authentication.
The private keys used in transaction security belong to the host The private keys used in transaction security belong to the entity
composing the reply, not to the zone involved. Request composing the reply, not to the zone involved. Request
authentication may also involve the private key of the host composing authentication may also involve the private key of the host or other
the request or other private keys depending on the request authority entity composing the request or other private keys depending on the
it is sought to establish. The corresponding public key(s) are request authority it is sought to establish. The corresponding public
normally stored in and retrieved from the DNS for verification. key(s) are normally stored in and retrieved from 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 public 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. This can be the associated with a Domain Name System (DNS) name. This can be the
skipping to change at page 13, line 9 skipping to change at page 12, line 39
The algorithm and public key fields are described in Section 3.2. The algorithm and public key fields are described in Section 3.2.
The format of the public key is algorithm dependent. The format of the public key is algorithm dependent.
KEY RRs do not specify their validity period but their authenticating KEY RRs do not specify their validity period but their authenticating
SIG RR(s) do as described in Section 4 below. SIG RR(s) do as 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 is for the object named in the owner name. The public key in a KEY RR is for the object named in the owner name.
A DNS name may refer to up to three different categories of things. A DNS name may refer to three different categories of things. For
For example, foo.host.example could be (1) a zone, (2) a host or example, foo.host.example could be (1) a zone, (2) a host or other
other end entity , or (3) the mapping into a DNS name of the user or end entity , or (3) the mapping into a DNS name of the user or
account foo@host.example. Thus, there are flag bits, as described account foo@host.example. Thus, there are flag bits, as described
below, in the KEY RR to indicate with which of these roles the owner below, in the KEY RR to indicate with which of these roles the owner
name and public key are associated. Note that an appropriate zone name and public key are associated. Note that an appropriate zone
KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
occur only at delegation points. occur only at delegation points.
3.1.2 The KEY RR Flag Field 3.1.2 The KEY RR Flag Field
In the "flags" field: In the "flags" field:
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
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bit 0 and 1 are the key "type" bits whose values have the following Bit 0 and 1 are the key "type" bits whose values have the following
meanings: meanings:
10: Bit 0 a one indicates that use of the key is prohibited 10: Use of the key is prohibited for authentication.
for authentication. 01: Use of the key is prohibited for confidentiality.
01: Bit 1 a one indicates that use of the key is prohibited 00: Use of the key for authentication and/or confidentiality
for confidentiality. is permitted. Note that DNS security makes use of keys for
00: If the bits are zero, then use of the key for authentication only. Confidentiality use flagging is provided for
authentication and/or confidentiality is permitted. Note that DNS use of keys in other protocols. Implementations not intended to
security makes use of keys for authentication only. support key distribution for confidentiality MAY require that the
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. confidentiality use prohibited bit be on for keys they serve.
11: If both bits are one, the "no key" value, there is no key 11: If both bits are one, the "no key" value, there is no key
information and the RR stops after the algorithm octet. By the information and the RR stops after the algorithm octet. By the
use of this "no key" value, a signed KEY RR can authenticatably 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 assert that, for example, a zone is not secured. See section 3.4
below. below.
Bits 2 is reserved and must be zero. Bits 2 is reserved and must be zero.
Bits 3 is reserved as a flag extension bit. If it is a one, a second Bits 3 is reserved as a flag extension bit. If it is a one, a second
skipping to change at page 14, line 28 skipping to change at page 14, line 10
user level service such a telnet, ftp, rlogin, etc. user level service such a telnet, ftp, rlogin, etc.
01: indicates that this is a zone key for the zone whose name 01: indicates that this is a zone key for the zone whose name
is the KEY RR owner name. This is the public key used for the is the KEY RR owner name. This is the public key used for the
primary DNS security feature of data origin authentication. Zone primary DNS security feature of data origin authentication. Zone
KEY RRs occur only at delegation points. KEY RRs occur only at delegation points.
10: indicates that this is a key associated with the non-zone 10: indicates that this is a key associated with the non-zone
"entity" whose name is the RR owner name. This will commonly be a "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 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 of entity such as a telephone number [RFC 1530] or numeric IP
address. This is the public key used in connection with DNS address. This is the public key used in connection with DNS
request and transaction authentication services if the owner name request and transaction authentication services. It could also be
designates a DNS resolver or server host. It could also be used used in an IP-security protocol where authentication at the host,
in an IP-security protocol where authentication at the host,
rather than user, level was desired, such as routing, NTP, etc. rather than user, level was desired, such as routing, NTP, etc.
11: reserved. 11: reserved.
Bits 8-11 are reserved and must be zero. Bits 8-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 things as specified in DNS dynamic that the key can validly sign things as specified in DNS dynamic
update [RFC 2137]. Note that zone keys (see bits 6 and 7 above) update [RFC 2137]. Note that zone keys (see bits 6 and 7 above)
always have authority to sign any RRs in the zone regardless of always have authority to sign any RRs in the zone regardless of
the value of the signatory field. the value of the signatory field.
skipping to change at page 15, line 16 skipping to change at page 14, line 44
0 -reserved 0 -reserved
1 TLS 1 TLS
2 email 2 email
3 dnssec 3 dnssec
4 IPSEC 4 IPSEC
5-254 - available for assignment by IANA 5-254 - available for assignment by IANA
255 All 255 All
In more detail: In more detail:
1 is reserved to refer to the TLS standard. The presence of a 1 is reserved for use in connection with TLS.
host KEY resource with this protocol value is an assertion that the
host speaks TLS.
2 is reserved for use in connection with email. 2 is reserved for use in connection with email.
3 is used for DNS security. The protocol field should be set to 3 is used for DNS security. The protocol field SHOULD be set to
this value for zone keys and other keys used in DNS security. this value for zone keys and other keys used in DNS security.
Implementations that can determine that a key is a DNS security key Implementations that can determine that a key is a DNS security key
by the fact that flags label it a zone key or the signatory flag by the fact that flags label it a zone key or the signatory flag
field is non-zero are NOT REQUIRED to check the protocol field. field is non-zero are NOT REQUIRED to check the protocol field.
4 is reserved to refer to the Oakley/IPSEC [RFC 1825] protocol 4 is reserved to refer to the Oakley/IPSEC [RFC 1825] protocol
and indicates that this key is valid for use in conjunction with that and indicates that this key is valid for use in conjunction with that
security standard. This key could be used in connection with secured security 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 flag bits are set. owner name of the KEY RR if the entity or user flag bits are set.
The presence of a KEY resource with this protocol value is an The presence of a KEY resource with this protocol value is an
skipping to change at page 16, line 5 skipping to change at page 15, line 21
protocol for which KEY RR protocol octet values have been defined. protocol for which KEY RR protocol octet values have been defined.
The use of this value is discouraged and the use of different keys The use of this value is discouraged and the use of different keys
for different protocols is encouraged. for different protocols is encouraged.
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 as described in Section 4.1. The following values are SIG resource as described in Section 4.1. The following values are
assigned: assigned:
VALUE Protocol VALUE Algorithm
0 - reserved 0 - reserved, see Section 11
1 RSA/MD5 [draft-ietf-dnssec-rsa-*.txt] - recommended 1 RSA/MD5 [draft-ietf-dnssec-rsa-*.txt] - recommended
2 Diffie-Hellman [draft-ietf-dnssec-dhk-*.txt] - key only 2 Diffie-Hellman [draft-ietf-dnssec-dhk-*.txt] - optional, key only
3 DSA [draft-ietf-dnssec-dss-*.txt] - MANDATORY 3 DSA [draft-ietf-dnssec-dss-*.txt] - MANDATORY
4 reserved for elliptic curve 4 reserved for elliptic curve crypto
5-251 - available (see below) 5-251 - available, see Section 11
252 reserved for indirect keys 252 reserved for indirect keys
253 - available (but was "null" [RFC 2065]) 253 private - domain name (see below)
254 private (see below) 254 private - OID (see below)
255 - reserved 255 - reserved, see Section 11
Algorithm specific formats and procedures are given in separate Algorithm specific formats and procedures are given in separate
documents. The mandatory to implement for interoperability algorithm documents. The mandatory to implement for interoperability algorithm
is number 3, DSA. It is recommended that the RSA/MD5 algorithm, is number 3, DSA. It is recommended that the RSA/MD5 algorithm,
number 1, also be implemented. Algorithm 2 is used to indicate number 1, also be implemented. Algorithm 2 is used to indicate
Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve. Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
Numbers 5 through 251 and 253 are available for assignment should Algorithm number 252 indicates an indirect key format where the
sufficient reason arise. However, the designation of a new algorithm actual key material is elsewhere. This format is to be defined in a
could have a major impact on interoperability and requires an IETF separate document.
standards action.
Number 252 is reserved for the definition of an indirect key format
where they actual key material is elsewhere.
Number 254 is reserved for private use and will never be assigned a Algorithm numbers 253 and 254 are reserved for private use and will
specific algorithm. For number 254, the public key area for the KEY never be assigned a specific algorithm. For number 253, the public
RR and the signature will actually begin with a length byte followed key area and the signature begin with a wire encoded domain name.
by an Object Identifier (ISO OID) of that length. The OID indicates Only local domain name compression is permitted. The domain name
the private algorithm in use and the remainder of the area is indicates the private algorithm to use and the remainder of the
whatever is required by that algorithm. public key area is whatever is required by that algorithm. For
number 254, the public key area for the KEY RR and the signature
begin with an unsigned length byte followed by a BER encoded Object
Identifier (ISO OID) of that length. The OID indicates the private
algorithm in use and the remainder of the area is whatever is
required by that algorithm. Entities should only use domain names
and OIDs they control to designate their private algorithms.
Values 0 and 255 are reserved but the value 0 is used in the Values 0 and 255 are reserved but the value 0 is used in the
algorithm field when that field is not used. An example is in a KEY algorithm field when that field is not used. An example is in a KEY
RR with the top two flag bits on, the "no-key" value, where no key is RR with the top two flag bits on, the "no-key" value, where no key is
present. present.
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 flags, algorithm byte, Various combinations of the no-key type flags, algorithm byte,
protocol byte, and any future assigned protocol indicating flags are protocol byte, and any future assigned protocol indicating flags are
skipping to change at page 18, line 8 skipping to change at page 17, line 30
trusted key specifying zone KEY RR, then that zone is only trusted key specifying zone KEY RR, then that zone is only
experimentally secure for the algorithm. Both authenticated and experimentally secure for the algorithm. Both authenticated and
non-authenticated RRs for it should be accepted by the resolver. non-authenticated RRs for it should be accepted by the resolver.
3. If every trusted zone KEY RR that the zone and algorithm has is 3. If every trusted zone KEY RR that the zone and algorithm has is
key specifying, then it is secure for that algorithm and only key specifying, then it is secure for that algorithm and only
authenticated RRs from it will be accepted. authenticated RRs from it will be accepted.
Examples: Examples:
(1) A resolver only trusts signatures by the superzone within the (1) A resolver initially trusts only signatures by the superzone of
DNS hierarchy so it will look only at the KEY RRs that are signed by zone Z within the DNS hierarchy. Thus it will look only at the KEY
the superzone. If it finds only no-key KEY RRs, it will assume the RRs that are signed by the superzone. If it finds only no-key KEY
zone is not secure. If it finds only key specifying KEY RRs, it will RRs, it will assume the zone is not secure. If it finds only key
assume the zone is secure and reject any unsigned responses. If it specifying KEY RRs, it will assume the zone is secure and reject any
finds both, it will assume the zone is experimentally secure unsigned responses. If it 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.xy. When securely from its local zone) and a third party, cert-auth.example.
considering data from zone Z, it may be signed by the superzone of Z, When considering data from zone Z, it may be signed by the superzone
by cert-auth.xy, by both, or by neither. The following table of Z, by cert-auth.example, by both, or by neither. The following
indicates whether zone Z will be considered secure, experimentally table indicates whether zone Z will be considered secure,
secure, or unsecured, depending on the signed zone KEY RRs for Z; experimentally secure, or unsecured, depending on the signed zone KEY
RRs for Z;
c e r t - a u t h . x y c e r t - a u t h . e x a m p l e
KEY RRs| None | NoKeys | Mixed | Keys | KEY RRs| None | NoKeys | Mixed | Keys |
S --+-----------+-----------+----------+----------+ S --+-----------+-----------+----------+----------+
u None | illegal | unsecured | experim. | secure | u None | illegal | unsecured | experim. | secure |
p --+-----------+-----------+----------+----------+ p --+-----------+-----------+----------+----------+
e NoKeys | unsecured | unsecured | experim. | secure | e NoKeys | unsecured | unsecured | experim. | secure |
r --+-----------+-----------+----------+----------+ r --+-----------+-----------+----------+----------+
Z Mixed | experim. | experim. | experim. | secure | Z Mixed | experim. | experim. | experim. | secure |
o --+-----------+-----------+----------+----------+ o --+-----------+-----------+----------+----------+
n Keys | secure | secure | secure | secure | n Keys | secure | secure | secure | secure |
skipping to change at page 18, line 46 skipping to change at page 18, line 28
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 (see Section 4.2). RR from a security aware server (see Section 4.2).
Security aware DNS servers include KEY RRs as additional information Security aware DNS servers include KEY RRs as additional information
in responses, where a KEY is available, in the following cases: in responses, where a KEY is available, in the following cases:
(1) On the retrieval of SOA or NS RRs, the KEY RRset with the same (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
name (perhaps just a zone key) SHOULD be included as additional name (perhaps just a zone key) SHOULD be included as additional
information if space is available. There will always be at least one information if space is available. If not all additional information
such KEY RR in a secure zone in connection with each subzone
delegation point, even if it has the no-key type value to indicate
that the subzone is unsecured. If not all additional information
will fit, type A and AAAA glue RRs have higher priority than KEY will fit, type A and AAAA glue RRs have higher priority than KEY
RR(s). RR(s).
(2) On retrieval of type A or AAAA RRs, the KEY RRset with the same (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
name (usually just a host RR and NOT the zone key which usually would name (usually just a host RR and NOT the zone key (which usually
have a different name) SHOULD be included if space is available. On would have a different name)) SHOULD be included if space is
inclusion of A or AAAA RRs as additional information, the KEY RRset available. On inclusion of A or AAAA RRs as additional information,
with the same name should also be included but with lower priority the KEY RRset with the same name should also be included but with
than the A or AAAA RRs. lower priority than the A or AAAA RRs.
4. The SIG Resource Record 4. The SIG Resource Record
The SIG or "signature" resource record (RR) is the fundamental way The SIG or "signature" resource record (RR) is the fundamental way
that data is authenticated in the secure Domain Name System (DNS). As that data is authenticated in the secure Domain Name System (DNS). As
such it is the heart of the security provided. such it is the heart of the security provided.
The SIG RR unforgably authenticates an RRset [RFC 2181] of a The SIG RR unforgably authenticates an RRset [RFC 2181] of a
particular type, class, and name and binds it to a time interval and particular type, class, and name and binds it to a time interval and
the signer's domain name. This is done using cryptographic the signer's domain name. This is done using cryptographic
skipping to change at page 20, line 44 skipping to change at page 19, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | | | key tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| / | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ / / /
/ signature / / signature /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1 4.1.1 Type Covered Field
The "type covered" is the type of the other RRs covered by this SIG. The "type covered" is the type of the other RRs covered by this SIG.
4.1.2 Algorithm Number Field 4.1.2 Algorithm Number Field
This octet is as described in section 3.2. This octet is as described in section 3.2.
4.1.3 Labels Field 4.1.3 Labels Field
The "labels" octet is an unsigned count of how many labels there are The "labels" octet is an unsigned count of how many labels there are
skipping to change at page 21, line 48 skipping to change at page 20, line 36
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 (see Section 8). This implies that all RRs the signature is verified (see Section 8). This generaly implies
for a particular type, name, and class, that is, all the RRs in any that all RRs for a particular type, name, and class, that is, all the
particular RRset, must have the same TTL to start with. RRs in any particular RRset, must have the same TTL to start with.
4.1.5 Signature Expiration and Inception Fields 4.1.5 Signature Expiration and Inception Fields
The SIG is valid from the "signature inception" time until the The SIG is valid from the "signature inception" time until the
"signature expiration" time. Both are unsigned numbers of seconds "signature expiration" time. Both are unsigned numbers of seconds
since the start of 1 January 1970, GMT, ignoring leap seconds. (See since the start of 1 January 1970, GMT, ignoring leap seconds. (See
also Section 4.4.) Ring arithmetic is used as for DNS SOA serial also Section 4.4.) Ring arithmetic is used as for DNS SOA serial
numbers [RFC 1982] which means that these times can never be more numbers [RFC 1982] which means that these times can never be more
than about 136.09 years in the future. A SIG RR may have an than about 68 years in the past or the future. This means that these
expiration time numerically less than the inception time if the times are ambiguous modulo ~136.09 years. However there is no
expiration time is near the 32 bit wrap around point and/or the security flaw because keys are required to be changed to new random
signature is long lived. keys by [draft-ietf-dnssec-secops-*.txt] at least every five years.
This means that the probability that the same key is in use N*136.09
years later should be the same as the probability that a random guess
will work.
A SIG RR may have an expiration time numerically less than the
inception time if the expiration time is near the 32 bit wrap around
point and/or the signature is long lived.
(To prevent misordering of network requests to update a zone (To prevent misordering of network requests to update a zone
dynamically, monotonically increasing "signature inception" times may dynamically, monotonically increasing "signature inception" times may
be necessary. [RFC 2137]) be necessary.)
SOA serial numbers for secure zones MUST not only be advanced when A secure zone must be considered changed for SOA serial number
their data is updated but also when new SIG RRs are inserted (ie, the purposes not only when its data is updated but also when new SIG RRs
zone or any part of it is re-signed). are inserted (ie, the zone or any part of it is re-signed).
4.1.6 Key Tag Field 4.1.6 Key Tag Field
The "key Tag" is a two octet quantity that is used to efficiently The "key Tag" is a two octet quantity that is used to efficiently
select between multiple keys which may be applicable and thus check select between multiple keys which may be applicable and thus check
that a public key about to be used for the computationally expensive that a public key about to be used for the computationally expensive
effort to check the signature is possibly valid. For algorithm 1 effort to check the signature is possibly valid. For algorithm 1
(MD5/RSA) as defined in [draft-ietf-dnssec-rsa-*.txt], it is the next (MD5/RSA) as defined in [draft-ietf-dnssec-rsa-*.txt], it is the next
to the bottom two octets of the public key modulus needed to decode to the bottom two octets of the public key modulus needed to decode
the signature field. That is to say, the most significant 16 of the the signature field. That is to say, the most significant 16 of the
skipping to change at page 24, line 13 skipping to change at page 23, line 13
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(s). for the inclusions of any request SIG(s).
WARNING: Request SIGs are unnecessary for any currently defined WARNING: Request SIGs are unnecessary for any currently defined
request other than update [RFC 2136, 2137] and will cause many old request other than update [RFC 2136, 2137] and will cause some old
DNS servers to give an error return or ignore a query. However, such DNS servers to give an error return or ignore a query. However, such
SIGs may in the future been needed for other requests. SIGs may in the future be needed 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 SHOULD, for every authenticated RRset the Security aware DNS servers SHOULD, for every authenticated RRset the
query will return, attempt to send the available SIG RRs which query will return, attempt to send the available SIG RRs which
authenticate the requested RRset. The following rules apply to the authenticate the requested RRset. The following rules apply to the
inclusion of SIG RRs in responses: inclusion of SIG RRs in responses:
skipping to change at page 24, line 38 skipping to change at page 23, line 38
priority for inclusion than additional RRs that may need to be priority for inclusion than additional RRs that may need to be
included. If space does not permit its inclusion, the response included. If space does not permit its inclusion, the response
MUST be considered truncated except as provided in 2 below. MUST be considered truncated except as provided in 2 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
the SIG RR with the additional information. the SIG RR with the additional information.
3. SIGs to authenticate glue records and NS RRs for subzones at a 3. SIGs to authenticate glue records and NS RRs for subzones at a
delegation point are unnecessary and MUST NOT be sent. (Note delegation point are unnecessary and MUST NOT be sent.
that KEYs given for a subzone in that subzone's superzone are
controlling so the superzone's signature on the KEY MUST be
included (unless the KEY was additional information and the SIG
did not fit).)
4. If a SIG covers any RR that would be in the answer section of 4. If a SIG covers any RR that would be in the answer section of
the response, its automatic inclusion MUST be in the answer the response, its automatic inclusion MUST be in the answer
section. If it covers an RR that would appear in the authority section. If it covers an RR that would appear in the authority
section, its automatic inclusion MUST be in the authority section, its automatic inclusion MUST be in the authority
section. If it covers an RR that would appear in the additional section. If it covers an RR that would appear in the additional
information section it MUST appear in the additional information information section it MUST appear in the additional information
section. This is a change in the existing standard [RFCs 1034, section. This is a change in the existing standard [RFCs 1034,
1035] which contemplates only NS and SOA RRs in the authority 1035] which contemplates only NS and SOA RRs in the authority
section. section.
skipping to change at page 25, line 29 skipping to change at page 24, line 25
response: response:
1. A security aware resolver that receives a response from a 1. A security aware resolver that receives a response from a
security aware server via a secure communication with the AD bit security aware server via a secure communication with the AD bit
(see Section 6.1) set, MAY choose to accept the RRs as received (see Section 6.1) set, MAY choose to accept the RRs as received
without verifying the zone SIG RRs. without verifying the zone SIG 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 a 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
the security services. the security services.
3. If SIG RRs are received in response to a user query explicitly 3. If SIG RRs are received in response to a user query explicitly
specifying the SIG type, no special processing is required. specifying the SIG type, no special processing is required.
skipping to change at page 27, line 38 skipping to change at page 26, line 26
5.1 The NXT Resource Record 5.1 The NXT Resource Record
The NXT resource record is used to securely indicate that RRs with an The NXT resource record is used to securely indicate that RRs with an
owner name in a certain name interval do not exist in a zone and to owner name in a certain name interval do not exist in a zone and to
indicate what RR types are present for an existing name. indicate what RR types are present for an existing name.
The owner name of the NXT RR is an existing name in the zone. It's The owner name of the NXT RR is an existing name in the zone. It's
RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
create a chain of all of the literal owner names in that zone, create a chain of all of the literal owner names in that zone,
including unexpanded wildcard but omitting the owner name of glue including unexpanded wildcards but omitting the owner name of glue
address records unless they would otherwise be included. This implies address records unless they would otherwise be included. This implies
a canonical ordering of all domain names in a zone as described in a canonical ordering of all domain names in a zone as described in
Section 8. The presence of the NXT RR means that no name between its Section 8. The presence of the NXT RR means that no name between its
owner name and the name in its RDATA area exists and that no other owner name and the name in its RDATA area exists and that no other
types exist under its owner name. types exist under its owner name.
There is a potential problem with the last NXT in a zone as it wants There is a potential problem with the last NXT in a zone as it wants
to have an owner name which is the last existing name in canonical to have an owner name which is the last existing name in canonical
order, which is easy, but it is not obvious what name to put in its order, which is easy, but it is not obvious what name to put in its
RDATA to indicate the entire remainder of the name space. This is RDATA to indicate the entire remainder of the name space. This is
skipping to change at page 29, line 6 skipping to change at page 27, line 46
5.3 Additional Complexity Due to Wildcards 5.3 Additional Complexity Due to Wildcards
Proving that a non-existent name response is correct or that a Proving that a non-existent name response is correct or that a
wildcard expansion response is correct makes things a little more wildcard expansion response is correct makes things a little more
complex. complex.
In particular, when a non-existent name response is returned, an NXT In particular, when a non-existent name response is returned, an NXT
must be returned showing that the exact name queried did not exist must be returned showing that the exact name queried did not exist
and, in general, one or more additional NXT's need to be returned to and, in general, one or more additional NXT's need to be returned to
also prove that there wasn't a wildcard whose expansion should have also prove that there wasn't a wildcard whose expansion should have
been returned except that there is no need to return multiple copies been returned. (There is no need to return multiple copies of the
of the same NXT. These NXTs, if any, are returned in the authority same NXT.) These NXTs, if any, are returned in the authority section
section of the response. of the response.
Furthermore, if a wildcard expansion is returned in a response, in Furthermore, if a wildcard expansion is returned in a response, in
general one or more NXTs needs to also be returned in the authority general one or more NXTs needs to also be returned in the authority
section to prove that no more specific name (including possibly more section to prove that no more specific name (including possibly more
specific wildcards in the zone) existed on which the response should specific wildcards in the zone) existed on which the response should
have been based. have been based.
5.4 Example 5.4 Example
Assume zone foo.nil has entries for Assume zone foo.nil has entries for
skipping to change at page 29, line 32 skipping to change at page 28, line 23
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:
foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
19970102030405 ;signature expiration 19970102030405 ;signature expiration
19961211100908 ;time signed 19961211100908 ;signature inception
2143 ;key identifier 2143 ;key identifier
foo.nil. ;signer foo.nil. ;signer
AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
) )
big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
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
19970102030405 ;signature expiration 19970102030405 ;signature expiration
19961211100908 ;time signed 19961211100908 ;signature inception
2143 ;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.
skipping to change at page 30, line 27 skipping to change at page 29, line 20
some old implementations may only return the NXT from the subzone on some old implementations may only return the NXT from the subzone on
explicit queries. explicit queries.
5.6 Zone Transfers 5.6 Zone Transfers
The subsections below describe how full and incremental zone The subsections below describe how full and incremental zone
transfers are secured. transfers are secured.
SIG RRs secure all authoritative RRs transferred for both full and SIG RRs secure all authoritative RRs transferred for both full and
incremental [RFC 1995] zone transfers. NXT RRs are an essential incremental [RFC 1995] zone transfers. NXT RRs are an essential
elements in secure zone transfers and assure that every authoritative element in secure zone transfers and assure that every authoritative
name and type will be present; however, if there are multiple SIGs 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 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 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 or delegation point NS or glue A or AAAA RRs a subset of these RRs or
simply a modified set could be sent as long as at least one of each simply a modified set could be sent as long as at least one of each
type is included. type is included.
When an incremental or full zone transfer request is received with 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 same or newer version number than that of the server's copy of
the zone, it is replied to with just the SOA RR of the server's the zone, it is replied to with just the SOA RR of the server's
current version and the SIG RRset verifying that SOA RR. current version and the SIG RRset verifying that SOA RR.
The complete NXT chaims specified in this document enable a resolver The complete NXT chains specified in this document enable a resolver
to obtain, by successive queries chaining through NXTs, all of the to obtain, by successive queries chaining through NXTs, all of the
names in a zone even if zone transfers are prohibited. Different names in a zone even if zone transfers are prohibited. Different
format NXTs may be specified in the future to avoid this. format NXTs may be specified in the future to avoid this.
5.6.1 Full Zone Transfers 5.6.1 Full Zone Transfers
To provide server authentication that a complete transfer has To provide server authentication that a complete transfer has
occurred, transaction authentication SHOULD be used on all full zone occurred, transaction authentication SHOULD be used on full zone
transfers. This provides strong server based protection for the transfers. This provides strong server based protection for the
entire zone in transit. entire zone in transit.
5.6.2 Incremental Zone Transfers 5.6.2 Incremental Zone Transfers
Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
verified in the same way as for a full zone transfer and the verified in the same way as for a full zone transfer and 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. But the completeness of an disjoint area of the zone updated. But the completeness of an
incremental transfer can not be confirmed because usually neither the incremental transfer can not be confirmed because usually neither the
deleted RR section nor the added RR section has a compete NXT chain. deleted RR section nor the added RR section has a compete zone NXT
As a result, a server which securely supports IXFR must handle IXFR chain. As a result, a server which securely supports IXFR must
SIG RRs for each incremental transfer set that it maintains. handle IXFR SIG RRs for each incremental transfer set that it
maintains.
The IXFR SIG is calculated over the incremental zone update The IXFR SIG is calculated over the incremental zone update
collection of RRs in the order in which it is transmitted: old SOA, collection of RRs in the order in which it is transmitted: old SOA,
then deleted RRs, then new SOA and added RRs. Within each section, then deleted RRs, then new SOA and added RRs. Within each section,
RRs must be ordered as specified in Section 8. If condensation of RRs must be ordered as specified in Section 8. If condensation of
adjacent incremental update sets is done by the zone owner, the adjacent incremental update sets is done by the zone owner, the
original IXFR SIG for each set included in the condensation must be original IXFR SIG for each set included in the condensation must be
discarded and a new on IXFR SIG calculated to cover the resulting discarded and a new on IXFR SIG calculated to cover the resulting
condensed set. condensed set.
skipping to change at page 34, line 12 skipping to change at page 32, line 40
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. so the zone can be authenticated.
While it might seem logical for everyone to start with a public key While it might seem logical for everyone to start with a public key
associated with the root zone and staticly configure this in every associated with the root zone and staticly configure this in every
resolver, this has problems. The logistics of updating every DNS resolver, this has problems. The logistics of updating every DNS
resolver in the world should this key ever change would be severe. resolver in the world should this key ever change would be severe.
Furthermore, many organizations will explicitly wish their "interior" Furthermore, many organizations will explicitly wish their "interior"
DNS implementations to completely trust only their own DNS servers. DNS implementations to completely trust only their own DNS servers.
Interior resolvers of such organizations can then go through the Interior resolvers of such organizations can then go through the
organization's zone servers to access data outsize the organization's organization's zone servers to access data outside the organization's
domain and need not be configured with keys above the organization's domain and need not be configured with keys above the organization's
DNS apex. DNS apex.
Host resolvers that are not part of a larger organization may be Host resolvers that are not part of a larger organization may be
configured with a key for the domain of their local ISP whose configured 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 The DNS 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 that zone's subzones which have possible to retrieve signed keys for that zone's subzones which have
a key. A secure sub-zone is indicated by a KEY RR with non-null key a key. A secure sub-zone is indicated by a KEY RR with non-null key
information appearing with the NS RRs for the sub-zone. These make information appearing with the NS RRs in the sub-zone and which may
it possible to descend within the tree of zones. also be present in the parent. These make it possible to descend
within the tree of zones.
6.3.1 Chaining Through KEYs 6.3.1 Chaining Through KEYs
In general, some RRset that you wish to validate in the secure DNS In general, some RRset that you wish to validate in the secure DNS
will be signed by one or more SIG RRs. Each of these SIG RRs has a 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 signer under whose name is stored the public KEY to use in
authenticating the SIG. Each of those KEYs will, generally, also be authenticating the SIG. Each of those KEYs will, generally, also be
signed with a SIG. And those SIGs will have signer names also signed with a SIG. And those SIGs will have signer names also
referring to KEYs. And so on. As a result, authentication leads to referring to KEYs. And so on. As a result, authentication leads to
chains of alternating SIG and KEY RRs with the first SIG signing the chains of alternating SIG and KEY RRs with the first SIG signing the
skipping to change at page 35, line 21 skipping to change at page 34, line 6
A and B are the same domain name (i.e., are identical after A and B are the same domain name (i.e., are identical after
letter case canonicalization). Let A > B mean that A is a letter case canonicalization). Let A > B mean that A is a
longer domain name than B formed by adding one or more whole longer domain name than B formed by adding one or more whole
labels on the left end of B, i.e., A is a direct or indirect labels on the left end of B, i.e., A is a direct or indirect
subdomain of B subdomain of B
Let Static be the owner names of the set of staticly configured Let Static be the owner names of the set of staticly configured
trusted keys at a resolver. trusted keys at a resolver.
Then Signer is a valid signer name for a SIG authenticating an Then Signer is a valid signer name for a SIG authenticating an
RRset (possibly a KEY RRset) with owner name Owner at a resolver RRset (possibly a KEY RRset) with owner name Owner at the
if any of the following three rules apply: resolver if any of the following three rules apply:
(1) Owner > or = Signer (except that if Signer is root, Owner (1) Owner > or = Signer (except that if Signer is root, Owner
must be root or a top level domain name). That is, Owner is the must be root or a top level domain name). That is, Owner is the
same as or a subdomain of Signer. same as or a subdomain of Signer.
(2) ( Owner < Signer ) and ( Signer > or = some Static ). That (2) ( Owner < Signer ) and ( Signer > or = some Static ). That
is, Owner is a superdomain of Signer and Signer is staticly is, Owner is a superdomain of Signer and Signer is staticly
configured or a subdomain of a staticly configured key. configured or a subdomain of a staticly configured key.
(3) Signer = some Static. That is, the signer is exactly some (3) Signer = some Static. That is, the signer is exactly some
skipping to change at page 36, line 34 skipping to change at page 35, line 16
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 reached via it could
counterfeit. The "distance" to data in such zones or zones reached be counterfeit. The "distance" to data in such zones or zones
via such zones could be set to 256 or more as this exceeds the reached via such zones could be set to 256 or more as this exceeds
largest possible distance through secure zones in the DNS. the largest possible distance through secure zones in the DNS.
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, 2030]). If such protocols are Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are
used, they MUST be used securely so that time can not be spoofed. used, they MUST be used securely so that time can not be spoofed.
skipping to change at page 37, line 21 skipping to change at page 36, line 12
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 Value Symbol
001 RSAMD5 001 RSAMD5
002 DH 002 DH
003 DSA 003 DSA
004 ECC 004 ECC
252 INDIRECT 252 INDIRECT
253 NULL (obsolete, see RFC 2065) 253 PRIVATEDNS
254 PRIVATE 254 PRIVATEOID
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 separated by instances of the verticle bar ("|") mnemonics as follows separated by instances of the verticle bar ("|")
character: character:
skipping to change at page 38, line 4 skipping to change at page 36, line 44
USER =0 (default, may be omitted) USER =0 (default, may be omitted)
ZONE =1 ZONE =1
HOST =2 (host or other end entity) HOST =2 (host or other end entity)
NTYP3 - reserved NTYP3 - reserved
8 FLAG8 - reserved 8 FLAG8 - reserved
9 FLAG9 - reserved 9 FLAG9 - reserved
10 FLAG10 - reserved 10 FLAG10 - reserved
11 FLAG11 - 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
No flag mnemonic need be present if the bit or field it repesents is
No flag mnemonic need be present if the bit or field it represents is
zero. zero.
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
001 TLS 001 TLS
002 EMAIL 002 EMAIL
003 DNSSEC 003 DNSSEC
004 IPSEC 004 IPSEC
skipping to change at page 40, line 7 skipping to change at page 38, line 23
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 signed. If a they should be derived from the zone as it is being signed. If a
signed file with NXTs added is printed or NXTs are printed by signed file with NXTs added is printed or NXTs are printed by
debugging code, they appear as the next domain name followed by the debugging code, they appear as the next domain name followed by the
RR type present bits as an unsigned interger or sequence of RR RR type present bits as an unsigned interger or sequence of RR
mnemonics. mnemonics.
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 specifies, for purposes of domain name system (DNS)
their default name order, and their order, for purposes of domain security, the canonical form of resource records (RRs), their name
name system (DNS) security. A canonical name order is necessary to order, and their overall order. A canonical name order is necessary
construct the NXT name chain. A canonical form and ordering within to construct the NXT name chain. A canonical form and ordering
an RRset is necessary in consistently constructing and verifying SIG within an RRset is necessary in consistently constructing and
RRs. A canonical ordering of types within a name is required in verifying SIG RRs. A canonical ordering of types within a name is
connection with incremental transfer (Section 5.6.2). required in connection with incremental transfer (Section 5.6.2).
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, (3) owner name wild cards in master file form (no substitution case, (3) owner name wild cards in master file form (no substitution
made for *), and (4) the original TTL substituted for the current made for *), and (4) the original TTL substituted for the current
TTL. TTL.
8.2 Canonical DNS Name Order 8.2 Canonical DNS Name Order
For purposes of DNS security, the canonical ordering of owner names For purposes of DNS security, the canonical ordering of owner names
is to sort individual labels as unsigned left justified octet strings is to sort individual labels as unsigned left justified octet strings
where the absence of a octet sorts before a zero value octet and where the absence of a octet sorts before a zero value octet and
upper case letters are treated as lower case letters. Names are then upper case letters are treated as lower case letters. Names in a
sorted by sorting on the highest level label and then, within those zone are sorted by sorting on the highest level label and then,
names with the same highest level label by the next lower label, etc. within those names with the same highest level label by the next
down to leaf node labels. Within a zone, the zone name itself always lower label, etc. down to leaf node labels. Within a zone, the zone
exists and all other names are the zone name with some prefix of name itself always exists and all other names are the zone name with
lower level labels. Thus the zone name itself always sorts first. some prefix of lower level labels. Thus the zone name itself always
sorts first.
Example: Example:
foo.example foo.example
a.foo.example a.foo.example
yljkjljk.a.foo.example yljkjljk.a.foo.example
Z.a.foo.example Z.a.foo.example
zABC.a.FOO.EXAMPLE zABC.a.FOO.EXAMPLE
z.foo.example z.foo.example
*.z.foo.example *.z.foo.example
\200.z.foo.example \200.z.foo.example
skipping to change at page 43, line 8 skipping to change at page 40, line 40
RRs including verification of SIGs at least for the mandatory RRs including verification of SIGs at least for the mandatory
algorithm, (2) maintains appropriate information in its local caches algorithm, (2) maintains appropriate information in its local caches
and database to indicate which RRs have been authenticated and to and database to indicate which RRs have been authenticated and to
what extent they have been authenticated, (3) performs additional what extent they have been authenticated, (3) performs additional
queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
needed, (4) normally sets the CD query header bit on its queries. needed, (4) normally sets the CD query header bit on its queries.
10. Security Considerations 10. Security Considerations
This document specifies extensions to the Domain Name System (DNS) This document specifies extensions to the Domain Name System (DNS)
protocol to provide data integrity and origin authentication, public protocol to provide data integrity and data origin authentication,
key distribution, and optional transaction and request security. public key distribution, and optional transaction and request
security.
It should be noted that, at most, these extensions guarantee the It should be noted that, at most, these extensions guarantee the
validity of resource records, including KEY resource records, validity of resource records, including KEY resource records,
retrieved from the DNS. They do not magically solve other security retrieved from the DNS. They do not magically solve other security
problems. For example, using secure DNS you can have high confidence problems. For example, using secure DNS you can have high confidence
in the IP address you retrieve for a host name; however, this does in the IP address you retrieve for a host name; however, this does
not stop someone for substituting an unauthorized host at that not stop someone for substituting an unauthorized host at that
address or capturing packets sent to that address and falsely address or capturing packets sent to that address and falsely
responding with packets apparently from that address. Any reasonably responding with packets apparently from that address. Any reasonably
complete security system will require the protection of many complete security system will require the protection of many
additional facets of the Internet beyond DNS. additional facets of the Internet beyond DNS.
The implementation of NXT RRs as described herein enables a resolver The implementation of NXT RRs as described herein enables a resolver
to determine all the names in a zone even if zone transfers are to determine all the names in a zone even if zone transfers are
prohibited (section 5.6). This is an active area of work and may prohibited (section 5.6). This is an active area of work and may
change. change.
A number of precautions in DNS implementation have evolved over the A number of precautions in DNS implementation have evolved over the
years to harden the insecure DNS against spoofing. These precautions years to harden the insecure DNS against spoofing. These precautions
should not generally be abandoned but should be considered to provide should not be abandoned but should be considered to provide
additional protection in case of key compromise in secure DNS. additional protection in case of key compromise in secure DNS.
References 11. IANA Considerations
[RFC 1032] - M. Stahl, "Domain Administrators Guide", November 1987. KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
assigned by IETF consensus. The remaining values of the NAMTYP flag
field and flag bits 4 and 5 (which could conceivably become an
extension of the NAMTYP field) can only be assigned by an IETF
standards action.
Algorithm numbers 5 through 251 are available for assignment should
sufficient reason arise. However, the designation of a new algorithm
could have a major impact on interoperability and requires an IETF
standards action. The existence of the private algorithm types 253
and 254 should satify most needs for private or proprietary
algorithms.
Additional values of the Protocol Octet (5-254) can be assigned by
IETF consensus.
The meaning of the first bit of the NXT RR "type bit map" being a one
can only be assigned by a standards action.
References
[RFC 1033] - M. Lottor, "Domain Administrators Operations Guide", [RFC 1033] - M. Lottor, "Domain Administrators Operations Guide",
November 1987. November 1987.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987. Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987. Specifications", STD 13, November 1987.
[RFC 1305] - D. Mills, "Network Time Protocol (v3)", March 1992. [RFC 1305] - D. Mills, "Network Time Protocol (v3)", March 1992.
[RFC 1530] - C. Malamud, and M. Rose, "Principles of Operation for [RFC 1530] - C. Malamud, and M. Rose, "Principles of Operation for
the TPC.INT Subdomain: General Principles and Policy", October 1993. the TPC.INT Subdomain: General Principles and Policy", October 1993.
[RFC 1750] - D. Eastlake, S. Crocker, and J. Schiller, "Randomness
Requirements for Security", December 1994.
[RFC 1825] - Ran Atkinson, "Security Architecture for the Internet [RFC 1825] - Ran Atkinson, "Security Architecture for the Internet
Protocol", August 1995. Protocol", August 1995.
[RFC 1982] - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", [RFC 1982] - Robert Elz, Rrandy Bush, "Serial Number Arithmetic",
09/03/1996. 09/03/1996.
[RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August [RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August
1996. 1996.
[RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 [RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996. for IPv4, IPv6 and OSI", October 1996.
[RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail [RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
November 1996. November 1996. (xxx update?)
[RFC 2065] - Donald Eastlake, Charles Kaufman, "Domain Name System [RFC 2065] - Donald Eastlake 3rd, Charles Kaufman, "Domain Name
Security Extensions", 01/03/1997. System Security Extensions", 01/03/1997.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2137] - Donald Eastlake, "Secure Domain Name System Dynamic [RFC 2137] - Donald Eastlake 3rd, "Secure Domain Name System Dynamic
Update", 04/21/1997. Update", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997. Specification", July 1997.
draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in
the Domain Name System (DNS)". the Domain Name System (DNS)".
draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman
Keys in the Domain Name System (DNS)". Keys in the Domain Name System (DNS)".
draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the
Domain Name System (DNS)". Domain Name System (DNS)".
draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing
Certificates in the Domain Name System". Certificates in the Domain Name System".
draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational
Security Considerations". Security Considerations".
draft-ietf-tls-*.txt,
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
CyberCash, Inc. IBM
318 Acton Street 318 Acton Street
Carlisle, MA 01741 USA Carlisle, MA 01741 USA
Telephone: +1 978-287-4877 Telephone: +1-914-784-7913
+1 703-620-4200 (main office, Reston, Virginia, USA) +1-978-287-4877
fax: +1 978-371-7148 fax: +1-978-371-7148
email: dee@cybercash.com email: dee3@us.ibm.com
Expiration and File Name Expiration and File Name
This draft expires October 1998. This draft expires May 1999.
Its file name is draft-ietf-dnssec-secext2-05.txt. Its file name is draft-ietf-dnssec-secext2-06.txt.
Appendix A: Base 64 Encoding Appendix A: Base 64 Encoding
The following encoding technique is taken from [RFC 2045] by N. The following encoding technique is taken from [RFC 2045] 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 49, line 49 skipping to change at page 47, line 49
now a recommended option. Algorithm 2 and 4 are designated as the now a recommended option. Algorithm 2 and 4 are designated as the
Diffie-Hellman key and elliptic cryptography algorithms Diffie-Hellman key and elliptic cryptography algorithms
respectively, all to be defined in separate documents. Algorithm respectively, all to be defined in separate documents. Algorithm
code point 252 is designated to indicate "indirect" keys, to be code point 252 is designated to indicate "indirect" keys, to be
defined in a separate document, where the actual key is elsewhere. defined in a separate document, where the actual key is elsewhere.
Both the KEY and SIG RR definitions have been simplified by Both the KEY and SIG RR definitions have been simplified by
eliminating the "null" algorithm 253 as defined in [RFC 2065]. eliminating the "null" algorithm 253 as defined in [RFC 2065].
That algorithm had been included because at the time it was That algorithm had been included because at the time it was
thought it might be useful in DNS dynamic update [RFC 2136]. It thought it might be useful in DNS dynamic update [RFC 2136]. It
was in fact not so used and it is dropped to simplify DNS was in fact not so used and it is dropped to simplify DNS
security. security. Howver, that algorithm number has been re-used to
indicate private algorithms where a domain name specifies the
algorithm.
5. The NXT RR has been changed so that (5a) the NXT RRs in a zone 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
cover all names, including wildcards as literal names without cover all names, including wildcards as literal names without
expansion, except for glue address records whose names would not expansion, except for glue address records whose names would not
otherwise appear, (5b) all NXT bit map areas whose first octet has otherwise appear, (5b) all NXT bit map areas whose first octet has
bit zero set have been reserved for future definition, (5c) the bit zero set have been reserved for future definition, (5c) the
number of and circumstances under which an NXT must be returned in number of and circumstances under which an NXT must be returned in
connection with wildcard names has been extended, and (5d) in connection with wildcard names has been extended, and (5d) in
connection with the bit map, references to the WKS RR have been connection with the bit map, references to the WKS RR have been
removed and verticle bars ("|") have been added between the RR removed and verticle bars ("|") have been added between the RR
skipping to change at page 50, line 24 skipping to change at page 48, line 26
7. A subsection covering incremental and full zone transfer has been 7. A subsection covering incremental and full zone transfer has been
added in Section 5. added in Section 5.
8. Concerning DNS chaining: Further specification and policy 8. Concerning DNS chaining: Further specification and policy
recommendations on secure resolution have been added, primarily in recommendations on secure resolution have been added, primarily in
Section 6.3.1. It is now clearly stated that authenticated data Section 6.3.1. It is now clearly stated that authenticated data
has a validity period of the intersection of the validity periods has a validity period of the intersection of the validity periods
of the SIG RRs in its authentication chain. The requirement to of the SIG RRs in its authentication chain. The requirement to
staticly configure a superzone's key signed by a zone in all of staticly configure a superzone's key signed by a zone in all of
the zone's authoritative servers has been removed. The the zone's authoritative servers has been removed. The
recommendation was dropped to continue DNS security checks in a recommendation to continue DNS security checks in a secure island
secure island of DNS data that is separated from other parts of of DNS data that is separated from other parts of the DNS tree by
the DNS tree by insecure zones and does not contain a zone for insecure zones and does not contain a zone for which a key has
which a key has been staticly configured. been staticly configured was dropped.
9. It was clarified that the presence of the AD bit in a response 9. It was clarified that the presence of the AD bit in a response
does not apply to the additional information section or to glue does not apply to the additional information section or to glue
address or delegation point NS RRs. address or delegation point NS RRs. The AD bit only indicates
that the answer and authority sections of the response are
authoritative.
10. It is now required that KEY RRs and NXT RRs be signed only with 10. It is now required that KEY RRs and NXT RRs be signed only with
zone-level keys. zone-level keys.
11. Add IANA Considerations section.
Appendix C: Key Tag Calculation Appendix C: Key Tag Calculation
The key tag field in the SIG RR is just a means of more efficiently The key tag field in the SIG RR is just a means of more efficiently
selecting the correct KEY RR to use when there is more than one KEY selecting the correct KEY RR to use when there is more than one KEY
RR candidate. It is possible for more than one candidate key to have RR candidate available, for example, in verifying a signature. It is
the same tag, in which case each must be tried in verifying a possible for more than one candidate key to have the same tag, in
signature, for example, until one works or all fail. The following which case each must be tried until one works or all fail. The
reference implementation is in ANSI C. It is coded for clarity, not following reference implementation of how to calculate the Key Tag,
efficiency. for all algorithms other than algorithm 1, is in ANSI C. It is coded
for clarity, not efficiency. (See section 4.1.6 for how to determine
the Key Tag of an algorithm 1 key.)
/* assumes int is at least 16 bits /* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return value first byte of the key tag is the most significant byte of return value
second byte of the key tag is the least significant byte of return value second byte of the key tag is the least significant byte of return value
*/ */
int keytag ( int keytag (
unsigned char key[], /* the RDATA part of the KEY RR */ unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */ unsigned int keysize, /* the RDLENGTH */
) )
{ {
long int ac; /* assumed to be 32 bits or larger */ long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i < keysize; ++i ) for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8; ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFFFF; ac += (ac>>16) & 0xFFFF;
return ac & 0xFFFF; return ac & 0xFFFF;
 End of changes. 88 change blocks. 
254 lines changed or deleted 300 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/