draft-ietf-dnsop-algorithm-update-06.txt   draft-ietf-dnsop-algorithm-update-07.txt 
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Obsoletes: 6944 (if approved) O. Sury Obsoletes: 6944 (if approved) O. Sury
Intended status: Standards Track Internet Systems Consortium Intended status: Standards Track Internet Systems Consortium
Expires: August 21, 2019 February 17, 2019 Expires: September 13, 2019 March 12, 2019
Algorithm Implementation Requirements and Usage Guidance for DNSSEC Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-06 draft-ietf-dnsop-algorithm-update-07
Abstract Abstract
The DNSSEC protocol makes use of various cryptographic algorithms in The DNSSEC protocol makes use of various cryptographic algorithms in
order to provide authentication of DNS data and proof of non- order to provide authentication of DNS data and proof of non-
existence. To ensure interoperability between DNS resolvers and DNS existence. To ensure interoperability between DNS resolvers and DNS
authoritative servers, it is necessary to specify a set of algorithm authoritative servers, it is necessary to specify a set of algorithm
implementation requirements and usage guidelines to ensure that there implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This is at least one algorithm that all implementations support. This
document defines the current algorithm implementation requirements document defines the current algorithm implementation requirements
and usage guidance for DNSSEC. This document obsoletes [RFC6944]. and usage guidance for DNSSEC. This document obsoletes [RFC6944].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2019. This Internet-Draft will expire on September 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4
3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4 3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4
3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6 3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6 3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6
3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7 3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 7 4.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 7
6. Implementation Report . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8 6. Operational Considerations . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The DNSSEC signing algorithms are defined by various RFCs, including The DNSSEC signing algorithms are defined by various RFCs, including
[RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080]. [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080].
DNSSEC is used to provide authentication of data. To ensure DNSSEC is used to provide authentication of data. To ensure
skipping to change at page 7, line 14 skipping to change at page 7, line 14
DNSSEC use case requiring 384-bit security strength to arise, SHA-384 DNSSEC use case requiring 384-bit security strength to arise, SHA-384
is provided for such applications and it MAY be used for generating is provided for such applications and it MAY be used for generating
DS and CDS records in these cases. DS and CDS records in these cases.
3.4. DS and CDS Algorithm Recommendation 3.4. DS and CDS Algorithm Recommendation
Operation recommendation for new and existing deployments. Operation recommendation for new and existing deployments.
The SHA-256 is RECOMMENDED DS and CDS algorithm. The SHA-256 is RECOMMENDED DS and CDS algorithm.
4. Security Considerations 4. Implementation Status
[RFC Editor Note: Please remove this entire seciton plus all
references to [RFC7942] prior to publication as an RFC.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
4.1. DNSKEY Algorithms
The following table contains the status of support in the open-source
DNS signers and validators in the current released versions as of the
time writing this document. Usually, the support for specific
algorithm has to be also included in the cryptographic libraries that
the software use.
+--------------------+------+--------+---------+----------+---------+
| Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound |
| | | DNS | | | |
+--------------------+------+--------+---------+----------+---------+
| RSAMD5 | Y | N | Y | N | N |
| DSA | Y | N | Y | N | Y |
| RSASHA1 | Y | Y | Y | Y | Y |
| DSA-NSEC3-SHA1 | Y | N | Y | N | Y |
| RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y |
| RSASHA256 | Y | Y | Y | Y | Y |
| RSASHA512 | Y | Y | Y | Y | Y |
| ECC-GOST | N | N | Y | N | Y |
| ECDSAP256SHA256 | Y | Y | Y | Y | Y |
| ECDSAP384SHA384 | Y | Y | Y | Y | Y |
| ED25519 | Y | Y | N | Y | Y |
| ED448 | N | N | N | Y | Y |
+--------------------+------+--------+---------+----------+---------+
5. Security Considerations
The security of cryptographic systems depends on both the strength of The security of cryptographic systems depends on both the strength of
the cryptographic algorithms chosen and the strength of the keys used the cryptographic algorithms chosen and the strength of the keys used
with those algorithms. The security also depends on the engineering with those algorithms. The security also depends on the engineering
of the protocol used by the system to ensure that there are no non- of the protocol used by the system to ensure that there are no non-
cryptographic ways to bypass the security of the overall system. cryptographic ways to bypass the security of the overall system.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for the use of DNSSEC, specifically with the selection of algorithms for the use of DNSSEC, specifically with the selection of
"mandatory-to-implement" algorithms. The algorithms identified in "mandatory-to-implement" algorithms. The algorithms identified in
skipping to change at page 7, line 37 skipping to change at page 8, line 46
us to believe that they are likely to remain secure into the us to believe that they are likely to remain secure into the
foreseeable future. However, this isn't necessarily forever, and it foreseeable future. However, this isn't necessarily forever, and it
is expected that new revisions of this document will be issued from is expected that new revisions of this document will be issued from
time to time to reflect the current best practices in this area. time to time to reflect the current best practices in this area.
Retiring an algorithm too soon would result in a zone signed with the Retiring an algorithm too soon would result in a zone signed with the
retired algorithm being downgraded to the equivalent of an unsigned retired algorithm being downgraded to the equivalent of an unsigned
zone. Therefore, algorithm deprecation must be done very slowly and zone. Therefore, algorithm deprecation must be done very slowly and
only after careful consideration and measurement of its use. only after careful consideration and measurement of its use.
5. Operational Considerations 6. Operational Considerations
DNSKEY algorithm rollover in a live zone is a complex process. See DNSKEY algorithm rollover in a live zone is a complex process. See
[RFC6781] and [RFC7583] for guidelines on how to perform algorithm [RFC6781] and [RFC7583] for guidelines on how to perform algorithm
rollovers. rollovers.
DS algorithm rollover in a live zone is also a complex process. DS algorithm rollover in a live zone is also a complex process.
Upgrading algorithm at the same time as rolling the new KSK key will Upgrading algorithm at the same time as rolling the new KSK key will
lead to DNSSEC validation failures, and users MUST upgrade the DS lead to DNSSEC validation failures, and users MUST upgrade the DS
algorithm first before rolling the Key Signing Key. algorithm first before rolling the Key Signing Key.
6. Implementation Report
6.1. DNSKEY Algorithms
The following table contains the status of support in the open-source
DNS signers and validators in the current released versions as of the
time writing this document. Usually, the support for specific
algorithm has to be also included in the cryptographic libraries that
the software use.
+--------------------+------+--------+---------+----------+---------+
| Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound |
| | | DNS | | | |
+--------------------+------+--------+---------+----------+---------+
| RSAMD5 | Y | N | Y | N | N |
| DSA | Y | N | Y | N | Y |
| RSASHA1 | Y | Y | Y | Y | Y |
| DSA-NSEC3-SHA1 | Y | N | Y | N | Y |
| RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y |
| RSASHA256 | Y | Y | Y | Y | Y |
| RSASHA512 | Y | Y | Y | Y | Y |
| ECC-GOST | N | N | Y | Y | Y |
| ECDSAP256SHA256 | Y | Y | Y | Y | Y |
| ECDSAP384SHA384 | Y | Y | Y | Y | Y |
| ED25519 | Y | Y | N | Y | Y |
| ED448 | N | N | N | Y | Y |
+--------------------+------+--------+---------+----------+---------+
7. IANA Considerations 7. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
8. Acknowledgements 8. Acknowledgements
This document borrows text from RFC 4307 by Jeffrey I. Schiller of This document borrows text from RFC 4307 by Jeffrey I. Schiller of
the Massachusetts Institute of Technology (MIT) and the 4307bis the Massachusetts Institute of Technology (MIT) and the 4307bis
document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault. document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault.
Much of the original text has been copied verbatim. Much of the original text has been copied verbatim.
skipping to change at page 9, line 11 skipping to change at page 9, line 33
Kudos to Roy Arends for bringing the DS rollover issue to the Kudos to Roy Arends for bringing the DS rollover issue to the
daylight. daylight.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702, and RRSIG Resource Records for DNSSEC", RFC 5702,
DOI 10.17487/RFC5702, October 2009, DOI 10.17487/RFC5702, October 2009, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5702>. editor.org/info/rfc5702>.
[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of
GOST Signature Algorithms in DNSKEY and RRSIG Resource GOST Signature Algorithms in DNSKEY and RRSIG Resource
Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July
2010, <https://www.rfc-editor.org/info/rfc5933>. 2010, <https://www.rfc-editor.org/info/rfc5933>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605, Signature Algorithm (DSA) for DNSSEC", RFC 6605,
DOI 10.17487/RFC6605, April 2012, DOI 10.17487/RFC6605, April 2012, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6605>. editor.org/info/rfc6605>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6781>. editor.org/info/rfc6781>.
[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)
DNSKEY Algorithm Implementation Status", RFC 6944, DNSKEY Algorithm Implementation Status", RFC 6944,
DOI 10.17487/RFC6944, April 2013, DOI 10.17487/RFC6944, April 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6944>. editor.org/info/rfc6944>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
Hash Function", RFC 6986, DOI 10.17487/RFC6986, August Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
2013, <https://www.rfc-editor.org/info/rfc6986>. 2013, <https://www.rfc-editor.org/info/rfc6986>.
[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:
Digital Signature Algorithm", RFC 7091, Digital Signature Algorithm", RFC 7091,
DOI 10.17487/RFC7091, December 2013, DOI 10.17487/RFC7091, December 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7091>. editor.org/info/rfc7091>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7344>. editor.org/info/rfc7344>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583, "DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015, DOI 10.17487/RFC7583, October 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7583>. editor.org/info/rfc7583>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8032>. editor.org/info/rfc8032>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078, the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017, DOI 10.17487/RFC8078, March 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8078>. editor.org/info/rfc8078>.
[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
Algorithm (EdDSA) for DNSSEC", RFC 8080, Algorithm (EdDSA) for DNSSEC", RFC 8080,
DOI 10.17487/RFC8080, February 2017, DOI 10.17487/RFC8080, February 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8080>. editor.org/info/rfc8080>.
[DNSKEY-IANA] [DNSKEY-IANA]
"DNSKEY Algorithms", <http://www.iana.org/assignments/ "DNSKEY Algorithms", <http://www.iana.org/assignments/
dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>. dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>.
[DS-IANA] "Delegation Signer Digest Algorithms", [DS-IANA] "Delegation Signer Digest Algorithms",
<http://www.iana.org/assignments/ds-rr-types/ <http://www.iana.org/assignments/ds-rr-types/
ds-rr-types.xhtml>. ds-rr-types.xhtml>.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
63 lines changed or deleted 91 lines changed or added

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