draft-ietf-dprive-dns-over-tls-00.txt | draft-ietf-dprive-dns-over-tls-01.txt | |||
---|---|---|---|---|
Network Working Group Z. Hu | Network Working Group Z. Hu | |||
Internet-Draft L. Zhu | Internet-Draft L. Zhu | |||
Intended status: Standards Track J. Heidemann | Intended status: Standards Track J. Heidemann | |||
Expires: March 21, 2016 USC/Information Sciences | Expires: April 13, 2016 USC/Information Sciences | |||
Institute | Institute | |||
A. Mankin | A. Mankin | |||
D. Wessels | D. Wessels | |||
Verisign Labs | Verisign Labs | |||
P. Hoffman | P. Hoffman | |||
ICANN | ICANN | |||
September 18, 2015 | October 11, 2015 | |||
DNS over TLS: Initiation and Performance Considerations | DNS over TLS: Initiation and Performance Considerations | |||
draft-ietf-dprive-dns-over-tls-00 | draft-ietf-dprive-dns-over-tls-01 | |||
Abstract | Abstract | |||
This document describes the use of TLS to provide privacy for DNS. | This document describes the use of TLS to provide privacy for DNS. | |||
Encryption provided by TLS eliminates opportunities for eavesdropping | Encryption provided by TLS eliminates opportunities for eavesdropping | |||
on DNS queries in the network, such as discussed in RFC 7258. In | and on-path tampering with DNS queries in the network, such as | |||
addition, this document specifies two usage profiles for DNS-over-TLS | discussed in RFC 7258. In addition, this document specifies two | |||
and provides advice on performance considerations to minimize | usage profiles for DNS-over-TLS and provides advice on performance | |||
overhead from using TCP and TLS with DNS. | considerations to minimize overhead from using TCP and TLS with DNS. | |||
Note: this document was formerly named | Note: this document was formerly named | |||
draft-ietf-dprive-start-tls-for-dns. Its name has been changed to | draft-ietf-dprive-start-tls-for-dns. Its name has been changed to | |||
better describe the mechanism now used. Please refer to working | better describe the mechanism now used. Please refer to working | |||
group archives under the former name for history and previous | group archives under the former name for history and previous | |||
discussion. [RFC Editor: please remove this paragraph prior to | discussion. [RFC Editor: please remove this paragraph prior to | |||
publication] | publication] | |||
Status of this Memo | Status of this Memo | |||
skipping to change at page 1, line 49 | skipping to change at page 1, line 49 | |||
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 http://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 March 21, 2016. | This Internet-Draft will expire on April 13, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | |||
(http://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 | |||
skipping to change at page 2, line 37 | skipping to change at page 2, line 37 | |||
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 | 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 | |||
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 | 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 | |||
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 | 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 | |||
4.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 7 | 4.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 7 | |||
5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 | 5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 | 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 | |||
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 | 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
Today, nearly all DNS queries [RFC1034], [RFC1035] are sent | Today, nearly all DNS queries [RFC1034], [RFC1035] are sent | |||
unencrypted, which makes them vulnerable to eavesdropping by an | unencrypted, which makes them vulnerable to eavesdropping by an | |||
attacker that has access to the network channel, reducing the privacy | attacker that has access to the network channel, reducing the privacy | |||
of the querier. Recent news reports have elevated these concerns, | of the querier. Recent news reports have elevated these concerns, | |||
and recent IETF work has specified privacy considerations for DNS | and recent IETF work has specified privacy considerations for DNS | |||
[RFC7626]. | [RFC7626]. | |||
skipping to change at page 4, line 24 | skipping to change at page 4, line 24 | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
3. Establishing and Managing DNS-over-TLS Sessions | 3. Establishing and Managing DNS-over-TLS Sessions | |||
3.1. Session Initiation | 3.1. Session Initiation | |||
A DNS server that supports DNS-over-TLS SHOULD listen for and accept | A DNS server that supports DNS-over-TLS SHOULD listen for and accept | |||
TCP connections on a designated port TBD identified in Section 6. | TCP connections on port 853. | |||
DNS clients desiring privacy from DNS-over-TLS from a particular | DNS clients desiring privacy from DNS-over-TLS from a particular | |||
server SHOULD establish a TCP connection to port TBD on the server. | server SHOULD establish a TCP connection to port 853 on the server. | |||
Upon successful establishment of the TCP connection, client and | Upon successful establishment of the TCP connection, client and | |||
server SHOULD immediately initiate a TLS handshake using the | server SHOULD immediately initiate a TLS handshake using the | |||
procedure described in [RFC5246]. | procedure described in [RFC5246]. | |||
DNS clients SHOULD remember server IP addresses that don't support | DNS clients SHOULD remember server IP addresses that don't support | |||
DNS-over-TLS, including timeouts, connection refusals, and TLS | DNS-over-TLS, including timeouts, connection refusals, and TLS | |||
handshake failures, and not request DNS-over-TLS from them for a | handshake failures, and not request DNS-over-TLS from them for a | |||
reasonable period (such as one hour per server). DNS clients | reasonable period (such as one hour per server). DNS clients | |||
following a pre-deployed privacy profile MAY be more aggressive about | following a pre-deployed privacy profile MAY be more aggressive about | |||
retrying DNS-over-TLS connection failures. | retrying DNS-over-TLS connection failures. | |||
skipping to change at page 5, line 20 | skipping to change at page 5, line 20 | |||
After TLS negotiation completes, the connection will be encrypted and | After TLS negotiation completes, the connection will be encrypted and | |||
is now protected from eavesdropping. At this point, normal DNS | is now protected from eavesdropping. At this point, normal DNS | |||
queries SHOULD take place. | queries SHOULD take place. | |||
3.3. Transmitting and Receiving Messages | 3.3. Transmitting and Receiving Messages | |||
All messages (requests and responses) in the established TLS session | All messages (requests and responses) in the established TLS session | |||
MUST use the two-octet length field described in Section 4.2.2 of | MUST use the two-octet length field described in Section 4.2.2 of | |||
[RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD | [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD | |||
transmit the two-octet length field, and the message described by | transmit the two-octet length field, and the message described by | |||
that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis], | that length field, to the TCP layer at the same time (e.g., in a | |||
Section 8). | single "write" system call) to make it more likely that all the data | |||
will be transmitted in a single TCP segment | ||||
([I-D.ietf-dnsop-5966bis], Section 8). | ||||
In order to minimize latency, clients SHOULD pipeline multiple | In order to minimize latency, clients SHOULD pipeline multiple | |||
queries over a TLS session. When a DNS client sends multiple queries | queries over a TLS session. When a DNS client sends multiple queries | |||
to a server, it should not wait for an outstanding reply before | to a server, it should not wait for an outstanding reply before | |||
sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). | sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). | |||
Since pipelined responses can arrive out-of-order, clients MUST match | Since pipelined responses can arrive out-of-order, clients MUST match | |||
responses to outstanding queries using the ID field and port number. | responses to outstanding queries using the ID field, query name, | |||
Failure by clients to properly match responses to outstanding queries | type, and class. Failure by clients to properly match responses to | |||
can have serious consequences for interoperability | outstanding queries can have serious consequences for | |||
([I-D.ietf-dnsop-5966bis], Section 7). | interoperability ([I-D.ietf-dnsop-5966bis], Section 7). | |||
3.4. Connection Reuse, Close and Reestablishment | 3.4. Connection Reuse, Close and Reestablishment | |||
For DNS clients that use library functions such as "gethostbyname()", | For DNS clients that use library functions such as "getaddrinfo()" | |||
current implementations are known to open and close TCP connections | and "gethostbyname()", current implementations are known to open and | |||
each DNS call. To avoid excess TCP connections, each with a single | close TCP connections each DNS call. To avoid excess TCP | |||
query, clients SHOULD reuse a single TCP connection to the recursive | connections, each with a single query, clients SHOULD reuse a single | |||
resolver. Alternatively they may prefer to use UDP to a DNS-over-TLS | TCP connection to the recursive resolver. Alternatively they may | |||
enabled caching resolver on the same machine that then uses a system- | prefer to use UDP to a DNS-over-TLS enabled caching resolver on the | |||
wide TCP connection to the recursive resolver. | same machine that then uses a system-wide TCP connection to the | |||
recursive resolver. | ||||
In order to amortize TCP and TLS connection setup costs, clients and | In order to amortize TCP and TLS connection setup costs, clients and | |||
servers SHOULD NOT immediately close a connection after each | servers SHOULD NOT immediately close a connection after each | |||
response. Instead, clients and servers SHOULD reuse existing | response. Instead, clients and servers SHOULD reuse existing | |||
connections for subsequent queries as long as they have sufficient | connections for subsequent queries as long as they have sufficient | |||
resources. In some cases, this means that clients and servers may | resources. In some cases, this means that clients and servers may | |||
need to keep idle connections open for some amount of time. | need to keep idle connections open for some amount of time. | |||
Proper management of established and idle connections is important to | Proper management of established and idle connections is important to | |||
the healthy operation of a DNS server. An implementor of DNS-over- | the healthy operation of a DNS server. An implementor of DNS-over- | |||
skipping to change at page 7, line 50 | skipping to change at page 7, line 50 | |||
configuring a network. For example, for clients on networks that | configuring a network. For example, for clients on networks that | |||
require authentication through web-based login, such authentication | require authentication through web-based login, such authentication | |||
may rely on DNS interception and spoofing. Techniques such as those | may rely on DNS interception and spoofing. Techniques such as those | |||
used by DNSSEC-trigger [dnssec-trigger] MAY be used during network | used by DNSSEC-trigger [dnssec-trigger] MAY be used during network | |||
configuration, with the intent to transition to the designated DNS | configuration, with the intent to transition to the designated DNS | |||
provider after authentication. The user MUST be alerted that the DNS | provider after authentication. The user MUST be alerted that the DNS | |||
is not private during such bootstrap. | is not private during such bootstrap. | |||
Methods for pre-deployment of the designated DNS provider are outside | Methods for pre-deployment of the designated DNS provider are outside | |||
the scope of this document. In corporate settings, such information | the scope of this document. In corporate settings, such information | |||
may be provided at system installation, for instance within the | may be provided at system installation. | |||
authenticated DHCP exchange [RFC3118]. | ||||
5. Performance Considerations | 5. Performance Considerations | |||
DNS-over-TLS incurs additional latency at session startup. It also | DNS-over-TLS incurs additional latency at session startup. It also | |||
requires additional state (memory) and increased processing (CPU). | requires additional state (memory) and increased processing (CPU). | |||
1. Latency: Compared to UDP, DNS-over-TCP requires an additional | 1. Latency: Compared to UDP, DNS-over-TCP requires an additional | |||
round-trip-time (RTT) of latency to establish a TCP connection. | round-trip-time (RTT) of latency to establish a TCP connection. | |||
TCP Fast Open [RFC7413] can eliminate that RTT when information | TCP Fast Open [RFC7413] can eliminate that RTT when information | |||
exists from prior connections. The TLS handshake adds another | exists from prior connections. The TLS handshake adds another | |||
skipping to change at page 8, line 51 | skipping to change at page 8, line 51 | |||
A full performance evaluation is outside the scope of this | A full performance evaluation is outside the scope of this | |||
specification. A more detailed analysis of the performance | specification. A more detailed analysis of the performance | |||
implications of DNS-over-TLS (and DNS-over-TCP) is discussed in | implications of DNS-over-TLS (and DNS-over-TCP) is discussed in | |||
[tdns] and [I-D.ietf-dnsop-5966bis]. | [tdns] and [I-D.ietf-dnsop-5966bis]. | |||
6. IANA Considerations | 6. IANA Considerations | |||
IANA is requested to add the following value to the "Service Name and | IANA is requested to add the following value to the "Service Name and | |||
Transport Protocol Port Number Registry" registry in the System | Transport Protocol Port Number Registry" registry in the System | |||
Range. The registry for that range requires IETF Review or IESG | Range. The registry for that range requires IETF Review or IESG | |||
Approval [RFC6335] and such a review has been requested using the | Approval [RFC6335] and such a review was requested using the Early | |||
Early Allocation process [RFC7120] for the well-known TCP port in | Allocation process [RFC7120] for the well-known TCP port in this | |||
this document. | document. | |||
We further recommend that IANA reserve the same port number over UDP | We further recommend that IANA reserve the same port number over UDP | |||
for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. | for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. | |||
Service Name domain-s | IANA responded to the early allocation request with the following | |||
Transport Protocol(s) TCP/UDP | TEMPORARY assignment: | |||
Assignee IESG | ||||
Contact TBD | Service Name domain-s | |||
Description DNS query-response protocol run over TLS | Port Number 853 | |||
Reference This document | Transport Protocol(s) TCP/UDP | |||
Assignee IETF DPRIVE Chairs | ||||
Contact Paul Hoffman | ||||
Description DNS query-response protocol run over TLS/DTLS | ||||
Reference This document | ||||
The TEMPORARY assignment expires 2016-10-08. IANA is requested to | ||||
make the assigmnent permanent upon publication of this document as an | ||||
RFC. | ||||
7. Design Evolution | 7. Design Evolution | |||
[Note to RFC Editor: please do not remove this section prior to | [Note to RFC Editor: please do not remove this section prior to | |||
publication as it may be useful to future Foo-over-TLS efforts] | publication as it may be useful to future Foo-over-TLS efforts] | |||
Earlier versions of this document proposed an upgrade-based approach | Earlier versions of this document proposed an upgrade-based approach | |||
to establishing a TLS session. The client would signal its interest | to establishing a TLS session. The client would signal its interest | |||
in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server | in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server | |||
would signal its acceptance by responding with the TLS OK bit set. | would signal its acceptance by responding with the TLS OK bit set. | |||
skipping to change at page 11, line 30 | skipping to change at page 11, line 38 | |||
arise out of the ability to eavesdrop on DNS messages. It does not | arise out of the ability to eavesdrop on DNS messages. It does not | |||
address other security issues in DNS, and there are a number of | address other security issues in DNS, and there are a number of | |||
residual risks that may affect its success at protecting privacy: | residual risks that may affect its success at protecting privacy: | |||
1. There are known attacks on TLS, such as person-in-the-middle and | 1. There are known attacks on TLS, such as person-in-the-middle and | |||
protocol downgrade. These are general attacks on TLS and not | protocol downgrade. These are general attacks on TLS and not | |||
specific to DNS-over-TLS; please refer to the TLS RFCs for | specific to DNS-over-TLS; please refer to the TLS RFCs for | |||
discussion of these security issues. Clients and servers MUST | discussion of these security issues. Clients and servers MUST | |||
adhere to the TLS implementation recommendations and security | adhere to the TLS implementation recommendations and security | |||
considerations of [RFC7525]. DNS clients keeping track of | considerations of [RFC7525]. DNS clients keeping track of | |||
servers known to support TLS (i.e., "pinning") enables clients to | servers known to support TLS enables clients to detect downgrade | |||
detect downgrade attacks. For servers with no connection history | attacks. For servers with no connection history and no apparent | |||
and no apparent support for TLS, clients depending on their | support for TLS, clients depending on their Privacy Profile and | |||
Privacy Profile and privacy requirements may choose to (a) try | privacy requirements may choose to (a) try another server when | |||
another server when available, (b) continue without TLS, or (c) | available, (b) continue without TLS, or (c) refuse to forward the | |||
refuse to forward the query. | query. | |||
2. Middleboxes [RFC3234] are be present in some networks and have | 2. Middleboxes [RFC3234] are present in some networks and have been | |||
been known to interfere with normal DNS resolution. Use of a | known to interfere with normal DNS resolution. Use of a | |||
designated port for DNS-over-TLS should avoid such interference. | designated port for DNS-over-TLS should avoid such interference. | |||
In general, clients that attempt TLS and fail can either fall | In general, clients that attempt TLS and fail can either fall | |||
back on unencrypted DNS, or wait and retry later, depending on | back on unencrypted DNS, or wait and retry later, depending on | |||
their Privacy Profile and privacy requirements. | their Privacy Profile and privacy requirements. | |||
3. Any protocol interactions prior to the TLS handshake are | 3. Any DNS protocol interactions prior to the TLS handshake that are | |||
performed in the clear and can be modified by a person-in-the- | performed in the clear can be modified by a person-in-the-middle | |||
middle attacker. For this reason, clients MAY discard cached | attacker. For example, unencrypted queries and responses might | |||
information about server capabilities advertised prior to the | take place over port 53 between a client and server prior to TLS. | |||
start of the TLS handshake. | For this reason, clients MAY discard cached information about | |||
server capabilities advertised prior to the start of the TLS | ||||
handshake. | ||||
4. This document does not itself specify ideas to resist known | 4. This document does not itself specify ideas to resist known | |||
traffic analysis or side channel leaks. Even with encrypted | traffic analysis or side channel leaks. Even with encrypted | |||
messages, a well-positioned party may be able to glean certain | messages, a well-positioned party may be able to glean certain | |||
details from an analysis of message timings and sizes. Clients | details from an analysis of message timings and sizes. Clients | |||
and servers may consider the use of a padding method to address | and servers may consider the use of a padding method to address | |||
privacy leakage due to message sizes [I-D.edns0-padding] | privacy leakage due to message sizes [I-D.edns0-padding] | |||
10. Contributing Authors | 10. Contributing Authors | |||
skipping to change at page 14, line 31 | skipping to change at page 14, line 39 | |||
Mohaisen, "Opportunistic Encryption with DANE Semantics | Mohaisen, "Opportunistic Encryption with DANE Semantics | |||
and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in | and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in | |||
progress), July 2015, | progress), July 2015, | |||
<http://tools.ietf.org/html/ | <http://tools.ietf.org/html/ | |||
draft-osterweil-dane-ipsec-03>. | draft-osterweil-dane-ipsec-03>. | |||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ | |||
RFC2818, May 2000, | RFC2818, May 2000, | |||
<http://www.rfc-editor.org/info/rfc2818>. | <http://www.rfc-editor.org/info/rfc2818>. | |||
[RFC3118] Droms, R. and W. Arbaugh., Ed., "Authentication for DHCP | ||||
Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, | ||||
<http://www.rfc-editor.org/info/rfc3118>. | ||||
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and | [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and | |||
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, | Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, | |||
<http://www.rfc-editor.org/info/rfc3234>. | <http://www.rfc-editor.org/info/rfc3234>. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, DOI 10.17487/RFC4033, March 2005, | RFC 4033, DOI 10.17487/RFC4033, March 2005, | |||
<http://www.rfc-editor.org/info/rfc4033>. | <http://www.rfc-editor.org/info/rfc4033>. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
End of changes. 19 change blocks. | ||||
55 lines changed or deleted | 63 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |