draft-ietf-dnssec-secext2-01.txt   draft-ietf-dnssec-secext2-02.txt 
DNS Security Working Group Donald E. Eastlake 3rd DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT CyberCash
OBSOLETES RFC 2065 OBSOLETES RFC 2065
UPDATES RFC 1034, 1035 UPDATES RFC 1034, 1035
Expires: 22 February 1998 23 August 1997 Expires: 20 May 1998 21 November 1997
Domain Name System Security Extensions Domain Name System Security Extensions
------ ---- ------ -------- ---------- ------ ---- ------ -------- ----------
Status of This Document Status of This Document
This draft, file name draft-ietf-dnssec-secext2-01.txt, is intended This draft, file name draft-ietf-dnssec-secext2-02.txt, is intended
to become a Draft Standard RFC obsoleting Proposed Standard RFC 2065. to become a Draft Standard RFC obsoleting Proposed Standard RFC 2065.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the DNS Security Working Group mailing list <dns-security@tis.com> to the DNS Security Working Group mailing list <dns-security@tis.com>
or to the author. or to the author.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
distribution services as well as DNS security. The stored keys distribution services as well as DNS security. The stored keys
enable security aware resolvers to learn the authenticating key of enable security aware resolvers to learn the authenticating key of
zones in addition to those for which they are initially configured. zones in addition to those for which they are initially configured.
Keys associated with DNS names can be retrieved to support other Keys associated with DNS names can be retrieved to support other
protocols. Provision is made for a variety of key types and protocols. Provision is made for a variety of key types and
algorithms. algorithms.
In addition, the security extensions provide for the optional In addition, the security extensions provide for the optional
authentication of DNS protocol transactions and requests. authentication of DNS protocol transactions and requests.
This document incorporates feedback from implementors and potential This document incorporates feedback from early implementors and
users to RFC 2065. potential users on RFC 2065.
Acknowledgments Acknowledgments
The significant contributions of the following persons (in alphabetic The significant contributions of the following persons (in alphabetic
order) to DNS security are gratefully acknowledged: order) to DNS security are gratefully acknowledged:
James M. Galvin James M. Galvin
John Gilmore John Gilmore
Olafur Gudmundsson Olafur Gudmundsson
Charlie Kaufman Charlie Kaufman
skipping to change at page 3, line 19 skipping to change at page 3, line 19
Abstract...................................................2 Abstract...................................................2
Acknowledgments............................................2 Acknowledgments............................................2
Table of Contents..........................................3 Table of Contents..........................................3
1. Overview of Contents....................................5 1. Overview of Contents....................................5
2. Overview of the DNS Extensions..........................6 2. Overview of the DNS Extensions..........................6
2.1 Services Not Provided..................................6 2.1 Services Not Provided..................................6
2.2 Key Distribution.......................................6 2.2 Key Distribution.......................................6
2.3 Data Origin Authentication and Integrity...............7 2.3 Data Origin Authentication and Integrity...............7
2.3.1 The SIG Resource Record..............................8 2.3.1 The SIG Resource Record..............................7
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................................11
3.1 KEY RDATA format......................................12 3.1 KEY RDATA format......................................11
3.1.1 Object Types, DNS Names, and Keys...................12 3.1.1 Object Types, DNS Names, and Keys...................11
3.1.2 The KEY RR Flag Field...............................13 3.1.2 The KEY RR Flag Field...............................12
3.1.3 The Protocol Octet..................................15 3.1.3 The Protocol Octet..................................13
3.2 The KEY Algorithm Number Specification................15 3.2 The KEY Algorithm Number Specification................14
3.2.1 The MD5/RSA Algorithm...............................15 3.2.1 The MD5/RSA Algorithm...............................15
3.3 Interaction of Flags, Algorithm, and Protocol Bytes...16 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
3.4 Determination of Zone Secure/Unsecured Status.........16 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..............17
4. The SIG Resource Record................................19 4. The SIG Resource Record................................19
4.1 SIG RDATA Format......................................19 4.1 SIG RDATA Format......................................19
4.1.1 ....................................................19 4.1.1 ....................................................19
4.1.2 Algorithm Number Field..............................20 4.1.2 Algorithm Number Field..............................20
4.1.3 Labels Field........................................20 4.1.3 Labels Field........................................20
4.1.4 Original TTL Field..................................20 4.1.4 Original TTL Field..................................20
4.1.5 Signature Expiration and Time Signed Fields.........21 4.1.5 Signature Expiration and Time Signed Fields.........21
4.1.6 Key Tag Field.......................................21 4.1.6 Key Tag Field.......................................21
4.1.7 Signer's Name Field.................................21 4.1.7 Signer's Name Field.................................21
skipping to change at page 4, line 7 skipping to change at page 4, line 7
4.1.8.1 Signature Data....................................22 4.1.8.1 Signature Data....................................22
4.1.8.2 MD5/RSA Algorithm Signature Calculation...........22 4.1.8.2 MD5/RSA Algorithm Signature Calculation...........22
4.1.8.3 Transaction and Request SIGs......................23 4.1.8.3 Transaction and Request SIGs......................23
4.2 SIG RRs in the Construction of Responses..............24 4.2 SIG RRs in the Construction of Responses..............24
4.3 Processing Responses and SIG RRs......................25 4.3 Processing Responses and SIG RRs......................25
4.4 Signature Lifetime, Expiration, TTLs, and Validity....26 4.4 Signature Lifetime, Expiration, TTLs, and Validity....26
4.5 The Root Zone as Signer...............................26 4.5 The Root Zone as Signer...............................26
5. Non-existent Names and Types...........................27 5. Non-existent Names and Types...........................27
5.1 The NXT Resource Record...............................27 5.1 The NXT Resource Record...............................27
5.2 NXT RDATA Format......................................28 5.2 NXT RDATA Format......................................28
5.3 Example...............................................28 5.3 Additional Complexity Due to Wildcards................28
5.4 Special Considerations at Delegation Points...........29 5.4 Example...............................................29
5.5 Zone Transfers........................................29 5.5 Special Considerations at Delegation Points...........29
5.5.1 Incremental Zone Transfers..........................30 5.6 Zone Transfers........................................30
5.6.1 Incremental Zone Transfers..........................30
6. How to Resolve Securely and the AD and CD Bits.........31 6. How to Resolve Securely and the AD and CD Bits.........32
6.1 The AD and CD Header Bits.............................31 6.1 The AD and CD Header Bits.............................32
6.2 Staticly Configured Keys..............................32 6.2 Staticly Configured Keys..............................33
6.3 Chaining Through The DNS..............................33 6.3 Chaining Through The DNS..............................34
6.3.1 Chaining Through KEYs...............................33 6.3.1 Chaining Through KEYs...............................34
6.3.2 Conflicting Data....................................34 6.3.2 Conflicting Data....................................35
6.4 Secure Time...........................................35 6.4 Secure Time...........................................36
7. ASCII Representation of Security RRs...................36 7. ASCII Representation of Security RRs...................37
7.1 Presentation of KEY RRs...............................36 7.1 Presentation of KEY RRs...............................37
7.2 Presentation of SIG RRs...............................37 7.2 Presentation of SIG RRs...............................38
7.3 Presentation of NXT RRs...............................38 7.3 Presentation of NXT RRs...............................39
8. Canonical Form and Order of Resource Records...........39 8. Canonical Form and Order of Resource Records...........40
8.1 Canonical RR Form.....................................39 8.1 Canonical RR Form.....................................40
8.2 Canonical DNS Name Order..............................39 8.2 Canonical DNS Name Order..............................40
8.3 Canonical RR Ordering Within An RRset.................39 8.3 Canonical RR Ordering Within An RRset.................40
9. Conformance............................................40 9. Conformance............................................41
9.1 Server Conformance....................................40 9.1 Server Conformance....................................41
9.2 Resolver Conformance..................................40 9.2 Resolver Conformance..................................41
10. Security Considerations...............................41 10. Security Considerations...............................42
References................................................42 References................................................43
Author's Addresses........................................44 Author's Addresses........................................45
Expiration and File Name..................................44 Expiration and File Name..................................45
Appendix A: Base 64 Encoding..............................45 Appendix A: Base 64 Encoding..............................46
Appendix B: Changes from RFC 2065.........................47 Appendix B: Changes from RFC 2065.........................48
Appendix C: Key Tag Calculation...........................48 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, and 1035. An earlier particularly as described in RFCs 1033, 1034, and 1035. An earlier
version of these extensions appears in RFC 2065. This replacement version of these extensions appears in RFC 2065. This replacement
for that RFC incorporates implementation experience and requests from for that RFC incorporates early implementation experience and
potential users. requests from potential users.
Section 2 provides an overview of the extensions and the key Section 2 provides an overview of the extensions and the key
distribution, data origin authentication, and transaction and request distribution, data origin authentication, and transaction and request
security they provide. security they provide.
Section 3 discusses the KEY resource record, its structure, and use Section 3 discusses the KEY resource record, its structure, and use
in DNS responses. These resource records represent the public keys in DNS responses. These resource records represent the public keys
of entities named in the DNS and are used for key distribution. of entities named in the DNS and are used for key distribution.
Section 4 discusses the SIG digital signature resource record, its Section 4 discusses the SIG digital signature resource record, its
structure, and use in DNS responses. These resource records are used structure, and use in DNS responses. These resource records are used
to authenticate other resource records in the DNS and optionally to to authenticate other resource records in the DNS and optionally to
authenticate DNS transactions and requests. authenticate DNS transactions and requests.
Section 5 discusses the NXT resource record (RR) and its use in DNS Section 5 discusses the NXT resource record (RR) and its use in DNS
responses including full and incremental zone transfers. The NXT RR responses including full and incremental zone transfers. The NXT RR
permits authenticated denial of the existence of a name or of a permits authenticated denial of the existence of a name or of an RR
particular type for an existing name. type for an existing name.
Section 6 discusses how a resolver can be configured with a starting Section 6 discusses how a resolver can be configured with a starting
key or keys and proceed to securely resolve DNS requests. key or keys and proceed to securely resolve DNS requests.
Interactions between resolvers and servers are discussed for Interactions between resolvers and servers are discussed for
combinations of security aware and security non-aware. Two combinations of security aware and security non-aware. Two
additional DNS header bits are defined for signaling between additional DNS header bits are defined for signaling between
resolvers and servers. resolvers and servers.
Section 7 describes the ASCII representation of the security resource Section 7 describes the ASCII representation of the security resource
records for use in master files and elsewhere. records for use in master files and elsewhere.
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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] or TLS [draft-ietf-tls-*].) 1825] or TLS [draft-ietf-tls-*].)
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 the DNS data origin authentication and other mechanism in support of DNS security itself and other protocols.
security services.
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.
It includes an algorithm identifier, the actual public key It includes an algorithm identifier, the actual public key
parameter(s), and a variety of flags including those indicating the parameter(s), and a variety of flags including those indicating the
type of entity the key is associated with and/or asserting that there type of entity the key is associated with and/or asserting that there
is no key associated with that entity. is no key associated with that entity.
Under conditions described in Section 3.5, security aware DNS servers Under conditions described in Section 3.5, security aware DNS servers
will automatically attempt to return KEY resources as additional will automatically attempt to return KEY resources as additional
information, along with those resource records actually requested, to information, along with those resource records actually requested, to
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) the DNS cryptographically generated digital signatures. (RRsets) in the DNS cryptographically generated digital signatures.
Commonly, there will be a single private key that signs for an entire Commonly, there will be a single private key that signs for an entire
zone. If a security aware resolver reliably learns the public key of zone. If a security aware resolver reliably learns the public key of
the zone, it can verify, for signed data read from that zone, that it the zone, it can verify, for signed data read from that zone, that it
was properly authorized and is current. The most secure was properly authorized and is current. The most secure
implementation is for the zone private key to be kept off-line and implementation is for the zone private key to be kept off-line and
used to re-sign all of the records in the zone periodically. used to re-sign all of the records in the zone periodically.
This data origin authentication key belongs to the zone and not to This data origin authentication key belongs to the zone and not to
the servers that store copies of the data. That means compromise of the servers that store copies of the data. That means compromise of
a server or even all servers for a zone will not necessarily affect a server or even all servers for a zone will not necessarily affect
skipping to change at page 7, line 39 skipping to change at page 7, line 38
zones, if the intervening zones in the DNS tree are secure and their zones, if the intervening zones in the DNS tree are secure and their
signed keys accessible. 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 from 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
Section 2.3.5). Section 2.3.5).
If signatures are separately retrieved and verified when retrieving If signatures are separately retrieved and verified when retrieving
the information they authenticate, there will be more trips to the the information they authenticate, there will be more trips to the
server and performance will suffer. Security aware servers mitigate server and performance will suffer. Security aware servers mitigate
that degradation by attempting to send the signature(s) needed. that degradation by attempting to send the signature(s) needed (see
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 RR set being signed to the Section 4. It cryptographically binds the RR set being signed to the
signer and a validity interval. signer and a validity interval.
Every name in a secured zone will have associated with it at least Every name in a secured zone will have associated with it at least
one SIG resource record for each resource type under that name except one SIG resource record for each resource type under that name except
for glue address RRs and 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.
2.3.2 Authenticating Name and Type Non-existence 2.3.2 Authenticating Name and Type Non-existence
The above security mechanism only provides a way to sign existing RR The above security mechanism only provides a way to sign existing
sets in a zone. "Data origin" authentication is not obviously RRsets in a zone. "Data origin" authentication is not obviously
provided for the non-existence of a domain name in a zone or the provided for the non-existence of a domain name in a zone or the
non-existence of a type for an existing name. This gap is filled by non-existence of a type for an existing name. This gap is filled by
the NXT RR which authenticatably asserts a range of non-existent the NXT RR which authenticatably asserts a range of non-existent
names in a zone and the non-existence of types for the existing name names in a zone and the non-existence of types for the existing name
just before that range. just before that range.
Section 5 below covers the NXT RR. Section 5 below covers the NXT RR.
2.3.3 Special Considerations With Time-to-Live 2.3.3 Special Considerations With Time-to-Live
skipping to change at page 10, line 11 skipping to change at page 10, line 8
with CNAME RRs, (2) suppress CNAME processing on retrieval of these with CNAME RRs, (2) suppress CNAME processing on retrieval of these
types as well as on retrieval of the type CNAME, and (3) types as well as on retrieval of the type CNAME, and (3)
automatically return SIG RRs authenticating the CNAME or CNAMEs automatically return SIG RRs authenticating the CNAME or CNAMEs
encountered in resolving a query. This is a change from the previous encountered in resolving a query. This is a change from the previous
DNS standard [RFCs 1034/1035] which prohibited any other RR type at a DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
node where a CNAME RR was present. node where a CNAME RR was present.
2.3.6 Signers Other Than The Zone 2.3.6 Signers Other Than The Zone
There are two cases where a SIG resource record is signed by other There are two cases where a SIG resource record is signed by other
than the zone private key. than the zone private key (see Section 2.4).
One is for support of dynamic update [RFC 2136], or future requests One is for support of dynamic update [RFC 2136], or future requests
which require authentication, where an entity is permitted to which require authentication, where an entity is permitted to
authenticate/update its records [RFC tbd]. 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 appropriately signed but the
other RR(s) may be signed with the entity's key. other RR(s) may be signed with the entity's key.
The second case is support of transaction and request authentication The second case is support of transaction authentication.
as described in Section 2.4 immediately below.
2.4 DNS Transaction and Request Authentication 2.4 DNS Transaction and Request Authentication
The data origin authentication service described above protects The data origin authentication service described above protects
retrieved resource records but provides no protection for DNS retrieved resource records but provides no protection for DNS
requests or for message headers. requests or for message headers.
If header bits are falsely set by a bad server, there is little that If header bits are falsely set by a bad server, there is little that
can be done. However, it is possible to add transaction can be done. However, it is possible to add transaction
authentication. Such authentication means that a resolver can be authentication. Such authentication means that a resolver can be
skipping to change at page 10, line 44 skipping to change at page 10, line 40
accomplished by optionally adding a special SIG resource record at accomplished by optionally adding a special SIG resource record at
the end of the reply which digitally signs the concatenation of the the end of the reply which digitally signs the concatenation of the
server's response and the resolver's query. server's response and the resolver's query.
Requests can also be authenticated by including a special SIG RR at Requests can also be authenticated by including a special SIG RR at
the end of the request. Authenticating requests serves no function the end of the request. Authenticating requests serves no function
in older DNS servers and requests with a non-empty additional in older DNS servers and requests with a non-empty additional
information section are ignored by many older and current DNS information section are ignored by many older and current DNS
servers. However, this syntax for signing requests is defined in servers. However, this syntax for signing requests is defined in
connection with authenticating secure dynamic update requests [RFC connection with authenticating secure dynamic update requests [RFC
tbd] or future requests requiring authentication. 2137] or future requests requiring authentication.
The private keys used in transaction and request security belong to The private keys used in transaction and request security belong to
the host composing the request or reply, not to the zone involved. the host composing the request or reply, not to the zone involved.
The corresponding public key is normally stored in and retrieved from The corresponding public key is normally stored in and retrieved from
the DNS for verification. the DNS for verification.
Because requests and replies are highly variable, message Because requests and replies are highly variable, message
authentication SIGs can not be pre-calculated. Thus it will be authentication SIGs can not be pre-calculated. Thus it will be
necessary to keep the private key on-line, for example in software or necessary to keep the private key on-line, for example in software or
in a directly connected piece of hardware. in a directly connected piece of hardware.
3. The KEY Resource Record 3. The KEY Resource Record
The KEY resource record (RR) is used to store a 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 host or other end entity, or a user. A KEY public key of a zone, a user, or a host or other end entity. A KEY
RR is, like any other RR, authenticated by a SIG RR. Security aware RR is, like any other RR, authenticated by a SIG RR. Security aware
DNS implementations MUST be designed to handle at least two DNS implementations MUST be designed to handle at least two
simultaneously valid keys of the same type associated with 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.
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
skipping to change at page 13, line 23 skipping to change at page 12, line 23
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| IP| Z | Z | Z | SIG | | A/C | Z | XT| Z | Z | NAMTYP| IP| Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bit 0 and 1 are the key "type" bits. Bit 0 a one indicates that use Bit 0 and 1 are the key "type" bits.
of the key is prohibited for authentication. Bit 1 a one Bit 0 a one indicates that use of the key is prohibited for
indicates that use of the key is prohibited for confidentiality. authentication.
Bit 1 a one indicates that use of the key is prohibited for
confidentiality.
If this field is zero, then use of the key for authentication If this field is zero, then use of the key for authentication
and/or confidentiality is permitted. Note that DNS security makes and/or confidentiality is permitted. Note that DNS security makes
use of keys for authentication only. Confidentiality use flagging use of keys for authentication only. Confidentiality use flagging
is provided for use of keys in other protocols. Implementations is provided for use of keys in other protocols. Implementations
not intended to support key distribution for confidentiality MAY not intended to support key distribution for confidentiality MAY
require that the confidentiality use prohibited bit be on for keys require that the confidentiality use prohibited bit be on for keys
they serve. If both bits are one, the "no key" value, there is no they serve.
key information and the RR stops after the algorithm octet. By If both bits are one, the "no key" value, there is no key
the use of this "no key" value, a signed KEY RR can information and the RR stops after the algorithm octet. By the
authenticatably assert that, for example, a zone is not secured. use of this "no key" value, a signed KEY RR can authenticatably
See section 3.4 below. assert that, for example, a zone is not secured. See section 3.4
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
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.
skipping to change at page 14, line 26 skipping to change at page 13, line 29
commonly be a host but could, in some parts of the DNS tree, be commonly be a host but could, in some parts of the DNS tree, be
some other type of entity such as a telephone number [RFC 1530] or some other type of entity such as a telephone number [RFC 1530] or
numeric IP address. This is the public key used in connection numeric IP address. This is the public key used in connection
with DNS request and transaction authentication services if the with DNS request and transaction authentication services if the
owner name designates a DNS resolver or server host. It could owner name designates a DNS resolver or server host. It could
also be used in an IP-security protocol where authentication at also be used in an IP-security protocol where authentication at
the host, rather than user, level was desired, such as routing, the host, rather than user, level was desired, such as routing,
NTP, etc. NTP, etc.
The value of 3 is reserved. The value of 3 is reserved.
Bit 8 is reserved to be the Oakley/IPSEC [RFC 1825] bit and indicates Bits 8-11 are reserved and must be zero.
that this key is valid for use in conjunction with that security
standard. This key could be used in connection with secured
communication on behalf of an end entity or user whose name is the
owner name of the KEY RR if the entity or user bits are on. The
presence of a KEY resource with the Oakley/IPSEC bit on is an
assertion that the host speaks Oakley/IPSEC.
Bits 9 through 11 are reserved and must be zero.
Bits 12-15 are the "signatory" field. If non-zero, they indicate Bits 12-15 are the "signatory" field. If non-zero, they indicate
that the key can validly sign RRs or updates of the same name. If that the key can validly sign RRs or updates of the same name. If
the owner name is a wildcard, then RRs or updates with any name the owner name is a wildcard, then RRs or updates with any name
which is in the wildcard's scope can, in some cases, be signed. which is in the wildcard's scope can, in some cases, be signed.
Fifteen different non-zero values are possible for this field and Fifteen different non-zero values are possible for this field and
any differences in their meaning are reserved for definition in any differences in their meaning are reserved for definition in
connection with DNS dynamic update [RFC tbd] or other new DNS connection with DNS dynamic update [RFC 2137] or other new DNS
commands. Zone keys (see bits 6 and 7 above) always have commands. Zone keys (see bits 6 and 7 above) always have
authority to sign any RRs in the zone regardless of the value of authority to sign any RRs in the zone regardless of the value of
the signatory field. The signatory field, like all other aspects the signatory field. The signatory field, like all other aspects
of the KEY RR, is only effective if the KEY RR is appropriately of the KEY RR, is only effective if the KEY RR is appropriately
signed by a SIG RR. signed by a SIG RR.
3.1.3 The Protocol Octet 3.1.3 The Protocol Octet
It is anticipated that some keys stored in DNS will be used in It is anticipated that some keys stored in DNS will be used in
conjunction with Internet protocols other than DNS (keys with the conjunction with Internet protocols other than DNS (keys with the
zone name type or with their signatory field non-zero). It is zone name type or with their signatory field non-zero). It is
intended that the protocol octet and possibly some of the unused intended that the protocol octet and possibly some of the unused
(must be zero) bits in the KEY RR flags will be used for this (must be zero) bits in the KEY RR flags will be used for this
purpose. purpose.
The following values of the Protocol Octet are reserved as indicated: The following values of the Protocol Octet are reserved as indicated:
VALUE Protocol VALUE Protocol
0 -reserved
1 TLS 1 TLS
2 Email 2 email
3 dnssec
4 IPSEC
5-254 -available for assignment by IANA
255 -reserved
In more detail:
1 is reserved to refer to the TLS standard being developed by
the tls working group. The presence of a KEY resource with this
protocol value is an assertion that the host speaks TLS.
2 is reserved
3 is used for DNS security. The protocol field should be set to
this value for zone keys and other keys used in DNS security.
Implementations that can determine that a key is a DNS security key
by the fact that flags label it a zone key or the signatory flag
field is non-zero are not required to check the protocol field.
4 is reserved to refer to the Oakley/IPSEC [RFC 1825] protocol
and indicates that this key is valid for use in conjunction with that
security standard. This key could be used in connection with secured
communication on behalf of an end entity or user whose name is the
owner name of the KEY RR if the entity or user bits are on. The
presence of a KEY resource with this protocol value is an assertion
that the host speaks Oakley/IPSEC.
3.2 The KEY Algorithm Number Specification 3.2 The KEY Algorithm Number Specification
This octet is the key algorithm parallel to the same field for the This octet is the key algorithm parallel to the same field for the
SIG resource. The MD5/RSA algorithm described in this document is SIG resource. The MD5/RSA algorithm described in this document is
number 1. Numbers 2 through 253 are available for assignment should number 1. Numbers 2 through 253 are available for assignment should
sufficient reason arise. However, the designation of a new algorithm sufficient reason arise. However, the designation of a new algorithm
could have a major impact on interoperability and requires an IETF could have a major impact on interoperability and requires an IETF
standards action. Number 254 is reserved for private use and will standards action. Number 254 is reserved for private use and will
never be assigned a specific algorithm. For number 254, the public never be assigned a specific algorithm. For number 254, the public
key area for the KEY RR and the signature will actually begin with a key area for the KEY RR and the signature will actually begin with a
length byte followed by an Object Identifier (ISO OID) of that length byte followed by an Object Identifier (ISO OID) of that
length. The OID indicates the private algorithm in use and the length. The OID indicates the private algorithm in use and the
remainder of the area is whatever is required by that algorithm. remainder of the area is whatever is required by that algorithm.
Values 0 and 255 are reserved. Values 0 and 255 are reserved.
3.2.1 The MD5/RSA Algorithm 3.2.1 The MD5/RSA Algorithm
If the type field does not have the "no key" value and the algorithm If the type flag field does not have the "no key" value and the
field is 1, indicating the MD5/RSA algorithm, the public key field is algorithm field is 1, indicating the MD5/RSA algorithm, the public
structured as follows: key field is structured as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pub exp length| public key exponent / | pub exp length| public key exponent /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
+- modulus / +- modulus /
| / | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
skipping to change at page 17, line 18 skipping to change at page 16, line 41
authenticated by a SIG RR or it will be discarded as bogus, (2) authenticated by a SIG RR or it will be discarded as bogus, (2)
unsecured, indicating that SIG RRs are not expected or required for unsecured, indicating that SIG RRs are not expected or required for
RRs retrieved from the zone, or (3) experimentally secure, which RRs retrieved from the zone, or (3) experimentally secure, which
indicates that SIG RRs might or might not be present but must be indicates that SIG RRs might or might not be present but must be
checked if found. The status of a zone is determined as follows: checked if found. The status of a zone is determined as follows:
1. If, for a zone, every zone KEY RR signed by a signer trusted by 1. If, for a zone, every zone KEY RR signed by a signer trusted by
the resolver and authorized by resolver policy to sign says there the resolver and authorized by resolver policy to sign says there
is no key for that zone, it is unsecured. is no key for that zone, it is unsecured.
2. If, for every trusted and resolver policy authorized zone KEY RR 2. If, for at least one trusted and resolver policy authorized zone
signer for a zone, there is at least one no-key KEY RR and at KEY RR signer for a zone, there is both a no-key KEY RR and a key
least one key specifying KEY RR(s), then that zone is only specifying KEY RR(s), then that zone is only experimentally
experimentally secure. Both authenticated and non-authenticated secure. Both authenticated and non-authenticated RRs for it
RRs for it should be accepted by the resolver. should be accepted by the resolver.
3. If every trusted and resolver policy authorized zone KEY RR signer 3. If every trusted and resolver policy authorized zone KEY RR signer
for the zone has only key specifying KEY RR(s) for the zone, then for the zone has only key specifying KEY RR(s) for the zone, then
it is secure and only authenticated RRs from it will be accepted. it is secure and only authenticated RRs from it will be accepted.
Examples: Examples:
(1) A resolver only trusts signatures by the superzone within the (1) A resolver only trusts signatures by the superzone within the
DNS hierarchy so it will look only at the KEY RRs that are signed by DNS hierarchy so it will look only at the KEY RRs that are signed by
the superzone. If it finds only no-key KEY RRs, it will assume the the superzone. If it finds only no-key KEY RRs, it will assume the
zone is not secure. If it finds only key specifying KEY RRs, it will zone is not secure. If it finds only key specifying KEY RRs, it will
assume the zone is secure and reject any unsigned responses. If it assume the zone is secure and reject any unsigned responses. If it
finds both, it will assume the zone is experimentally secure finds both, it will assume the zone is experimentally secure
(2) A resolver trusts the superzone of zone Z (to which it got (2) A resolver trusts the superzone of zone Z (to which it got
securely from its local zone) and a third party, cert-auth.xx. When securely from its local zone) and a third party, cert-auth.xy. When
considering data from zone Z, it may be signed by the superzone of Z, considering data from zone Z, it may be signed by the superzone of Z,
by cert-auth.xx, by both, or by neither. The following table by cert-auth.xy, by both, or by neither. The following table
indicates whether zone Z will be considered secure, experimentally indicates whether zone Z will be considered secure, experimentally
secure, or unsecured, depending on the signed zone KEY RRs for Z; secure, or unsecured, depending on the signed zone KEY RRs for Z;
c e r t - a u t h . x x c e r t - a u t h . x y
| None | NoKeys | Mixed | Keys | | 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 16 skipping to change at page 17, line 41
3.5 KEY RRs in the Construction of Responses 3.5 KEY RRs in the Construction of Responses
An explicit request for KEY RRs does not cause any special additional An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG information processing except, of course, for the corresponding SIG
RR from a security aware server. RR from a security aware server.
Security aware DNS servers 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 NS RRs, the zone key KEY RR(s) for the zone (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
served by these name servers must be included as additional name (usually 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, even if it has the no-key type value to such KEY RR in a secure zone in connection with a subzone delegation
indicate that the subzone is unsecured. If not all additional point, even if it has the no-key type value to indicate that the
information will fit, the KEY RR(s) have higher priority than type A subzone is unsecured. If not all additional information will fit,
or AAAA glue RRs. If such a KEY RR does not fit on a retrieval, the the type A or AAAA glue RRs have higher priority than KEY RR(s).
retrieval must be considered truncated.
(2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
be included if space is available. On inclusion of A or AAAA RRs as name (usually just a host RR and NOT the zone key which usually would
additional information, KEY RRs with the same name will also be have a different name) SHOULD be included if space is available. On
included but with lower priority than the A or AAAA RRs. inclusion of A or AAAA RRs as additional information, the KEY RRset
with the same name should also be included but with 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 of a particular type, The SIG RR unforgably authenticates an RRset of a particular type,
class, and name and binds it to a time interval and the signer's class, and name and binds it to a time interval and the signer's
domain name. This is done using cryptographic techniques and the domain name. This is done using cryptographic techniques and the
skipping to change at page 21, line 36 skipping to change at page 21, line 36
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 below, it is the next to the bottom two octets (MD5/RSA) as defined below, it is the next to the bottom two octets
of the public key modulus needed to decode the signature field. That of the public key modulus needed to decode the signature field. That
is to say, the most significant 16 of the lest significant 24 bits of is to say, the most significant 16 of the lest significant 24 bits of
the modulus in network order. For all other algorithms, including the modulus in network (big endian) order. For all other algorithms,
private algorithms, it is calculated as a simple checksum of the KEY including private algorithms, it is calculated as a simple checksum
RR as described in Appendix C. of the KEY RR as described in Appendix C.
4.1.7 Signer's Name Field 4.1.7 Signer's Name Field
The "signer's name" field is the domain name of the signer generating The "signer's name" field is the domain name of the signer generating
the SIG RR. This is the owner of the public KEY RR that can be used the SIG RR. This is the owner of the public KEY RR that can be used
to verify the signature. It is frequently the zone which contained to verify the signature. It is frequently the zone which contained
the RRset being authenticated. What signers signers should be the RRset being authenticated. What signers should be authorized to
authorized to sign what is a significant resolver policy question as sign what is a significant resolver policy question as discussed in
discussed in Section 6. The signer's name may be compressed with Section 6. The signer's name may be compressed with standard DNS name
standard DNS name compression when being transmitted over the compression when being transmitted over the network.
network.
4.1.8 Signature Field 4.1.8 Signature Field
The structure of the "signature" field is described below. The structure of the "signature" field is described below.
4.1.8.1 Signature Data 4.1.8.1 Signature Data
The actual signature portion of the SIG RR binds the other RDATA The actual signature portion of the SIG RR binds the other RDATA
fields to all of the "type covered" RRs with that owner name and fields to all of the "type covered" RRs with that owner name and
class. This covered RRset is thereby authenticated. To accomplish class. This covered RRset is thereby authenticated. To accomplish
this, a data sequence is constructed as follows: this, a data sequence is constructed as follows:
data = RDATA | RR(s)... data = RDATA | RR(s)...
where "|" is concatenation, RDATA is wire format of all the RDATA where "|" is concatenation, RDATA is wire format of all the RDATA
fields in the SIG RR itself including the canonical form of the fields in the SIG RR itself including the canonical form of the
signers name before and not including the signature, and RR(s) are signers name before but not including the signature, and RR(s) are
all the RR(s) of the type covered with the same owner name and class all the RR(s) of the type covered with the same owner name and class
as the SIG RR in canonical form and order as defined in section 8. as the SIG RR in canonical form and order as defined in Section 8.
How this data sequence is processed into the signature is algorithm How this data sequence is processed into the signature is algorithm
dependent. dependent.
SIGs SHOULD NOT be included in a zone for any "meta-type" such as SIGs SHOULD NOT be included in a zone for any "meta-type" such as
ANY, AXFR, etc. ANY, AXFR, etc.
4.1.8.2 MD5/RSA Algorithm Signature Calculation 4.1.8.2 MD5/RSA Algorithm Signature Calculation
For the MD5/RSA algorithm, the signature is as follows For the MD5/RSA algorithm, the signature is as follows
skipping to change at page 23, line 13 skipping to change at page 23, line 13
(The above specifications are identical to the corresponding part of (The above specifications are identical to the corresponding part of
Public Key Cryptographic Standard #1 [PKCS1].) Public Key Cryptographic Standard #1 [PKCS1].)
The size of n, including most and least significant bits (which will The size of n, including most and least significant bits (which will
be 1) MUST be not less than 512 bits and not more than 4096 bits. n be 1) MUST be not less than 512 bits and not more than 4096 bits. n
and e SHOULD be chosen such that the public exponent is small. and e SHOULD be chosen such that the public exponent is small.
Leading zero bytes are permitted in the MD5/RSA algorithm signature. Leading zero bytes are permitted in the MD5/RSA algorithm signature.
A public exponent of 3 minimizes the effort needed to decode a A public exponent of 3 minimizes the effort needed to decode a
signature. Use of 3 as the public exponent may be weak for signature. Use of 3 as the public exponent is weak for
confidentiality uses since, if the same data can be collected confidentiality uses since, if the same data can be collected
encrypted under three different keys with an exponent of 3 then, encrypted under three different keys with an exponent of 3 then,
using the Chinese Remainder Theorem [NETSEC], the original plain text using the Chinese Remainder Theorem [NETSEC], the original plain text
can be easily recovered. This weakness is not significant for DNS can be easily recovered. This weakness is not significant for DNS
security because we seek only authentication, not confidentiality. security because we seek only authentication, not confidentiality.
4.1.8.3 Transaction and Request SIGs 4.1.8.3 Transaction and Request SIGs
A response message from a security aware server may optionally A response message from a security aware server may optionally
contain a special SIG at the end of the additional information contain a special SIG at the end of the additional information
skipping to change at page 23, line 49 skipping to change at page 23, line 49
response corresponds to the intended query, and that the response response corresponds to the intended query, and that the response
comes from the queried server. comes from the queried server.
A DNS request may be optionally signed by including one or more SIGs A DNS request may be optionally signed by including one or more SIGs
at the end of the query. Such SIGs are identified by having a "type at the end of the query. Such SIGs are identified by having a "type
covered" field of zero. They sign the preceding DNS request message covered" field of zero. They sign the preceding DNS request message
including DNS header but not including the IP header or any request including DNS header but not including the IP header or any request
SIGs at the end and before the request RR counts have been adjusted SIGs at the end and before the request RR counts have been adjusted
for the inclusions of any request SIG(s). for the inclusions of any request SIG(s).
WARNING: Request SIGs are unnecessary for currently defined queries WARNING: Request SIGs are unnecessary for any currently defined
and will cause almost all existing DNS servers to completely ignore a request other than update [RFC 2136, 2137] and will cause many
query. However, such SIGs are needed to authenticate some DNS secure existing DNS servers to ignore a query. However, such SIGs may in
dynamic update requests [RFC tbd] and may in the future been needed the future been needed for other requests.
for other requests.
Except where needed to authenticate an update or similar privileged Except where needed to authenticate an update or similar privileged
request, servers are not required to check request SIGs. request, servers are not required to check request SIGs.
4.2 SIG RRs in the Construction of Responses 4.2 SIG RRs in the Construction of Responses
Security aware DNS servers SHOULD, for every authenticated RR the Security aware DNS servers SHOULD, for every authenticated RR 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 RR. The following rules apply to the
inclusion of SIG RRs in responses: inclusion of SIG RRs in responses:
skipping to change at page 26, line 8 skipping to change at page 26, line 8
authenticate RRs depending on resolver policy (see Section 6). If a authenticate RRs depending on resolver policy (see Section 6). If a
resolver does not implement transaction and/or request SIGs, it MUST resolver does not implement transaction and/or request SIGs, it MUST
ignore them without error. ignore them without error.
If all checks indicate that the SIG RR is valid then RRs verified by If all checks indicate that the SIG RR is valid then RRs verified by
it should be considered authenticated. it should be considered authenticated.
4.4 Signature Lifetime, Expiration, TTLs, and Validity 4.4 Signature Lifetime, Expiration, TTLs, and Validity
Security aware servers MUST NOT consider SIG RRs to authenticate Security aware servers MUST NOT consider SIG RRs to authenticate
anything after their expiration time and NOT consider any RR to be anything before their time signed or after their expiration time and
authenticated after all its signatures have expired. Within that NOT consider any RR to be authenticated after all its signatures have
constraint, servers should continue to follow DNS TTL aging. Thus expired. Within that constraint, servers should continue to follow
authoritative servers should continue to follow the zone refresh and DNS TTL aging. Thus authoritative servers should continue to follow
expire parameters and a non-authoritative server should count down the zone refresh and expire parameters and a non-authoritative server
the TTL and discard RRs when the TTL is zero. In addition, when RRs should count down the TTL and discard RRs when the TTL is zero. In
are transmitted in a query response, the TTL should be trimmed so addition, when RRs are transmitted in a query response, the TTL
that current time plus the TTL does not extend beyond the signature should be trimmed so that current time plus the TTL does not extend
expiration time. Thus, in general, the TTL on a transmitted RR would beyond the signature expiration time. Thus, in general, the TTL on a
be transmitted RR would be
min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
When signatures are generated, signature expiration times should be When signatures are generated, signature expiration times should be
set far enough in the future that it is quite certain that new set far enough in the future that it is quite certain that new
signatures can be generated before the old ones expire. However, signatures can be generated before the old ones expire. However,
setting expiration too far into the future could, if bad data or setting expiration too far into the future could, if bad data or
signatures were ever generated, mean a long time to flush such signatures were ever generated, mean a long time to flush such
badness. badness.
skipping to change at page 28, line 28 skipping to change at page 28, line 28
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 similar to the WKS RR socket bit map.
The first bit represents RR type zero (an illegal type which can not The first bit represents RR type zero (an illegal type which can not
be present.) A one bit indicates that at least one RR of that type be present.) A one bit indicates that at least one RR of that type
is present for the owner name. A zero indicates that no such RR is is present for the owner name. A zero indicates that no such RR is
present. All bits not specified because they are beyond the end of present. All bits not specified because they are beyond the end of
the bit map are assumed to be zero. Note that bit 30, for NXT, will the bit map are assumed to be zero. Note that bit 30, for NXT, will
always be on so the minimum bit map length is actually four octets. always be on so the minimum bit map length is actually four octets.
Trailing zero octets are prohibited in this format. This format must Trailing zero octets are prohibited in this format. This format must
be used unless there are RRs with a type number greater than 127. If be used unless there are RRs with a type number greater than 127. If
the zero bit of the type bit map is a one, it indicates that a the zero bit of the type bit map is a one, it indicates that there
exists at least on RR with a type number greater than 127 and a
different format is in use which is to be defined. different format is in use which is to be defined.
The NXT bit map should be printed as a list of RR type mnemonics or The NXT bit map should be printed as a list of RR type mnemonics or
decimal numbers similar to the WKS RR. decimal numbers similar to the WKS RR.
The domain name may be compressed with standard DNS name compression The domain name may be compressed with standard DNS name compression
when being transmitted over the network. The size of the bit map can when being transmitted over the network. The size of the bit map can
be inferred from the RDLENGTH and the length of the next domain name. be inferred from the RDLENGTH and the length of the next domain name.
5.3 Example 5.3 Additional Complexity Due to Wildcards
Proving that a non-existent name response is correct or that a
wildcard expansion response is correct makes things a little more
complex.
In particular, when a non-existent name response is returned, an NXT
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
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
the response.
Furthermore, if a wildcard expansion is returned in a response, in
general one or more NXTs needs to also be returned in the authority
section to prove that no more specific name (including possibly more
specific wildcards in the zone) existed on which the response should
have been based.
5.4 Example
Assume zone foo.nil has entries for Assume zone foo.nil has entries for
big.foo.nil, big.foo.nil,
medium.foo.nil. medium.foo.nil.
small.foo.nil. small.foo.nil.
tiny.foo.nil. tiny.foo.nil.
Then a query to a security aware server for huge.foo.nil would Then a query to a security aware server for huge.foo.nil would
produce an error reply with an RCODE of NXDOMAIN and the authority produce an error reply with an RCODE of NXDOMAIN and the authority
section data including something like the following: section data including something like the following:
big.foo.nil. NXT medium.foo.nil. A MX SIG NXT 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
19970102030405 ;signature expiration
19961211100908 ;time signed
2143 ;key identifier
foo.nil. ;signer
AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
)
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 ;time signed
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.
5.4 Special Considerations at Delegation Points 5.5 Special Considerations at Delegation Points
A name (other than root) which is the head of a zone also appears as A name (other than root) which is the head of a zone also appears as
the leaf in a superzone. If both are secure, there will always be the leaf in a superzone. If both are secure, there will always be
two different NXT RRs with the same name. They can be distinguished two different NXT RRs with the same name. They can be distinguished
by their signers and next domain name fields. Security aware servers by their signers and next domain name fields. Security aware servers
should return the correct NXT automatically when required to should return the correct NXT automatically when required to
authenticate the non-existence of a name and both NXTs, if available, authenticate the non-existence of a name and both NXTs, if available,
on explicit query for type NXT. on explicit query for type NXT.
Non-security aware servers will never automatically return an NXT and Non-security aware servers will never automatically return an NXT and
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.5 Zone Transfers 5.6 Zone Transfers
The sections below describe how full and incremental zone transfers The sections below describe how full and incremental zone transfers
are secured. 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 elements 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 could delegation point NS or glue A or AAAA RRs a subset of these RRs could
be sent as long as at least one of each type is included. be sent as long as at least one of each type is included.
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 all full zone
transfers. This provides strong protection for the entire zone in transfers. This provides strong server based protection for the
transit. entire zone in transit.
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(s) verifying that SOA RR. current version and the SIG(s) verifying that SOA RR.
5.5.1 Incremental Zone Transfers 5.6.1 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 NXT chain.
As a result, a server which securely supports IXFR must handle IXFR As a result, a server which securely supports IXFR must handle IXFR
SIG RRs for each incremental transfer set that it maintains. 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. It is recommended then deleted RRs, then new SOA and added RRs. Within each section,
that, within each section, RRs be ordered as specified in Section 8. RRs must be ordered as specified in Section 8. If condensation of
If condensation of adjacent incremental update sets is done by the adjacent incremental update sets is done by the zone owner, the
zone owner, the original IXFR SIG for each set included in the original IXFR SIG for each set included in the condensation must be
condensation must be discarded and a new on IXFR SIG calculated to discarded and a new on IXFR SIG calculated to cover the resulting
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. verification of the internal SIGs.
6. How to Resolve Securely and the AD and CD Bits 6. How to Resolve Securely and the AD and CD Bits
skipping to change at page 32, line 25 skipping to change at page 33, line 25
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | | NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These bits are zero in old servers and resolvers. Thus the responses These bits are zero in old servers and resolvers. Thus the responses
of old servers are not flagged as authenticated to security aware of old servers are not flagged as authenticated to security aware
resolvers and queries from non-security aware resolvers do not assert resolvers and queries from non-security aware resolvers do not assert
the checking disabled bit and thus will be answered by security aware the checking disabled bit and thus will be answered by security aware
servers only with Authenticated or Insecure data. Aware resolvers servers only with Authenticated or Insecure data. Security aware
MUST NOT trust the AD bit unless they trust the server they are resolvers MUST NOT trust the AD bit unless they trust the server they
talking to and either have a secure path to it or use DNS transaction are talking to and either have a secure path to it or use DNS
security. transaction security.
Any security aware resolver willing to do cryptography SHOULD assert Any security aware resolver willing to do cryptography SHOULD assert
the CD bit on all queries to permit it to impose its own policies and the CD bit on all queries to permit it to impose its own policies and
to reduce DNS latency time by allowing security aware servers to to reduce DNS latency time by allowing security aware servers to
answer with Pending data. answer with Pending data.
Security aware servers NEVER return Bad data. For non-security aware Security aware servers NEVER return Bad data. For non-security aware
resolvers or security aware resolvers requesting service by having resolvers or security aware resolvers requesting service by having
the CD bit clear, security aware servers MUST return only the CD bit clear, security aware servers MUST return only
Authenticated or Insecure data with the AD bit set in the response. Authenticated or Insecure data with the AD bit set in the response.
skipping to change at page 33, line 35 skipping to change at page 34, line 35
KEY RR with non-null key information appearing with the NS RRs for 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 the sub-zone. These make it possible to descend within the tree of
zones. zones.
6.3.1 Chaining Through KEYs 6.3.1 Chaining Through KEYs
In general, some RRset in the secure DNS will be signed by one or In general, some RRset in the secure DNS will be signed by one or
more SIG RRs. Each of these SIG RRs has a signer under whose name is more SIG RRs. Each of these SIG RRs has a signer under whose name is
stored the public KEY to use in verifying the SIG. Each of those stored the public KEY to use in verifying the SIG. Each of those
KEYs will, generally, also be signed with a SIG. And those SIGs will KEYs will, generally, also be signed with a SIG. And those SIGs will
also refer to KEYs. And so on. As a result, verifying leads to have signer names also refering to KEYs. And so on. As a result,
chains of alternating SIG and KEY RRs with the first SIG signing the verifying leads to chains of alternating SIG and KEY RRs with the
original data whose validity is to be shown and the final KEY being first SIG signing the original data whose validity is to be shown and
some key staticly configured at the resolver performing the the final KEY being some key staticly configured at the resolver
verification. performing the verification.
In testing such a chain, the validation of a SIG over some data with In testing such a chain, the validation of a SIG over some data with
reference to a KEY is an objective cryptographic test; however, the reference to a KEY is an objective cryptographic test; however, the
judgement that a SIG with a particular signer name can authenticate judgement that a SIG with a particular signer name can authenticate
data (possibly a KEY RRset) with a particular owner name is a policy data (possibly a KEY RRset) with a particular owner name is a policy
question. Ultimately, this is a policy local to the resolver and any question. Ultimately, this is a policy local to the resolver and any
clients that depend on that resolver's decisions. It is, however, clients that depend on that resolver's decisions. It is, however,
strongly recommended, that the following policy be adopted: strongly recommended, that the following policy be 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. Let A dropping one or more whole labels from the left end of B. Let A
= B mean that A and B are the same domain name (i.e., are = B mean that A and B are the same domain name (i.e., are
identical after letter case canonicalization). Let A > B mean identical after letter case canonicalization). Let A > B mean
that A is a longer domain name than B formed by adding one or that A is a longer domain name than B formed by adding one or
more whole labels on the left end of B. more whole labels on the left end of B.
Let K 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 SG is a valid signer name for a SIG authenticating data Then Sign is a valid signer name for a SIG authenticating data
(possibly a KEY RRset) with owner name OW at a resolver if any (possibly a KEY RRset) with owner name Own at a resolver if any
of the following three rules apply: of the following three rules apply:
(1) OW > SG except that if SG is root (.), OW must be a top (1) Own > Sign except that if Sign is root (.), Own must be a
level domain name. top level domain name.
(2) ( OW < or = SG ) and ( SG > some K ). (2) ( Own < or = Sign ) and ( Sign > some Static ).
(3) SG = some K. (3) Sign = some Static.
Rule 1 is the rule for descending the DNS tree and includes a special Rule 1 is the rule for descending the DNS tree and includes a special
prohibition on the root zone key due to the restriction that the root prohibition on the root zone key due to the restriction that the root
zone be only one label deep. zone be only one label deep.
Rule 2 is the rule for ascending the DNS tree from one or more Rule 2 is the rule for ascending the DNS tree from one or more
staticly configured keys. Rule 2 has no effect if only root keys are staticly configured keys. Rule 2 has no effect if only root keys are
staticly configured. staticly configured.
Rule 3 is a rule permitting direct cross certification. Rule 3 is a rule permitting direct cross certification.
skipping to change at page 36, line 40 skipping to change at page 37, line 40
1 NOCONF confidentiality use prohibited 1 NOCONF confidentiality use prohibited
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
6-7 name type 6-7 name type
USER =0 USER =0
ZONE =1 ZONE =1
HOST =2 (host or other end entity) HOST =2 (host or other end entity)
NTYP3 - reserved NTYP3 - reserved
8 OAKLEY key usable for Oakley/IPSEC 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
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 002 EMAIL 001 TLS
002 EMAIL
003 DNSSEC
004 IPSEC
Note that if the type field has the "no key" value (ie, both NOAUTH Note that if the type field has the "no key" value (ie, both NOAUTH
and NOCONF are on), nothing appears after the algorithm octet. and NOCONF are on), nothing appears after the algorithm octet.
The remaining public key portion is represented in base 64 (see The remaining public key portion is represented in base 64 (see
Appendix A) and may be divided up into any number of white space Appendix A) and may be divided up into any number of white space
separated substrings, down to single base 64 digits, which are separated substrings, down to single base 64 digits, which are
concatenated to obtain the full signature. These substrings can span concatenated to obtain the full signature. These substrings can span
lines using the standard parenthesis. lines using the standard parenthesis.
Note that the public key may have internal sub-fields but these do Note that the public key may have internal sub-fields but these do
skipping to change at page 41, line 7 skipping to change at page 42, line 7
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, (2) maintains appropriate
information in its local caches and database to indicate which RRs information in its local caches and database to indicate which RRs
have been authenticated and to what extent they have been have been authenticated and to what extent they have been
authenticated, (3) performs additional queries as necessary to authenticated, (3) performs additional queries as necessary to
attempt to obtain KEY, SIG, or NXT RRs from non-security aware attempt to obtain KEY, SIG, or NXT RRs from non-security aware
servers, (4) normally sets the CD query header bit on its queries. servers, (4) normally sets the CD query header bit on its queries.
10. Security Considerations 10. Security Considerations
This document describes 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
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
skipping to change at page 44, line 12 skipping to change at page 45, line 12
draft-ietf-tls-*.txt draft-ietf-tls-*.txt
Author's Addresses Author's Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
CyberCash, Inc. CyberCash, Inc.
318 Acton Street 318 Acton Street
Carlisle, MA 01741 USA Carlisle, MA 01741 USA
Telephone: +1 508-287-4877 Telephone: +1 978-287-4877
+1 508-371-7148(fax) +1 978-371-7148(fax)
+1 703-620-4200(main office, Reston, Virginia, USA) +1 703-620-4200(main office, Reston, Virginia, USA)
EMail: dee@cybercash.com EMail: dee@cybercash.com
Expiration and File Name Expiration and File Name
This draft expires 19 February 1998. This draft expires 20 May 1998.
Its file name is draft-ietf-dnssec-secext2-01.txt. Its file name is draft-ietf-dnssec-secext2-02.txt.
Appendix A: Base 64 Encoding Appendix A: Base 64 Encoding
The following encoding technique is taken from RFC 1521 by N. The following encoding technique is taken from RFC 1521 by N.
Borenstein and N. Freed. It is reproduced here in an edited form for Borenstein and N. Freed. It is reproduced here in an edited form for
convenience. convenience.
A 65-character subset of US-ASCII is used, enabling 6 bits to be A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=", represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.) is used to signify a special processing function.)
skipping to change at page 47, line 11 skipping to change at page 48, line 11
padding characters, or (3) the final quantum of encoding input is padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character. characters followed by one "=" padding character.
Appendix B: Changes from RFC 2065 Appendix B: Changes from RFC 2065
This section summarizes the most important changes that have been This section summarizes the most important changes that have been
made since RFC 2065. made since RFC 2065.
1. Most of Section 7 of RFC 2065 called "Operational Considerations", 1. Most of Section 7 of RFC 2065 called "Operational Considerations",
has been split off into a separate document. has been removed and may be made into a separate document.
2. The KEY RR has been changed by (2a) eliminating the "experimental" 2. The KEY RR has been changed by (2a) eliminating the "experimental"
flag as unnecessary, (2b) reserving a flag bit for flags flag as unnecessary, (2b) reserving a flag bit for flags
expansion, (2c) more compactly encoding a number of bit fields in expansion, (2c) more compactly encoding a number of bit fields in
such a way as to leave unchanged bits actually used by the limited such a way as to leave unchanged bits actually used by the limited
code currently deployed, and (2d) for the RSA MD5 algorithm code currently deployed, (2d) eliminating the IPSEC and email flag
increasing the maximum required key modulus size implementation to bits which are replaced by reserved values of the protocol field,
4096 bits. Section 3.4 describing the meaning of various and (2e) for the RSA MD5 algorithm increasing the maximum required
combinations of "no-key" and key present KEY RRs has been added. key modulus size implementation to 4096 bits. Section 3.4
describing the meaning of various combinations of "no-key" and key
present KEY RRs has been added.
3. The SIG RR has been changed by (3a) clarifying that signature 3. The SIG RR has been changed by (3a) clarifying that signature
expiration and date signed used serial number ring arithmetic, and expiration and date signed used serial number ring arithmetic, and
(3b) changing the definition of the key footprint/tag for (3b) changing the definition of the key footprint/tag for
algorithms other than 1 (i.e., algorithms to be defined in the algorithms other than 1 (i.e., algorithms to be defined in the
future) and adding Appendix C to document its calculation. In future) and adding Appendix C to document its calculation. In
addition, the SIG covering type AXFR has been eliminated. addition, the SIG covering type AXFR has been eliminated.
5. Both the KEY and SIG RR definitions have been simplified by 5. Both the KEY and SIG RR definitions have been simplified by
eliminating the "null" algorithm 253 as defined in RFC 2065. That eliminating the "null" algorithm 253 as defined in RFC 2065. That
algorithm had been included because at the time it was thought it algorithm had been included because at the time it was thought it
might be useful in DNS dynamic update [RFC 2136]. It was in fact might be useful in DNS dynamic update [RFC 2136]. It was in fact
not so used and it is dropped to simplify DNS security. not so used and it is dropped to simplify DNS security.
6. The NXT RR has been changed so that (6a) the NXT RRs in a zone 6. The NXT RR has been changed so that (6a) 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 and (6b) all NXT bit map areas whose first octet has bit expansion, (6b) all NXT bit map areas whose first octet has bit
zero set have been reserved for future definition, and (6c) zero set have been reserved for future definition, (6c) extending
additional minor changes made to assure a unique encoding of RR the number of and circumsatnces under which an NXT must be
type combinations currently existing int he DNS. returned in connection with wildcard names, and (6d) additional
minor changes made to assure a unique encoding of RR type
combinations currently existing int he DNS.
7. Information on the canonical form and ordering of RRs has been 7. Information on the canonical form and ordering of RRs has been
moved into a separate section, number 8. moved into a separate section, number 8.
8. A subsection covering incremental and full zone transfer has been 8. A subsection covering incremental and full zone transfer has been
added in Section 5. added in Section 5.
9. Further specification and policy recommendations on secure 9. Further specification and policy recommendations on secure
resolution have been added, primarily in section 6.3.1. resolution have been added, primarily in section 6.3.1.
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 in verifying the signature when selecting the correct KEY RR to use in verifying the signature when
there is more than one KEY RR candidate. It is possible for more there is more than one KEY RR candidate. It is possible for more
than one candidate key to have the same tag, in which case each must than one candidate key to have the same tag, in which case each must
be tried in verifying the signature until one works or all fail. The be tried in verifying the signature until one works or all fail. The
following reference implementation is in ANSI C. following reference implementation is in ANSI C. It is not coded for
efficiency.
void keytag ( /* assumes int is at least 16 bits
first byte of tag is most significant byte of return value
second byte of tag is least significatn byte of return value */
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 */
unsigned char tag[2] /* return calculated tag */
) )
{ {
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) & 0xFF; ac += (ac>>16) & 0xFFFF;
tag[0] = ac>>8; return ac & 0xFFFF;
tag[1] = ac;
} }
 End of changes. 79 change blocks. 
178 lines changed or deleted 235 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/