draft-ietf-dnsop-refuse-any-06.txt   draft-ietf-dnsop-refuse-any-07.txt 
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft Afilias Internet-Draft Afilias
Updates: 1034, 1035 (if approved) O. Gudmundsson Updates: 1034, 1035 (if approved) O. Gudmundsson
Intended status: Standards Track M. Majkowski Intended status: Standards Track M. Majkowski
Expires: September 6, 2018 Cloudflare Inc. Expires: February 15, 2019 Cloudflare Inc.
March 5, 2018 E. Hunt
ISC
August 14, 2018
Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
draft-ietf-dnsop-refuse-any-06 draft-ietf-dnsop-refuse-any-07
Abstract Abstract
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
The operator of an authoritative DNS server might choose not to The operator of an authoritative DNS server might choose not to
respond to such queries for reasons of local policy, motivated by respond to such queries for reasons of local policy, motivated by
security, performance or other reasons. security, performance or other reasons.
The DNS specification does not include specific guidance for the The DNS specification does not include specific guidance for the
behaviour of DNS servers or clients in this situation. This document behaviour of DNS servers or clients in this situation. This document
aims to provide such guidance. aims to provide such guidance.
This document updates RFC 1034 and RFC 1035.
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 https://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 September 6, 2018. This Internet-Draft will expire on February 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations for Use of ANY Queries . . . . . . . . . . . . . 3 2. Motivations for Use of ANY Queries . . . . . . . . . . . . . 3
3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4 3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4
4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4 4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4
4.1. Answer with a Subset of Available RRSets . . . . . . . . 5 4.1. Answer with a Subset of Available RRSets . . . . . . . . 5
4.2. Answer with a Synthesised HINFO RRSet . . . . . . . . . . 5 4.2. Answer with a Synthesised HINFO RRSet . . . . . . . . . . 5
4.3. Answer with Best Guess as to Intention . . . . . . . . . 6 4.3. Answer with Best Guess as to Intention . . . . . . . . . 6
4.4. Behaviour with TCP Transport . . . . . . . . . . . . . . 6 4.4. Behaviour with TCP Transport . . . . . . . . . . . . . . 6
5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 6 5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 6
6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 6 6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Updates to RFC 1034 and RFC 1035 . . . . . . . . . . . . . . 7 7. Updates to RFC 1034 and RFC 1035 . . . . . . . . . . . . . . 7
8. Implementation Experience . . . . . . . . . . . . . . . . . . 7 8. Implementation Experience . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 9 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 10
A.1. Change History . . . . . . . . . . . . . . . . . . . . . 9 A.1. Change History . . . . . . . . . . . . . . . . . . . . . 10
A.1.1. draft-ietf-dnsop-refuse-any-06 . . . . . . . . . . . 9 A.1.1. draft-ietf-dnsop-refuse-any-07 . . . . . . . . . . . 10
A.1.2. draft-ietf-dnsop-refuse-any-05 . . . . . . . . . . . 9 A.1.2. draft-ietf-dnsop-refuse-any-06 . . . . . . . . . . . 10
A.1.3. draft-ietf-dnsop-refuse-any-04 . . . . . . . . . . . 9 A.1.3. draft-ietf-dnsop-refuse-any-05 . . . . . . . . . . . 10
A.1.4. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 10 A.1.4. draft-ietf-dnsop-refuse-any-04 . . . . . . . . . . . 10
A.1.5. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 10 A.1.5. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 10
A.1.6. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 10 A.1.6. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 10
A.1.7. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 10 A.1.7. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 11
A.1.8. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 10 A.1.8. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 11
A.1.9. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 10 A.1.9. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 A.1.10. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
The operator of an authoritative DNS server might choose not to The operator of an authoritative DNS server might choose not to
respond to such queries for reasons of local policy, motivated by respond to such queries for reasons of local policy, motivated by
security, performance or other reasons. security, performance or other reasons.
The DNS specification [RFC1034] [RFC1035] does not include specific The DNS specification [RFC1034] [RFC1035] does not include specific
guidance for the behaviour of DNS servers or clients in this guidance for the behaviour of DNS servers or clients in this
skipping to change at page 3, line 27 skipping to change at page 3, line 34
In this document, "conventional ANY response" means an ANY response In this document, "conventional ANY response" means an ANY response
that is constructed in accordance with the algorithm documented in that is constructed in accordance with the algorithm documented in
section 4.3.2 of [RFC1034] and specifically without implementing any section 4.3.2 of [RFC1034] and specifically without implementing any
of the mechanisms described in this document. of the mechanisms described in this document.
In an exchange of DNS messages between two hosts, this document In an exchange of DNS messages between two hosts, this document
refers to the host sending a DNS request as the initiator, and the refers to the host sending a DNS request as the initiator, and the
host sending a DNS response as the responder. host sending a DNS response as the responder.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Motivations for Use of ANY Queries 2. Motivations for Use of ANY Queries
ANY queries are legitimately used for debugging and checking the ANY queries are legitimately used for debugging and checking the
state of a DNS server for a particular name. state of a DNS server for a particular name.
ANY queries are sometimes used as a attempt to reduce the number of ANY queries are sometimes used as a attempt to reduce the number of
queries needed to get information, e.g. to obtain MX, A and AAAA queries needed to get information, e.g. to obtain MX, A and AAAA
RRSets for a mail domain in a single query. There is no documented RRSets for a mail domain in a single query. There is no documented
guidance available for this use case, however, and some guidance available for this use case, however, and some
skipping to change at page 6, line 5 skipping to change at page 6, line 10
understanding that a TTL that is too long might make policy changes understanding that a TTL that is too long might make policy changes
relating to ANY queries difficult to change in the future. The relating to ANY queries difficult to change in the future. The
specific value used is hence a familiar balance when choosing TTL for specific value used is hence a familiar balance when choosing TTL for
any RR in any zone, and be specified according to local policy. any RR in any zone, and be specified according to local policy.
If the DNS query includes DO=1 and the QNAME corresponds to a zone If the DNS query includes DO=1 and the QNAME corresponds to a zone
that is known by the responder to be signed, a valid RRSIG for the that is known by the responder to be signed, a valid RRSIG for the
RRSets in the answer (or authority if answer is empty) section MUST RRSets in the answer (or authority if answer is empty) section MUST
be returned. In the case of DO=0, the RRSIG SHOULD be omitted. be returned. In the case of DO=0, the RRSIG SHOULD be omitted.
A system that receives an HINFO response SHOULD NOT infer that the
response was generated according to this specification and apply any
special processing of the response, since in general it is not
possible to tell with certainty whether the HINFO RRSet received was
synthesised. In particular, systems SHOULD NOT rely upon the HINFO
RDATA described in this seection to distinguish between synthesised
and non-synthesised HINFO RRSets.
4.3. Answer with Best Guess as to Intention 4.3. Answer with Best Guess as to Intention
In some cases it is possible to guess what the initiator wants in the In some cases it is possible to guess what the initiator wants in the
answer but not always. Some implementations have implemented the answer (but not always). Some implementations have implemented the
spirit of this document by returning all of CNAME or (MX A and AAAA) spirit of this document by returning all RRSets of RRType CNAME, MX,
RRsets that are present. This is not a guess but a heuristic that A and AAAA that are present at the owner name but suppressing others.
seems to work well in practice. The main drawback is the size of the This heuristic seems to work well in practice, satisfying the needs
answer. of some applications whilst suppressing other RRSets such as TXT and
DNSKEY that can often contribute to large responses. Whilst some
applications may be satisfied by this behaviour, the resulting
responses in the general case are larger than the approaches
described in Section 4.1 and Section 4.2.
As in the first one if the zone is signed RRSIG MUST be returned if As before, if the zone is signed and the DO bit is set on the
there the DO bit is set on query. corresponding query, an RRSIG RRSet MUST be included in the response.
4.4. Behaviour with TCP Transport 4.4. Behaviour with TCP Transport
A DNS responder MAY behave differently when processing ANY queries A DNS responder MAY behave differently when processing ANY queries
received over different transport, e.g. by providing a conventional received over different transport, e.g. by providing a conventional
ANY response over TCP whilst using one of the other mechanisms ANY response over TCP whilst using one of the other mechanisms
specified in this document in the case where a query was received specified in this document in the case where a query was received
using UDP. using UDP.
Implementers SHOULD provide configuration options to allow operators Implementers SHOULD provide configuration options to allow operators
skipping to change at page 7, line 20 skipping to change at page 7, line 37
7. Updates to RFC 1034 and RFC 1035 7. Updates to RFC 1034 and RFC 1035
This document extends the specification for processing ANY queries This document extends the specification for processing ANY queries
described in section 4.3.2 of [RFC1034]. described in section 4.3.2 of [RFC1034].
It is important to note that returning a subset of available RRSets It is important to note that returning a subset of available RRSets
when processing an ANY query is legitimate and consistent with when processing an ANY query is legitimate and consistent with
[RFC1035]; it can be argued that ANY does not always mean ALL, as [RFC1035]; it can be argued that ANY does not always mean ALL, as
used in section 3.2.3 of [RFC1035]. The main difference here is that used in section 3.2.3 of [RFC1035]. The main difference here is that
the TC bit SHOULD not be set on the response indicating that this is the TC bit SHOULD NOT be set on the response indicating that this is
not a complete answer. not a complete answer.
This document describes optional behaviour for both DNS initiators This document describes optional behaviour for both DNS initiators
and responders, and implementation of the guidance provided by this and responders, and implementation of the guidance provided by this
document is OPTIONAL. document is OPTIONAL.
RRSIG queries (i.e. queries with QTYPE=RRSIG) are similar to ANY RRSIG queries (i.e. queries with QTYPE=RRSIG) are similar to ANY
queries in the sense that they have the potential to generate large queries in the sense that they have the potential to generate large
responses as well as extra work for the responders that process them, responses as well as extra work for the responders that process them,
e.g. in the case where signatures are generated on-the-fly. RRSIG e.g. in the case where signatures are generated on-the-fly. RRSIG
skipping to change at page 8, line 34 skipping to change at page 8, line 49
+------+-------+-------------------------------+--------------------+ +------+-------+-------------------------------+--------------------+
| Type | Value | Meaning | Reference | | Type | Value | Meaning | Reference |
+------+-------+-------------------------------+--------------------+ +------+-------+-------------------------------+--------------------+
| * | 255 | A request for some or all | [RFC1035][RFC6895] | | * | 255 | A request for some or all | [RFC1035][RFC6895] |
| | | records the server has | [This Document] | | | | records the server has | [This Document] |
| | | available | | | | | available | |
+------+-------+-------------------------------+--------------------+ +------+-------+-------------------------------+--------------------+
11. Acknowledgements 11. Acknowledgements
Evan Hunt and David Lawrence provided valuable observations and David Lawrence provided valuable observations and concrete
concrete suggestions. Jeremy Laidman helped make the document suggestions. Jeremy Laidman helped make the document better. Tony
better. Tony Finch realized that this document was valuable and Finch realized that this document was valuable and implemented it
implemented it while under attack. Richard Gibson identified areas while under attack. Richard Gibson identified areas where more
where more detail and accuracy was useful. A large number of other detail and accuracy was useful. A large number of other people also
people also provided comments and suggestions we thank them all for provided comments and suggestions we thank them all for the feedback.
the feedback.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc1034>. <https://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, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Nameservers in Reflector Attacks", BCP 140, RFC 5358,
DOI 10.17487/RFC5358, October 2008, DOI 10.17487/RFC5358, October 2008,
<https://www.rfc-editor.org/info/rfc5358>. <https://www.rfc-editor.org/info/rfc5358>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
skipping to change at page 9, line 36 skipping to change at page 10, line 11
[1] http://www.iana.org/assignments/dns-parameters/dns- [1] http://www.iana.org/assignments/dns-parameters/dns-
parameters.xhtml#dns-parameters-4 parameters.xhtml#dns-parameters-4
Appendix A. Editorial Notes Appendix A. Editorial Notes
This section (and sub-sections) to be removed prior to publication. This section (and sub-sections) to be removed prior to publication.
A.1. Change History A.1. Change History
A.1.1. draft-ietf-dnsop-refuse-any-06 A.1.1. draft-ietf-dnsop-refuse-any-07
Address AD's concerns: more colour to describe updates to 1034/1035
in the abstract; don't rely upon HINFO RDATA formatting; language
cleanup around guess intent. Add Evan as author (originator of the
"choose one record" response idea).
A.1.2. draft-ietf-dnsop-refuse-any-06
Update RFC 1034 as well as RFC 1035; define the term "conventional Update RFC 1034 as well as RFC 1035; define the term "conventional
ANY response"; soften and qualify ANY does not mean ALL; note that ANY response"; soften and qualify ANY does not mean ALL; note that
the subset mode response lacks signalling. the subset mode response lacks signalling.
A.1.2. draft-ietf-dnsop-refuse-any-05 A.1.3. draft-ietf-dnsop-refuse-any-05
Minor editorial changes. Soften advice on RRSIG queries. Version Minor editorial changes. Soften advice on RRSIG queries. Version
bump. bump.
A.1.3. draft-ietf-dnsop-refuse-any-04 A.1.4. draft-ietf-dnsop-refuse-any-04
These are the changes requested during WGLC. The title has been These are the changes requested during WGLC. The title has been
updated for readability The behavior section now contains description updated for readability The behavior section now contains description
of three different approaches in order of preference. Text added on of three different approaches in order of preference. Text added on
behavior over TCP. The document is clear in how it updates from behavior over TCP. The document is clear in how it updates from
RFC1035. Minor adjustments for readability and remove redundancy. RFC1035. Minor adjustments for readability and remove redundancy.
A.1.4. draft-ietf-dnsop-refuse-any-03 A.1.5. draft-ietf-dnsop-refuse-any-03
Change section name to "Updates to RFC1034", few minor grammar Change section name to "Updates to RFC1034", few minor grammar
changes suggested by Matthew Pounsett and Tony Finch. changes suggested by Matthew Pounsett and Tony Finch.
Text clarifications, reflecting experience, added implementation Text clarifications, reflecting experience, added implementation
experience. experience.
A.1.5. draft-ietf-dnsop-refuse-any-02 A.1.6. draft-ietf-dnsop-refuse-any-02
Added suggestion to call out RRSIG is optional when DO=0. Added suggestion to call out RRSIG is optional when DO=0.
Number of text suggestions from Jeremy Laidman. Number of text suggestions from Jeremy Laidman.
A.1.6. draft-ietf-dnsop-refuse-any-01 A.1.7. draft-ietf-dnsop-refuse-any-01
Add IANA Considerations Add IANA Considerations
A.1.7. draft-ietf-dnsop-refuse-any-00 A.1.8. draft-ietf-dnsop-refuse-any-00
Re-submitted with a different name following adoption at the dnsop WG Re-submitted with a different name following adoption at the dnsop WG
meeting convened at IETF 94. meeting convened at IETF 94.
A.1.8. draft-jabley-dnsop-refuse-any-01 A.1.9. draft-jabley-dnsop-refuse-any-01
Make signing of RRSets in answers from signed zones mandatory. Make signing of RRSets in answers from signed zones mandatory.
Document the option of returning an existing RRSet in place of a Document the option of returning an existing RRSet in place of a
synthesised one. synthesised one.
A.1.9. draft-jabley-dnsop-refuse-any-00 A.1.10. draft-jabley-dnsop-refuse-any-00
Initial draft circulated for comment. Initial draft circulated for comment.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Afilias Afilias
300-184 York Street 300-184 York Street
London, ON N6A 1B5 London, ON N6A 1B5
Canada Canada
skipping to change at page 11, line 4 skipping to change at page 11, line 35
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Afilias Afilias
300-184 York Street 300-184 York Street
London, ON N6A 1B5 London, ON N6A 1B5
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@afilias.info Email: jabley@afilias.info
Olafur Gudmundsson Olafur Gudmundsson
Cloudflare Inc. Cloudflare Inc.
Email: olafur+ietf@cloudflare.com Email: olafur+ietf@cloudflare.com
Marek Majkowski Marek Majkowski
Cloudflare Inc. Cloudflare Inc.
Email: marek@cloudflare.com Email: marek@cloudflare.com
Evan Hunt
ISC
950 Charter St
Redwood City, CA 94063
USA
Email: each@isc.org
 End of changes. 27 change blocks. 
47 lines changed or deleted 77 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/