1 Internet Engineering Task Force (IETF) W. Toorop
2 Request for Comments: 9103 NLnet Labs
3 Updates: 1995, 5936, 7766 S. Dickinson
4 Category: Standards Track Sinodun IT
5 ISSN: 2070-1721 S. Sahib
6 Brave Software
7 P. Aras
8 A. Mankin
9 Salesforce
10 August 2021
11
12
13 DNS Zone Transfer over TLS
14
15 Abstract
16
17 DNS zone transfers are transmitted in cleartext, which gives
18 attackers the opportunity to collect the content of a zone by
19 eavesdropping on network connections. The DNS Transaction Signature
20 (TSIG) mechanism is specified to restrict direct zone transfer to
21 authorized clients only, but it does not add confidentiality. This
22 document specifies the use of TLS, rather than cleartext, to prevent
23 zone content collection via passive monitoring of zone transfers: XFR
24 over TLS (XoT). Additionally, this specification updates RFC 1995
25 and RFC 5936 with respect to efficient use of TCP connections and RFC
26 7766 with respect to the recommended number of connections between a
27 client and server for each transport.
28
29 Status of This Memo
30
31 This is an Internet Standards Track document.
32
33 This document is a product of the Internet Engineering Task Force
34 (IETF). It represents the consensus of the IETF community. It has
35 received public review and has been approved for publication by the
36 Internet Engineering Steering Group (IESG). Further information on
37 Internet Standards is available in Section 2 of RFC 7841.
38
39 Information about the current status of this document, any errata,
40 and how to provide feedback on it may be obtained at
41 https://www.rfc-editor.org/info/rfc9103.
42
43 Copyright Notice
44
45 Copyright (c) 2021 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
47
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (https://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
57
58 Table of Contents
59
60 1. Introduction
61 2. Terminology
62 3. Threat Model
63 4. Design Considerations for XoT
64 5. Connection and Data Flows in Existing XFR Mechanisms
65 5.1. AXFR Mechanism
66 5.2. IXFR Mechanism
67 5.3. Data Leakage of NOTIFY and SOA Message Exchanges
68 5.3.1. NOTIFY
69 5.3.2. SOA
70 6. Updates to Existing Specifications
71 6.1. Update to RFC 1995 for IXFR over TCP
72 6.2. Update to RFC 5936 for AXFR over TCP
73 6.3. Updates to RFCs 1995 and 5936 for XFR over TCP
74 6.3.1. Connection Reuse
75 6.3.2. AXFRs and IXFRs on the Same Connection
76 6.3.3. XFR Limits
77 6.3.4. The edns-tcp-keepalive EDNS(0) Option
78 6.3.5. Backwards Compatibility
79 6.4. Update to RFC 7766
80 7. XoT Specification
81 7.1. Connection Establishment
82 7.2. TLS Versions
83 7.3. Port Selection
84 7.4. High-Level XoT Descriptions
85 7.5. XoT Transfers
86 7.6. XoT Connections
87 7.7. XoT vs. ADoT
88 7.8. Response RCODES
89 7.9. AXoT Specifics
90 7.9.1. Padding AXoT Responses
91 7.10. IXoT Specifics
92 7.10.1. Condensation of Responses
93 7.10.2. Fallback to AXFR
94 7.10.3. Padding of IXoT Responses
95 7.11. Name Compression and Maximum Payload Sizes
96 8. Multi-primary Configurations
97 9. Authentication Mechanisms
98 9.1. TSIG
99 9.2. SIG(0)
100 9.3. TLS
101 9.3.1. Opportunistic TLS
102 9.3.2. Strict TLS
103 9.3.3. Mutual TLS
104 9.4. IP-Based ACL on the Primary
105 9.5. ZONEMD
106 10. XoT Authentication
107 11. Policies for Both AXoT and IXoT
108 12. Implementation Considerations
109 13. Operational Considerations
110 14. IANA Considerations
111 15. Security Considerations
112 16. References
113 16.1. Normative References
114 16.2. Informative References
115 Appendix A. XoT Server Connection Handling
116 A.1. Listening Only on a Specific IP Address for TLS
117 A.2. Client-Specific TLS Acceptance
118 A.3. SNI-Based TLS Acceptance
119 A.4. Transport-Specific Response Policies
120 A.4.1. SNI-Based Response Policies
121 Acknowledgements
122 Contributors
123 Authors' Addresses
124
125 1. Introduction
126
127 DNS has a number of privacy vulnerabilities, as discussed in detail
128 in [RFC9076]. Query privacy between stub resolvers and recursive
129 resolvers has received the most attention to date, with Standards
130 Track documents for both DNS over TLS (DoT) [RFC7858] and DNS over
131 HTTPS (DoH) [RFC8484] and a proposal for DNS over QUIC
132 [DPRIVE-DNSOQUIC]. There is ongoing work on DNS privacy requirements
133 for exchanges between recursive resolvers and authoritative servers
134 and some suggestions for how signaling of DoT support by
135 authoritative name servers might work. However, there is currently
136 no RFC that specifically defines recursive-to-authoritative DNS over
137 TLS (ADoT).
138
139 [RFC9076] establishes that a stub resolver's DNS query transactions
140 are not public and that they need protection, but, on zone transfer
141 [RFC1995] [RFC5936], it says only:
142
143 | Privacy risks for the holder of a zone (the risk that someone gets
144 | the data) are discussed in [RFC5155] and [RFC5936].
145
146 In what way is exposing the full contents of a zone a privacy risk?
147 The contents of the zone could include information such as names of
148 persons used in names of hosts. Best practice is not to use personal
149 information for domain names, but many such domain names exist. The
150 contents of the zone could also include references to locations that
151 allow inference about location information of the individuals
152 associated with the zone's organization. It could also include
153 references to other organizations. Examples of this could be:
154
155 * Person-laptop.example.org
156
157 * MX-for-Location.example.org
158
159 * Service-tenant-from-another-org.example.org
160
161 Additionally, the full zone contents expose all the IP addresses of
162 endpoints held in the DNS records, which can make reconnaissance and
163 attack targeting easier, particularly for IPv6 addresses or private
164 networks. There may also be regulatory, policy, or other reasons why
165 the zone contents in full must be treated as private.
166
167 Neither of the RFCs mentioned in [RFC9076] contemplate the risk that
168 someone gets the data through eavesdropping on network connections,
169 only via enumeration or unauthorized transfer, as described in the
170 following paragraphs.
171
172 Zone enumeration is trivially possible for DNSSEC zones that use
173 NSEC, i.e., queries for the authenticated denial-of-existence records
174 allow a client to walk through the entire zone contents. [RFC5155]
175 specifies NSEC3, a mechanism to provide measures against zone
176 enumeration for DNSSEC-signed zones (a goal was to make it as hard to
177 enumerate a DNSSEC-signed zone as an unsigned zone). Whilst this is
178 widely used, it has been demonstrated that zone walking is possible
179 for precomputed NSEC3 using attacks, such as those described in
180 [NSEC3-attacks]. This prompted further work on an alternative
181 mechanism for DNSSEC-authenticated denial of existence (NSEC5
182 [NSEC5]); however, questions remain over the practicality of this
183 mechanism.
184
185 [RFC5155] does not address data obtained outside zone enumeration
186 (nor does [NSEC5]). Preventing eavesdropping of zone transfers (as
187 described in this document) is orthogonal to preventing zone
188 enumeration, though they aim to protect the same information.
189
190 [RFC5936] specifies using TSIG [RFC8945] for authorization of the
191 clients of a zone transfer and for data integrity but does not
192 express any need for confidentiality, and TSIG does not offer
193 encryption.
194
195 Section 8 of the NIST document "Secure Domain Name System (DNS)
196 Deployment Guide" [NIST-GUIDE] discusses restricting access for zone
197 transfers using Access Control Lists (ACLs) and TSIG in more detail.
198 It also discusses the possibility that specific deployments might
199 choose to use a lower-level network layer to protect zone transfers,
200 e.g., IPsec.
201
202 It is noted that in all the common open-source implementations such
203 ACLs are applied on a per-query basis (at the time of writing).
204 Since requests typically occur on TCP connections, authoritative
205 servers must therefore accept any TCP connection and then handle the
206 authentication of each zone transfer (XFR) request individually.
207
208 Because both AXFR (authoritative transfer) and IXFR (incremental zone
209 transfer) are typically carried out over TCP from authoritative DNS
210 protocol implementations, encrypting zone transfers using TLS
211 [RFC8499] -- based closely on DoT [RFC7858] -- seems like a simple
212 step forward. This document specifies how to use TLS (1.3 or later)
213 as a transport to prevent zone collection from zone transfers.
214
215 This document also updates the previous specifications for zone
216 transfers to clarify and extend them, mainly with respect to TCP
217 usage:
218
219 * [RFC1995] (IXFR) and [RFC5936] (AXFR) are both updated to add
220 further specification on efficient use of TCP connections.
221
222 * Section 6.2.2 of [RFC7766] ("DNS Transport over TCP -
223 Implementation Requirements") is updated with a new recommendation
224 about the number of connections between a client and server for
225 each transport.
226
227 2. Terminology
228
229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
231 "OPTIONAL" in this document are to be interpreted as described in BCP
232 14 [RFC2119] [RFC8174] when, and only when, they appear in all
233 capitals, as shown here.
234
235 Privacy terminology is as described in Section 3 of [RFC6973].
236
237 DNS terminology is as described in [RFC8499]. Note that, as in
238 [RFC8499], the terms 'primary' and 'secondary' are used for two
239 servers engaged in zone transfers.
240
241 DoT: DNS over TLS, as specified in [RFC7858]
242
243 XFR over TCP: Used to mean both IXFR over TCP [RFC1995] and AXFR
244 over TCP [RFC5936]
245
246 XoT: XFR-over-TLS mechanisms, as specified in this document, which
247 apply to both AXFR over TLS and IXFR over TLS (XoT is
248 pronounced 'zot' since X here stands for 'zone transfer')
249
250 AXoT: AXFR over TLS
251
252 IXoT: IXFR over TLS
253
254 3. Threat Model
255
256 The threat model considered here is one where the current contents
257 and size of the zone are considered sensitive and should be protected
258 during transfer.
259
260 The threat model does not, however, consider the existence of a zone,
261 the act of zone transfer between two entities, nor the identities of
262 the name servers hosting a zone (including both those acting as
263 hidden primaries/secondaries or directly serving the zone) as
264 sensitive information. The proposed mechanism does not attempt to
265 obscure such information. The reasons for this include:
266
267 * much of this information can be obtained by various methods,
268 including active scanning of the DNS, and
269
270 * an attacker who can monitor network traffic can rather easily
271 infer relations between name servers simply from traffic patterns,
272 even when some or all of the traffic is encrypted (in terms of
273 current deployments).
274
275 The model does not consider attacks on the mechanisms that trigger a
276 zone transfer, e.g., NOTIFY messages.
277
278 It is noted that simply using XoT will indicate a desire by the zone
279 owner that the contents of the zone remain confidential and so could
280 be subject to blocking (e.g., via blocking of port 853) if an
281 attacker had such capabilities. However, this threat is likely true
282 of any such mechanism that attempts to encrypt data passed between
283 name servers, e.g., IPsec.
284
285 4. Design Considerations for XoT
286
287 The following principles were considered in the design for XoT:
288
289 Confidentiality: Clearly using an encrypted transport for zone
290 transfers will defeat zone content leakage that can occur via
291 passive surveillance.
292
293 Authentication: Use of single or mutual TLS (mTLS) authentication
294 (in combination with ACLs) can complement and potentially be an
295 alternative to TSIG.
296
297 Performance:
298 * Existing AXFR and IXFR mechanisms have the burden of backwards
299 compatibility with older implementations based on the original
300 specifications in [RFC1034] and [RFC1035]. For example, some
301 older AXFR servers don't support using a TCP connection for
302 multiple AXFR sessions or XFRs of different zones because they
303 have not been updated to follow the guidance in [RFC5936]. Any
304 implementation of XoT would obviously be required to implement
305 optimized and interoperable transfers, as described in
306 [RFC5936], e.g., transfer of multiple zones over one
307 connection.
308
309 * Current usage of TCP for IXFR is suboptimal in some cases,
310 i.e., connections are frequently closed after a single IXFR.
311
312 5. Connection and Data Flows in Existing XFR Mechanisms
313
314 The original specification for zone transfers in [RFC1034] and
315 [RFC1035] was based on a polling mechanism: a secondary performed a
316 periodic query for the SOA (start of zone authority) record (based on
317 the refresh timer) to determine if an AXFR was required.
318
319 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY,
320 respectively, to provide for prompt propagation of zone updates.
321 This has largely replaced AXFR where possible, particularly for
322 dynamically updated zones.
323
324 [RFC5936] subsequently redefined the specification of AXFR to improve
325 performance and interoperability.
326
327 In this document, the term 'XFR mechanism' is used to describe the
328 entire set of message exchanges between a secondary and a primary
329 that concludes with a successful AXFR or IXFR request/response. This
330 set may or may not include:
331
332 * NOTIFY messages
333
334 * SOA queries
335
336 * Fallback from IXFR to AXFR
337
338 * Fallback from IXFR over UDP to IXFR over TCP
339
340 The term is used to encompass the range of permutations that are
341 possible and is useful to distinguish the 'XFR mechanism' from a
342 single XFR request/response exchange.
343
344 5.1. AXFR Mechanism
345
346 The figure below provides an outline of an AXFR mechanism including
347 NOTIFYs.
348
349 Secondary Primary
350
351 | NOTIFY |
352 | <-------------------------------- | UDP
353 | --------------------------------> |
354 | NOTIFY Response |
355 | |
356 | |
357 | SOA Request |
358 | --------------------------------> | UDP (or part of
359 | <-------------------------------- | a TCP session)
360 | SOA Response |
361 | |
362 | |
363 | |
364 | AXFR Request | ---
365 | --------------------------------> | |
366 | <-------------------------------- | |
367 | AXFR Response 1 | |
368 | (Zone data) | |
369 | | |
370 | <-------------------------------- | | TCP
371 | AXFR Response 2 | | Session
372 | (Zone data) | |
373 | | |
374 | <-------------------------------- | |
375 | AXFR Response 3 | |
376 | (Zone data) | ---
377 | |
378
379 Figure 1: AXFR Mechanism
380
381 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP)
382 from the primary to the secondary. A secondary may also initiate
383 an AXFR based on a refresh timer or scheduled/triggered zone
384 maintenance.
385
386 2. The secondary will normally (but not always) make an SOA query to
387 the primary to obtain the serial number of the zone held by the
388 primary.
389
390 3. If the primary serial is higher than the secondary's serial
391 (using Serial Number Arithmetic [RFC1982]), the secondary makes
392 an AXFR request (over TCP) to the primary, after which the AXFR
393 data flows in one or more AXFR responses on the TCP connection.
394 [RFC5936] defines this specific step as an 'AXFR session', i.e.,
395 as an AXFR query message and the sequence of AXFR response
396 messages returned for it.
397
398 [RFC5936] re-specified AXFR, providing additional guidance beyond
399 that provided in [RFC1034] and [RFC1035] and importantly specified
400 that AXFR must use TCP as the transport protocol.
401
402 Additionally, Sections 4.1, 4.1.1, and 4.1.2 of [RFC5936] provide
403 improved guidance for AXFR clients and servers with regard to reuse
404 of TCP connections for multiple AXFRs and AXFRs of different zones.
405 However, [RFC5936] was constrained by having to be backwards
406 compatible with some very early basic implementations of AXFR. For
407 example, it outlines that the SOA query can also happen on this
408 connection. However, this can cause interoperability problems with
409 older implementations that support only the trivial case of one AXFR
410 per connection.
411
412 5.2. IXFR Mechanism
413
414 The figure below provides an outline of the IXFR mechanism including
415 NOTIFYs.
416
417 Secondary Primary
418
419 | NOTIFY |
420 | <-------------------------------- | UDP
421 | --------------------------------> |
422 | NOTIFY Response |
423 | |
424 | |
425 | SOA Request |
426 | --------------------------------> | UDP or TCP
427 | <-------------------------------- |
428 | SOA Response |
429 | |
430 | |
431 | |
432 | IXFR Request |
433 | --------------------------------> | UDP or TCP
434 | <-------------------------------- |
435 | IXFR Response |
436 | (Zone data) |
437 | |
438 | | ---
439 | IXFR Request | |
440 | --------------------------------> | | Retry over
441 | <-------------------------------- | | TCP if
442 | IXFR Response | | required
443 | (Zone data) | ---
444
445 Figure 2: IXFR Mechanism
446
447 1. An IXFR is normally (but not always) preceded by a NOTIFY (over
448 UDP) from the primary to the secondary. A secondary may also
449 initiate an IXFR based on a refresh timer or scheduled/triggered
450 zone maintenance.
451
452 2. The secondary will normally (but not always) make an SOA query to
453 the primary to obtain the serial number of the zone held by the
454 primary.
455
456 3. If the primary serial is higher than the secondary's serial
457 (using Serial Number Arithmetic [RFC1982]), the secondary makes
458 an IXFR request to the primary, after which the primary sends an
459 IXFR response.
460
461 [RFC1995] specifies that IXFR may use UDP if the entire IXFR response
462 can be contained in a single DNS packet, otherwise, TCP is used. In
463 fact, it says:
464
465 | Thus, a client should first make an IXFR query using UDP.
466
467 So there may be a fourth step above where the client falls back to
468 IXFR over TCP. There may also be an additional step where the
469 secondary must fall back to AXFR because, e.g., the primary does not
470 support IXFR.
471
472 However, it is noted that most of the widely used open-source
473 implementations of authoritative name servers (including both [BIND]
474 and [NSD]) do IXFR using TCP by default in their latest releases.
475 For BIND, TCP connections are sometimes used for SOA queries, but, in
476 general, they are not used persistently and are closed after an IXFR
477 is completed.
478
479 5.3. Data Leakage of NOTIFY and SOA Message Exchanges
480
481 This section presents a rationale for considering the encryption of
482 the other messages in the XFR mechanism.
483
484 Since the SOA of the published zone can be trivially discovered by
485 simply querying the publicly available authoritative servers, leakage
486 of this resource record (RR) via such a direct query is not discussed
487 in the following sections.
488
489 5.3.1. NOTIFY
490
491 Unencrypted NOTIFY messages identify configured secondaries on the
492 primary.
493
494 [RFC1996] also states:
495
496 | If ANCOUNT>0, then the answer section represents an unsecure hint
497 | at the new RRset for this <QNAME,QCLASS,QTYPE>.
498
499 But since the only query type (QTYPE) for NOTIFY defined at the time
500 of this writing is SOA, this does not pose a potential leak.
501
502 5.3.2. SOA
503
504 For hidden XFR servers (either primaries or secondaries), an SOA
505 response directly from that server only additionally leaks the degree
506 of SOA serial number lag of any downstream secondary of that server.
507
508 6. Updates to Existing Specifications
509
510 For convenience, the term 'XFR over TCP' is used in this document to
511 mean both IXFR over TCP and AXFR over TCP; therefore, statements that
512 use that term update both [RFC1995] and [RFC5936] and implicitly also
513 apply to XoT. Differences in behavior specific to XoT are discussed
514 in Section 7.
515
516 Both [RFC1995] and [RFC5936] were published sometime before TCP
517 became a widely supported transport for DNS. [RFC1995], in fact,
518 says nothing with respect to optimizing IXFRs over TCP or reusing
519 already open TCP connections to perform IXFRs or other queries.
520 Therefore, there arguably is an implicit assumption that a TCP
521 connection is used for one and only one IXFR request. Indeed, many
522 major open-source implementations take this approach (at the time of
523 this writing). And whilst [RFC5936] gives guidance on connection
524 reuse for AXFR, it predates more recent specifications describing
525 persistent TCP connections (e.g., [RFC7766], [RFC7828]), and AXFR
526 implementations again often make less-than-optimal use of open
527 connections.
528
529 Given this, new implementations of XoT will clearly benefit from
530 specific guidance on TCP/TLS connection usage for XFR, because this
531 will:
532
533 * result in more consistent XoT implementations with better
534 interoperability and
535
536 * remove any need for XoT implementations to support legacy behavior
537 for XoT connections that XFR-over-TCP implementations have
538 historically often supported.
539
540 Therefore, this document updates both the previous specifications for
541 XFR over TCP ([RFC1995] and [RFC5936]) to clarify that:
542
543 * Implementations MUST use [RFC7766] ("DNS Transport over TCP -
544 Implementation Requirements") to optimize the use of TCP
545 connections.
546
547 * Whilst [RFC7766] states that "DNS clients SHOULD pipeline their
548 queries" on TCP connections, it did not distinguish between XFRs
549 and other queries for this behavior. It is now recognized that
550 XFRs are not as latency sensitive as other queries and can be
551 significantly more complex for clients to handle, both because of
552 the large amount of state that must be kept and because there may
553 be multiple messages in the responses. For these reasons, it is
554 clarified here that a valid reason for not pipelining queries is
555 when they are all XFR queries, i.e., clients sending multiple XFRs
556 MAY choose not to pipeline those queries. Clients that do not
557 pipeline XFR queries therefore have no additional requirements to
558 handle out-of-order or intermingled responses (as described
559 later), since they will never receive them.
560
561 * Implementations SHOULD use the edns-tcp-keepalive EDNS(0) option
562 [RFC7828] to manage persistent connections. This is more flexible
563 than the alternative of simply using fixed timeouts.
564
565 The following sections include detailed clarifications on the updates
566 to XFR behavior implied in [RFC7766] and how the use of [RFC7828]
567 applies specifically to XFR exchanges. They also discuss how IXFR
568 and AXFR can reuse the same TCP connection.
569
570 For completeness, the recent specification of extended DNS error
571 (EDE) codes [RFC8914] is also mentioned here. For zone transfers,
572 when returning REFUSED to a zone transfer request from an
573 'unauthorized' client (e.g., where the client is not listed in an ACL
574 for zone transfers or does not sign the request with a valid TSIG
575 key), the extended DNS error code 18 - Prohibited can also be sent.
576
577 6.1. Update to RFC 1995 for IXFR over TCP
578
579 For clarity, an IXFR-over-TCP server compliant with this
580 specification MUST be able to handle multiple concurrent IXoT
581 requests on a single TCP connection (for the same and different
582 zones) and SHOULD send the responses as soon as they are available,
583 which might be out of order compared to the requests.
584
585 6.2. Update to RFC 5936 for AXFR over TCP
586
587 For clarity, an AXFR-over-TCP server compliant with this
588 specification MUST be able to handle multiple concurrent AXoT
589 sessions on a single TCP connection (for the same and different
590 zones). The response streams for concurrent AXFRs MAY be
591 intermingled, and AXFR-over-TCP clients compliant with this
592 specification, which pipeline AXFR requests, MUST be able to handle
593 this.
594
595 6.3. Updates to RFCs 1995 and 5936 for XFR over TCP
596
597 6.3.1. Connection Reuse
598
599 As specified, XFR-over-TCP clients SHOULD reuse any existing open TCP
600 connection when starting any new XFR request to the same primary, and
601 for issuing SOA queries, instead of opening a new connection. The
602 number of TCP connections between a secondary and primary SHOULD be
603 minimized (also see Section 6.4).
604
605 Valid reasons for not reusing existing connections might include:
606
607 * As already noted in [RFC7766], separate connections for different
608 zones might be preferred for operational reasons. In this case,
609 the number of concurrent connections for zone transfers SHOULD be
610 limited to the total number of zones transferred between the
611 client and server.
612
613 * A configured limit for the number of outstanding queries or XFR
614 requests allowed on a single TCP connection has been reached.
615
616 * The message ID pool has already been exhausted on an open
617 connection.
618
619 * A large number of timeouts or slow responses have occurred on an
620 open connection.
621
622 * An edns-tcp-keepalive EDNS(0) option with a timeout of 0 has been
623 received from the server, and the client is in the process of
624 closing the connection (see Section 6.3.4).
625
626 If no TCP connections are currently open, XFR clients MAY send SOA
627 queries over UDP or a new TCP connection.
628
629 6.3.2. AXFRs and IXFRs on the Same Connection
630
631 Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a
632 single TCP connection for both IXFR and AXFR requests. [RFC5936]
633 does make the general statement:
634
635 | Non-AXFR session traffic can also use an open connection.
636
637 In this document, the above is clarified to indicate that
638 implementations capable of both AXFR and IXFR and compliant with this
639 specification SHOULD:
640
641 * use the same TCP connection for both AXFR and IXFR requests to the
642 same primary,
643
644 * pipeline such requests (if they pipeline XFR requests in general)
645 and MAY intermingle them, and
646
647 * send the response(s) for each request as soon as they are
648 available, i.e., responses MAY be sent intermingled.
649
650 For some current implementations, adding all the above functionality
651 would introduce significant code complexity. In such a case, there
652 will need to be an assessment of the trade-off between that and the
653 performance benefits of the above for XFR.
654
655 6.3.3. XFR Limits
656
657 The server MAY limit the number of concurrent IXFRs, AXFRs, or total
658 XFR transfers in progress (or from a given secondary) to protect
659 server resources. Servers SHOULD return SERVFAIL if this limit is
660 hit, since it is a transient error and a retry at a later time might
661 succeed (there is no previous specification for this behavior).
662
663 6.3.4. The edns-tcp-keepalive EDNS(0) Option
664
665 XFR clients that send the edns-tcp-keepalive EDNS(0) option on every
666 XFR request provide the server with maximum opportunity to update the
667 edns-tcp-keepalive timeout. The XFR server may use the frequency of
668 recent XFRs to calculate an average update rate as input to the
669 decision of what edns-tcp-keepalive timeout to use. If the server
670 does not support edns-tcp-keepalive, the client MAY keep the
671 connection open for a few seconds ([RFC7766] recommends that servers
672 use timeouts of at least a few seconds).
673
674 Whilst the specification for EDNS(0) [RFC6891] does not specifically
675 mention AXFRs, it does say:
676
677 | If an OPT record is present in a received request, compliant
678 | responders MUST include an OPT record in their respective
679 | responses.
680
681 In this document, the above is clarified to indicate that if an OPT
682 record is present in a received AXFR request, compliant responders
683 MUST include an OPT record in each of the subsequent AXFR responses.
684 Note that this requirement, combined with the use of edns-tcp-
685 keepalive, enables AXFR servers to signal the desire to close a
686 connection (when existing transactions have competed) due to low
687 resources by sending an edns-tcp-keepalive EDNS(0) option with a
688 timeout of 0 on any AXFR response. This does not signal that the
689 AXFR is aborted, just that the server wishes to close the connection
690 as soon as possible.
691
692 6.3.5. Backwards Compatibility
693
694 Certain legacy behaviors were noted in [RFC5936], with provisions
695 that implementations may want to offer options to fallback to legacy
696 behavior when interoperating with servers known to not support
697 [RFC5936]. For purposes of interoperability, IXFR and AXFR
698 implementations may want to continue offering such configuration
699 options, as well as supporting some behaviors that were
700 underspecified prior to this work (e.g., performing IXFR and AXFRs on
701 separate connections). However, XoT connections should have no need
702 to do so.
703
704 6.4. Update to RFC 7766
705
706 [RFC7766] made general implementation recommendations with regard to
707 TCP/TLS connection handling:
708
709 | To mitigate the risk of unintentional server overload, DNS clients
710 | MUST take care to minimize the number of concurrent TCP
711 | connections made to any individual server. It is RECOMMENDED that
712 | for any given client/server interaction there SHOULD be no more
713 | than one connection for regular queries, one for zone transfers,
714 | and one for each protocol that is being used on top of TCP (for
715 | example, if the resolver was using TLS). However, it is noted
716 | that certain primary/ secondary configurations with many busy
717 | zones might need to use more than one TCP connection for zone
718 | transfers for operational reasons (for example, to support
719 | concurrent transfers of multiple zones).
720
721 Whilst this recommends a particular behavior for the clients using
722 TCP, it does not relax the requirement for servers to handle 'mixed'
723 traffic (regular queries and zone transfers) on any open TCP/TLS
724 connection. It also overlooks the potential that other transports
725 might want to take the same approach with regard to using separate
726 connections for different purposes.
727
728 This specification updates the above general guidance in [RFC7766] to
729 provide the same separation of connection purpose (regular queries
730 and zone transfers) for all transports being used on top of TCP.
731
732 Therefore, it is RECOMMENDED that for each protocol used on top of
733 TCP in any given client/server interaction there SHOULD be no more
734 than one connection for regular queries and one for zone transfers.
735
736 As an illustration, it could be imagined that in the future such an
737 interaction could hypothetically include one or all of the following:
738
739 * one TCP connection for regular queries
740
741 * one TCP connection for zone transfers
742
743 * one TLS connection for regular queries
744
745 * one TLS connection for zone transfers
746
747 * one DoH connection for regular queries
748
749 * one DoH connection for zone transfers
750
751 Section 6.3.1 provides specific details of the reasons why more than
752 one connection for a given transport might be required for zone
753 transfers from a particular client.
754
755 7. XoT Specification
756
757 7.1. Connection Establishment
758
759 During connection establishment, the Application-Layer Protocol
760 Negotiation (ALPN) token "dot" [DoT-ALPN] MUST be selected in the TLS
761 handshake.
762
763 7.2. TLS Versions
764
765 All implementations of this specification MUST use only TLS 1.3
766 [RFC8446] or later.
767
768 7.3. Port Selection
769
770 The connection for XoT SHOULD be established using port 853, as
771 specified in [RFC7858], unless there is mutual agreement between the
772 primary and secondary to use a port other than port 853 for XoT.
773 There MAY be agreement to use different ports for AXoT and IXoT or
774 for different zones.
775
776 7.4. High-Level XoT Descriptions
777
778 It is useful to note that in XoT it is the secondary that initiates
779 the TLS connection to the primary for an XFR request so that, in
780 terms of connectivity, the secondary is the TLS client and the
781 primary is the TLS server.
782
783 The figure below provides an outline of the AXoT mechanism including
784 NOTIFYs.
785
786 Secondary Primary
787
788 | NOTIFY |
789 | <-------------------------------- | UDP
790 | --------------------------------> |
791 | NOTIFY Response |
792 | |
793 | |
794 | SOA Request |
795 | --------------------------------> | UDP (or part of
796 | <-------------------------------- | a TCP/TLS session)
797 | SOA Response |
798 | |
799 | |
800 | |
801 | AXFR Request | ---
802 | --------------------------------> | |
803 | <-------------------------------- | |
804 | AXFR Response 1 | |
805 | (Zone data) | |
806 | | |
807 | <-------------------------------- | | TLS
808 | AXFR Response 2 | | Session
809 | (Zone data) | |
810 | | |
811 | <-------------------------------- | |
812 | AXFR Response 3 | |
813 | (Zone data) | ---
814 | |
815
816 Figure 3: AXoT Mechanism
817
818 The figure below provides an outline of the IXoT mechanism including
819 NOTIFYs.
820
821 Secondary Primary
822
823 | NOTIFY |
824 | <-------------------------------- | UDP
825 | --------------------------------> |
826 | NOTIFY Response |
827 | |
828 | |
829 | SOA Request |
830 | --------------------------------> | UDP (or part of
831 | <-------------------------------- | a TCP/TLS session)
832 | SOA Response |
833 | |
834 | |
835 | |
836 | IXFR Request | ---
837 | --------------------------------> | |
838 | <-------------------------------- | |
839 | IXFR Response | |
840 | (Zone data) | |
841 | | | TLS
842 | | | session
843 | IXFR Request | |
844 | --------------------------------> | |
845 | <-------------------------------- | |
846 | IXFR Response | |
847 | (Zone data) | ---
848
849 Figure 4: IXoT Mechanism
850
851 7.5. XoT Transfers
852
853 For a zone transfer between two endpoints to be considered protected
854 with XoT, all XFR requests and responses for that zone MUST be sent
855 over TLS connections, where at a minimum:
856
857 * The client MUST authenticate the server by use of an
858 authentication domain name using a Strict Privacy profile, as
859 described in [RFC8310].
860
861 * The server MUST validate the client is authorized to request or
862 proxy a zone transfer by using one or both of the following
863 methods:
864
865 - mutual TLS (mTLS)
866
867 - an IP-based ACL (which can be either per message or per
868 connection) combined with a valid TSIG/SIG(0) signature on the
869 XFR request
870
871 If only one method is selected, then mTLS is preferred because it
872 provides strong cryptographic protection at both endpoints.
873
874 Authentication mechanisms are discussed in full in Section 9, and the
875 rationale for the above requirement is discussed in Section 10.
876 Transfer group policies are discussed in Section 11.
877
878 7.6. XoT Connections
879
880 The details in Section 6 about, e.g., persistent connections and XFR
881 message handling, are fully applicable to XoT connections as well.
882 However, any behavior specified here takes precedence for XoT.
883
884 If no TLS connections are currently open, XoT clients MAY send SOA
885 queries over UDP, TCP, or TLS.
886
887 7.7. XoT vs. ADoT
888
889 As noted earlier, there is currently no specification for encryption
890 of connections from recursive resolvers to authoritative servers.
891 Some authoritative servers are experimenting with ADoT, and
892 opportunistic encryption has also been raised as a possibility;
893 therefore, it is highly likely that use of encryption by
894 authoritative servers will evolve in the coming years.
895
896 This raises questions in the short term with regard to TLS connection
897 and message handling for authoritative servers. In particular, there
898 is likely to be a class of authoritative servers that wish to use XoT
899 in the near future with a small number of configured secondaries but
900 that do not wish to support DoT for regular queries from recursives
901 in that same time frame. These servers have to potentially cope with
902 probing and direct queries from recursives and from test servers and
903 also potential attacks that might wish to make use of TLS to overload
904 the server.
905
906 [RFC5936] clearly states that non-AXFR session traffic can use an
907 open connection; however, this requirement needs to be reevaluated
908 when considering the application of the same model to XoT. Proposing
909 that a server should also start responding to all queries received
910 over TLS just because it has enabled XoT would be equivalent to
911 defining a form of authoritative DoT. This specification does not
912 propose that, but it also does not prohibit servers from answering
913 queries unrelated to XFR exchanges over TLS. Rather, this
914 specification simply outlines in later sections:
915
916 * the utilization of EDE codes by XoT servers in response to queries
917 on TLS connections that they are not willing to answer (see
918 Section 7.8)
919
920 * the operational and policy options that an operator of a XoT
921 server has with regard to managing TLS connections and messages
922 (see Appendix A)
923
924 7.8. Response RCODES
925
926 XoT clients and servers MUST implement EDE codes. If a XoT server
927 receives non-XoT traffic it is not willing to answer on a TLS
928 connection, it SHOULD respond with REFUSED and the extended DNS error
929 code 21 - Not Supported [RFC8914]. XoT clients should not send any
930 further queries of this type to the server for a reasonable period of
931 time (for example, one hour), i.e., long enough that the server
932 configuration or policy might be updated.
933
934 Historically, servers have used the REFUSED RCODE for many
935 situations; therefore, clients often had no detailed information on
936 which to base an error or fallback path when queries were refused.
937 As a result, the client behavior could vary significantly. XoT
938 servers that refuse queries must cater to the fact that client
939 behavior might vary from continually retrying queries regardless of
940 receiving REFUSED to every query or, at the other extreme, clients
941 may decide to stop using the server over any transport. This might
942 be because those clients are either non-XoT clients or do not
943 implement EDE codes.
944
945 7.9. AXoT Specifics
946
947 7.9.1. Padding AXoT Responses
948
949 The goal of padding AXoT responses is two fold:
950
951 * to obfuscate the actual size of the transferred zone to minimize
952 information leakage about the entire contents of the zone
953
954 * to obfuscate the incremental changes to the zone between SOA
955 updates to minimize information leakage about zone update activity
956 and growth
957
958 Note that the reuse of XoT connections for transfers of multiple
959 different zones slightly complicates any attempt to analyze the
960 traffic size and timing to extract information. Also, effective
961 padding may require the state to be kept because zones may grow and/
962 or shrink over time.
963
964 It is noted here that, depending on the padding policies eventually
965 developed for XoT, the requirement to obfuscate the total zone size
966 might require a server to create 'empty' AXoT responses, that is,
967 AXoT responses that contain no RRs apart from an OPT RR containing
968 the EDNS(0) option for padding. For example, without this
969 capability, the maximum size that a tiny zone could be padded to
970 would theoretically be limited if there had to be a minimum of 1 RR
971 per packet.
972
973 However, as with existing AXFR, the last AXoT response message sent
974 MUST contain the same SOA that was in the first message of the AXoT
975 response series in order to signal the conclusion of the zone
976 transfer.
977
978 [RFC5936] says:
979
980 | Each AXFR response message SHOULD contain a sufficient number of
981 | RRs to reasonably amortize the per-message overhead, up to the
982 | largest number that will fit within a DNS message (taking the
983 | required content of the other sections into account, as described
984 | below).
985
986 'Empty' AXoT responses generated in order to meet a padding
987 requirement will be exceptions to the above statement. For
988 flexibility, for future proofing, and in order to guarantee support
989 for future padding policies, it is stated here that secondary
990 implementations MUST be resilient to receiving padded AXoT responses,
991 including 'empty' AXoT responses that contain only an OPT RR
992 containing the EDNS(0) option for padding.
993
994 Recommendations of specific policies for padding AXoT responses are
995 out of scope for this specification. Detailed considerations of such
996 policies and the trade-offs involved are expected to be the subject
997 of future work.
998
999 7.10. IXoT Specifics
1000
1001 7.10.1. Condensation of Responses
1002
1003 [RFC1995] says that condensation of responses is optional and MAY be
1004 done. Whilst it does add complexity to generating responses, it can
1005 significantly reduce the size of responses. However, any such
1006 reduction might be offset by increased message size due to padding.
1007 This specification does not update the optionality of condensation
1008 for XoT responses.
1009
1010 7.10.2. Fallback to AXFR
1011
1012 Fallback to AXFR can happen, for example, if the server is not able
1013 to provide an IXFR for the requested SOA. Implementations differ in
1014 how long they store zone deltas and how many may be stored at any one
1015 time.
1016
1017 Just as with IXFR over TCP, after a failed IXFR, an IXoT client
1018 SHOULD request the AXFR on the already open XoT connection.
1019
1020 7.10.3. Padding of IXoT Responses
1021
1022 The goal of padding IXoT responses is to obfuscate the incremental
1023 changes to the zone between SOA updates to minimize information
1024 leakage about zone update activity and growth. Both the size and
1025 timing of the IXoT responses could reveal information.
1026
1027 IXFR responses can vary greatly in size from the order of 100 bytes
1028 for one or two record updates to tens of thousands of bytes for
1029 large, dynamic DNSSEC-signed zones. The frequency of IXFR responses
1030 can also depend greatly on if and how the zone is DNSSEC signed.
1031
1032 In order to guarantee support for future padding policies, it is
1033 stated here that secondary implementations MUST be resilient to
1034 receiving padded IXoT responses.
1035
1036 Recommendation of specific policies for padding IXoT responses are
1037 out of scope for this specification. Detailed considerations of such
1038 padding policies, the use of traffic obfuscation techniques (such as
1039 generating fake XFR traffic), and the trade-offs involved are
1040 expected to be the subject of future work.
1041
1042 7.11. Name Compression and Maximum Payload Sizes
1043
1044 It is noted here that name compression [RFC1035] can be used in XFR
1045 responses to reduce the size of the payload; however, the maximum
1046 value of the offset that can be used in the name compression pointer
1047 structure is 16384. For some DNS implementations, this limits the
1048 size of an individual XFR response used in practice to something
1049 around the order of 16 KB. In principle, larger payload sizes can be
1050 supported for some responses with more sophisticated approaches
1051 (e.g., by precalculating the maximum offset required).
1052
1053 Implementations may wish to offer options to disable name compression
1054 for XoT responses to enable larger payloads. This might be
1055 particularly helpful when padding is used, since minimizing the
1056 payload size is not necessarily a useful optimization in this case
1057 and disabling name compression will reduce the resources required to
1058 construct the payload.
1059
1060 8. Multi-primary Configurations
1061
1062 This model can provide flexibility and redundancy, particularly for
1063 IXFR. A secondary will receive one or more NOTIFY messages and can
1064 send an SOA to all of the configured primaries. It can then choose
1065 to send an XFR request to the primary with the highest SOA (or based
1066 on other criteria, e.g., RTT).
1067
1068 When using persistent connections, the secondary may have a XoT
1069 connection already open to one or more primaries. Should a secondary
1070 preferentially request an XFR from a primary to which it already has
1071 an open XoT connection or the one with the highest SOA (assuming it
1072 doesn't have a connection open to it already)?
1073
1074 Two extremes can be envisaged here. The first one can be considered
1075 a 'preferred primary connection' model. In this case, the secondary
1076 continues to use one persistent connection to a single primary until
1077 it has reason not to. Reasons not to might include the primary
1078 repeatedly closing the connection, long query/response RTTs on
1079 transfers, or the SOA of the primary being an unacceptable lag behind
1080 the SOA of an alternative primary.
1081
1082 The other extreme can be considered a 'parallel primary connection'
1083 model. Here, a secondary could keep multiple persistent connections
1084 open to all available primaries and only request XFRs from the
1085 primary with the highest serial number. Since normally the number of
1086 secondaries and primaries in direct contact in a transfer group is
1087 reasonably low, this might be feasible if latency is the most
1088 significant concern.
1089
1090 Recommendation of a particular scheme is out of scope of this
1091 document, but implementations are encouraged to provide configuration
1092 options that allow operators to make choices about this behavior.
1093
1094 9. Authentication Mechanisms
1095
1096 To provide context to the requirements in Section 7.5, this section
1097 provides a brief summary of some of the existing authentication and
1098 validation mechanisms (both transport independent and TLS specific)
1099 that are available when performing zone transfers. Section 10 then
1100 discusses in more detail specifically how a combination of TLS
1101 authentication, TSIG, and IP-based ACLs interact for XoT.
1102
1103 In this document, the mechanisms are classified based on the
1104 following properties:
1105
1106 Data Origin Authentication (DO):
1107 Authentication 1) of the fact that the DNS message originated from
1108 the party with whom credentials were shared and 2) of the data
1109 integrity of the message contents (the originating party may or
1110 may not be the party operating the far end of a TCP/TLS connection
1111 in a 'proxy' scenario).
1112
1113 Channel Confidentiality (CC):
1114 Confidentiality of the communication channel between the client
1115 and server (i.e., the two endpoints of a TCP/TLS connection) from
1116 passive surveillance.
1117
1118 Channel Authentication (CA):
1119 Authentication of the identity of the party to whom a TCP/TLS
1120 connection is made (this might not be a direct connection between
1121 the primary and secondary in a proxy scenario).
1122
1123 9.1. TSIG
1124
1125 TSIG [RFC8945] provides a mechanism for two or more parties to use
1126 shared secret keys that can then be used to create a message digest
1127 to protect individual DNS messages. This allows each party to
1128 authenticate that a request or response (and the data in it) came
1129 from the other party, even if it was transmitted over an unsecured
1130 channel or via a proxy.
1131
1132 Properties: Data origin authentication.
1133
1134 9.2. SIG(0)
1135
1136 SIG(0) [RFC2931] similarly provides a mechanism to digitally sign a
1137 DNS message but uses public key authentication, where the public keys
1138 are stored in DNS as KEY RRs and a private key is stored at the
1139 signer.
1140
1141 Properties: Data origin authentication.
1142
1143 9.3. TLS
1144
1145 9.3.1. Opportunistic TLS
1146
1147 Opportunistic TLS for DoT is defined in [RFC8310] and can provide a
1148 defense against passive surveillance, providing on-the-wire
1149 confidentiality. Essentially:
1150
1151 * if clients know authentication information for a server, they
1152 SHOULD try to authenticate the server,
1153
1154 * if this fails or clients do not know the information, they MAY
1155 fallback to using TLS without authentication, or
1156
1157 * clients MAY fallback to using cleartext if TLS is not available.
1158
1159 As such, it does not offer a defense against active attacks (e.g., an
1160 on-path active attacker on the connection from client to server) and
1161 is not considered as useful for XoT.
1162
1163 Properties: None guaranteed.
1164
1165 9.3.2. Strict TLS
1166
1167 Strict TLS for DoT [RFC8310] requires that a client is configured
1168 with an authentication domain name (and/or Subject Public Key Info
1169 (SPKI) pin set) that MUST be used to authenticate the TLS handshake
1170 with the server. If authentication of the server fails, the client
1171 will not proceed with the connection. This provides a defense for
1172 the client against active surveillance, providing client-to-server
1173 authentication and end-to-end channel confidentiality.
1174
1175 Properties: Channel confidentiality and channel authentication (of
1176 the server).
1177
1178 9.3.3. Mutual TLS
1179
1180 This is an extension to Strict TLS [RFC8310] that requires that a
1181 client is configured with an authentication domain name (and/or SPKI
1182 pin set) and a client certificate. The client offers the certificate
1183 for authentication by the server, and the client can authenticate the
1184 server the same way as in Strict TLS. This provides a defense for
1185 both parties against active surveillance, providing bidirectional
1186 authentication and end-to-end channel confidentiality.
1187
1188 Properties: Channel confidentiality and mutual channel
1189 authentication.
1190
1191 9.4. IP-Based ACL on the Primary
1192
1193 Most DNS server implementations offer an option to configure an IP-
1194 based ACL, which is often used in combination with TSIG-based ACLs to
1195 restrict access to zone transfers on primary servers on a per-query
1196 basis.
1197
1198 This is also possible with XoT, but it must be noted that, as with
1199 TCP, the implementation of such an ACL cannot be enforced on the
1200 primary until an XFR request is received on an established
1201 connection.
1202
1203 As discussed in Appendix A, an IP-based per-connection ACL could also
1204 be implemented where only TLS connections from recognized secondaries
1205 are accepted.
1206
1207 Properties: Channel authentication of the client.
1208
1209 9.5. ZONEMD
1210
1211 For completeness, ZONEMD [RFC8976] ("Message Digest for DNS Zones")
1212 is described here. The ZONEMD message digest is a mechanism that can
1213 be used to verify the content of a standalone zone. It is designed
1214 to be independent of the transmission channel or mechanism, allowing
1215 a general consumer of a zone to do origin authentication of the
1216 entire zone contents. Note that the current version of [RFC8976]
1217 states:
1218
1219 | As specified herein, ZONEMD is impractical for large, dynamic
1220 | zones due to the time and resources required for digest
1221 | calculation. However, the ZONEMD record is extensible so that new
1222 | digest schemes may be added in the future to support large,
1223 | dynamic zones.
1224
1225 It is complementary but orthogonal to the above mechanisms and can be
1226 used in conjunction with XoT but is not considered further here.
1227
1228 10. XoT Authentication
1229
1230 It is noted that zone transfer scenarios can vary from a simple
1231 single primary/secondary relationship where both servers are under
1232 the control of a single operator to a complex hierarchical structure
1233 that includes proxies and multiple operators. Each deployment
1234 scenario will require specific analysis to determine which
1235 combination of authentication methods are best suited to the
1236 deployment model in question.
1237
1238 The XoT authentication requirement specified in Section 7.5 addresses
1239 the issue of ensuring that the transfers are encrypted between the
1240 two endpoints directly involved in the current transfers. The
1241 following table summarizes the properties of a selection of the
1242 mechanisms discussed in Section 9. The two-letter abbreviations for
1243 the properties are used below: (S) indicates the secondary and (P)
1244 indicates the primary.
1245
1246 +================+=======+=======+=======+=======+=======+=======+
1247 | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) |
1248 +================+=======+=======+=======+=======+=======+=======+
1249 | Strict TLS | | Y | Y | | Y | |
1250 +----------------+-------+-------+-------+-------+-------+-------+
1251 | Mutual TLS | | Y | Y | | Y | Y |
1252 +----------------+-------+-------+-------+-------+-------+-------+
1253 | ACL on primary | | | | | | Y |
1254 +----------------+-------+-------+-------+-------+-------+-------+
1255 | TSIG | Y | | | Y | | |
1256 +----------------+-------+-------+-------+-------+-------+-------+
1257
1258 Table 1: Properties of Authentication Methods for XoT
1259
1260 Based on this analysis, it can be seen that:
1261
1262 * Using just mutual TLS can be considered a standalone solution
1263 since both endpoints are cryptographically authenticated.
1264
1265 * Using secondary-side Strict TLS with a primary-side IP-based ACL
1266 and TSIG/SIG(0) combination provides sufficient protection to be
1267 acceptable.
1268
1269 Using just an IP-based ACL could be susceptible to attacks that can
1270 spoof TCP IP addresses; using TSIG/SIG(0) alone could be susceptible
1271 to attacks that were able to capture such messages should they be
1272 accidentally sent in cleartext by any server with the key.
1273
1274 11. Policies for Both AXoT and IXoT
1275
1276 Whilst the protection of the zone contents in a transfer between two
1277 endpoints can be provided by the XoT protocol, the protection of all
1278 the transfers of a given zone requires operational administration and
1279 policy management.
1280
1281 The entire group of servers involved in XFR for a particular set of
1282 zones (all the primaries and all the secondaries) is called the
1283 'transfer group'.
1284
1285 In order to assure the confidentiality of the zone information, the
1286 entire transfer group MUST have a consistent policy of using XoT. If
1287 any do not, this is a weak link for attackers to exploit. For
1288 clarification, this means that within any transfer group both AXFRs
1289 and IXFRs for a zone MUST all use XoT.
1290
1291 An individual zone transfer is not considered protected by XoT unless
1292 both the client and server are configured to use only XoT, and the
1293 overall zone transfer is not considered protected until all members
1294 of the transfer group are configured to use only XoT with all other
1295 transfers servers (see Section 12).
1296
1297 A XoT policy MUST specify if:
1298
1299 * mutual TLS is used and/or
1300
1301 * an IP-based ACL and TSIG/SIG(0) combination is used.
1302
1303 Since this may require configuration of a number of servers who may
1304 be under the control of different operators, the desired consistency
1305 could be hard to enforce and audit in practice.
1306
1307 Certain aspects of the policies can be relatively easy to test
1308 independently, e.g., by requesting zone transfers without TSIG, from
1309 unauthorized IP addresses or over cleartext DNS. Other aspects, such
1310 as if a secondary will accept data without a TSIG digest or if
1311 secondaries are using Strict as opposed to Opportunistic TLS, are
1312 more challenging.
1313
1314 The mechanics of coordinating or enforcing such policies are out of
1315 the scope of this document but may be the subject of future
1316 operational guidance.
1317
1318 12. Implementation Considerations
1319
1320 Server implementations may want to also offer options that allow ACLs
1321 on a zone to specify that a specific client can use either XoT or
1322 TCP. This would allow for flexibility while clients are migrating to
1323 XoT.
1324
1325 Client implementations may similarly want to offer options to cater
1326 to the multi-primary case where the primaries are migrating to XoT.
1327
1328 13. Operational Considerations
1329
1330 If the options described in Section 12 are available, such
1331 configuration options MUST only be used in a 'migration mode' and
1332 therefore should be used with great care.
1333
1334 It is noted that use of a TLS proxy in front of the primary server is
1335 a simple deployment solution that can enable server-side XoT.
1336
1337 14. IANA Considerations
1338
1339 This document has no IANA actions.
1340
1341 15. Security Considerations
1342
1343 This document specifies a security measure against a DNS risk: the
1344 risk that an attacker collects entire DNS zones through eavesdropping
1345 on cleartext DNS zone transfers.
1346
1347 This does not mitigate:
1348
1349 * the risk that some level of zone activity might be inferred by
1350 observing zone transfer sizes and timing on encrypted connections
1351 (even with padding applied), in combination with obtaining SOA
1352 records by directly querying authoritative servers,
1353
1354 * the risk that hidden primaries might be inferred or identified via
1355 observation of encrypted connections, or
1356
1357 * the risk of zone contents being obtained via zone enumeration
1358 techniques.
1359
1360 Security concerns of DoT are outlined in [RFC7858] and [RFC8310].
1361
1362 16. References
1363
1364 16.1. Normative References
1365
1366 [DoT-ALPN] IANA, "TLS Application-Layer Protocol Negotiation (ALPN)
1367 Protocol IDs", <https://www.iana.org/assignments/tls-
1368 extensiontype-values/>.
1369
1370 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1371 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1372 <https://www.rfc-editor.org/info/rfc1034>.
1373
1374 [RFC1035] Mockapetris, P., "Domain names - implementation and
1375 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1376 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
1377
1378 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1379 DOI 10.17487/RFC1995, August 1996,
1380 <https://www.rfc-editor.org/info/rfc1995>.
1381
1382 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
1383 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
1384 August 1996, <https://www.rfc-editor.org/info/rfc1996>.
1385
1386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1387 Requirement Levels", BCP 14, RFC 2119,
1388 DOI 10.17487/RFC2119, March 1997,
1389 <https://www.rfc-editor.org/info/rfc2119>.
1390
1391 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
1392 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
1393 2000, <https://www.rfc-editor.org/info/rfc2931>.
1394
1395 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
1396 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
1397 <https://www.rfc-editor.org/info/rfc5936>.
1398
1399 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
1400 Morris, J., Hansen, M., and R. Smith, "Privacy
1401 Considerations for Internet Protocols", RFC 6973,
1402 DOI 10.17487/RFC6973, July 2013,
1403 <https://www.rfc-editor.org/info/rfc6973>.
1404
1405 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
1406 D. Wessels, "DNS Transport over TCP - Implementation
1407 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
1408 <https://www.rfc-editor.org/info/rfc7766>.
1409
1410 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
1411 edns-tcp-keepalive EDNS0 Option", RFC 7828,
1412 DOI 10.17487/RFC7828, April 2016,
1413 <https://www.rfc-editor.org/info/rfc7828>.
1414
1415 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1416 and P. Hoffman, "Specification for DNS over Transport
1417 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1418 2016, <https://www.rfc-editor.org/info/rfc7858>.
1419
1420 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1421 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1422 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1423
1424 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
1425 for DNS over TLS and DNS over DTLS", RFC 8310,
1426 DOI 10.17487/RFC8310, March 2018,
1427 <https://www.rfc-editor.org/info/rfc8310>.
1428
1429 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1430 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1431 <https://www.rfc-editor.org/info/rfc8446>.
1432
1433 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1434 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
1435 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
1436
1437 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
1438 Lawrence, "Extended DNS Errors", RFC 8914,
1439 DOI 10.17487/RFC8914, October 2020,
1440 <https://www.rfc-editor.org/info/rfc8914>.
1441
1442 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
1443 Gudmundsson, O., and B. Wellington, "Secret Key
1444 Transaction Authentication for DNS (TSIG)", STD 93,
1445 RFC 8945, DOI 10.17487/RFC8945, November 2020,
1446 <https://www.rfc-editor.org/info/rfc8945>.
1447
1448 16.2. Informative References
1449
1450 [BIND] ISC, "BIND 9.16.16", <https://www.isc.org/bind/>.
1451
1452 [DPRIVE-DNSOQUIC]
1453 Huitema, C., Dickinson, S., and A. Mankin, "Specification
1454 of DNS over Dedicated QUIC Connections", Work in Progress,
1455 Internet-Draft, draft-ietf-dprive-dnsoquic-03, 12 July
1456 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
1457 dprive-dnsoquic-03>.
1458
1459 [NIST-GUIDE]
1460 Chandramouli, R. and S. Rose, "Secure Domain Name System
1461 (DNS) Deployment Guide", September 2013,
1462 <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
1463 NIST.SP.800-81-2.pdf>.
1464
1465 [NSD] NLnet Labs, "NSD 4.3.6",
1466 <https://www.nlnetlabs.nl/projects/nsd/about/>.
1467
1468 [NSEC3-attacks]
1469 Goldberg, S., Naor, N., Papadopoulos, D., Reyzin, L.,
1470 Vasant, S., and A. Ziv, "Stretching NSEC3 to the Limit:
1471 Efficient Zone Enumeration Attacks on NSEC3 Variants",
1472 February 2015,
1473 <https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>.
1474
1475 [NSEC5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and
1476 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of
1477 Existence", Work in Progress, Internet-Draft, draft-
1478 vcelak-nsec5-08, 29 December 2018,
1479 <https://datatracker.ietf.org/doc/html/draft-vcelak-
1480 nsec5-08>.
1481
1482 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
1483 DOI 10.17487/RFC1982, August 1996,
1484 <https://www.rfc-editor.org/info/rfc1982>.
1485
1486 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
1487 Security (DNSSEC) Hashed Authenticated Denial of
1488 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
1489 <https://www.rfc-editor.org/info/rfc5155>.
1490
1491 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
1492 for DNS (EDNS(0))", STD 75, RFC 6891,
1493 DOI 10.17487/RFC6891, April 2013,
1494 <https://www.rfc-editor.org/info/rfc6891>.
1495
1496 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1497 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1498 <https://www.rfc-editor.org/info/rfc8484>.
1499
1500 [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
1501 Hardaker, "Message Digest for DNS Zones", RFC 8976,
1502 DOI 10.17487/RFC8976, February 2021,
1503 <https://www.rfc-editor.org/info/rfc8976>.
1504
1505 [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
1506 DOI 10.17487/RFC9076, July 2021,
1507 <https://www.rfc-editor.org/info/rfc9076>.
1508
1509 [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
1510 Encrypted Client Hello", Work in Progress, Internet-Draft,
1511 draft-ietf-tls-esni-13, 12 August 2021,
1512 <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
1513 esni-13>.
1514
1515 Appendix A. XoT Server Connection Handling
1516
1517 This appendix provides a non-normative outline of the pros and cons
1518 of XoT server connection-handling options.
1519
1520 For completeness, it is noted that an earlier draft version of this
1521 document suggested using a XoT-specific ALPN to negotiate TLS
1522 connections that supported only a limited set of queries (SOA, XFRs);
1523 however, this did not gain support. Reasons given included
1524 additional code complexity and the fact that XoT and ADoT are both
1525 DNS wire format and so should share the "dot" ALPN.
1526
1527 A.1. Listening Only on a Specific IP Address for TLS
1528
1529 Obviously, a name server that hosts a zone and services queries for
1530 the zone on an IP address published in an NS record may wish to use a
1531 separate IP address for XoT to listen for TLS, only publishing that
1532 address to its secondaries.
1533
1534 Pros: Probing of the public IP address will show no support for TLS.
1535 ACLs will prevent zone transfer on all transports on a per-query
1536 basis.
1537
1538 Cons: Attackers passively observing traffic will still be able to
1539 observe TLS connections to the separate address.
1540
1541 A.2. Client-Specific TLS Acceptance
1542
1543 Primaries that include IP-based ACLs and/or mutual TLS in their
1544 authentication models have the option of only accepting TLS
1545 connections from authorized clients. This could be implemented
1546 either using a proxy or directly in the DNS implementation.
1547
1548 Pros: Connection management happens at setup time. The maximum
1549 number of TLS connections a server will have to support can be
1550 easily assessed. Once the connection is accepted, the server
1551 might well be willing to answer any query on that connection since
1552 it is coming from a configured secondary, and a specific response
1553 policy on the connection may not be needed (see below).
1554
1555 Cons: Currently, none of the major open-source implementations of a
1556 DNS authoritative server support such an option.
1557
1558 A.3. SNI-Based TLS Acceptance
1559
1560 Primaries could also choose to only accept TLS connections based on a
1561 Server Name Indication (SNI) that was published only to their
1562 secondaries.
1563
1564 Pros: Reduces the number of accepted connections.
1565
1566 Cons: As above. Also, this is not a recommended use of SNI. For
1567 SNIs sent in the clear, this would still allow attackers passively
1568 observing traffic to potentially abuse this mechanism. The use of
1569 Encrypted Client Hello [TLS-ESNI] may be of use here.
1570
1571 A.4. Transport-Specific Response Policies
1572
1573 Some primaries might rely on TSIG/SIG(0) combined with per-query, IP-
1574 based ACLs to authenticate secondaries. In this case, the primary
1575 must accept all incoming TLS/TCP connections and then apply a
1576 transport-specific response policy on a per-query basis.
1577
1578 As an aside, whilst [RFC7766] makes a general purpose distinction in
1579 the advice to clients about their usage of connections (between
1580 regular queries and zone transfers), this is not strict, and nothing
1581 in the DNS protocol prevents using the same connection for both types
1582 of traffic. Hence, a server cannot know the intention of any client
1583 that connects to it; it can only inspect the messages it receives on
1584 such a connection and make per-query decisions about whether or not
1585 to answer those queries.
1586
1587 Example policies a XoT server might implement are:
1588
1589 strict: REFUSE all queries on TLS connections, except SOA and
1590 authorized XFR requests
1591
1592 moderate: REFUSE all queries on TLS connections until one is
1593 received that is signed by a recognized TSIG/SIG(0) key,
1594 then answer all queries on the connection after that
1595
1596 complex: apply a heuristic to determine which queries on a TLS
1597 connections to REFUSE
1598
1599 relaxed: answer all non-XoT queries on all TLS connections with
1600 the same policy applied to TCP queries
1601
1602 Pros: Allows for flexible behavior by the server that could be
1603 changed over time.
1604
1605 Cons: The server must handle the burden of accepting all TLS
1606 connections just to perform XFRs with a small number of
1607 secondaries. Client behavior to a REFUSED response is not clearly
1608 defined (see Section 7.8). Currently, none of the major open-
1609 source implementations of a DNS authoritative server offer an
1610 option for different response policies in different transports
1611 (but such functionality could potentially be implemented using a
1612 proxy).
1613
1614 A.4.1. SNI-Based Response Policies
1615
1616 In a similar fashion, XoT servers might use the presence of an SNI in
1617 the Client Hello to determine which response policy to initially
1618 apply to the TLS connections.
1619
1620 Pros: This has the potential to allow a clean distinction between a
1621 XoT service and any future DoT-based service for answering
1622 recursive queries.
1623
1624 Cons: As above.
1625
1626 Acknowledgements
1627
1628 The authors thank Tony Finch, Benno Overeinder, Shumon Huque, Tim
1629 Wicinski, and many other members of DPRIVE for review and
1630 discussions.
1631
1632 The authors particularly thank Peter van Dijk, Ondrej Sury, Brian
1633 Dickson, and several other open-source DNS implementers for valuable
1634 discussion and clarification on the issue associated with pipelining
1635 XFR queries and handling out-of-order/intermingled responses.
1636
1637 Contributors
1638
1639 Significant contributions to the document were made by:
1640
1641 Han Zhang
1642 Salesforce
1643 San Francisco, CA
1644 United States of America
1645
1646 Email: hzhang@salesforce.com
1647
1648
1649 Authors' Addresses
1650
1651 Willem Toorop
1652 NLnet Labs
1653 Science Park 400
1654 1098 XH Amsterdam
1655 Netherlands
1656
1657 Email: willem@nlnetlabs.nl
1658
1659
1660 Sara Dickinson
1661 Sinodun IT
1662 Magdalen Centre
1663 Oxford Science Park
1664 Oxford
1665 OX4 4GA
1666 United Kingdom
1667
1668 Email: sara@sinodun.com
1669
1670
1671 Shivan Sahib
1672 Brave Software
1673 Vancouver BC
1674 Canada
1675
1676 Email: shivankaulsahib@gmail.com
1677
1678
1679 Pallavi Aras
1680 Salesforce
1681 Herndon, VA
1682 United States of America
1683
1684 Email: paras@salesforce.com
1685
1686
1687 Allison Mankin
1688 Salesforce
1689 Herndon, VA
1690 United States of America
1691
1692 Email: allison.mankin@gmail.com
1693
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions). Reference: https://bind9.readthedocs.io/en/v9_18_0/notes.html#new-features Remote TLS certificate verification, Strict TLS and Mutual TLS authentication mechanisms are supported. Gory details visible at https://gitlab.isc.org/isc-projects/bind9/-/issues/1784.