< draft-ietf-dnsop-edns-chain-query-05.txt   draft-ietf-dnsop-edns-chain-query-06.txt >
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track November 17, 2015 Intended status: Standards Track January 18, 2016
Expires: May 20, 2016 Expires: July 21, 2016
Chain Query requests in DNS Chain Query requests in DNS
draft-ietf-dnsop-edns-chain-query-05 draft-ietf-dnsop-edns-chain-query-06
Abstract Abstract
This document defines an EDNS0 extension that can be used by a This document defines an EDNS0 extension that can be used by a
security-aware validating Resolver configured to use a Forwarder to security-aware validating resolver configured to use a Forwarder to
send a single query, requesting a complete validation path along with send a single query, requesting a complete validation path along with
the regular query answer. The reduction in queries lowers the the regular query answer. The reduction in queries potentially
latency and reduces the need to send multiple queries at once. This lowers the latency and reduces the need to send multiple queries at
extension mandates the use of source IP verified transport such as once. This extension mandates the use of source IP verified
TCP or UDP with EDNS-COOKIE so it cannot be abused in amplification transport such as TCP or UDP with EDNS-COOKIE so it cannot be abused
attacks. in amplification attacks.
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 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 May 20, 2016. This Internet-Draft will expire on July 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5
5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5
5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 6 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 5
5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6
6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8
6.2. NS record Considerations . . . . . . . . . . . . . . . . 8 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8
6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 6.3. Session Management . . . . . . . . . . . . . . . . . . . 8
6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 8 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9
6.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9
6.6. Anycast Considerations . . . . . . . . . . . . . . . . . 9
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10
9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12 9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12
9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. EDNS0 option code for CHAIN . . . . . . . . . . . . . . 14 10.1. EDNS0 option code for CHAIN . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 26 skipping to change at page 3, line 25
queries required for the complete answer, it usually has a much queries required for the complete answer, it usually has a much
bigger cache and does not experience significant slowdown from last- bigger cache and does not experience significant slowdown from last-
mile latency. mile latency.
This EDNS0 extension allows the Forwarder to indicate which part of This EDNS0 extension allows the Forwarder to indicate which part of
the DNS hierarchy it already contains in its cache. This reduces the the DNS hierarchy it already contains in its cache. This reduces the
amount of data required to be transferred and reduces the work the amount of data required to be transferred and reduces the work the
upstream Recursive Resolver has to perform. upstream Recursive Resolver has to perform.
This EDNS0 extension is only intended to be sent by Forwarders to This EDNS0 extension is only intended to be sent by Forwarders to
Recursive Resolvers. It can (and should) be ignored by Authoritative Recursive Resolvers. It MUST be ignored by Authoritative Servers.
Servers.
1.1. Requirements Notation 1.1. Requirements Notation
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The DNS terminology used in this document is that of The DNS terminology used in this document is that of [RFC7719].
[DNS-TERMINOLOGY]. Additionally, the following terms are used: Additionally, the following terms are used:
Recursive Resolver: A nameserver that is responsible for resolving Recursive Resolver: A nameserver that is responsible for resolving
domain names for clients by following the domain's delegation domain names for clients by following the domain's delegation
chain, starting at the root. Recursive Resolvers frequently use chain, starting at the root. Recursive Resolvers frequently use
caches to be able to respond to client queries quickly. Described caches to be able to respond to client queries quickly. Described
in [RFC1035] chapter 7. in [RFC1035] chapter 7.
Validating Resolver: A recursive nameserver that also performs Validating Resolver: A recursive nameserver that also performs
DNSSEC [RFC4033] validation. Also known as "security-aware DNSSEC [RFC4033] validation. Also known as "security-aware
resolver". resolver".
skipping to change at page 6, line 30 skipping to change at page 6, line 25
its query strategy based on the desired queries and its cache its query strategy based on the desired queries and its cache
contents. contents.
A Forwarder can request the CHAIN option with every outgoing DNS A Forwarder can request the CHAIN option with every outgoing DNS
query. However, it is RECOMMENDED that Forwarders remember which query. However, it is RECOMMENDED that Forwarders remember which
upstream Recursive Resolvers did not return the option (and upstream Recursive Resolvers did not return the option (and
additional data) with their response. The Forwarder SHOULD fallback additional data) with their response. The Forwarder SHOULD fallback
to regular DNS for subsequent queries to those Recursive Resolvers. to regular DNS for subsequent queries to those Recursive Resolvers.
It MAY switch to another Recursive Resolver that does support the It MAY switch to another Recursive Resolver that does support the
CHAIN option or try again later to see if the server has become less CHAIN option or try again later to see if the server has become less
loaded and is now willing to answer with Query Chains. loaded and is now willing to answer with Query Chains. A fallback
strategy similar to that described in [RFC6891] section 6.2.2 SHOULD
be employed to avoid persistent interference due to non-clean paths.
5.4. Generate a Response 5.4. Generate a Response
When a query containing a non-zero CHAIN option is received from a When a query containing a non-zero CHAIN option is received from a
Forwarder, the upstream Recursive Resolver supporting CHAIN MAY Forwarder, the upstream Recursive Resolver supporting CHAIN MAY
respond by confirming that it is returning a CHAIN. To do so, it respond by confirming that it is returning a CHAIN. To do so, it
MUST set the CHAIN option to the lowest Trust Point sent as part of MUST set the CHAIN option to the lowest Trust Point sent as part of
the chain, with its corresponding OPTION-LENGTH. It extends the the chain, with its corresponding OPTION-LENGTH. It extends the
Authority Section in the DNS answer packet with the DNS RRsets Authority Section in the DNS answer packet with the DNS RRsets
required for validating the answer. The DNS RRsets added start with required for validating the answer. The DNS RRsets added start with
skipping to change at page 8, line 30 skipping to change at page 8, line 32
via the DNSKEY and DS RRsets without using the NS RRset. However, via the DNSKEY and DS RRsets without using the NS RRset. However,
the Forwarder might be forced to switch from Forwarder mode to the Forwarder might be forced to switch from Forwarder mode to
Recursive Resolver mode due to a network topology change. In Recursive Resolver mode due to a network topology change. In
Recursive Resolver mode, the NS RRsets are needed to find and query Recursive Resolver mode, the NS RRsets are needed to find and query
Authoritative Servers directly. It is RECOMMENDED that the DNS Authoritative Servers directly. It is RECOMMENDED that the DNS
Forwarder populate its cache with this information to avoid requiring Forwarder populate its cache with this information to avoid requiring
future queries to obtain any missing NS records. Therefore, CHAIN future queries to obtain any missing NS records. Therefore, CHAIN
responses MUST include the NS RRset from the child zone, including responses MUST include the NS RRset from the child zone, including
the RRSIG records required for validation. the RRSIG records required for validation.
6.3. TCP Session Management 6.3. Session Management
It is RECOMMENDED that TCP sessions not immediately be closed after It is RECOMMENDED that TCP sessions not immediately be closed after
the DNS answer to the first query is received. It is recommended to the DNS answer to the first query is received. It is recommended to
use [TCP-KEEPALIVE]. use [TCP-KEEPALIVE].
Both DNS clients and servers are subject to resource constraints Both DNS clients and servers are subject to resource constraints
which will limit the extent to which Chain Queries can be executed. which will limit the extent to which Chain Queries can be executed.
Effective limits for the number of active sessions that can be Effective limits for the number of active sessions that can be
maintained on individual clients and servers should be established, maintained on individual clients and servers should be established,
either as configuration options or by interrogation of process limits either as configuration options or by interrogation of process limits
skipping to change at page 9, line 4 skipping to change at page 9, line 6
imposed by the operating system. imposed by the operating system.
In the event that there is greater demand for Chain Queries than can In the event that there is greater demand for Chain Queries than can
be accommodated, DNS servers may stop advertising the CHAIN option in be accommodated, DNS servers may stop advertising the CHAIN option in
successive DNS messages. This allows, for example, clients with successive DNS messages. This allows, for example, clients with
other candidate servers to query to establish new sessions with other candidate servers to query to establish new sessions with
different servers in expectation that those servers might still allow different servers in expectation that those servers might still allow
Chain Queries. Chain Queries.
6.4. Negative Trust Anchors 6.4. Negative Trust Anchors
If a CHAIN answer would intersect with a Negative Trust Anchor If a CHAIN answer would intersect with a Negative Trust Anchor
[RFC7646], a partian CHAIN up to the node above the Negative Trust [RFC7646], a partial CHAIN up to the node above the Negative Trust
Anchor should be returned. Anchor should be returned.
6.5. Non-Clean Paths 6.5. Anycast Considerations
Many paths between DNS clients and Recursive Resolvers suffer from
poor hygiene, limiting the free flow of DNS messages that include
particular EDNS0 options, or messages that exceed a particular size.
A fallback strategy similar to that described in [RFC6891] section
6.2.2 SHOULD be employed to avoid persistent interference due to non-
clean paths.
6.6. Anycast Considerations
Recursive Resolvers of various types are commonly deployed using Recursive Resolvers of various types are commonly deployed using
anycast [RFC4786]. anycast [RFC4786].
Successive DNS transactions between a client and server using UDP Successive DNS transactions between a client and server using UDP
transport may involve responses generated by different anycast nodes, transport may involve responses generated by different anycast nodes,
and the use of anycast in the implementation of a DNS server is and the use of anycast in the implementation of a DNS server is
effectively undetectable by the client. The CHAIN option SHOULD NOT effectively undetectable by the client. The CHAIN option SHOULD NOT
be included in responses using UDP transport from servers provisioned be included in responses using UDP transport from servers provisioned
using anycast unless all anycast server nodes are capable of using anycast unless all anycast server nodes are capable of
processing the CHAIN option. processing the CHAIN option.
Changes in network topology between clients and anycast servers may Since DNS queries using CHAIN may result in longer TCP sessions,
cause disruption to TCP sessions making use of CHAIN more often than network topology changes may disrupt them more frequently. Anycast
with TCP sessions that omit it, since the TCP sessions are expected servers MAY make use of TCP multipath [RFC6824] to anchor the server
to be longer-lived. Anycast servers MAY make use of TCP multipath side of the TCP connection to an unambiguously-unicast address in
[RFC6824] to anchor the server side of the TCP connection to an order to avoid disruption due to topology changes.
unambiguously-unicast address in order to avoid disruption due to
topology changes.
7. Implementation Status 7. Implementation Status
[RFC Editor Note: Please remove this entire seciton prior to
publication as an RFC.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
skipping to change at page 10, line 51 skipping to change at page 10, line 51
This includes the DNSKEY RRset with its RRSIG records. In other This includes the DNSKEY RRset with its RRSIG records. In other
words, according to its cache, ".com" is DNSSEC validated as words, according to its cache, ".com" is DNSSEC validated as
"secure" and can be used to continue a DNSSEC validated chain. "secure" and can be used to continue a DNSSEC validated chain.
o The Resolver on the client opens a TCP connection to its upstream o The Resolver on the client opens a TCP connection to its upstream
Recursive Resolver on port 53. It adds the CHAIN option as Recursive Resolver on port 53. It adds the CHAIN option as
follows: follows:
* Option-code, set to 13 * Option-code, set to 13
* Option-length, set to 0x00 0x04 * Option-length, set to 5
* Closest Trust Point set to "com." * Closest Trust Point set to "com." (0x03 0x63 0x6f 0x6d 0x00)
o The upstream Recursive Resolver receives a DNS query over TCP with o The upstream Recursive Resolver receives a DNS query over TCP with
the CHAIN Closest Trust Point set to "com.". After accepting the the CHAIN Closest Trust Point set to "com.". After accepting the
query it starts constructing a DNS reply packet. query it starts constructing a DNS reply packet.
o The upstream Recursive Resolver performs all the regular work to o The upstream Recursive Resolver performs all the regular work to
ensure it has all the answers to the query for the A record of ensure it has all the answers to the query for the A record of
"www.example.com.". It does so without using the CHAIN option - "www.example.com.". It does so without using the CHAIN option -
unless it is also configured as a Forwarder. The answer to the unless it is also configured as a Forwarder. The answer to the
original DNS question could be the actual A record, the DNSSEC original DNS question could be the actual A record, the DNSSEC
proof of non-existence, or an insecure NXDOMAIN response. proof of non-existence, or an insecure NXDOMAIN response.
o The upstream Recursive Resolver adds the CHAIN option to the DNS o The upstream Recursive Resolver adds the CHAIN option to the DNS
response as follows: response as follows:
* Option-code, set to 13 * Option-code, set to 13
* Option-length, set to 0x00 0x04 * Option-length, set to 5
* The Closest Trust Point is set to "com.". * The Closest Trust Point is set to "com." (0x03 0x63 0x6f 0x6d
0x00)
o The upstream Recursive Resolver constructs the DNS Authority o The upstream Recursive Resolver constructs the DNS Authority
Section and fills it (in any order) with: Section and fills it (in any order) with:
* The DS RRset for "example.com." and its corresponding RRSIGs * The DS RRset for "example.com." and its corresponding RRSIGs
(made by the "com." DNSKEY(s)) (made by the "com." DNSKEY(s))
* The DNSKEY RRset for "example.com." and its corresponding * The DNSKEY RRset for "example.com." and its corresponding
RRSIGs (made by the "example.com" DNSKEY(s)) RRSIGs (made by the "example.com" DNSKEY(s))
skipping to change at page 12, line 38 skipping to change at page 12, line 38
returned depending on the error condition. returned depending on the error condition.
9.2. Out-of-path Query for example.com 9.2. Out-of-path Query for example.com
A Recursive Resolver receives a query for the A record for A Recursive Resolver receives a query for the A record for
example.com. It includes the CHAIN option with the following example.com. It includes the CHAIN option with the following
parameters: parameters:
o Option-code, set to 13 o Option-code, set to 13
o Option-length, set to 0x00 0x0D o Option-length, set to 14
o The Closest Trust Point set to 'unrelated.ca.' o The Closest Trust Point set to 'unrelated.ca.' (0x09 0x75 0x6e
0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)
As there is no chain that leads from "unrelated.ca." to As there is no chain that leads from "unrelated.ca." to
"example.com", the Resolving Nameserver answers with an empty CHAIN "example.com", the Resolving Nameserver answers with an empty CHAIN
specified using: specified using:
o Option-code, set to 13 o Option-code, set to 13
o Option-length, set to 0x00 0x00 o Option-length, set to 0x00 0x00
o The Closest Trust Point is omitted (zero length) o The Closest Trust Point is omitted (zero length)
skipping to change at page 14, line 31 skipping to change at page 14, line 31
11. Acknowledgements 11. Acknowledgements
Andrew Sullivan pointed out that we do not need any new data formats Andrew Sullivan pointed out that we do not need any new data formats
to support DNS chains. Olafur Gudmundsson ensured the RRsets are to support DNS chains. Olafur Gudmundsson ensured the RRsets are
returned in the proper Sections. Thanks to Tim Wicinski for his returned in the proper Sections. Thanks to Tim Wicinski for his
thorough review. thorough review.
12. Normative References 12. Normative References
[DNS-TERMINOLOGY]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
progress), September 2015.
[EDNS-COOKIE] [EDNS-COOKIE]
Eastlake, Donald., "Domain Name System (DNS) Cookies", Eastlake, Donald., "Domain Name System (DNS) Cookies",
draft-ietf-dnsop-cookies (work in progress), November draft-ietf-dnsop-cookies (work in progress), December
2015. 2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
skipping to change at page 15, line 49 skipping to change at page 15, line 44
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, DOI Code: The Implementation Status Section", RFC 6982, DOI
10.17487/RFC6982, July 2013, 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
and R. Weber, "Definition and Use of DNSSEC Negative Trust and R. Weber, "Definition and Use of DNSSEC Negative Trust
Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
<http://www.rfc-editor.org/info/rfc7646>. <http://www.rfc-editor.org/info/rfc7646>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
[TCP-KEEPALIVE] [TCP-KEEPALIVE]
Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
tcp-keepalive-04 (work in progress), October 2015. tcp-keepalive-05 (work in progress), January 2016.
Author's Address Author's Address
Paul Wouters Paul Wouters
Red Hat Red Hat
Email: pwouters@redhat.com Email: pwouters@redhat.com
 End of changes. 27 change blocks. 
54 lines changed or deleted 48 lines changed or added

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