-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathdraft-ietf-dprive-xfr-over-tls-03.html
1582 lines (1472 loc) · 105 KB
/
draft-ietf-dprive-xfr-over-tls-03.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>DNS Zone Transfer-over-TLS</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Terminology"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Use Cases for XFR-over-TLS"/>
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Threat model"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Connection and Data Flows in Existing XFR Mechanisms"/>
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 AXFR Mechanism"/>
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 IXFR Mechanism"/>
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 Data Leakage of NOTIFY and SOA Message Exchanges"/>
<link href="#rfc.section.4.3.1" rel="Chapter" title="4.3.1 NOTIFY"/>
<link href="#rfc.section.4.3.2" rel="Chapter" title="4.3.2 SOA"/>
<link href="#rfc.section.5" rel="Chapter" title="5 Updates to existing specifications"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Update to RFC1995 for IXFR-over-TCP"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Update to RFC5936 for AXFR-over-TCP"/>
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Updates to RFC1995 and RFC5936 for XFR-over-TCP"/>
<link href="#rfc.section.5.3.1" rel="Chapter" title="5.3.1 Connection reuse"/>
<link href="#rfc.section.5.3.2" rel="Chapter" title="5.3.2 AXFRs and IXFRs on the same connection"/>
<link href="#rfc.section.5.3.3" rel="Chapter" title="5.3.3 XFR limits"/>
<link href="#rfc.section.5.3.4" rel="Chapter" title="5.3.4 The edns-tcp-keepalive EDNS0 Option"/>
<link href="#rfc.section.5.3.5" rel="Chapter" title="5.3.5 Backwards compatibility"/>
<link href="#rfc.section.5.4" rel="Chapter" title="5.4 Update to RFC7766"/>
<link href="#rfc.section.6" rel="Chapter" title="6 XoT specification"/>
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 TLS versions"/>
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Port selection"/>
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 High level XoT descriptions"/>
<link href="#rfc.section.6.4" rel="Chapter" title="6.4 XoT transfers"/>
<link href="#rfc.section.6.5" rel="Chapter" title="6.5 XoT connections"/>
<link href="#rfc.section.6.6" rel="Chapter" title="6.6 XoT vs ADoT"/>
<link href="#rfc.section.6.7" rel="Chapter" title="6.7 Response RCODES"/>
<link href="#rfc.section.6.8" rel="Chapter" title="6.8 AXoT specifics"/>
<link href="#rfc.section.6.8.1" rel="Chapter" title="6.8.1 Padding AXoT responses"/>
<link href="#rfc.section.6.9" rel="Chapter" title="6.9 IXoT specifics"/>
<link href="#rfc.section.6.9.1" rel="Chapter" title="6.9.1 Condensation of responses"/>
<link href="#rfc.section.6.9.2" rel="Chapter" title="6.9.2 Fallback to AXFR"/>
<link href="#rfc.section.6.9.3" rel="Chapter" title="6.9.3 Padding of IXoT responses"/>
<link href="#rfc.section.6.10" rel="Chapter" title="6.10 Name compression and maximum payload sizes"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Multi-primary Configurations"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Authentication mechanisms"/>
<link href="#rfc.section.8.1" rel="Chapter" title="8.1 TSIG"/>
<link href="#rfc.section.8.2" rel="Chapter" title="8.2 SIG(0)"/>
<link href="#rfc.section.8.3" rel="Chapter" title="8.3 TLS"/>
<link href="#rfc.section.8.3.1" rel="Chapter" title="8.3.1 Opportunistic TLS"/>
<link href="#rfc.section.8.3.2" rel="Chapter" title="8.3.2 Strict TLS"/>
<link href="#rfc.section.8.3.3" rel="Chapter" title="8.3.3 Mutual TLS"/>
<link href="#rfc.section.8.4" rel="Chapter" title="8.4 IP Based ACL on the Primary"/>
<link href="#rfc.section.8.5" rel="Chapter" title="8.5 ZONEMD"/>
<link href="#rfc.section.9" rel="Chapter" title="9 XoT authentication"/>
<link href="#rfc.section.10" rel="Chapter" title="10 Policies for Both AXoT and IXoT"/>
<link href="#rfc.section.11" rel="Chapter" title="11 Implementation Considerations"/>
<link href="#rfc.section.12" rel="Chapter" title="12 Implementation Status"/>
<link href="#rfc.section.13" rel="Chapter" title="13 IANA Considerations"/>
<link href="#rfc.section.14" rel="Chapter" title="14 Security Considerations"/>
<link href="#rfc.section.15" rel="Chapter" title="15 Acknowledgements"/>
<link href="#rfc.section.16" rel="Chapter" title="16 Contributors"/>
<link href="#rfc.section.17" rel="Chapter" title="17 Changelog"/>
<link href="#rfc.references" rel="Chapter" title="18 References"/>
<link href="#rfc.references.1" rel="Chapter" title="18.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="18.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A XoT server connection handling"/>
<link href="#rfc.appendix.A.1" rel="Chapter" title="A.1 Only listen on TLS on a specific IP address"/>
<link href="#rfc.appendix.A.2" rel="Chapter" title="A.2 Client specific TLS acceptance"/>
<link href="#rfc.appendix.A.3" rel="Chapter" title="A.3 SNI based TLS acceptance"/>
<link href="#rfc.appendix.A.4" rel="Chapter" title="A.4 TLS specific response policies"/>
<link href="#rfc.appendix.A.4.1" rel="Chapter" title="A.4.1 SNI based response policies"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.1 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. Mankin" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-dprive-xfr-over-tls-03" />
<meta name="dct.issued" scheme="ISO8601" content="2020-11-2" />
<meta name="dct.abstract" content="DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of TLS, rather then clear text, to prevent zone content collection via passive monitoring of zone transfers: XFR-over-TLS (XoT). Additionally, this specification updates RFC1995, RFC5936 and RFC7766. " />
<meta name="description" content="DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of TLS, rather then clear text, to prevent zone content collection via passive monitoring of zone transfers: XFR-over-TLS (XoT). Additionally, this specification updates RFC1995, RFC5936 and RFC7766. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">dprive</td>
<td class="right">W. Toorop</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">NLnet Labs</td>
</tr>
<tr>
<td class="left">Updates: 1995, 5936, 7766 (if approved)</td>
<td class="right">S. Dickinson</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">Sinodun IT</td>
</tr>
<tr>
<td class="left">Expires: May 6, 2021</td>
<td class="right">S. Sahib</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">P. Aras</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">A. Mankin</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Salesforce</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">November 2, 2020</td>
</tr>
</tbody>
</table>
<p class="title">DNS Zone Transfer-over-TLS<br />
<span class="filename">draft-ietf-dprive-xfr-over-tls-03</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of TLS, rather then clear text, to prevent zone content collection via passive monitoring of zone transfers: XFR-over-TLS (XoT). Additionally, this specification updates RFC1995, RFC5936 and RFC7766. </p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on May 6, 2021.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>2. <a href="#rfc.section.2">Terminology</a></li>
<li>3. <a href="#rfc.section.3">Use Cases for XFR-over-TLS</a></li>
<ul><li>3.1. <a href="#rfc.section.3.1">Threat model</a></li>
</ul><li>4. <a href="#rfc.section.4">Connection and Data Flows in Existing XFR Mechanisms</a></li>
<ul><li>4.1. <a href="#rfc.section.4.1">AXFR Mechanism</a></li>
<li>4.2. <a href="#rfc.section.4.2">IXFR Mechanism</a></li>
<li>4.3. <a href="#rfc.section.4.3">Data Leakage of NOTIFY and SOA Message Exchanges</a></li>
<ul><li>4.3.1. <a href="#rfc.section.4.3.1">NOTIFY</a></li>
<li>4.3.2. <a href="#rfc.section.4.3.2">SOA</a></li>
</ul></ul><li>5. <a href="#rfc.section.5">Updates to existing specifications</a></li>
<ul><li>5.1. <a href="#rfc.section.5.1">Update to RFC1995 for IXFR-over-TCP</a></li>
<li>5.2. <a href="#rfc.section.5.2">Update to RFC5936 for AXFR-over-TCP</a></li>
<li>5.3. <a href="#rfc.section.5.3">Updates to RFC1995 and RFC5936 for XFR-over-TCP</a></li>
<ul><li>5.3.1. <a href="#rfc.section.5.3.1">Connection reuse</a></li>
<li>5.3.2. <a href="#rfc.section.5.3.2">AXFRs and IXFRs on the same connection</a></li>
<li>5.3.3. <a href="#rfc.section.5.3.3">XFR limits</a></li>
<li>5.3.4. <a href="#rfc.section.5.3.4">The edns-tcp-keepalive EDNS0 Option</a></li>
<li>5.3.5. <a href="#rfc.section.5.3.5">Backwards compatibility</a></li>
</ul><li>5.4. <a href="#rfc.section.5.4">Update to RFC7766</a></li>
</ul><li>6. <a href="#rfc.section.6">XoT specification</a></li>
<ul><li>6.1. <a href="#rfc.section.6.1">TLS versions</a></li>
<li>6.2. <a href="#rfc.section.6.2">Port selection</a></li>
<li>6.3. <a href="#rfc.section.6.3">High level XoT descriptions</a></li>
<li>6.4. <a href="#rfc.section.6.4">XoT transfers</a></li>
<li>6.5. <a href="#rfc.section.6.5">XoT connections</a></li>
<li>6.6. <a href="#rfc.section.6.6">XoT vs ADoT</a></li>
<li>6.7. <a href="#rfc.section.6.7">Response RCODES</a></li>
<li>6.8. <a href="#rfc.section.6.8">AXoT specifics</a></li>
<ul><li>6.8.1. <a href="#rfc.section.6.8.1">Padding AXoT responses</a></li>
</ul><li>6.9. <a href="#rfc.section.6.9">IXoT specifics</a></li>
<ul><li>6.9.1. <a href="#rfc.section.6.9.1">Condensation of responses</a></li>
<li>6.9.2. <a href="#rfc.section.6.9.2">Fallback to AXFR</a></li>
<li>6.9.3. <a href="#rfc.section.6.9.3">Padding of IXoT responses</a></li>
</ul><li>6.10. <a href="#rfc.section.6.10">Name compression and maximum payload sizes</a></li>
</ul><li>7. <a href="#rfc.section.7">Multi-primary Configurations</a></li>
<li>8. <a href="#rfc.section.8">Authentication mechanisms</a></li>
<ul><li>8.1. <a href="#rfc.section.8.1">TSIG</a></li>
<li>8.2. <a href="#rfc.section.8.2">SIG(0)</a></li>
<li>8.3. <a href="#rfc.section.8.3">TLS</a></li>
<ul><li>8.3.1. <a href="#rfc.section.8.3.1">Opportunistic TLS</a></li>
<li>8.3.2. <a href="#rfc.section.8.3.2">Strict TLS</a></li>
<li>8.3.3. <a href="#rfc.section.8.3.3">Mutual TLS</a></li>
</ul><li>8.4. <a href="#rfc.section.8.4">IP Based ACL on the Primary</a></li>
<li>8.5. <a href="#rfc.section.8.5">ZONEMD</a></li>
</ul><li>9. <a href="#rfc.section.9">XoT authentication</a></li>
<li>10. <a href="#rfc.section.10">Policies for Both AXoT and IXoT</a></li>
<li>11. <a href="#rfc.section.11">Implementation Considerations</a></li>
<li>12. <a href="#rfc.section.12">Implementation Status</a></li>
<li>13. <a href="#rfc.section.13">IANA Considerations</a></li>
<li>14. <a href="#rfc.section.14">Security Considerations</a></li>
<li>15. <a href="#rfc.section.15">Acknowledgements</a></li>
<li>16. <a href="#rfc.section.16">Contributors</a></li>
<li>17. <a href="#rfc.section.17">Changelog</a></li>
<li>18. <a href="#rfc.references">References</a></li>
<ul><li>18.1. <a href="#rfc.references.1">Normative References</a></li>
<li>18.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">XoT server connection handling</a></li>
<ul><li>A.1. <a href="#rfc.appendix.A.1">Only listen on TLS on a specific IP address</a></li>
<li>A.2. <a href="#rfc.appendix.A.2">Client specific TLS acceptance</a></li>
<li>A.3. <a href="#rfc.appendix.A.3">SNI based TLS acceptance</a></li>
<li>A.4. <a href="#rfc.appendix.A.4">TLS specific response policies</a></li>
<ul><li>A.4.1. <a href="#rfc.appendix.A.4.1">SNI based response policies</a></li>
</ul></ul><li><a href="#rfc.authors">Authors' Addresses</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">DNS has a number of privacy vulnerabilities, as discussed in detail in <a href="#RFC7626">[RFC7626]</a>. Stub client to recursive resolver query privacy has received the most attention to date, with standards track documents for both DNS-over-TLS (DoT) <a href="#RFC7858">[RFC7858]</a> and DNS-over-HTTPS (DoH) <a href="#RFC8484">[RFC8484]</a>, and a proposal for DNS-over-QUIC <a href="#I-D.ietf-dprive-dnsoquic">[I-D.ietf-dprive-dnsoquic]</a>. There is ongoing work on DNS privacy requirements for exchanges between recursive resolvers and authoritative servers <a href="#I-D.ietf-dprive-phase2-requirements">[I-D.ietf-dprive-phase2-requirements]</a> and some suggestions for how signaling of DoT support by authoritatives might work, e.g., <a href="#I-D.vandijk-dprive-ds-dot-signal-and-pin">[I-D.vandijk-dprive-ds-dot-signal-and-pin]</a>. However there is currently no RFC that specifically defines recursive to authoritative DNS-over-TLS (ADoT). </p>
<p><a href="#RFC7626">[RFC7626]</a> established that stub client DNS query transactions are not public and needed protection, but on zone transfer <a href="#RFC1995">[RFC1995]</a> <a href="#RFC5936">[RFC5936]</a> it says only: </p>
<pre>
"Privacy risks for the holder of a zone (the risk that someone
gets the data) are discussed in [RFC5936] and [RFC5155]."
</pre>
<p id="rfc.section.1.p.3">In what way is exposing the full contents of a zone a privacy risk? The contents of the zone could include information such as names of persons used in names of hosts. Best practice is not to use personal information for domain names, but many such domain names exist. The contents of the zone could also include references to locations that allow inference about location information of the individuals associated with the zone's organization. It could also include references to other organizations. Examples of this could be: </p>
<p/>
<ul>
<li>Person-laptop.example.org</li>
<li>MX-for-Location.example.org</li>
<li>Service-tenant-from-another-org.example.org</li>
</ul>
<p> </p>
<p id="rfc.section.1.p.5">There may also be regulatory, policy or other reasons why the zone contents in full must be treated as private. </p>
<p id="rfc.section.1.p.6">Neither of the RFCs mentioned in <a href="#RFC7626">[RFC7626]</a> contemplates the risk that someone gets the data through eavesdropping on network connections, only via enumeration or unauthorized transfer as described in the following paragraphs. </p>
<p id="rfc.section.1.p.7">Zone enumeration is trivially possible for DNSSEC zones which use NSEC; i.e. queries for the authenticated denial of existences records allow a client to walk through the entire zone contents. <a href="#RFC5155">[RFC5155]</a> specifies NSEC3, a mechanism to provide measures against zone enumeration for DNSSEC signed zones (a goal was to make it as hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst this is widely used, zone walking is now possible with NSEC3 due to crypto-breaking advances. This has prompted further work on an alternative mechanism for DNSSEC authenticated denial of existence - NSEC5 <a href="#I-D.vcelak-nsec5">[I-D.vcelak-nsec5]</a> - however questions remain over the practicality of this mechanism. </p>
<p><a href="#RFC5155">[RFC5155]</a> does not address data obtained outside zone enumeration (nor does <a href="#I-D.vcelak-nsec5">[I-D.vcelak-nsec5]</a>). Preventing eavesdropping of zone transfers (this draft) is orthogonal to preventing zone enumeration, though they aim to protect the same information. </p>
<p><a href="#RFC5936">[RFC5936]</a> specifies using TSIG <a href="#RFC2845">[RFC2845]</a> for authorization of the clients of a zone transfer and for data integrity, but does not express any need for confidentiality, and TSIG does not offer encryption. Some operators use SSH tunneling or IPSec to encrypt the transfer data. </p>
<p id="rfc.section.1.p.10">Section 8 of the NIST guide on 'Secure Domain Name System (DNS) Deployment' <a href="#nist-guide">[nist-guide]</a> discusses restricting access for zone transfers using ACLs and TSIG in more detail. It is noted that in all the common open source implementations such ACLs are applied on a per query basis. Since requests typically occur on TCP connections authoritatives must cater for accepting any TCP connection and then handling the authentication of each XFR request individually. </p>
<p id="rfc.section.1.p.11">Because both AXFR and IXFR zone transfers are typically carried out over TCP from authoritative DNS protocol implementations, encrypting zone transfers using TLS, based closely on DoT <a href="#RFC7858">[RFC7858]</a>, seems like a simple step forward. This document specifies how to use TLS as a transport to prevent zone collection from zone transfers. </p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#terminology" id="terminology">Terminology</a></h1>
<p id="rfc.section.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <a href="#RFC2119">[RFC2119]</a> and <a href="#RFC8174">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here. </p>
<p id="rfc.section.2.p.2">Privacy terminology is as described in Section 3 of <a href="#RFC6973">[RFC6973]</a>. </p>
<p id="rfc.section.2.p.3">Note that in this document we choose to use the terms 'primary' and 'secondary' for two servers engaged in zone transfers. </p>
<p id="rfc.section.2.p.4">DNS terminology is as described in <a href="#RFC8499">[RFC8499]</a>. </p>
<p id="rfc.section.2.p.5">DoT: DNS-over-TLS as specified in <a href="#RFC7858">[RFC7858]</a> </p>
<p id="rfc.section.2.p.6">XFR-over-TCP: Used to mean both IXFR-over-TCP <a href="#RFC1995">[RFC1995]</a> and AXFR-over-TCP <a href="#RFC5936">[RFC5936]</a>. </p>
<p id="rfc.section.2.p.7">XoT: Generic XFR-over-TLS mechanisms as specified in this document </p>
<p id="rfc.section.2.p.8">AXoT: AXFR-over-TLS </p>
<p id="rfc.section.2.p.9">IXoT: IXFR over-TLS </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#use-cases-for-xfrovertls" id="use-cases-for-xfrovertls">Use Cases for XFR-over-TLS</a></h1>
<p/>
<ul>
<li>Confidentiality. Clearly using an encrypted transport for zone transfers will defeat zone content leakage that can occur via passive surveillance.</li>
<li>Authentication. Use of single or mutual TLS (mTLS) authentication (in combination with ACLs) can complement and potentially be an alternative to TSIG.</li>
<li>Performance. Existing AXFR and IXFR mechanisms have the burden of backwards compatibility with older implementations based on the original specifications in <a href="#RFC1034">[RFC1034]</a> and <a href="#RFC1035">[RFC1035]</a>. For example, some older AXFR servers don’t support using a TCP connection for multiple AXFR sessions or XFRs of different zones because they have not been updated to follow the guidance in <a href="#RFC5936">[RFC5936]</a>. Any implementation of XFR-over-TLS (XoT) would obviously be required to implement optimized and interoperable transfers as described in <a href="#RFC5936">[RFC5936]</a>, e.g., transfer of multiple zones over one connection.</li>
<li>Performance. Current usage of TCP for IXFR is sub-optimal in some cases i.e. connections are frequently closed after a single IXFR.</li>
</ul>
<p> </p>
<h1 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1.</a> <a href="#threat-model" id="threat-model">Threat model</a></h1>
<p id="rfc.section.3.1.p.1">The threat model considered here is one where the current contents and size of the zone are considered sensitive and should be protected during transfer. </p>
<p id="rfc.section.3.1.p.2">The threat model does not, however, consider the existence of a zone, the act of zone transfer between two entities, nor the identities of the nameservers hosting a zone (including both those acting as hidden primaries/secondaries or directly serving the zone) as sensitive information. The proposed mechanisms does not attempt to obscure such information. The reasons for this include: </p>
<p/>
<ul>
<li>much of this information can be obtained by various methods including active scanning of the DNS</li>
<li>an attacker who can monitor network traffic can relatively easily infer relations between nameservers simply from traffic patterns, even when some or all of the traffic is encrypted</li>
</ul>
<p> </p>
<p id="rfc.section.3.1.p.4">It is noted that simply using XoT will indicate a desire by the zone owner that the contents of the zone remain confidential and so could be subject to blocking (e.g. via blocking of port 853) if an attacker had such capabilities. However this threat is likely true of any such mechanism that attempts to encrypt data passed between nameservers e.g. IPsec. </p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#connection-and-data-flows-in-existing-xfr-mechanisms" id="connection-and-data-flows-in-existing-xfr-mechanisms">Connection and Data Flows in Existing XFR Mechanisms</a></h1>
<p id="rfc.section.4.p.1">The original specification for zone transfers in <a href="#RFC1034">[RFC1034]</a> and <a href="#RFC1035">[RFC1035]</a> was based on a polling mechanism: a secondary performed a periodic SOA query (based on the refresh timer) to determine if an AXFR was required. </p>
<p><a href="#RFC1995">[RFC1995]</a> and <a href="#RFC1996">[RFC1996]</a> introduced the concepts of IXFR and NOTIFY respectively, to provide for prompt propagation of zone updates. This has largely replaced AXFR where possible, particularly for dynamically updated zones. </p>
<p><a href="#RFC5936">[RFC5936]</a> subsequently redefined the specification of AXFR to improve performance and interoperability. </p>
<p id="rfc.section.4.p.4">In this document we use the phrase "XFR mechanism" to describe the entire set of message exchanges between a secondary and a primary that concludes in a successful AXFR or IXFR request/response. This set may or may not include </p>
<p/>
<ul>
<li>NOTIFY messages</li>
<li>SOA queries</li>
<li>Fallback from IXFR to AXFR</li>
<li>Fallback from IXFR-over-UDP to IXFR-over-TCP</li>
</ul>
<p> </p>
<p id="rfc.section.4.p.6">The term is used to encompasses the range of permutations that are possible and is useful to distinguish the 'XFR mechanism' from a single XFR request/response exchange. </p>
<h1 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1.</a> <a href="#axfr-mechanism" id="axfr-mechanism">AXFR Mechanism</a></h1>
<p id="rfc.section.4.1.p.1">The figure below provides an outline of an AXFR mechanism including NOTIFYs. </p>
<pre>
Secondary Primary
| NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TCP
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
Figure 1. AXFR Mechanism
</pre>
<p/>
<ol>
<li>An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from the primary to the secondary. A secondary may also initiate an AXFR based on a refresh timer or scheduled/triggered zone maintenance.</li>
<li>The secondary will normally (but not always) make a SOA query to the primary to obtain the serial number of the zone held by the primary.</li>
<li>If the primary serial is higher than the secondaries serial (using Serial Number Arithmetic <a href="#RFC1982">[RFC1982]</a>), the secondary makes an AXFR request (over TCP) to the primary after which the AXFR data flows in one or more AXFR responses on the TCP connection. <a href="#RFC5936">[RFC5936]</a> defines this specific step as an 'AXFR session' i.e. as an AXFR query message and the sequence of AXFR response messages returned for it.</li>
</ol>
<p> </p>
<p><a href="#RFC5936">[RFC5936]</a> re-specified AXFR providing additional guidance beyond that provided in <a href="#RFC1034">[RFC1034]</a> and <a href="#RFC1035">[RFC1035]</a> and importantly specified that AXFR must use TCP as the transport protocol. </p>
<p id="rfc.section.4.1.p.4">Additionally, sections 4.1, 4.1.1 and 4.1.2 of <a href="#RFC5936">[RFC5936]</a> provide improved guidance for AXFR clients and servers with regard to re-use of TCP connections for multiple AXFRs and AXFRs of different zones. However <a href="#RFC5936">[RFC5936]</a> was constrained by having to be backwards compatible with some very early basic implementations of AXFR. For example, it outlines that the SOA query can also happen on this connection. However, this can cause interoperability problems with older implementations that support only the trivial case of one AXFR per connection. </p>
<h1 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2.</a> <a href="#ixfr-mechanism" id="ixfr-mechanism">IXFR Mechanism</a></h1>
<p id="rfc.section.4.2.p.1">The figure below provides an outline of the IXFR mechanism including NOTIFYs. </p>
<pre>
Secondary Primary
| NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP or TCP
| <-------------------------------- |
| SOA Response |
| |
| |
| |
| IXFR Request |
| --------------------------------> | UDP or TCP
| <-------------------------------- |
| IXFR Response |
| (Zone data) |
| |
| | ---
| IXFR Request | |
| --------------------------------> | | Retry over
| <-------------------------------- | | TCP if
| IXFR Response | | required
| (Zone data) | ---
Figure 1. IXFR Mechanism
</pre>
<p/>
<ol>
<li>An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from the primary to the secondary. A secondary may also initiate an IXFR based on a refresh timer or scheduled/triggered zone maintenance.</li>
<li>The secondary will normally (but not always) make a SOA query to the primary to obtain the serial number of the zone held by the primary.</li>
<li>If the primary serial is higher than the secondaries serial (using Serial Number Arithmetic <a href="#RFC1982">[RFC1982]</a>), the secondary makes an IXFR request to the primary after the primary sends an IXFR response.</li>
</ol>
<p> </p>
<p><a href="#RFC1995">[RFC1995]</a> specifies that Incremental Transfer may use UDP if the entire IXFR response can be contained in a single DNS packet, otherwise, TCP is used. In fact it says: </p>
<pre>
"Thus, a client should first make an IXFR query using UDP."
</pre>
<p id="rfc.section.4.2.p.4">So there may be a fourth step above where the client falls back to IXFR-over-TCP. There may also be a fourth step where the secondary must fall back to AXFR because, e.g., the primary does not support IXFR. </p>
<p id="rfc.section.4.2.p.5">However it is noted that most widely used open source authoritative nameserver implementations (including both <a href="https://www.isc.org/bind/">BIND</a> and <a href="https://www.nlnetlabs.nl/projects/nsd/about/">NSD</a>) do IXFR using TCP by default in their latest releases. For BIND TCP connections are sometimes used for SOA queries but in general they are not used persistently and close after an IXFR is completed. </p>
<h1 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3.</a> <a href="#data-leakage-of-notify-and-soa-message-exchanges" id="data-leakage-of-notify-and-soa-message-exchanges">Data Leakage of NOTIFY and SOA Message Exchanges</a></h1>
<p id="rfc.section.4.3.p.1">This section attempts to presents a rationale for considering encrypting the other messages in the XFR mechanism. </p>
<p id="rfc.section.4.3.p.2">Since the SOA of the published zone can be trivially discovered by simply querying the publicly available authoritative servers leakage of this RR is not discussed in the following sections. </p>
<h1 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1.</a> <a href="#notify" id="notify">NOTIFY</a></h1>
<p id="rfc.section.4.3.1.p.1">Unencrypted NOTIFY messages identify configured secondaries on the primary. </p>
<p><a href="#RFC1996">[RFC1996]</a> also states: </p>
<pre>
"If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE).
</pre>
<p id="rfc.section.4.3.1.p.3">But since the only supported QTYPE for NOTIFY is SOA, this does not pose a potential leak. </p>
<h1 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2.</a> <a href="#soa" id="soa">SOA</a></h1>
<p id="rfc.section.4.3.2.p.1">For hidden primaries or secondaries the SOA response leaks only the degree of lag of any downstream secondary. </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#updates-to-existing-specifications" id="updates-to-existing-specifications">Updates to existing specifications</a></h1>
<p id="rfc.section.5.p.1">For convenience, the phrase 'XFR-over-TCP' is used in this document to mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements that use it update both <a href="#RFC1995">[RFC1995]</a> and <a href="#RFC5936">[RFC5936]</a>, and implicitly also apply to XoT. Differences in behavior specific to XoT are discussed in <a href="#xot-specification">Section 6</a>. </p>
<p id="rfc.section.5.p.2">Both <a href="#RFC1995">[RFC1995]</a> and <a href="#RFC5936">[RFC5936]</a> were published sometime before TCP was considered a first class transport for DNS. <a href="#RFC1995">[RFC1995]</a>, in fact, says nothing with respect to optimizing IXFRs over TCP or re-using already open TCP connections to perform IXFRs or other queries. Therefore, there arguably is an implicit assumption (probably unintentional) that a TCP connection is used for one and only one IXFR request. Indeed, several open source implementations currently take this approach. And whilst <a href="#RFC5936">[RFC5936]</a> gives guidance on connection re-use for AXFR, it pre-dates more recent specifications describing persistent TCP connections e.g. <a href="#RFC7626">[RFC7626]</a>, <a href="#RFC7828">[RFC7828]</a> and AXFR implementations again often make less than optimal use of open connections. </p>
<p id="rfc.section.5.p.3">Given this, new implementations of XoT will clearly benefit from specific guidance on TCP/TLS connection usage for XFR because this will: </p>
<p/>
<ul>
<li>result in more consistent XoT implementations with better interoperability</li>
<li>remove any need for XoT implementations to support legacy behavior that XFR-over-TCP implementations have historically often supported</li>
</ul>
<p> </p>
<p id="rfc.section.5.p.5">Therefore this document updates both the previous specifications for XFR-over-TCP to clarify that implementations MUST use <a href="#RFC7766">[RFC7766]</a> (DNS Transport over TCP - Implementation Requirements) to optimize the use of TCP connections and SHOULD use <a href="#RFC7828">[RFC7828]</a> (The edns-tcp-keepalive EDNS0 Option) to manage persistent connections. </p>
<p id="rfc.section.5.p.6">The following sections include detailed clarifications on the updates to XFR behavior implied in <a href="#RFC7766">[RFC7766]</a> and how the use of <a href="#RFC7828">[RFC7828]</a> applies specifically to XFR exchanges. It also discusses how IXFR and AXFR can reuse the same TCP connection. </p>
<p id="rfc.section.5.p.7">For completeness, we also mention here the recent specification of extended DNS error (EDE) codes <a href="#RFC8914">[RFC8914]</a>. For zone transfers, when returning REFUSED to a zone transfer request to an 'unauthorized' client (e.g. where the client is not listed in an ACL for zone transfers or does not sign the request with the correct TSIG key), the extended DNS error code 18 (Prohibited) can also be sent. </p>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> <a href="#update-to-rfc1995-for-ixfrovertcp" id="update-to-rfc1995-for-ixfrovertcp">Update to RFC1995 for IXFR-over-TCP</a></h1>
<p id="rfc.section.5.1.p.1">For clarity - an IXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent IXoT requests on a single TCP connection (for the same and different zones) and SHOULD send the responses as soon as they are available, which might be out-of-order compared to the requests. </p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> <a href="#update-to-rfc5936-for-axfrovertcp" id="update-to-rfc5936-for-axfrovertcp">Update to RFC5936 for AXFR-over-TCP</a></h1>
<p id="rfc.section.5.2.p.1">For clarity - an AXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent AXoT sessions on a single TCP connection (for the same and different zones). The response streams for concurrent AXFRs MAY be intermingled and AXFR-over-TCP clients compliant with this specification MUST be able to handle this. </p>
<h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> <a href="#updates-to-rfc1995-and-rfc5936-for-xfrovertcp" id="updates-to-rfc1995-and-rfc5936-for-xfrovertcp">Updates to RFC1995 and RFC5936 for XFR-over-TCP</a></h1>
<h1 id="rfc.section.5.3.1"><a href="#rfc.section.5.3.1">5.3.1.</a> <a href="#connection-reuse" id="connection-reuse">Connection reuse</a></h1>
<p id="rfc.section.5.3.1.p.1">As specified, XFR-over-TCP clients SHOULD re-use any existing open TCP connection when starting any new XFR request to the same primary, and for issuing SOA queries, instead of opening a new connection. The number of TCP connections between a secondary and primary SHOULD be minimized (also see <a href="#update-to-rfc7766">Section 5.4</a>). </p>
<p id="rfc.section.5.3.1.p.2">Valid reasons for not re-using existing connections might include: </p>
<p/>
<ul>
<li>reaching a configured limit for the number of outstanding queries or XFR requests allowed on a single TCP connection</li>
<li>the message ID pool has already been exhausted on an open connection</li>
<li>a large number of timeouts or slow responses have occurred on an open connection</li>
<li>an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been received from the server and the client is in the process of closing the connection (see <a href="#the-ednstcpkeepalive-edns0-option">Section 5.3.4</a>)</li>
</ul>
<p> </p>
<p id="rfc.section.5.3.1.p.4">If no TCP connections are currently open, XFR clients MAY send SOA queries over UDP or a new TCP connection. </p>
<h1 id="rfc.section.5.3.2"><a href="#rfc.section.5.3.2">5.3.2.</a> <a href="#axfrs-and-ixfrs-on-the-same-connection" id="axfrs-and-ixfrs-on-the-same-connection">AXFRs and IXFRs on the same connection</a></h1>
<p id="rfc.section.5.3.2.p.1">Neither <a href="#RFC1995">[RFC1995]</a> nor <a href="#RFC5936">[RFC5936]</a> explicitly discuss the use of a single TCP connection for both IXFR and AXFR requests. <a href="#RFC5936">[RFC5936]</a> does make the general state: </p>
<pre>
"Non-AXFR session traffic can also use an open TCP connection."
</pre>
<p id="rfc.section.5.3.2.p.2">We clarify here that implementations capable of both AXFR and IXFR and compliant with this specification SHOULD </p>
<p/>
<ul>
<li>use the same TCP connection for both AXFR and IXFR requests to the same primary</li>
<li>pipeline such request and MAY intermingle them</li>
<li>send the response(s) for each request as soon as they are available i.e. responses MAY be sent intermingled</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.3.3"><a href="#rfc.section.5.3.3">5.3.3.</a> <a href="#xfr-limits" id="xfr-limits">XFR limits</a></h1>
<p id="rfc.section.5.3.3.p.1">The server MAY limit the number of concurrent IXFRs, AXFRs or total XFR transfers in progress, or from a given secondary, to protect server resources. </p>
<p id="rfc.section.5.3.3.p.2">[OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the limit on concurrent transfers is reached since this is regarded as a soft limit and a retry can/should succeed. Should there be a specific recommendation here about what is returned re: SERVFAIL vs REFUSED? </p>
<p id="rfc.section.5.3.3.p.3">[OPEN QUESTION] Is there a desire to define an additional XFR specific EDE code so that a client can determine why a specific XFR request was declined in this case e.g., Max concurrent XFR: too may concurrent transfers in progress. It could potentially contain a retry delay, or at least clients can apply a reasonable back-off for the retry. This could avoid retry storms which have been observed to actually increase the load on primaries in certain scenarios. </p>
<h1 id="rfc.section.5.3.4"><a href="#rfc.section.5.3.4">5.3.4.</a> <a href="#the-ednstcpkeepalive-edns0-option" id="the-ednstcpkeepalive-edns0-option">The edns-tcp-keepalive EDNS0 Option</a></h1>
<p id="rfc.section.5.3.4.p.1">XFR clients that send the edns-tcp-keepalive EDNS0 option on every XFR request provide the server with maximum opportunity to update the edns-tcp-keepalive timeout. The XFR server may use the frequency of recent XFRs to calculate an average update rate as input to the decision of what edns-tcp-keepalive timeout to use. If the server does not support edns-tcp-keepalive the client MAY keep the connection open for a few seconds (<a href="#RFC7766">[RFC7766]</a> recommends that servers use timeouts of at least a few seconds). </p>
<p id="rfc.section.5.3.4.p.2">Whilst the specification for EDNS0 <a href="#RFC6891">[RFC6891]</a> does not specifically mention AXFRs, it does say </p>
<pre>
"If an OPT record is present in a received request, compliant
responders MUST include an OPT record in their respective
responses."
</pre>
<p id="rfc.section.5.3.4.p.3">We clarify here that if an OPT record is present in a received AXFR request, compliant responders MUST include an OPT record in each of the subsequent AXFR responses. Note that this requirement, combined with the use of edns-tcp-keepalive, enables AXFR servers to signal the desire to close a connection (when existing transactions have competed) due to low resources by sending an edns-tcp-keepalive EDNS0 option with a timeout of 0 on any AXFR response. This does not signal that the AXFR is aborted, just that the server wishes to close the connection as soon as possible. </p>
<h1 id="rfc.section.5.3.5"><a href="#rfc.section.5.3.5">5.3.5.</a> <a href="#backwards-compatibility" id="backwards-compatibility">Backwards compatibility</a></h1>
<p id="rfc.section.5.3.5.p.1">Certain legacy behaviors were noted in <a href="#RFC5936">[RFC5936]</a>, with provisos that implementations may want to offer options to fallback to legacy behavior when interoperating with servers known not to support <a href="#RFC5936">[RFC5936]</a>. For purposes of interoperability, IXFR and AXFR implementations may want to continue offering such configuration options, as well as supporting some behaviors that were underspecified prior to this work (e.g. performing IXFR and AXFRs on separate connections). However, XoT implementations should have no need to do so. </p>
<h1 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4.</a> <a href="#update-to-rfc7766" id="update-to-rfc7766">Update to RFC7766</a></h1>
<p><a href="#RFC7766">[RFC7766]</a> made general implementation recommendations with regard to TCP/TLS connection handling: </p>
<pre>
"To mitigate the risk of unintentional server overload, DNS
clients MUST take care to minimize the number of concurrent TCP
connections made to any individual server. It is RECOMMENDED
that for any given client/server interaction there SHOULD be no
more than one connection for regular queries, one for zone
transfers, and one for each protocol that is being used on top
of TCP (for example, if the resolver was using TLS). However,
it is noted that certain primary/ secondary configurations with
many busy zones might need to use more than one TCP connection
for zone transfers for operational reasons (for example, to
support concurrent transfers of multiple zones)."
</pre>
<p id="rfc.section.5.4.p.2">Whilst this recommends a particular behavior for the clients using TCP, it does not relax the requirement for servers to handle 'mixed' traffic (regular queries and zone transfers) on any open TCP/TLS connection. It also overlooks the potential that other transports might want to take the same approach with regard to using separate connections for different purposes. </p>
<p id="rfc.section.5.4.p.3">This specification for XoT updates the guidance in <a href="#RFC7766">[RFC7766]</a> to provide the same separation of connection purpose (regular queries and zone transfers) for all transports being used on top of TCP. Therefore, it is RECOMMENDED that for each protocol used on top of TCP in any given client/server interaction there SHOULD be no more than one connection for regular queries and one for zone transfers. As an illustration, it could be imagined that in future such an interaction could hypothetically include one or all of the following: </p>
<p/>
<ul>
<li>one TCP connection for regular queries</li>
<li>one TCP connection for zone transfers</li>
<li>one TLS connection for regular queries</li>
<li>one TLS connection for zone transfers</li>
<li>one DoH connection for regular queries</li>
<li>one DoH connection for zone transfers</li>
</ul>
<p> </p>
<p id="rfc.section.5.4.p.5">We provide specific details in the later sections of reasons where more than one connection for a given transport might be required for zone transfers from a particular client. </p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#xot-specification" id="xot-specification">XoT specification</a></h1>
<h1 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1.</a> <a href="#tls-versions" id="tls-versions">TLS versions</a></h1>
<p id="rfc.section.6.1.p.1">For improved security all implementations of this specification MUST use only TLS 1.3 <a href="#RFC8446">[RFC8446]</a> or later. </p>
<h1 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2.</a> <a href="#port-selection" id="port-selection">Port selection</a></h1>
<p id="rfc.section.6.2.p.1">The connection for XoT SHOULD be established using port 853, as specified in <a href="#RFC7858">[RFC7858]</a>, unless there is mutual agreement between the secondary and primary to use a port other than port 853 for XoT. There MAY be agreement to use different ports for AXoT and IXoT, or for different zones. </p>
<h1 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3.</a> <a href="#high-level-xot-descriptions" id="high-level-xot-descriptions">High level XoT descriptions</a></h1>
<p id="rfc.section.6.3.p.1">It is useful to note that in XoT 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. </p>
<p id="rfc.section.6.3.p.2">The figure below provides an outline of the AXoT mechanism including NOTIFYs. </p>
<pre>
Secondary Primary
| NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TLS
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
Figure 3. AXoT Mechanism
</pre>
<p id="rfc.section.6.3.p.3">The figure below provides an outline of the IXoT mechanism including NOTIFYs. </p>
<pre>
Secondary Primary
| NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| IXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | |
| | | TLS
| | | session
| IXFR Request | |
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | ---
Figure 1. IXoT Mechanism
</pre>
<h1 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4.</a> <a href="#xot-transfers" id="xot-transfers">XoT transfers</a></h1>
<p id="rfc.section.6.4.p.1">For a zone transfer between two end points to be considered protected with XoT all XFR requests and response for that zone MUST be sent over TLS connections where at a minimum: </p>
<p/>
<ul>
<li>the client MUST authenticate the server by use of an authentication domain name using a Strict Privacy Profile as described in <a href="#RFC8310">[RFC8310]</a></li>
<li>the server MUST validate the client is authorized to request or proxy a zone transfer by using one or both of the following: <ul><li>an IP based ACL (which can be either per-message or per-connection)</li><li>Mutual TLS (mTLS)</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.6.4.p.3">The server MAY also require a valid TSIG/SIG(0) signature, but this alone is not sufficient to authenticate the client or server. </p>
<p id="rfc.section.6.4.p.4">Authentication mechanisms are discussed in full in <a href="#authentication-mechanisms">Section 8</a> and the rationale for the above requirement in <a href="#xot-authentication">Section 9</a>. Transfer group policies are discussed in <a href="#policies-for-both-axot-and-ixot">Section 10</a>. </p>
<h1 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5.</a> <a href="#xot-connections" id="xot-connections">XoT connections</a></h1>
<p id="rfc.section.6.5.p.1">The details in <a href="#updates-to-existing-specifications">Section 5</a> about e.g., persistent connections and XFR message handling are fully applicable to XoT connections as well. However any behavior specified here takes precedence for XoT. </p>
<p id="rfc.section.6.5.p.2">If no TLS connections are currently open, XoT clients MAY send SOA queries over UDP or TCP, or TLS. </p>
<h1 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6.</a> <a href="#xot-vs-adot" id="xot-vs-adot">XoT vs ADoT</a></h1>
<p id="rfc.section.6.6.p.1">As noted earlier, there is currently no specification for encryption of connections from recursive resolvers to authoritative servers. Some authoritatives are experimenting with ADoT and opportunistic encryption has also been raised as a possibility; it is therefore highly likely that use of encryption by authoritative servers will evolve in the coming years. </p>
<p id="rfc.section.6.6.p.2">This raises questions in the short term,§§ with regard to TLS connection and message handling for authoritative servers. In particular, there is likely to be a class of authoritatives that wish to use XoT in the near future with a small number of configured secondaries but that do wish to support DoT for regular queries from recursive in that same time frame. These servers have to potentially cope with probing and direct queries from recursives and from test servers, and also potential attacks that might wish to make use of TLS to overload the server. </p>
<p><a href="#RFC5936">[RFC5936]</a> clearly states that non-AXFR session traffic can use an open TCP connection, however, this requirement needs to be re-evaluated when considering applying the same model to XoT. Proposing that a server should also start responding to all queries received over TLS just because it has enabled XoT would be equivalent to defining a form of authoritative DoT. This specification does not propose that, but it also does not prohibit servers from answering queries unrelated to XFR exchanges over TLS. Rather, this specification simply outlines in later sections: </p>
<p/>
<ul>
<li>how XoT implementations should utilize EDE codes in response to queries on TLS connections they are not willing to answer (see <a href="#response-rcodes">Section 6.7</a>)</li>
<li>the operational and policy options that a XoT server operator has with regard to managing TLS connections and messages (see <a href="#xot-server-connection-handling">Appendix A</a>)</li>
</ul>
<p> </p>
<h1 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7.</a> <a href="#response-rcodes" id="response-rcodes">Response RCODES</a></h1>
<p id="rfc.section.6.7.p.1">XoT clients and servers MUST implement EDE codes. If a XoT server receives non-XoT traffic it is not willing to answer on a TLS connection it SHOULD respond with the extended DNS error code 21 - Not Supported <a href="#RFC8914">[RFC8914]</a>. XoT clients should not send any further queries of this type to the server for a reasonable period of time (for example, one hour) i.e., long enough that the server configuration or policy might be updated. </p>
<p id="rfc.section.6.7.p.2">[OPEN QUESTION] Should this instead be Prohibited (by policy), or should a new EDE be created for this case? </p>
<p id="rfc.section.6.7.p.3">Historically servers have used the REFUSED RCODE for many situations, and so clients often had no detailed information on which to base an error or fallback path when queries were refused. As a result the client behavior could vary significantly. XoT severs that refuse queries must cater for the fact that client behavior might vary from continually retrying queries regardless of receiving REFUSED to every query, or at the other extreme clients may decide to stop using the server over any transport. This might be because those clients are either non-XoT clients or do not implement EDE codes. </p>
<h1 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8.</a> <a href="#axot-specifics" id="axot-specifics">AXoT specifics</a></h1>
<h1 id="rfc.section.6.8.1"><a href="#rfc.section.6.8.1">6.8.1.</a> <a href="#padding-axot-responses" id="padding-axot-responses">Padding AXoT responses</a></h1>
<p id="rfc.section.6.8.1.p.1">The goal of padding AXoT responses would be two fold: </p>
<p/>
<ul>
<li>to obfuscate the actual size of the transferred zone to minimize information leakage about the entire contents of the zone.</li>
<li>to obfuscate the incremental changes to the zone between SOA updates to minimize information leakage about zone update activity and growth.</li>
</ul>
<p> </p>
<p id="rfc.section.6.8.1.p.3">Note that the re-use of XoT connections for transfers of multiple different zones complicates any attempt to analyze the traffic size and timing to extract information. </p>
<p id="rfc.section.6.8.1.p.4">It is noted here that, depending on the padding policies eventually developed for XoT, the requirement to obfuscate the total zone size might require a server to create 'empty' AXoT responses. That is, AXoT responses that contain no RR's apart from an OPT RR containing the EDNS(0) option for padding. For example, without this capability the maximum size that a tiny zone could be padded to would theoretically be limited if there had to be a minimum of 1 RR per packet. </p>
<p id="rfc.section.6.8.1.p.5">However, as with existing AXFR, the last AXoT response message sent MUST contain the same SOA that was in the first message of the AXoT response series in order to signal the conclusion of the zone transfer. </p>
<p><a href="#RFC5936">[RFC5936]</a> says: </p>
<pre>
"Each AXFR response message SHOULD contain a sufficient number
of RRs to reasonably amortize the per-message overhead, up to
the largest number that will fit within a DNS message (taking
the required content of the other sections into account, as
described below)."
</pre>
<p id="rfc.section.6.8.1.p.7">'Empty' AXoT responses generated in order to meet a padding requirement will be exceptions to the above statement. For flexibility, future proofing and in order to guarantee support for future padding policies, we state here that secondary implementations MUST be resilient to receiving padded AXoT responses, including 'empty' AXoT responses that contain only an OPT RR containing the EDNS(0) option for padding. </p>
<p id="rfc.section.6.8.1.p.8">Recommendation of specific policies for padding AXoT responses are out of scope for this specification. Detailed considerations of such policies and the trade-offs involved are expected to be the subject of future work. </p>
<h1 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9.</a> <a href="#ixot-specifics" id="ixot-specifics">IXoT specifics</a></h1>
<h1 id="rfc.section.6.9.1"><a href="#rfc.section.6.9.1">6.9.1.</a> <a href="#condensation-of-responses" id="condensation-of-responses">Condensation of responses</a></h1>