-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathdraft-ietf-dprive-xfr-over-tls-01.html
1041 lines (969 loc) · 59.2 KB
/
draft-ietf-dprive-xfr-over-tls-01.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.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 Connection and Data Flows in XoT"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Performance Considerations"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 TLS versions"/>
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 AXoT mechanism"/>
<link href="#rfc.section.5.4" rel="Chapter" title="5.4 IXoT mechanism"/>
<link href="#rfc.section.5.4.1" rel="Chapter" title="5.4.1 Fallback to AXFR"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Zone Transfer with DoT - Authentication"/>
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 TSIG"/>
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 SIG(0)"/>
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 TLS"/>
<link href="#rfc.section.6.3.1" rel="Chapter" title="6.3.1 Opportunistic"/>
<link href="#rfc.section.6.3.2" rel="Chapter" title="6.3.2 Strict"/>
<link href="#rfc.section.6.3.3" rel="Chapter" title="6.3.3 Mutual"/>
<link href="#rfc.section.6.4" rel="Chapter" title="6.4 IP Based ACL on the Primary"/>
<link href="#rfc.section.6.5" rel="Chapter" title="6.5 ZONEMD"/>
<link href="#rfc.section.6.6" rel="Chapter" title="6.6 Comparison of Authentication Methods"/>
<link href="#rfc.section.7" rel="Chapter" title="7 Policies for Both AXFR and IXFR"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Multi-primary Configurations"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Implementation Considerations"/>
<link href="#rfc.section.10" rel="Chapter" title="10 Implementation Status"/>
<link href="#rfc.section.11" rel="Chapter" title="11 IANA Considerations"/>
<link href="#rfc.section.12" rel="Chapter" title="12 Security Considerations"/>
<link href="#rfc.section.13" rel="Chapter" title="13 Acknowledgements"/>
<link href="#rfc.section.14" rel="Chapter" title="14 Changelog"/>
<link href="#rfc.references" rel="Chapter" title="15 References"/>
<link href="#rfc.references.1" rel="Chapter" title="15.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="15.2 Informative References"/>
<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="Zhang, H., Aras, P., Toorop, W., Dickinson, S., and A. Mankin" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-dprive-xfr-over-tls-01" />
<meta name="dct.issued" scheme="ISO8601" content="2020-5-20" />
<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 DNS-over-TLS to prevent zone contents collection via passive monitoring of zone transfers. " />
<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 DNS-over-TLS to prevent zone contents collection via passive monitoring of zone transfers. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">dprive</td>
<td class="right">H. Zhang</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">P. Aras</td>
</tr>
<tr>
<td class="left">Updates: 1995 (if approved)</td>
<td class="right">Salesforce</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">W. Toorop</td>
</tr>
<tr>
<td class="left">Expires: November 21, 2020</td>
<td class="right">NLnet Labs</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">S. Dickinson</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Sinodun IT</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">May 20, 2020</td>
</tr>
</tbody>
</table>
<p class="title">DNS Zone Transfer-over-TLS<br />
<span class="filename">draft-ietf-dprive-xfr-over-tls-01</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 DNS-over-TLS to prevent zone contents collection via passive monitoring of zone transfers. </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 November 21, 2020.</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>
<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">Connection and Data Flows in XoT</a></li>
<ul><li>5.1. <a href="#rfc.section.5.1">Performance Considerations</a></li>
<li>5.2. <a href="#rfc.section.5.2">TLS versions</a></li>
<li>5.3. <a href="#rfc.section.5.3">AXoT mechanism</a></li>
<li>5.4. <a href="#rfc.section.5.4">IXoT mechanism</a></li>
<ul><li>5.4.1. <a href="#rfc.section.5.4.1">Fallback to AXFR</a></li>
</ul></ul><li>6. <a href="#rfc.section.6">Zone Transfer with DoT - Authentication</a></li>
<ul><li>6.1. <a href="#rfc.section.6.1">TSIG</a></li>
<li>6.2. <a href="#rfc.section.6.2">SIG(0)</a></li>
<li>6.3. <a href="#rfc.section.6.3">TLS</a></li>
<ul><li>6.3.1. <a href="#rfc.section.6.3.1">Opportunistic</a></li>
<li>6.3.2. <a href="#rfc.section.6.3.2">Strict</a></li>
<li>6.3.3. <a href="#rfc.section.6.3.3">Mutual</a></li>
</ul><li>6.4. <a href="#rfc.section.6.4">IP Based ACL on the Primary</a></li>
<li>6.5. <a href="#rfc.section.6.5">ZONEMD</a></li>
<li>6.6. <a href="#rfc.section.6.6">Comparison of Authentication Methods</a></li>
</ul><li>7. <a href="#rfc.section.7">Policies for Both AXFR and IXFR</a></li>
<li>8. <a href="#rfc.section.8">Multi-primary Configurations</a></li>
<li>9. <a href="#rfc.section.9">Implementation Considerations</a></li>
<li>10. <a href="#rfc.section.10">Implementation Status</a></li>
<li>11. <a href="#rfc.section.11">IANA Considerations</a></li>
<li>12. <a href="#rfc.section.12">Security Considerations</a></li>
<li>13. <a href="#rfc.section.13">Acknowledgements</a></li>
<li>14. <a href="#rfc.section.14">Changelog</a></li>
<li>15. <a href="#rfc.references">References</a></li>
<ul><li>15.1. <a href="#rfc.references.1">Normative References</a></li>
<li>15.2. <a href="#rfc.references.2">Informative References</a></li>
</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="#I-D.ietf-dprive-rfc7626-bis">[I-D.ietf-dprive-rfc7626-bis]</a>. Stub client to recursive resolver query privacy has received the most attention to date. There are now standards track documents for three encryption capabilities for stub to recursive queries and more work going on to guide deployment of specifically DNS-over-TLS (DoT) <a href="#RFC7858">[RFC7858]</a> and DNS-over-HTTPS (DoH) <a href="#RFC8484">[RFC8484]</a>. </p>
<p><a href="#I-D.ietf-dprive-rfc7626-bis">[I-D.ietf-dprive-rfc7626-bis]</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>
<p id="rfc.section.1.p.3">"Privacy risks for the holder of a zone (the risk that someone gets the data) are discussed in [RFC5936] and [RFC5155]." </p>
<p id="rfc.section.1.p.4">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. 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.5">Neither of the RFCs mentioned in <a href="#I-D.ietf-dprive-rfc7626-bis">[I-D.ietf-dprive-rfc7626-bis]</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><a href="#RFC5155">[RFC5155]</a> specifies NSEC3 to prevent zone enumeration, which is when queries for the authenticated denial of existences records of DNSSEC allow a client to walk through the entire zone. Note that the need for this protection also motivates NSEC5 <a href="#I-D.vcelak-nsec5">[I-D.vcelak-nsec5]</a>; zone walking is now possible with NSEC3 due to crypto-breaking advances, and NSEC5 is a response to this problem. </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.9">Because the AXFR zone transfer is typically carried out-over-TCP from authoritative DNS protocol implementations, encrypting AXFR using DNS-over-TLS <a href="#RFC7858">[RFC7858]</a> seems like a simple step forward. This document specifies how to use DoT to prevent zone collection from zone transfers, including discussion of approaches for IXFR, which uses UDP or TCP. </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">XoT: Generic XFR-over-TLS mechanisms as specified in this document </p>
<p id="rfc.section.2.p.7">AXoT: AXFR-over-TLS </p>
<p id="rfc.section.2.p.8">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 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 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.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>
<p><a href="https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/02_updates/02-draft-svg/AXFR_mechanism.svg">Figure 1. AXFR Mechanism</a> </p>
<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.</li>
</ol>
<p> </p>
<p><a href="#RFC5936">[RFC5936]</a> specifies that AXFR must use TCP as the transport protocol but details that there is no restriction in the protocol that a single TCP session must be used only for a single AXFR exchange, or even solely for XFRs. 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>
<p id="rfc.section.4.1.p.5">Further details of the limitations in existing AXFR implementations are outlined in <a href="#RFC5936">[RFC5936]</a>. </p>
<p id="rfc.section.4.1.p.6">It is noted that unless the NOTIFY is sent over a trusted communication channel and/or signed by TSIG is can be spoofed causing unnecessary zone transfer attempts. </p>
<p id="rfc.section.4.1.p.7">Similarly unless the SOA query is sent over a trusted communication channel and/or signed by TSIG the response can, in principle, be spoofed causing a secondary to incorrectly believe its version of the zone is update to date. Repeated successful attacks on the SOA could result in a secondary serving stale zone data. </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>
<p><a href="https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/02_updates/02-draft-svg/IXFR%20mechanism.svg">Figure 1. IXFR Mechanism</a> </p>
<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 is says in non-normative language: </p>
<p id="rfc.section.4.2.p.5">"Thus, a client should first make an IXFR query using UDP." </p>
<p id="rfc.section.4.2.p.6">So there may be a forth step above where the client falls back to IXFR-over-TCP. There may also be a forth 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.7">However it is noted that at least two widely used open source authoritative nameserver implementations (<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>
<p id="rfc.section.4.2.p.8">It is noted that the specification for IXFR was published well before TCP was considered a first class transport for DNS. This document therefore updates <a href="#RFC1995">[RFC1995]</a> to state that DNS implementations that support IXFR-over-TCP MUST use <a href="#RFC7766">[RFC7766]</a> to optimise the use of TCP connections and SHOULD use <a href="#RFC7858">[RFC7858]</a> to manage persistent connections. </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 also 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>
<p id="rfc.section.4.3.1.p.3">"If ANCOUNT>0, then the answer section represents an unsecure hint at the new RRset for this . </p>
<p id="rfc.section.4.3.1.p.4">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 the degree of lag of any downstream secondary. </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#connection-and-data-flows-in-xot" id="connection-and-data-flows-in-xot">Connection and Data Flows in XoT</a></h1>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> <a href="#performance-considerations" id="performance-considerations">Performance Considerations</a></h1>
<p id="rfc.section.5.1.p.1">The details in <a href="#RFC7766">[RFC7766]</a>, <a href="#RFC7858">[RFC7858]</a> and <a href="#RFC8310">[RFC8310]</a> about e.g. using persistent connections and TLS Session Resumption <a href="#RFC5077">[RFC5077]</a> are fully applicable to XFR-over-TLS as well. </p>
<p id="rfc.section.5.1.p.2">It is RECOMMENDED that clients and servers that support XoT also implement EDNS0 Keepalive [RFC7828]. </p>
<p id="rfc.section.5.1.p.3">It is useful to note that in these mechanisms it is the secondary that initiates the TLS connection to the primary for a XFR request, so that in terms of connectivity the secondary is the TLS client and the primary the TLS server. </p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> <a href="#tls-versions" id="tls-versions">TLS versions</a></h1>
<p id="rfc.section.5.2.p.1">For improved security all implementations of this specification MUST use only TLS 1.3 [RFC8446] or later. </p>
<h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> <a href="#axot-mechanism" id="axot-mechanism">AXoT mechanism</a></h1>
<p id="rfc.section.5.3.p.1">The figure below provides an outline of the AXoT mechanism including NOTIFYs. </p>
<p><a href="https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/02_updates/02-draft-svg/AXoT_mechanism_1.svg">Figure 3: AXoT mechanism</a> </p>
<p id="rfc.section.5.3.p.3">The connection for AXFR-over-TLS 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 XFR-over-TLS. </p>
<p id="rfc.section.5.3.p.4">All implementations that support XoT MUST fully implement <a href="#RFC5953">[RFC5953]</a> behavior on TLS connections. </p>
<p id="rfc.section.5.3.p.5">Sections 4.1, 4.1.1 and 4.1.2 of <a href="#RFC5936">[RFC5936]</a> describe guidance for AXFR clients and servers with regard to re-use of sessions for multiple AXFRs, AXFRs of different zones and using TCP session for other queries including SOA. </p>
<p id="rfc.section.5.3.p.6">For clarity we restate here that an AXoT client MAY use an already opened TLS connection to send a AXFR request. Using an existing open connection is RECOMMENDED over opening a new connection. (Non-AXoT session traffic can also use an open connection.) </p>
<p id="rfc.section.5.3.p.7">For clarity we additionally state here that an AXoT client MAY use an already opened TLS connection to send a SOA request. Using an existing open connection is RECOMMENDED over opening a new connection. </p>
<p id="rfc.section.5.3.p.8">QUESTION: Should there be a requirement that the SOA is always done on a TLS connection if the XFR is? For the case when no transfer is required this could be unnecessary overhead. </p>
<h1 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4.</a> <a href="#ixot-mechanism" id="ixot-mechanism">IXoT mechanism</a></h1>
<p id="rfc.section.5.4.p.1">The figure below provides an outline of the IXoT mechanism including NOTIFYs. </p>
<p><a href="https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/02_updates/02-draft-svg/IXoT_mechanism_1.svg">Figure 4: IXoT mechanism</a> </p>
<p id="rfc.section.5.4.p.3">The connection for IXFR-over-TLS 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 XFR-over-TLS. </p>
<p><a href="#RFC1995">[RFC1995]</a> says nothing with respect to optimizing IXFRs over TCP or re-using already open TCP connections to perform IXFRs or other queries. We provide guidance here that aligns with the guidance in <a href="#RFC5936">[RFC5936]</a> for AXFR and with that for performant TCP/TLS usage in <a href="#RFC7766">[RFC7766]</a> and <a href="#RFC7858">[RFC7858]</a>. </p>
<p id="rfc.section.5.4.p.5">An IXoT client MAY use an already opened TLS connection to send a IXFR request. Using an existing open connection is RECOMMENDED over opening a new connection. (Non-IXoT session traffic can also use an open connection.) </p>
<p id="rfc.section.5.4.p.6">An IXoT client MAY use an already open TLS connection to send an SOA query. Using an existing open connection is RECOMMENDED over opening a new connection. </p>
<p id="rfc.section.5.4.p.7">An IXoT server MUST be able to handle multiple IXoT requests on a single TLS connection, as well as to handle other query/response transactions over it. </p>
<p id="rfc.section.5.4.p.8">An IXoT client MAY keep an existing TLS session open in the expectation it is likely to need to perform an IXFR in the near future. The client may use the frequency of recent IXFRs to calculate an average update rate and then use EDNS0 Keepalive to request an appropriate timeout from the server (if the server supports EDNS0 Keepalive). If the server does not support EDNS0 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.4.p.9">An IXoT client MAY pipeline IXFR requests for different zones on a single TLS connection. AN IXoT server MAY respond to those requests out of order. </p>
<p id="rfc.section.5.4.p.10">QUESTION: Since this is a new specification should there be a requirement that IXoT servers are RECOMMENDED to condense responses as described in Section 6 of [RFC1995]. [RFC1995] document says this is optional and MAY be done but it can significantly reduce the size of responses and may have implications for padding? </p>
<h1 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1.</a> <a href="#fallback-to-axfr" id="fallback-to-axfr">Fallback to AXFR</a></h1>
<p id="rfc.section.5.4.1.p.1">Fallback to AXFR can happen, for example, if the server is not able to provide an IXFR for the requested SOA. Implementations differ in how long they store zone deltas and how many may be stored at any one time. </p>
<p id="rfc.section.5.4.1.p.2">After a failed IXFR a IXoT client SHOULD request the AXFR on the already open TLS connection. </p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#zone-transfer-with-dot--authentication" id="zone-transfer-with-dot--authentication">Zone Transfer with DoT - Authentication</a></h1>
<h1 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1.</a> <a href="#tsig" id="tsig">TSIG</a></h1>
<p id="rfc.section.6.1.p.1">TSIG <a href="#RFC2845">[RFC2845]</a> provides a mechanism for two parties to exchange secret keys which can then be used to create a message digest to protect individual DNS messages. This allows each party to authenticate that a request or response (and the data in it) came from the other party, even if it was transmitted-over-an unsecured channel or via a proxy. It provides party-to-party data authentication, but not hop-to-hop channel authentication or confidentiality. </p>
<h1 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2.</a> <a href="#sig0" id="sig0">SIG(0)</a></h1>
<p id="rfc.section.6.2.p.1">TBD </p>
<h1 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3.</a> <a href="#tls" id="tls">TLS</a></h1>
<h1 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1.</a> <a href="#opportunistic" id="opportunistic">Opportunistic</a></h1>
<p id="rfc.section.6.3.1.p.1">Opportunistic TLS <a href="#RFC8310">[RFC8310]</a> provides a defence against passive surveillance, providing on-the-wire confidentiality. </p>
<h1 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2.</a> <a href="#strict" id="strict">Strict</a></h1>
<p id="rfc.section.6.3.2.p.1">Strict TLS <a href="#RFC8310">[RFC8310]</a> requires that a client is configured with an authentication domain name (and/or SPKI pinset) that should be used to authenticate the TLS handshake with the server. This additionally provides a defense for the client against active surveillance, providing client-to-server authentication and end-to-end channel confidentiality. </p>
<h1 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3.</a> <a href="#mutual" id="mutual">Mutual</a></h1>
<p id="rfc.section.6.3.3.p.1">This is an extension to Strict TLS <a href="#RFC8310">[RFC8310]</a> which requires that a client is configured with an authentication domain name (and/or SPKI pinset) and a client certificate. The client offers the certificate for authentication by the server and the client can authentic the server the same way as in Strict TLS. This provides a defense for both parties against active surveillance, providing bi-directional authentication and end-to-end channel confidentiality. </p>
<h1 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4.</a> <a href="#ip-based-acl-on-the-primary" id="ip-based-acl-on-the-primary">IP Based ACL on the Primary</a></h1>
<p id="rfc.section.6.4.p.1">Most DNS server implementations offer an option to configure an IP based Access Control List (ACL), which is often used in combination with TSIG based ACLs to restrict access to zone transfers on primary servers. </p>
<p id="rfc.section.6.4.p.2">This is also possible with XoT but it must be noted that as with TCP the implementation of such an ACL cannot be enforced on the primary until a XFR request is received on an established connection. </p>
<p id="rfc.section.6.4.p.3">If control were to be any more fine-grained than this then a separate, dedicated port would need to be agreed between primary and secondary for XoT such that implementations would be able to refuse connections on that port to all clients except those configured as secondaries. </p>
<h1 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5.</a> <a href="#zonemd" id="zonemd">ZONEMD</a></h1>
<p id="rfc.section.6.5.p.1">Message Digest for DNS Zones (ZONEMD) <a href="#I-D.ietf-dnsop-dns-zone-digest">[I-D.ietf-dnsop-dns-zone-digest]</a> digest is a mechanism that can be used to verify the content of a standalone zone. It is designed to be independent of the transmission channel or mechanism, allowing a general consumer of a zone to do origin authentication of the entire zone contents. Note that the current version of <a href="#I-D.ietf-dnsop-dns-zone-digest">[I-D.ietf-dnsop-dns-zone-digest]</a> states: </p>
<p><samp>As specified at this time, ZONEMD is not designed for use in large, dynamic zones due to the time and resources required for digest calculation. The ZONEMD record described in this document includes fields reserved for future work to support large, dynamic zones.</samp> </p>
<p id="rfc.section.6.5.p.3">It is complementary the above mechanisms and can be used in conjunction with XFR-over-TLS but is not considered further. </p>
<h1 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6.</a> <a href="#comparison-of-authentication-methods" id="comparison-of-authentication-methods">Comparison of Authentication Methods</a></h1>
<p id="rfc.section.6.6.p.1">The Table below compares the properties of each of the above methods in terms of what protection they provide to the secondary and primary servers during XoT in terms of: </p>
<p/>
<ul>
<li>'Data Auth': Authentication that the DNS message data is signed by the party with whom credentials were shared (the signing party may or may not be party operating the far end of a TCP/TLS connection in a 'proxy' scenario). For the primary the TSIG on the XFR request confirms that the requesting party is authorized to request zone data, for the secondary it authenticates the zone data that is received.</li>
<li>'Channel Conf': Confidentiality of the communication channel between the client and server (i.e. the two end points of a TCP/TLS connection).</li>
<li>Channel Auth: Authentication of the identity of party to whom a TCP/TLS connection is made (this might not be a direct connection between the primary and secondary in a proxy scenario).</li>
</ul>
<p> </p>
<p id="rfc.section.6.6.p.3">It is noted that zone transfer scenarios can vary from a simple single primary/secondary relationship where both servers are under the control of a single operator to a complex hierarchical structure which includes proxies and multiple operators. Each deployment scenario will require specific analysis to determine which authentication methods are best suited to the deployment model in question. </p>
<p><a href="https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/02_updates/02-draft-svg/Properties_of_Authentication_methods_for_XoT.svg">Table 1: Properties of Authentication methods for XoT</a> </p>
<p id="rfc.section.6.6.p.5">Based on this analysis it can be seen that: </p>
<p/>
<ul>
<li>A combination of Opportunistic TLS and TSIG provides both data authentication and channel confidentiality for both parties. However this does not stop a MitM attack on the channel which could be used to gather zone data.</li>
<li>Using just mutual TLS can be considered a standalone solution if the secondary has reason to place equivalent trust in channel authentication as data authentication e.g. the same operator runs both the primary and secondary.</li>
<li>Using TSIG, Strict TLS and an ACL on the primary provides all 3 properties for both parties with probably the lowest operational overhead.</li>
</ul>
<p> </p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#policies-for-both-axfr-and-ixfr" id="policies-for-both-axfr-and-ixfr">Policies for Both AXFR and IXFR</a></h1>
<p id="rfc.section.7.p.1">We call the entire group of servers involved in XFR (all the primaries and all the secondaries) the 'transfer group'. </p>
<p id="rfc.section.7.p.2">Within any transfer group both AXFRs and IXFRs for a zone SHOULD all use the same policy e.g. if AXFRs use AXoT all IXFRs SHOULD use IXoT. </p>
<p id="rfc.section.7.p.3">In order to assure the confidentiality of the zone information, the entire transfer group MUST have a consistent policy of requiring confidentiality. If any do not, this is a weak link for attackers to exploit. </p>
<p id="rfc.section.7.p.4">A XoT policy should specify </p>
<p/>
<ul>
<li>If TSIG is required</li>
<li>What kind of TLS is required (Opportunistic, Strict or mTLS)</li>
<li>If IP based ACLs should also be used.</li>
</ul>
<p> </p>
<p id="rfc.section.7.p.6">Since this may require configuration of a number of servers who may be under the control of different operators the desired consistency could be hard to enforce and audit in practice. </p>
<p id="rfc.section.7.p.7">Certain aspects of the Policies can be relatively easily tested independently e.g. by requesting zone transfers without TSIG, from unauthorized IP addresses or over cleartext DNS. Other aspects such as if a secondary will accept data without a TSIG digest or if secondaries are using Strict as opposed to Opportunistic TLS are more challenging. </p>
<p id="rfc.section.7.p.8">NOTE: The authors request feedback on this challenge and welcome suggestions of how to practically manage this. </p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#multiprimary-configurations" id="multiprimary-configurations">Multi-primary Configurations</a></h1>
<p id="rfc.section.8.p.1">Also known as multi-master configurations this model can provide flexibility and redundancy particularly for IXFR. A secondary will receive one or more NOTIFY messages and can send an SOA to all of the configured primaries. It can then choose to send an IXFR request to the primary with the highest SOA (or other criteria e.g. RTT). </p>
<p id="rfc.section.8.p.2">When using persistent connections the secondary may have a TLS connection already open to one or more primaries. Should a secondary preferentially request an IXFR from a primary to which it already has an open TLS connection or the one with the highest SOA (assuming it doesn't have a connection open to it already)? </p>
<p id="rfc.section.8.p.3">Two extremes can be envisaged here. In the first case the secondary continues to use one persistent connection to a single primary until it has reason not to. Reasons not to might include the primary repeatedly closing the connection, long RTTs on transfers or the SOA of the primary being an unacceptable lag behind the SOA of an alternative primary. </p>
<p id="rfc.section.8.p.4">At the other extreme a primary could keep multiple persistent connections open to all available primaries and only request IXFRs from the primary with the highest serial number. Since normally the number of secondaries and primaries in direct contact in a transfer group is reasonably low this might be feasible if latency is the most significant concern. </p>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#implementation-considerations" id="implementation-considerations">Implementation Considerations</a></h1>
<p id="rfc.section.9.p.1">TBD </p>
<h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a href="#implementation-status" id="implementation-status">Implementation Status</a></h1>
<p id="rfc.section.10.p.1">The 1.9.2 version of <a href="https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/Changelog">Unbound</a> includes an option to perform AXFR-over-TLS (instead of TCP). This requires the client (secondary) to authenticate the server (primary) using a configured authentication domain name. </p>
<p id="rfc.section.10.p.2">It is noted that use of a TLS proxy in front of the primary server is a simple deployment solution that can enable server side XoT. </p>
<h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a></h1>
<p id="rfc.section.11.p.1">TBD </p>
<h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a></h1>
<p id="rfc.section.12.p.1">This document specifies a security measure against a DNS risk: the risk that an attacker collects entire DNS zones through eavesdropping on clear text DNS zone transfers. It presents a new Security Consideration for DNS. Some questions to discuss are: </p>
<p/>
<ul>
<li>How should padding be used in IXFR?</li>
<li>Should there be an option to 'pad' an AXFR response (i.e. a set of AXFR responses on a given connection) to hide the zone size?</li>
</ul>
<p> </p>
<h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a></h1>
<p id="rfc.section.13.p.1">The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for review and discussions. </p>
<h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a href="#changelog" id="changelog">Changelog</a></h1>
<p id="rfc.section.14.p.1">draft-ietf-dprive-xfr-over-tls-00 </p>
<p/>
<ul>
<li>Minor editorial updates</li>
<li>Add requirement for TLS 1.3. or later</li>
</ul>
<p> </p>
<p id="rfc.section.14.p.3">draft-ietf-dprive-xfr-over-tls-00 </p>
<p/>
<ul>
<li>Rename after adoption and reference update.</li>
<li>Add placeholder for SIG(0) discussion</li>
<li>Update section on ZONEMD</li>
</ul>
<p> </p>
<p id="rfc.section.14.p.5">draft-hzpa-dprive-xfr-over-tls-02 </p>
<p/>
<ul>
<li>Substantial re-work of the document.</li>
</ul>
<p> </p>
<p id="rfc.section.14.p.7">draft-hzpa-dprive-xfr-over-tls-01 </p>
<p/>
<ul>
<li>Editorial changes, updates to references.</li>
</ul>
<p> </p>
<p id="rfc.section.14.p.9">draft-hzpa-dprive-xfr-over-tls-00 </p>
<p/>
<ul>
<li>Initial commit</li>
</ul>
<p> </p>
<h1 id="rfc.references"><a href="#rfc.references">15.</a> References</h1>
<h1 id="rfc.references.1"><a href="#rfc.references.1">15.1.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="I-D.ietf-dprive-rfc7626-bis">[I-D.ietf-dprive-rfc7626-bis]</b>
</td>
<td class="top"><a>Bortzmeyer, S.</a> and <a>S. Dickinson</a>, "<a href="http://tools.ietf.org/html/draft-ietf-dprive-rfc7626-bis-05">DNS Privacy Considerations</a>", Internet-Draft draft-ietf-dprive-rfc7626-bis-05, May 2020.</td>
</tr>
<tr>
<td class="reference">
<b id="I-D.vcelak-nsec5">[I-D.vcelak-nsec5]</b>
</td>
<td class="top"><a>Vcelak, J.</a>, <a>Goldberg, S.</a>, <a>Papadopoulos, D.</a>, <a>Huque, S.</a> and <a>D. Lawrence</a>, "<a href="http://tools.ietf.org/html/draft-vcelak-nsec5-08">NSEC5, DNSSEC Authenticated Denial of Existence</a>", Internet-Draft draft-vcelak-nsec5-08, December 2018.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC1995">[RFC1995]</b>
</td>
<td class="top"><a>Ohta, M.</a>, "<a href="http://tools.ietf.org/html/rfc1995">Incremental Zone Transfer in DNS</a>", RFC 1995, DOI 10.17487/RFC1995, August 1996.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a>Bradner, S.</a>, "<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2845">[RFC2845]</b>
</td>
<td class="top"><a>Vixie, P.</a>, <a>Gudmundsson, O.</a>, <a>Eastlake 3rd, D.</a> and <a>B. Wellington</a>, "<a href="http://tools.ietf.org/html/rfc2845">Secret Key Transaction Authentication for DNS (TSIG)</a>", RFC 2845, DOI 10.17487/RFC2845, May 2000.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5077">[RFC5077]</b>
</td>
<td class="top"><a>Salowey, J.</a>, <a>Zhou, H.</a>, <a>Eronen, P.</a> and <a>H. Tschofenig</a>, "<a href="http://tools.ietf.org/html/rfc5077">Transport Layer Security (TLS) Session Resumption without Server-Side State</a>", RFC 5077, DOI 10.17487/RFC5077, January 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5155">[RFC5155]</b>
</td>
<td class="top"><a>Laurie, B.</a>, <a>Sisson, G.</a>, <a>Arends, R.</a> and <a>D. Blacka</a>, "<a href="http://tools.ietf.org/html/rfc5155">DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</a>", RFC 5155, DOI 10.17487/RFC5155, March 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5936">[RFC5936]</b>
</td>
<td class="top"><a>Lewis, E.</a> and <a>A. Hoenes</a>, "<a href="http://tools.ietf.org/html/rfc5936">DNS Zone Transfer Protocol (AXFR)</a>", RFC 5936, DOI 10.17487/RFC5936, June 2010.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6973">[RFC6973]</b>
</td>
<td class="top"><a>Cooper, A.</a>, <a>Tschofenig, H.</a>, <a>Aboba, B.</a>, <a>Peterson, J.</a>, <a>Morris, J.</a>, <a>Hansen, M.</a> and <a>R. Smith</a>, "<a href="http://tools.ietf.org/html/rfc6973">Privacy Considerations for Internet Protocols</a>", RFC 6973, DOI 10.17487/RFC6973, July 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7858">[RFC7858]</b>
</td>
<td class="top"><a>Hu, Z.</a>, <a>Zhu, L.</a>, <a>Heidemann, J.</a>, <a>Mankin, A.</a>, <a>Wessels, D.</a> and <a>P. Hoffman</a>, "<a href="http://tools.ietf.org/html/rfc7858">Specification for DNS over Transport Layer Security (TLS)</a>", RFC 7858, DOI 10.17487/RFC7858, May 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC8174">[RFC8174]</b>
</td>
<td class="top"><a>Leiba, B.</a>, "<a href="http://tools.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a>", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC8310">[RFC8310]</b>
</td>
<td class="top"><a>Dickinson, S.</a>, <a>Gillmor, D.</a> and <a>T. Reddy</a>, "<a href="http://tools.ietf.org/html/rfc8310">Usage Profiles for DNS over TLS and DNS over DTLS</a>", RFC 8310, DOI 10.17487/RFC8310, March 2018.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC8484">[RFC8484]</b>
</td>
<td class="top"><a>Hoffman, P.</a> and <a>P. McManus</a>, "<a href="http://tools.ietf.org/html/rfc8484">DNS Queries over HTTPS (DoH)</a>", RFC 8484, DOI 10.17487/RFC8484, October 2018.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC8499">[RFC8499]</b>
</td>
<td class="top"><a>Hoffman, P.</a>, <a>Sullivan, A.</a> and <a>K. Fujiwara</a>, "<a href="http://tools.ietf.org/html/rfc8499">DNS Terminology</a>", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.references.2"><a href="#rfc.references.2">15.2.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="I-D.ietf-dnsop-dns-zone-digest">[I-D.ietf-dnsop-dns-zone-digest]</b>
</td>
<td class="top"><a>Wessels, D.</a>, <a>Barber, P.</a>, <a>Weinberg, M.</a>, <a>Kumari, W.</a> and <a>W. Hardaker</a>, "<a href="http://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-07">Message Digest for DNS Zones</a>", Internet-Draft draft-ietf-dnsop-dns-zone-digest-07, April 2020.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC1034">[RFC1034]</b>
</td>
<td class="top"><a>Mockapetris, P.</a>, "<a href="http://tools.ietf.org/html/rfc1034">Domain names - concepts and facilities</a>", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC1035">[RFC1035]</b>
</td>
<td class="top"><a>Mockapetris, P.</a>, "<a href="http://tools.ietf.org/html/rfc1035">Domain names - implementation and specification</a>", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC1982">[RFC1982]</b>
</td>
<td class="top"><a>Elz, R.</a> and <a>R. Bush</a>, "<a href="http://tools.ietf.org/html/rfc1982">Serial Number Arithmetic</a>", RFC 1982, DOI 10.17487/RFC1982, August 1996.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC1996">[RFC1996]</b>
</td>
<td class="top"><a>Vixie, P.</a>, "<a href="http://tools.ietf.org/html/rfc1996">A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</a>", RFC 1996, DOI 10.17487/RFC1996, August 1996.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5953">[RFC5953]</b>
</td>
<td class="top"><a>Hardaker, W.</a>, "<a href="http://tools.ietf.org/html/rfc5953">Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)</a>", RFC 5953, DOI 10.17487/RFC5953, August 2010.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7766">[RFC7766]</b>
</td>
<td class="top"><a>Dickinson, J.</a>, <a>Dickinson, S.</a>, <a>Bellis, R.</a>, <a>Mankin, A.</a> and <a>D. Wessels</a>, "<a href="http://tools.ietf.org/html/rfc7766">DNS Transport over TCP - Implementation Requirements</a>", RFC 7766, DOI 10.17487/RFC7766, March 2016.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.authors">
<a href="#rfc.authors">Authors' Addresses</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Han Zhang</span>
<span class="n hidden">
<span class="family-name">Zhang</span>
</span>
</span>
<span class="org vcardline">Salesforce</span>
<span class="adr">
<span class="vcardline">
<span class="locality">San Francisco, CA</span>,
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline">United States</span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Pallavi Aras</span>
<span class="n hidden">
<span class="family-name">Aras</span>
</span>
</span>
<span class="org vcardline">Salesforce</span>
<span class="adr">
<span class="vcardline">
<span class="locality">Herndon, VA</span>,
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline">United States</span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Willem Toorop</span>
<span class="n hidden">
<span class="family-name">Toorop</span>
</span>
</span>
<span class="org vcardline">NLnet Labs</span>
<span class="adr">
<span class="vcardline">Science Park 400</span>
<span class="vcardline">
<span class="locality">Amsterdam</span>,
<span class="region"></span>
<span class="code">1098 XH</span>
</span>
<span class="country-name vcardline">The Netherlands</span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Sara Dickinson</span>
<span class="n hidden">
<span class="family-name">Dickinson</span>
</span>