draft-ietf-dnssec-secext2-04.txt   draft-ietf-dnssec-secext2-05.txt 
DNS Security Working Group Donald E. Eastlake 3rd DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT CyberCash
OBSOLETES RFC 2065 OBSOLETES RFC 2065
UPDATES RFC 1034, 1035 UPDATES RFC 1034, 1035
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-04.txt, is intended This draft, file name draft-ietf-dnssec-secext2-05.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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet- other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' ``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, 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 ds.internic.net (East USA), ftp.isi.edu (West USA), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
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.
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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................................12 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...................12 3.1.1 Object Types, DNS Names, and Keys...................13
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.........17
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................................20 4. The SIG Resource Record................................20
4.1 SIG RDATA Format......................................20 4.1 SIG RDATA Format......................................20
4.1.1 ....................................................20 4.1.1 ....................................................20
skipping to change at page 4, line 19 skipping to change at page 4, line 19
5.6.2 Incremental Zone Transfers..........................31 5.6.2 Incremental Zone Transfers..........................31
6. How to Resolve Securely and the AD and CD Bits.........32 6. How to Resolve Securely and the AD and CD Bits.........32
6.1 The AD and CD Header Bits.............................32 6.1 The AD and CD Header Bits.............................32
6.2 Staticly Configured Keys..............................33 6.2 Staticly Configured Keys..............................33
6.3 Chaining Through The DNS..............................34 6.3 Chaining Through The DNS..............................34
6.3.1 Chaining Through KEYs...............................34 6.3.1 Chaining Through KEYs...............................34
6.3.2 Conflicting Data....................................36 6.3.2 Conflicting Data....................................36
6.4 Secure Time...........................................36 6.4 Secure Time...........................................36
7. ASCII Representation of Security RRs...................38 7. ASCII Representation of Security RRs...................37
7.1 Presentation of KEY RRs...............................38 7.1 Presentation of KEY RRs...............................37
7.2 Presentation of SIG RRs...............................39 7.2 Presentation of SIG RRs...............................38
7.3 Presentation of NXT RRs...............................40 7.3 Presentation of NXT RRs...............................39
8. Canonical Form and Order of Resource Records...........41 8. Canonical Form and Order of Resource Records...........40
8.1 Canonical RR Form.....................................41 8.1 Canonical RR Form.....................................40
8.2 Canonical DNS Name Order..............................41 8.2 Canonical DNS Name Order..............................40
8.3 Canonical RR Ordering Within An RRset.................42 8.3 Canonical RR Ordering Within An RRset.................41
8.4 Canonical Ordering of RR Types........................42 8.4 Canonical Ordering of RR Types........................41
9. Conformance............................................43 9. Conformance............................................42
9.1 Server Conformance....................................43 9.1 Server Conformance....................................42
9.2 Resolver Conformance..................................43 9.2 Resolver Conformance..................................42
10. Security Considerations...............................44 10. Security Considerations...............................43
References................................................45 References................................................44
Author's Address..........................................47 Author's Address..........................................46
Expiration and File Name..................................47 Expiration and File Name..................................46
Appendix A: Base 64 Encoding..............................48 Appendix A: Base 64 Encoding..............................47
Appendix B: Changes from RFC 2065.........................50 Appendix B: Changes from RFC 2065.........................49
Appendix C: Key Tag Calculation...........................52 Appendix C: Key Tag Calculation...........................51
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 10, line 16 skipping to change at page 10, line 16
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 a SIG resource record is signed by other than
one of the private key(s) used to authenticate a zone. 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]. The public key of the
entity must be present in the DNS and be appropriately signed but the entity must be present in the DNS and be signed by a zone level key
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 zone owner or
that a request or transaction originated with the relevant host. that a request or transaction originated with the relevant host.
Other signatures can provide other types of assurances. Other signatures can provide other types of assurances.
skipping to change at page 10, line 47 skipping to change at page 10, line 47
sure it is at least getting messages from the server it thinks it sure it is at least getting messages from the server it thinks it
queried and that the response is from the query it sent (i.e., that 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 are ignored by many of them. However, this information section produce error returns or may even be ignored by
syntax for signing requests is defined in connection with many of them. However, this syntax for signing requests is defined in
authenticating secure dynamic update requests [RFC 2137] or future connection with authenticating secure dynamic update requests [RFC
requests requiring authentication. 2137] or 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 host
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 composing
the request or other private keys depending on request authority it the request or other private keys depending on the request authority
is sought to establish. The corresponding public key(s) are normally it is sought to establish. The corresponding public key(s) are
stored in and retrieved from the DNS for verification. 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
public key of a zone, a user, or a host or other end entity. A KEY public key of a zone, a user, or a host or other end entity. Security
RR is, like any other RR, authenticated by a SIG RR. Security aware aware DNS implementations MUST be designed to handle at least two
DNS implementations MUST be designed to handle at least two
simultaneously valid keys of the same type associated with the same simultaneously valid keys of the same type associated with the same
name. name.
The type number for the KEY RR is 25. The type number for the KEY RR is 25.
A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs
must be signed by a zone level key.
3.1 KEY RDATA format 3.1 KEY RDATA format
The RDATA for a KEY RR consists of flags, a protocol octet, the The RDATA for a KEY RR consists of flags, a protocol octet, the
algorithm number octet, and the public key itself. The format is as algorithm number octet, and the public key itself. The format is as
follows: follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm | | flags | protocol | algorithm |
skipping to change at page 13, line 5 skipping to change at page 13, line 9
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.
This DNS name may refer to up to three different categories of A DNS name may refer to up to three different categories of things.
things. For example, foo.host.example could be (1) a zone, (2) a For example, foo.host.example could be (1) a zone, (2) a host or
host or other end entity , or (3) the mapping into a DNS name of the other end entity , or (3) the mapping into a DNS name of the user or
user or account foo@host.example. Thus, there are flag bits, as account foo@host.example. Thus, there are flag bits, as described
described below, in the KEY RR to indicate with which of these roles below, in the KEY RR to indicate with which of these roles the owner
the owner name and public key are associated. Note that an name and public key are associated. Note that an appropriate zone
appropriate zone KEY RR MUST occur at the apex node of a secure zone KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
skipping to change at page 14, line 5 skipping to change at page 14, line 9
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
16 bit flag field is added after the algorithm octet and before 16 bit flag field is added after the algorithm octet and before
the key data. This bit MUST NOT be set unless one or more such the key data. This bit MUST NOT be set unless one or more such
additional bits have been defined and are non-zero. additional bits have been defined and are non-zero.
Bits 4-5 are reserved and must be zero. Bits 4-5 are reserved and must be zero.
Bits 6 and 7 form a field that encodes the name type. Field values Bits 6 and 7 form a field that encodes the name type. Field values
have the following meanings: have the following meanings:
0 - indicates that this is a key associated with a "user" or 00: indicates that this is a key associated with a "user" or
"account" at an end entity, usually a host. The coding of the "account" at an end entity, usually a host. The coding of the
owner name is that used for the responsible individual mailbox in owner name is that used for the responsible individual mailbox in
the SOA and RP RRs: The owner name is the user name as the name of the SOA and RP RRs: The owner name is the user name as the name of
a node under the entity name. For example, "j_random_user" on a node under the entity name. For example, "j_random_user" on
host.subdomain.example could have a public key associated through host.subdomain.example could have a public key associated through
a KEY RR with name j_random_user.host.subdomain.example. It could a KEY RR with name j_random_user.host.subdomain.example. It could
be used in a security protocol where authentication of a user was be used in a security protocol where authentication of a user was
desired. This key might be useful in IP or other security for a desired. This key might be useful in IP or other security for a
user level service such a telnet, ftp, rlogin, etc. user level service such a telnet, ftp, rlogin, etc.
1 - 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.
2 - 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 if the owner name
designates a DNS resolver or server host. It could also be used designates a DNS resolver or server host. It could also be 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.
3 - 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.
3.1.3 The Protocol Octet 3.1.3 The Protocol Octet
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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 to refer to the TLS standard. The presence of a
KEY resource with this protocol value is an assertion that the host host KEY resource with this protocol value is an assertion that the
speaks TLS. 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 bits are on. The owner name of the KEY RR if the entity or user flag bits are set.
presence of a KEY resource with this protocol value is an assertion The presence of a KEY resource with this protocol value is an
that the host speaks Oakley/IPSEC. assertion that the host speaks Oakley/IPSEC.
255 indicates that the key can be used in connection with any 255 indicates that the key can be used in connection with any
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:
skipping to change at page 18, line 45 skipping to change at page 18, line 45
3.5 KEY RRs in the Construction of Responses 3.5 KEY RRs in the Construction of Responses
An explicit request for KEY RRs does not cause any special additional An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG information processing except, of course, for the corresponding SIG
RR from a security aware server (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 (usually 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. There will always be at least one
such KEY RR in a secure zone in connection with each subzone 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 delegation point, even if it has the no-key type value to indicate
that the subzone is unsecured. If not all additional information 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 would
have a different name) SHOULD be included if space is available. On have a different name) SHOULD be included if space is available. On
skipping to change at page 23, line 7 skipping to change at page 23, line 7
the SIG RR. This is the owner name of the public KEY RR that can be the SIG RR. This is the owner name of the public KEY RR that can be
used to verify the signature. It is frequently the zone which used to verify the signature. It is frequently the zone which
contained the RRset being authenticated. Which signers should be contained the RRset being authenticated. Which signers should be
authorized to sign what is a significant resolver policy question as authorized to sign what is a significant resolver policy question as
discussed in Section 6. The signer's name may be compressed with discussed in Section 6. The signer's name may be compressed with
standard DNS name compression when being transmitted over the standard DNS name compression when being transmitted over the
network. network.
4.1.8 Signature Field 4.1.8 Signature Field
The structure of the "signature" field is described below.
The actual signature portion of the SIG RR binds the other RDATA The actual signature portion of the SIG RR binds the other RDATA
fields to the RRset of the "type covered" RRs with that owner name fields to the RRset of the "type covered" RRs with that owner name
and class. This covered RRset is thereby authenticated. To and class. This covered RRset is thereby authenticated. To
accomplish this, a data sequence is constructed as follows: accomplish this, a data sequence is constructed as follows:
data = RDATA | RR(s)... data = RDATA | RR(s)...
where "|" is concatenation, where "|" is concatenation,
RDATA is the wire format of all the RDATA fields in the SIG RR itself RDATA is the wire format of all the RDATA fields in the SIG RR itself
skipping to change at page 24, line 14 skipping to change at page 24, 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 request other than update [RFC 2136, 2137] and will cause many old
existing DNS servers to ignore a query. However, such SIGs may in DNS servers to give an error return or ignore a query. However, such
the future been needed for other requests. SIGs may in the future been 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 RR 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 RR. 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:
1. when an RRset is placed in a response, its SIG RR has a higher 1. when an RRset is placed in a response, its SIG RR has a higher
priority for inclusion than 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 non-authoritative data (glue records and NS 3. SIGs to authenticate glue records and NS RRs for subzones at a
RRs for subzones) are unnecessary and MUST NOT be sent. (Note delegation point are unnecessary and MUST NOT be sent. (Note
that KEYs given for a subzone in that subzone's superzone are that KEYs given for a subzone in that subzone's superzone are
controlling so the superzone's signature on the KEY MUST be controlling so the superzone's signature on the KEY MUST be
included (unless the KEY was additional information and the SIG included (unless the KEY was additional information and the SIG
did not fit).) 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
skipping to change at page 27, line 8 skipping to change at page 27, line 8
setting expiration too far into the future could mean a long time to setting expiration too far into the future could mean a long time to
flush any bad data or signatures that may have been generated. flush any bad data or signatures that may have been generated.
It is recommended that signature lifetime be a small multiple of the It is recommended that signature lifetime be a small multiple of the
TTL (ie, 4 to 16 times the TTL) but not less than a reasonable TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
maximum re-signing interval and not less than the zone expiry time. maximum re-signing interval and not less than the zone expiry time.
5. Non-existent Names and Types 5. Non-existent Names and Types
The SIG RR mechanism described in Section 4 above provides strong The SIG RR mechanism described in Section 4 above provides strong
authentication of RRs that exist in a zone. But is it not clear authentication of RRs that exist in a zone. But it is not clear
above how to verifiably deny the existence of a name in a zone or a above how to verifiably deny the existence of a name in a zone or a
type for an existent name. type for an existent name.
The nonexistence of a name in a zone is indicated by the NXT ("next") The nonexistence of a name in a zone is indicated by the NXT ("next")
RR for a name interval containing the nonexistent name. An NXT RR or RR for a name interval containing the nonexistent name. An NXT RR or
RRs and its or their SIG(s) are returned in the authority section, RRs and its or their SIG(s) are returned in the authority section,
along with the error, if the server is security aware. The same is along with the error, if the server is security aware. The same is
true for a non-existent type under an existing name except that there true for a non-existent type under an existing name except that there
is no error indication other than an empty answer section is no error indication other than an empty answer section
accompanying the NXT(s). This is a change in the existing standard accompanying the NXT(s). This is a change in the existing standard
skipping to change at page 28, line 9 skipping to change at page 28, line 9
RDATA to indicate the entire remainder of the name space. This is RDATA to indicate the entire remainder of the name space. This is
handled by treating the name space as circular and putting the zone handled by treating the name space as circular and putting the zone
name in the RDATA of the last NXT in a zone. name in the RDATA of the last NXT in a zone.
The NXT RRs for a zone SHOULD be automatically calculated and added The NXT RRs for a zone SHOULD be automatically calculated and added
to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed
the zone minimum TTL. the zone minimum TTL.
The type number for the NXT RR is 30. The type number for the NXT RR is 30.
NXT RRs are only signed by zone level keys.
5.2 NXT RDATA Format 5.2 NXT RDATA Format
The RDATA for an NXT RR consists simply of a domain name followed by The RDATA for an NXT RR consists simply of a domain name followed by
a bit map, as shown below. a bit map, as shown below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next domain name / | next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type bit map / | type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NXT RR type bit map format currently defined is one bit per RR The NXT RR type bit map format currently defined is one bit per RR
type present for the owner name similar to the WKS RR socket bit map. type present for the owner name. A one bit indicates that at least
A one bit indicates that at least one RR of that type is present for one RR of that type is present for the owner name. A zero indicates
the owner name. A zero indicates that no such RR is present. All that no such RR is present. All bits not specified because they are
bits not specified because they are beyond the end of the bit map are beyond the end of the bit map are assumed to be zero. Note that bit
assumed to be zero. Note that bit 30, for NXT, will always be on so 30, for NXT, will always be on so the minimum bit map length is
the minimum bit map length is actually four octets. Trailing zero actually four octets. Trailing zero octets are prohibited in this
octets are prohibited in this format. The first bit represents RR format. The first bit represents RR type zero (an illegal type which
type zero (an illegal type which can not be present) and so will be can not be present) and so will be zero in this format. This format
zero in this format. This format is not used if there exists an RR is not used if there exists an RR with a type number greater than
with a type number greater than 127. If the zero bit of the type bit 127. If the zero bit of the type bit map is a one, it indicates that
map is a one, it indicates that a different format is being used a different format is being used which will always be the case if a
which will always be the case if a type number greater than 127 is type number greater than 127 is present.
present.
The domain name may be compressed with standard DNS name compression The domain name may be compressed with standard DNS name compression
when being transmitted over the network. The size of the bit map can when being transmitted over the network. The size of the bit map can
be inferred from the RDLENGTH and the length of the next domain name. be inferred from the RDLENGTH and the length of the next domain name.
5.3 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. All the NXT's are returned in the authority section of been returned except that there is no need to return multiple copies
the response. of the same NXT. These NXTs, if any, are returned in the authority
section 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 31, line 27 skipping to change at page 31, line 27
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.
The IXFR SIG really belongs to the zone as a whole, not to the zone The IXFR SIG really belongs to the zone as a whole, not to the zone
name. Although it should be correct for the zone name, the labels name. Although it SHOULD be correct for the zone name, the labels
field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only
sent as part of an incremental zone transfer. After validation of sent as part of an incremental zone transfer. After validation of
the IXFR SIG, the transferred RRs MAY be considered valid without the IXFR SIG, the transferred RRs MAY be considered valid without
verification of the internal SIGs if such trust in the server verification of the internal SIGs if such trust in the server
conforms to local policy. conforms to local policy.
6. How to Resolve Securely and the AD and CD Bits 6. How to Resolve Securely and the AD and CD Bits
Retrieving or resolving secure data from the Domain Name System (DNS) Retrieving or resolving secure data from the Domain Name System (DNS)
involves starting with one or more trusted public keys that have been involves starting with one or more trusted public keys that have been
skipping to change at page 32, line 43 skipping to change at page 32, line 43
described in Section 6.1. described in Section 6.1.
The proper validation of signatures requires a reasonably secure The proper validation of signatures requires a reasonably secure
shared opinion of the absolute time between resolvers and servers as shared opinion of the absolute time between resolvers and servers as
described in Section 6.4. described in Section 6.4.
6.1 The AD and CD Header Bits 6.1 The AD and CD Header Bits
Two previously unused bits are allocated out of the DNS Two previously unused bits are allocated out of the DNS
query/response format header. The AD (authentic data) bit indicates query/response format header. The AD (authentic data) bit indicates
in a response that all the data included in the response is answer in a response that all the data included in the answer and authority
and authority data that has been authenticated by the server portion of the response has been authenticated by the server
according to the policies of that server or is accompanying according to the policies of that server. The CD (checking disabled)
additional information section data. The CD (checking disabled) bit bit indicates in a query that Pending (non-authenticated) data is
indicates in a query that Pending (non-authenticated) data is
acceptable to the resolver sending the query. acceptable to the resolver sending the query.
These bits are allocated from the previously must-be-zero Z field as These bits are allocated from the previously must-be-zero Z field as
follows: follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 34, line 13 skipping to change at page 34, line 13
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 outsize the organization's
domain and should not be configured with keys above the domain and need not be configured with keys above the organization's
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 and, if the zone is not root, for its superzone. If an a key. A secure sub-zone is indicated by a KEY RR with non-null key
authoritative secure zone server will have its public key (or that of information appearing with the NS RRs for the sub-zone. These make
any subzone) staticly configured, then it MUST also include the KEY it possible to descend within the tree of zones.
RR for one or more super-zones (possibly including root) signed by
the secure zone via static configuration. It is safest to always
include this upward key. This makes it possible to climb the tree of
zones if one starts below root. A secure sub-zone is indicated by a
KEY RR with non-null key information appearing with the NS RRs for
the sub-zone. 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
original data whose authenticity is to be shown and the final KEY original data whose authenticity is to be shown and the final KEY
being some trusted key staticly configured at the resolver performing being some trusted key staticly configured at the resolver performing
the authentication. the authentication.
In testing such a chain, the validity periods of the SIGs encountered In testing such a chain, the validity periods of the SIGs encountered
must be intersected to determine the validity period of the must be intersected to determine the validity period of the
authentication of the data, a purely algorithmic process. In authentication of the data, a purely algorithmic process. In
addition, the validation of each SIG over the data with reference to addition, the validation of each SIG over the data with reference to
a KEY must meet the objective cryptographic test implied by the a KEY must meet the objective cryptographic test implied by the
cryptographic algorithm used, although even here the resolver may cryptographic algorithm used (although even here the resolver may
have policies as to trusted algorithms and key lengths. Finally, the have policies as to trusted algorithms and key lengths). Finally,
judgement that a SIG with a particular signer name can authenticate the judgement that a SIG with a particular signer name can
data (possibly a KEY RRset) with a particular owner name, is authenticate data (possibly a KEY RRset) with a particular owner
primarily a policy question. Ultimately, this is a policy local to name, is primarily a policy question. Ultimately, this is a policy
the resolver and any clients that depend on that resolver's local to the resolver and any clients that depend on that resolver's
decisions. It is, however, recommended, that the following policy be decisions. It is, however, recommended, that the policy below be
adopted: adopted:
Let A < B mean that A is a shorter domain name than B formed by Let A < B mean that A is a shorter domain name than B formed by
dropping one or more whole labels from the left end of B, i.e., dropping one or more whole labels from the left end of B, i.e.,
A is a direct or indirect superdomain of B. Let A = B mean that A is a direct or indirect superdomain of B. Let A = B mean that
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
skipping to change at page 38, line 30 skipping to change at page 37, line 30
252 INDIRECT 252 INDIRECT
253 NULL (obsolete, see RFC 2065) 253 NULL (obsolete, see RFC 2065)
254 PRIVATE 254 PRIVATE
7.1 Presentation of KEY RRs 7.1 Presentation of KEY RRs
KEY RRs may appear as single logical lines in a zone data master file KEY RRs may appear as single logical lines in a zone data master file
[RFC 1033]. [RFC 1033].
The flag field is represented as an unsigned integer or a sequence of The flag field is represented as an unsigned integer or a sequence of
mnemonics as follows: mnemonics as follows separated by instances of the verticle bar ("|")
character:
BIT Mnemonic Explanation BIT Mnemonic Explanation
0-1 key type 0-1 key type
NOCONF =1 confidentiality use prohibited NOCONF =1 confidentiality use prohibited
NOAUTH =2 authentication use prohibited NOAUTH =2 authentication use prohibited
NOKEY =3 no key present NOKEY =3 no key present
2 FLAG2 - reserved 2 FLAG2 - reserved
3 EXTEND flags extension 3 EXTEND flags extension
4 FLAG4 - reserved 4 FLAG4 - reserved
5 FLAG5 - reserved 5 FLAG5 - reserved
skipping to change at page 39, line 4 skipping to change at page 38, line 4
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
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
255 ALL 255 ALL
skipping to change at page 39, line 32 skipping to change at page 38, line 35
Note that the public key may have internal sub-fields but these do Note that the public key may have internal sub-fields but these do
not appear in the master file representation. For example, with not appear in the master file representation. For example, with
algorithm 1 there is a public exponent size, then a public exponent, algorithm 1 there is a public exponent size, then a public exponent,
and then a modulus. With algorithm 254, there will be an OID size, and then a modulus. With algorithm 254, there will be an OID size,
an OID, and algorithm dependent information. But in both cases only a an OID, and algorithm dependent information. But in both cases only a
single logical base 64 string will appear in the master file. single logical base 64 string will appear in the master file.
7.2 Presentation of SIG RRs 7.2 Presentation of SIG RRs
A SIG RR may be represented as a single logical line in a zone data A data SIG RR may be represented as a single logical line in a zone
file [RFC 1033] but there are some special considerations as data file [RFC 1033] but there are some special considerations as
described below. (It does not make sense to include a transaction or described below. (It does not make sense to include a transaction or
request authenticating SIG RR in a file as they are a transient request authenticating SIG RR in a file as they are a transient
authentication that covers data including an ephemeral transaction authentication that covers data including an ephemeral transaction
number and so must be calculated in real time.) number and so must be calculated in real time.)
There is no particular problem with the signer, covered type, and There is no particular problem with the signer, covered type, and
times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY
is the year, the first MM is the month number (01-12), DD is the day is the year, the first MM is the month number (01-12), DD is the day
of the month (01-31), HH is the hour in 24 hours notation (00-23), of the month (01-31), HH is the hour in 24 hours notation (00-23),
the second MM is the minute (00-59), and SS is the second (00-59). the second MM is the minute (00-59), and SS is the second (00-59).
skipping to change at page 40, line 22 skipping to change at page 39, line 24
to single base 64 digits, which are concatenated to obtain the full to single base 64 digits, which are concatenated to obtain the full
signature. These substrings can be split between lines using the signature. These substrings can be split between lines using the
standard parenthesis. standard parenthesis.
7.3 Presentation of NXT RRs 7.3 Presentation of NXT RRs
NXT RRs do not appear in original unsigned zone master files since NXT RRs do not appear in original unsigned zone master files since
they should be derived from the zone as it is being 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 in the same format as the WKS RR. RR type present bits as an unsigned interger or sequence of RR
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 describes the canonical form of resource records (RRs),
their default name order, and their order, for purposes of domain their default name order, and their order, for purposes of domain
name system (DNS) security. A canonical name order is necessary to name system (DNS) security. A canonical name order is necessary to
construct the NXT name chain. A canonical form and ordering within construct the NXT name chain. A canonical form and ordering within
an RRset is necessary in constructing SIG RRs. A canonical ordering an RRset is necessary in consistently constructing and verifying SIG
of types within a name is required in connection with incremental RRs. A canonical ordering of types within a name is required in
transfer (Section 5.6.2). 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.
skipping to change at page 43, line 42 skipping to change at page 42, line 42
9.2 Resolver Conformance 9.2 Resolver Conformance
Two levels of resolver compliance (including the resolver portion of Two levels of resolver compliance (including the resolver portion of
a server) are defined for DNS Security: a server) are defined for DNS Security:
BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
when they are explicitly requested. when they are explicitly requested.
FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
RRs including verification of SIGs, (2) maintains appropriate RRs including verification of SIGs at least for the mandatory
information in its local caches and database to indicate which RRs algorithm, (2) maintains appropriate information in its local caches
have been authenticated and to what extent they have been and database to indicate which RRs have been authenticated and to
authenticated, (3) performs additional queries as necessary to what extent they have been authenticated, (3) performs additional
attempt to obtain KEY, SIG, or NXT RRs when needed, (4) normally sets queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
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 origin authentication, public
key distribution, and optional transaction and request security. 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
skipping to change at page 47, line 19 skipping to change at page 46, line 19
318 Acton Street 318 Acton Street
Carlisle, MA 01741 USA Carlisle, MA 01741 USA
Telephone: +1 978-287-4877 Telephone: +1 978-287-4877
+1 703-620-4200 (main office, Reston, Virginia, USA) +1 703-620-4200 (main office, Reston, Virginia, USA)
fax: +1 978-371-7148 fax: +1 978-371-7148
email: dee@cybercash.com email: dee@cybercash.com
Expiration and File Name Expiration and File Name
This draft expires September 1998. This draft expires October 1998.
Its file name is draft-ietf-dnssec-secext2-04.txt. Its file name is draft-ietf-dnssec-secext2-05.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 51, line 4 skipping to change at page 50, line 4
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.
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, and (5c) bit zero set have been reserved for future definition, (5c) the
extending the number of and circumstances under which an NXT must number of and circumstances under which an NXT must be returned in
be returned in connection with wildcard names. connection with wildcard names has been extended, and (5d) in
connection with the bit map, references to the WKS RR have been
removed and verticle bars ("|") have been added between the RR
type mnemonics in the ASCII representation.
6. Information on the canonical form and ordering of RRs has been 6. Information on the canonical form and ordering of RRs has been
moved into a separate Section 8. moved into a separate Section 8.
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 relaxed in cases where the zone's authoritative servers has been removed. The
the public key for that zone and all of its direct and indirect recommendation was dropped to continue DNS security checks in a
subzones is not staticly configured. The recommendation was secure island of DNS data that is separated from other parts of
dropped to continue DNS security checks in a secure island of DNS the DNS tree by insecure zones and does not contain a zone for
data that is separated from other parts of the DNS tree by which a key has been staticly configured.
insecure zones and does not contain a zone for which a key has
been staticly configured.
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.
10. It is now required that KEY RRs and NXT RRs be signed only with
zone-level keys.
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. It is possible for more than one candidate key to have
the same tag, in which case each must be tried in verifying a the same tag, in which case each must be tried in verifying a
signature, for example, until one works or all fail. The following signature, for example, until one works or all fail. The following
reference implementation is in ANSI C. It is coded for clarity, not reference implementation is in ANSI C. It is coded for clarity, not
efficiency. efficiency.
 End of changes. 50 change blocks. 
131 lines changed or deleted 134 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/