draft-ietf-dprive-xfr-over-tls-00.txt   draft-ietf-dprive-xfr-over-tls-01.txt 
dprive H. Zhang dprive H. Zhang
Internet-Draft P. Aras Internet-Draft P. Aras
Updates: 1995 (if approved) Salesforce Updates: 1995 (if approved) Salesforce
Intended status: Standards Track W. Toorop Intended status: Standards Track W. Toorop
Expires: May 21, 2020 NLnet Labs Expires: November 21, 2020 NLnet Labs
S. Dickinson S. Dickinson
Sinodun IT Sinodun IT
A. Mankin A. Mankin
Salesforce Salesforce
November 18, 2019 May 20, 2020
DNS Zone Transfer-over-TLS DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-00 draft-ietf-dprive-xfr-over-tls-01
Abstract Abstract
DNS zone transfers are transmitted in clear text, which gives DNS zone transfers are transmitted in clear text, which gives
attackers the opportunity to collect the content of a zone by attackers the opportunity to collect the content of a zone by
eavesdropping on network connections. The DNS Transaction Signature eavesdropping on network connections. The DNS Transaction Signature
(TSIG) mechanism is specified to restrict direct zone transfer to (TSIG) mechanism is specified to restrict direct zone transfer to
authorized clients only, but it does not add confidentiality. This authorized clients only, but it does not add confidentiality. This
document specifies use of DNS-over-TLS to prevent zone contents document specifies use of DNS-over-TLS to prevent zone contents
collection via passive monitoring of zone transfers. collection via passive monitoring of zone transfers.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 21, 2020. This Internet-Draft will expire on November 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 28 skipping to change at page 2, line 28
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 4 3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 4
4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5 4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5
4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 5 4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 5
4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6 4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6
4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 7 4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 7
4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Connection and Data Flows in XoT . . . . . . . . . . . . . . 8 5. Connection and Data Flows in XoT . . . . . . . . . . . . . . 8
5.1. Performance Considerations . . . . . . . . . . . . . . . 8 5.1. Performance Considerations . . . . . . . . . . . . . . . 8
5.2. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8 5.2. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8
5.3. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9 5.3. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10 5.4. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9
5.4.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10
6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10 6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10
6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 10 6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 11
6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 11
6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11 6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11
6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Comparison of Authentication Methods . . . . . . . . . . 11 6.6. Comparison of Authentication Methods . . . . . . . . . . 12
7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 12 7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 13
8. Multi-primary Configurations . . . . . . . . . . . . . . . . 13 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 14
9. Implementation Considerations . . . . . . . . . . . . . . . . 14 9. Implementation Considerations . . . . . . . . . . . . . . . . 14
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . 17 15.2. Informative References . . . . . . . . . . . . . . . . . 17
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
DNS has a number of privacy vulnerabilities, as discussed in detail DNS has a number of privacy vulnerabilities, as discussed in detail
in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver
query privacy has received the most attention to date. There are now query privacy has received the most attention to date. There are now
standards track documents for three encryption capabilities for stub standards track documents for three encryption capabilities for stub
to recursive queries and more work going on to guide deployment of to recursive queries and more work going on to guide deployment of
specifically DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) specifically DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH)
skipping to change at page 4, line 29 skipping to change at page 4, line 31
Privacy terminology is as described in Section 3 of [RFC6973]. Privacy terminology is as described in Section 3 of [RFC6973].
Note that in this document we choose to use the terms 'primary' and Note that in this document we choose to use the terms 'primary' and
'secondary' for two servers engaged in zone transfers. 'secondary' for two servers engaged in zone transfers.
DNS terminology is as described in [RFC8499]. DNS terminology is as described in [RFC8499].
DoT: DNS-over-TLS as specified in [RFC7858] DoT: DNS-over-TLS as specified in [RFC7858]
DoH: DNS-over-HTTPS as specified in [RFC8484]
XoT: Generic XFR-over-TLS mechanisms as specified in this document XoT: Generic XFR-over-TLS mechanisms as specified in this document
AXoT: AXFR-over-TLS AXoT: AXFR-over-TLS
IXoT: IXFR over-TLS IXoT: IXFR over-TLS
3. Use Cases for XFR-over-TLS 3. Use Cases for XFR-over-TLS
o Confidentiality. Clearly using an encrypted transport for zone o Confidentiality. Clearly using an encrypted transport for zone
transfers will defeat zone content leakage that can occur via transfers will defeat zone content leakage that can occur via
skipping to change at page 4, line 52 skipping to change at page 5, line 4
o Authentication. Use of single or mutual TLS authentication (in o Authentication. Use of single or mutual TLS authentication (in
combination with ACLs) can complement and potentially be an combination with ACLs) can complement and potentially be an
alternative to TSIG. alternative to TSIG.
o Performance. Existing AXFR and IXFR mechanisms have the burden of o Performance. Existing AXFR and IXFR mechanisms have the burden of
backwards compatibility with older implementations based on the backwards compatibility with older implementations based on the
original specifications in [RFC1034] and [RFC1035]. For example, original specifications in [RFC1034] and [RFC1035]. For example,
some older AXFR servers don't support using a TCP connection for some older AXFR servers don't support using a TCP connection for
multiple AXFR sessions or XFRs of different zones because they multiple AXFR sessions or XFRs of different zones because they
have not been updated to follow the guidance in [RFC5836]. Any have not been updated to follow the guidance in [RFC5936]. Any
implementation of XFR-over-TLS would obviously be required to implementation of XFR-over-TLS would obviously be required to
implement optimized and interoperable transfers as described in implement optimized and interoperable transfers as described in
[RFC5936] e.g. transfer of multiple zones-over-one connection. [RFC5936] e.g. transfer of multiple zones over one connection.
o Performance. Current usage of TCP for IXFR is sub-optimal in some o Performance. Current usage of TCP for IXFR is sub-optimal in some
cases i.e. connections are frequently closed after a single IXFR. cases i.e. connections are frequently closed after a single IXFR.
4. Connection and Data Flows in Existing XFR Mechanisms 4. Connection and Data Flows in Existing XFR Mechanisms
The original specification for zone transfers in [RFC1034] and The original specification for zone transfers in [RFC1034] and
[RFC1035] was based on a polling mechanism: a secondary performed a [RFC1035] was based on a polling mechanism: a secondary performed a
periodic SOA query (based on the refresh timer) to determine if an periodic SOA query (based on the refresh timer) to determine if an
AXFR was required. AXFR was required.
skipping to change at page 7, line 41 skipping to change at page 7, line 45
connections and SHOULD use [RFC7858] to manage persistent connections and SHOULD use [RFC7858] to manage persistent
connections. connections.
4.3. Data Leakage of NOTIFY and SOA Message Exchanges 4.3. Data Leakage of NOTIFY and SOA Message Exchanges
This section attempts to presents a rationale for also encrypting the This section attempts to presents a rationale for also encrypting the
other messages in the XFR mechanism. other messages in the XFR mechanism.
Since the SOA of the published zone can be trivially discovered by Since the SOA of the published zone can be trivially discovered by
simply querying the publicly available authoritative servers leakage simply querying the publicly available authoritative servers leakage
RR of this is not discussed in the following sections. of this RR is not discussed in the following sections.
4.3.1. NOTIFY 4.3.1. NOTIFY
Unencrypted NOTIFY messages identify configured secondaries on the Unencrypted NOTIFY messages identify configured secondaries on the
primary. primary.
[RFC1996] also states: [RFC1996] also states:
"If ANCOUNT>0, then the answer section represents an unsecure hint at "If ANCOUNT>0, then the answer section represents an unsecure hint at
the new RRset for this . the new RRset for this .
skipping to change at page 8, line 24 skipping to change at page 8, line 27
5.1. Performance Considerations 5.1. Performance Considerations
The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using
persistent connections and TLS Session Resumption [RFC5077] are fully persistent connections and TLS Session Resumption [RFC5077] are fully
applicable to XFR-over-TLS as well. applicable to XFR-over-TLS as well.
It is RECOMMENDED that clients and servers that support XoT also It is RECOMMENDED that clients and servers that support XoT also
implement EDNS0 Keepalive [RFC7828]. implement EDNS0 Keepalive [RFC7828].
5.2. AXoT mechanism It is useful to note that in these mechanisms it is the secondary
that initiates the TLS connection to the primary for a XFR request,
so that in terms of connectivity the secondary is the TLS client and
the primary the TLS server.
5.2. TLS versions
For improved security all implementations of this specification MUST
use only TLS 1.3 [RFC8446] or later.
5.3. AXoT mechanism
The figure below provides an outline of the AXoT mechanism including The figure below provides an outline of the AXoT mechanism including
NOTIFYs. NOTIFYs.
Figure 3: AXoT mechanism [5] Figure 3: AXoT mechanism [5]
The connection for AXFR-over-TLS SHOULD be established using port
853, as specified in [RFC7858], unless there is mutual agreement
between the secondary and primary to use a port other than port 853
for XFR-over-TLS.
All implementations that support XoT MUST fully implement [RFC5953] All implementations that support XoT MUST fully implement [RFC5953]
behavior on TLS connections. behavior on TLS connections.
Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR
clients and servers with regard to re-use of sessions for multiple clients and servers with regard to re-use of sessions for multiple
AXFRs, AXFRs of different zones and using TCP session for other AXFRs, AXFRs of different zones and using TCP session for other
queries including SOA. queries including SOA.
For clarity we restate here that an AXoT client MAY use an already For clarity we restate here that an AXoT client MAY use an already
opened TLS connection to send a AXFR request. Using an existing open opened TLS connection to send a AXFR request. Using an existing open
connection is RECOMMENDED over opening a new connection. (Non-AXoT connection is RECOMMENDED over opening a new connection. (Non-AXoT
session traffic can also use an open connection.) session traffic can also use an open connection.)
For clarity we additionally state here that an AXoT client MAY use an For clarity we additionally state here that an AXoT client MAY use an
already opened TLS connection to send a SOA request. Using an already opened TLS connection to send a SOA request. Using an
existing open connection is RECOMMENDED over opening a new existing open connection is RECOMMENDED over opening a new
connection. connection.
The connection for AXFR-over-TLS SHOULD be established using port
853, as specified in [RFC7858], unless there is mutual agreement
between the secondary and primary to use a port other than port 853
for XFR-over-TLS.
QUESTION: Should there be a requirement that the SOA is always done QUESTION: Should there be a requirement that the SOA is always done
on a TLS connection if the XFR is? For the case when no transfer is on a TLS connection if the XFR is? For the case when no transfer is
required this could be unnecessary overhead. required this could be unnecessary overhead.
5.3. IXoT mechanism 5.4. IXoT mechanism
The figure below provides an outline of the IXoT mechanism including The figure below provides an outline of the IXoT mechanism including
NOTIFYs. NOTIFYs.
Figure 4: IXoT mechanism [6] Figure 4: IXoT mechanism [6]
The connection for IXFR-over-TLS SHOULD be established using port The connection for IXFR-over-TLS SHOULD be established using port
853, as specified in [RFC7858], unless there is mutual agreement 853, as specified in [RFC7858], unless there is mutual agreement
between the secondary and primary to use a port other than port 853 between the secondary and primary to use a port other than port 853
for XFR-over-TLS. for XFR-over-TLS.
skipping to change at page 10, line 5 skipping to change at page 10, line 23
request an appropriate timeout from the server (if the server request an appropriate timeout from the server (if the server
supports EDNS0 Keepalive). If the server does not support EDNS0 supports EDNS0 Keepalive). If the server does not support EDNS0
Keepalive the client MAY keep the connection open for a few seconds Keepalive the client MAY keep the connection open for a few seconds
([RFC7766] recommends that servers use timeouts of at least a few ([RFC7766] recommends that servers use timeouts of at least a few
seconds). seconds).
An IXoT client MAY pipeline IXFR requests for different zones on a An IXoT client MAY pipeline IXFR requests for different zones on a
single TLS connection. AN IXoT server MAY respond to those requests single TLS connection. AN IXoT server MAY respond to those requests
out of order. out of order.
5.3.1. Fallback to AXFR QUESTION: Since this is a new specification should there be a
requirement that IXoT servers are RECOMMENDED to condense responses
as described in Section 6 of [RFC1995]. [RFC1995] document says this
is optional and MAY be done but it can significantly reduce the size
of responses and may have implications for padding?
5.4.1. Fallback to AXFR
Fallback to AXFR can happen, for example, if the server is not able Fallback to AXFR can happen, for example, if the server is not able
to provide an IXFR for the requested SOA. Implementations differ in to provide an IXFR for the requested SOA. Implementations differ in
how long they store zone deltas and how many may be stored at any one how long they store zone deltas and how many may be stored at any one
time. time.
After a failed IXFR a IXoT client SHOULD request the AXFR on the After a failed IXFR a IXoT client SHOULD request the AXFR on the
already open TLS connection. already open TLS connection.
6. Zone Transfer with DoT - Authentication 6. Zone Transfer with DoT - Authentication
skipping to change at page 11, line 17 skipping to change at page 11, line 43
authentication and end-to-end channel confidentiality. authentication and end-to-end channel confidentiality.
6.4. IP Based ACL on the Primary 6.4. IP Based ACL on the Primary
Most DNS server implementations offer an option to configure an IP Most DNS server implementations offer an option to configure an IP
based Access Control List (ACL), which is often used in combination based Access Control List (ACL), which is often used in combination
with TSIG based ACLs to restrict access to zone transfers on primary with TSIG based ACLs to restrict access to zone transfers on primary
servers. servers.
This is also possible with XoT but it must be noted that as with TCP This is also possible with XoT but it must be noted that as with TCP
the implementation of such and ACL cannot be enforced on the primary the implementation of such an ACL cannot be enforced on the primary
until a XFR request is received on an established connection. until a XFR request is received on an established connection.
If control were to be any more fine-grained than this then a separate If control were to be any more fine-grained than this then a
port would be required for XoT such that implementations would be separate, dedicated port would need to be agreed between primary and
able to refuse connections on that port to all clients except those secondary for XoT such that implementations would be able to refuse
configured as secondaries. connections on that port to all clients except those configured as
secondaries.
6.5. ZONEMD 6.5. ZONEMD
Message Digest for DNS Zones (ZONEMD) Message Digest for DNS Zones (ZONEMD)
[I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be [I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be
used to verify the content of a standalone zone. It is designed to used to verify the content of a standalone zone. It is designed to
be independent of the transmission channel or mechanism, allowing a be independent of the transmission channel or mechanism, allowing a
general consumer of a zone to do origin authentication of the entire general consumer of a zone to do origin authentication of the entire
zone contents. Note that the current version of zone contents. Note that the current version of
[I-D.ietf-dnsop-dns-zone-digest] states: [I-D.ietf-dnsop-dns-zone-digest] states:
skipping to change at page 14, line 37 skipping to change at page 15, line 16
TBD TBD
12. Security Considerations 12. Security Considerations
This document specifies a security measure against a DNS risk: the This document specifies a security measure against a DNS risk: the
risk that an attacker collects entire DNS zones through eavesdropping risk that an attacker collects entire DNS zones through eavesdropping
on clear text DNS zone transfers. It presents a new Security on clear text DNS zone transfers. It presents a new Security
Consideration for DNS. Some questions to discuss are: Consideration for DNS. Some questions to discuss are:
o Should DoT in this new case be required to use only TLS 1.3 and
higher to avoid residual exposure?
o How should padding be used in IXFR? o How should padding be used in IXFR?
o Should there be an option to 'pad' an AXFR response (i.e. a set of o Should there be an option to 'pad' an AXFR response (i.e. a set of
AXFR responses on a given connection) to hide the zone size? AXFR responses on a given connection) to hide the zone size?
13. Acknowledgements 13. Acknowledgements
The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for
review and discussions. review and discussions.
14. Changelog 14. Changelog
draft-ietf-dprive-xfr-over-tls-00 draft-ietf-dprive-xfr-over-tls-00
o Minor editorial updates
o Add requirement for TLS 1.3. or later
draft-ietf-dprive-xfr-over-tls-00
o Rename after adoption and reference update. o Rename after adoption and reference update.
o Add placeholder for SIG(0) discussion o Add placeholder for SIG(0) discussion
o Update section on ZONEMD o Update section on ZONEMD
draft-hzpa-dprive-xfr-over-tls-02 draft-hzpa-dprive-xfr-over-tls-02
o Substantial re-work of the document. o Substantial re-work of the document.
skipping to change at page 15, line 33 skipping to change at page 16, line 11
draft-hzpa-dprive-xfr-over-tls-00 draft-hzpa-dprive-xfr-over-tls-00
o Initial commit o Initial commit
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-dprive-rfc7626-bis] [I-D.ietf-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in Considerations", draft-ietf-dprive-rfc7626-bis-05 (work in
progress), October 2019. progress), May 2020.
[I-D.vcelak-nsec5] [I-D.vcelak-nsec5]
Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and
D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of
Existence", draft-vcelak-nsec5-08 (work in progress), Existence", draft-vcelak-nsec5-08 (work in progress),
December 2018. December 2018.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, <https://www.rfc- DOI 10.17487/RFC1995, August 1996, <https://www.rfc-
editor.org/info/rfc1995>. editor.org/info/rfc1995>.
skipping to change at page 17, line 10 skipping to change at page 17, line 32
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-dnsop-dns-zone-digest] [I-D.ietf-dnsop-dns-zone-digest]
Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
Hardaker, "Message Digest for DNS Zones", draft-ietf- Hardaker, "Message Digest for DNS Zones", draft-ietf-
dnsop-dns-zone-digest-02 (work in progress), October 2019. dnsop-dns-zone-digest-07 (work in progress), April 2020.
[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>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
 End of changes. 26 change blocks. 
48 lines changed or deleted 66 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/