Technical Summary
The DNS Security Extensions (DNSSEC) were developed to provide
origin authentication and integrity protection for DNS data by using
digital signatures. These digital signatures can be generated using
different algorithms. This draft sets out to specify a way for
validating end-system resolvers to signal to a server which digital
signature and hash algorithms they support.
Working Group Summary
The DNSEXT WG members reviewed and commented on previous revisions
of the document. All substantive comments were reviewed and the
document updated accordingly. Most reviewers feel that the proposed
extensions would be harmless to the protocol and would be useful for
measuring cryptographic algorithm implementation uptake in
clients. A minority of the reviewers questioned the need for such
signalling. No reviewers flagged the existence of the proposed EDNS0
extension create interoperability or deployment problems.
Document Quality
The document does not change any protocol or change client or server
processing in any significant way, but proposes a new option to
EDNS(0) to aid authoritative DNS zone administrators to measure
cryptograpic algorithm code in clients.
Personnel
Patrik Fältström is the Document Shepherd, and Ted Lemon is the
Responsible Area Director.
RFC Editor Note
Please make the following changes, to which the authors have agreed:
Section 1 Introduction
OLD:
Each digital signature RR (RRSIG) contains an algorithm code number.
NEW:
Each digital signature (RRSIG) RR contains an algorithm code number that corresponds to a DNSSEC public key (DNSKEY RR).
OLD:
Likewise, Delegation Signer (DS) RRs and NSEC3 RRs use a hashed value as part of their RDATA
NEW:
Likewise, Delegation Signer (DS) RRs and Hashed Authenticated Denial of Existence (NSEC3) RRs use a hashed value as part of their RDATA
OLD:
These proposed EDNS options serve to measure the acceptance and use of new digital signing algorithms.
NEW:
These proposed EDNS0 options serve to measure the acceptance and use of new digital signing algorithms.
Section 2 Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood
(DHU) and NSEC3 Hash Understood (N3U) Using EDNS
OLD:
These options are contained in the RDATA of the OPT meta-RR. This document defines three new EDNS options for a client to signal which digital signature and/or hash algorithms the client supports.
NEW:
These options are contained in the resource record data (RDATA) of the OPT meta-RR. This document defines three new EDNS0 options for a client to signal which digital signature and/or hash algorithms the client supports.
Section 3.1.1
OLD:
A validating stub resolver already (usually) sets the DO bit
[RFC4035] to indicate that it wishes to receive additional DNSSEC RRs
(i.e. RRSIG RRs) in the response. Such validating resolvers SHOULD
include the DAU, DHU and/or the N3U option(s) in the OPT RR when
sending a query.
NEW:
A validating stub resolver sets the DO bit
[RFC4035] to indicate that it wishes to receive additional DNSSEC RRs
(i.e. RRSIG RRs) in the response. Such validating resolvers SHOULD
include the DAU, DHU and/or the N3U option(s) in the OPT RR when
sending a query.
Section 3.2.1
OLD:
If the client did include the DO and CD bits, but did not include the DAU, DHU and/or N3U option(s) in the query,
NEW:
If the client did include the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU and/or N3U option(s) in the query,
In Section 4:
OLD
Intermediate proxies [RFC5625] that understand DNS are
RECOMMENDED to
NEW:
Intermediate proxies [RFC5625-442] that understand DNS are
RECOMMENDED to
Section 5
OLD:
If the options are present but the DNSSEC-OK (OK) bit is not set,
NEW:
If the options are present but the DNSSEC-OK (DO) bit is not set,
In Section 9:
OLD:
[RFC5625] Bellis, R., "DNS Proxy
Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
NEW:
[RFC5625-442] Bellis, R., "DNS Proxy
Implementation Guidelines",
BCP 152, RFC 5625 section 4.4.2, August 2009.