-
Notifications
You must be signed in to change notification settings - Fork 7
/
draft-ietf-dprive-xfr-over-tls-02.txt
1512 lines (983 loc) · 56.4 KB
/
draft-ietf-dprive-xfr-over-tls-02.txt
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
dprive W. Toorop
Internet-Draft NLnet Labs
Updates: 1995, 7766 (if approved) S. Dickinson
Intended status: Standards Track Sinodun IT
Expires: January 14, 2021 S. Sahib
P. Aras
A. Mankin
Salesforce
July 13, 2020
DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-02
Abstract
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 contents collection via passive monitoring of zone transfers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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/.
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."
This Internet-Draft will expire on January 14, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Toorop, et al. Expires January 14, 2021 [Page 1]
Internet-Draft XFR-over-TLS July 2020
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 5
4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5
4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6
4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7
4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 8
4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Connections and Data Flows in XoT . . . . . . . . . . . . . . 8
5.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Connection usage . . . . . . . . . . . . . . . . . . . . 8
5.2.1. High level XoT descriptions . . . . . . . . . . . . . 9
5.2.2. Previous specifications . . . . . . . . . . . . . . . 9
5.3. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 10
5.4. Connection Establishment . . . . . . . . . . . . . . . . 10
5.4.1. Draft Version Identification . . . . . . . . . . . . 11
5.5. Port selection . . . . . . . . . . . . . . . . . . . . . 11
5.6. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 11
5.6.1. Coverage and relationship to RFC5936 . . . . . . . . 12
5.6.2. AXoT connection and message handling . . . . . . . . 12
5.6.3. Padding AXoT responses . . . . . . . . . . . . . . . 14
5.7. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. Coverage and relationship to RFC1995 . . . . . . . . 15
5.7.2. IXoT connection and message handling . . . . . . . . 15
5.7.3. Condensation of responses . . . . . . . . . . . . . . 16
5.7.4. Fallback to AXFR . . . . . . . . . . . . . . . . . . 16
5.7.5. Padding of IXoT responses . . . . . . . . . . . . . . 16
6. Multi-primary Configurations . . . . . . . . . . . . . . . . 16
7. Zone Transfer with DoT - Authentication . . . . . . . . . . . 17
7.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 18
7.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 18
7.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 18
7.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 19
Toorop, et al. Expires January 14, 2021 [Page 2]
Internet-Draft XFR-over-TLS July 2020
7.6. Comparison of Authentication Methods . . . . . . . . . . 19
8. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 20
9. Implementation Considerations . . . . . . . . . . . . . . . . 21
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11.1. Registration of XoT Identification String . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
16.1. Normative References . . . . . . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . 24
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
DNS has a number of privacy vulnerabilities, as discussed in detail
in [RFC7626]. Stub client to recursive resolver query privacy has
received the most attention to date, with standards track documents
for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH)
[RFC8484], and a proposal for DNS-over-QUIC
[I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy
requirements for exchanges between recursive resolvers and
authoritative servers [I-D.ietf-dprive-phase2-requirements] and some
suggestions for how signaling of DoT support by authoritatives might
work, e.g., [I-D.vandijk-dprive-ds-dot-signal-and-pin]. However
there is currently no RFC that specifically defines authoritative
support for DNS-over-TLS.
[RFC7626] established that stub client DNS query transactions are not
public and needed protection, but on zone transfer [RFC1995]
[RFC5936] it says only:
"Privacy risks for the holder of a zone (the risk that someone
gets the data) are discussed in [RFC5936] and [RFC5155]."
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:
o Person-laptop.example.org
Toorop, et al. Expires January 14, 2021 [Page 3]
Internet-Draft XFR-over-TLS July 2020
o MX-for-Location.example.org
o Service-tenant-from-another-org.example.org
There may also be regulatory, policy or other reasons why the zone
contents in full must be treated as private.
Neither of the RFCs mentioned in [RFC7626] 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.
[RFC5155] 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 [I-D.vcelak-nsec5]; zone
walking is now possible with NSEC3 due to crypto-breaking advances,
and NSEC5 is a response to this problem.
[RFC5155] does not address data obtained outside zone enumeration
(nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone
transfers (this draft) is orthogonal to preventing zone enumeration,
though they aim to protect the same information.
[RFC5936] specifies using TSIG [RFC2845] 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.
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 [RFC7858], seems like
a simple step forward. This document specifies how to use TLS as a
transport to prevent zone collection from zone transfers.
2. Terminology
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 [RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Privacy terminology is as described in Section 3 of [RFC6973].
Note that in this document we choose to use the terms 'primary' and
'secondary' for two servers engaged in zone transfers.
Toorop, et al. Expires January 14, 2021 [Page 4]
Internet-Draft XFR-over-TLS July 2020
DNS terminology is as described in [RFC8499].
DoT: DNS-over-TLS as specified in [RFC7858]
XoT: Generic XFR-over-TLS mechanisms as specified in this document
AXoT: AXFR-over-TLS
IXoT: IXFR over-TLS
3. Use Cases for XFR-over-TLS
o Confidentiality. Clearly using an encrypted transport for zone
transfers will defeat zone content leakage that can occur via
passive surveillance.
o Authentication. Use of single or mutual TLS authentication (in
combination with ACLs) can complement and potentially be an
alternative to TSIG.
o Performance. Existing AXFR and IXFR mechanisms have the burden of
backwards compatibility with older implementations based on the
original specifications in [RFC1034] and [RFC1035]. 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 [RFC5936]. Any
implementation of XFR-over-TLS (XoT) would obviously be required
to implement optimized and interoperable transfers as described in
[RFC5936], e.g., transfer of multiple zones over one connection.
o Performance. Current usage of TCP for IXFR is sub-optimal in some
cases i.e. connections are frequently closed after a single IXFR.
4. Connection and Data Flows in Existing XFR Mechanisms
The original specification for zone transfers in [RFC1034] and
[RFC1035] 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.
[RFC1995] and [RFC1996] 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.
[RFC5936] subsequently redefined the specification of AXFR to improve
performance and interoperability.
Toorop, et al. Expires January 14, 2021 [Page 5]
Internet-Draft XFR-over-TLS July 2020
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
o NOTIFY messages
o SOA queries
o Fallback from IXFR to AXFR
o Fallback from IXFR-over-UDP to IXFR-over-TCP
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.
4.1. AXFR Mechanism
The figure below provides an outline of an AXFR mechanism including
NOTIFYs.
Figure 1. AXFR Mechanism [1]
1. 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.
2. 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.
3. If the primary serial is higher than the secondaries serial
(using Serial Number Arithmetic [RFC1982]), 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.
[RFC5936] specifies that AXFR must use TCP as the transport protocol
but details that there is no restriction in the protocol that a
single TCP connection 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.
Further details of the limitations in existing AXFR implementations
are outlined in [RFC5936].
Toorop, et al. Expires January 14, 2021 [Page 6]
Internet-Draft XFR-over-TLS July 2020
4.2. IXFR Mechanism
The figure below provides an outline of the IXFR mechanism including
NOTIFYs.
Figure 1. IXFR Mechanism [2]
1. 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.
2. 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.
3. If the primary serial is higher than the secondaries serial
(using Serial Number Arithmetic [RFC1982]), the secondary makes
an IXFR request to the primary after the primary sends an IXFR
response.
[RFC1995] 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:
"Thus, a client should first make an IXFR query using UDP."
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.
However it is noted that at least two widely used open source
authoritative nameserver implementations (BIND [3] and NSD [4]) 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.
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 [RFC1995] to state that DNS implementations that
support IXFR-over-TCP MUST use [RFC7766] to optimize the use of TCP
connections and SHOULD use [RFC7858] to manage persistent
connections.
Toorop, et al. Expires January 14, 2021 [Page 7]
Internet-Draft XFR-over-TLS July 2020
4.3. Data Leakage of NOTIFY and SOA Message Exchanges
This section attempts to presents a rationale for also encrypting the
other messages in the XFR mechanism.
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.
4.3.1. NOTIFY
Unencrypted NOTIFY messages identify configured secondaries on the
primary.
[RFC1996] also states:
"If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE).
But since the only supported QTYPE for NOTIFY is SOA, this does not
pose a potential leak.
4.3.2. SOA
For hidden primaries or secondaries the SOA response leaks the degree
of lag of any downstream secondary.
5. Connections and Data Flows in XoT
5.1. TLS versions
For improved security all implementations of this specification MUST
use only TLS 1.3 [RFC8446] or later.
5.2. Connection usage
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.
The details in [RFC7766], [RFC7858] and [RFC8310] about, e.g.,
persistent connection and message handling are fully applicable to
XoT as well. However any behavior specified here takes precedence
for XoT.
Toorop, et al. Expires January 14, 2021 [Page 8]
Internet-Draft XFR-over-TLS July 2020
5.2.1. High level XoT descriptions
The figure below provides an outline of the AXoT mechanism including
NOTIFYs.
Figure 3: AXoT mechanism [5]
The figure below provides an outline of the IXoT mechanism including
NOTIFYs.
Figure 4: IXoT mechanism [6]
5.2.2. Previous specifications
We note that whilst [RFC5936] already recommends re-using open TCP
connections, it does state:
"Non-AXFR session traffic can also use an open TCP connection."
when discussing AXFR-over-TCP. It defines an AXFR session as an AXFR
query message and the sequence of AXFR response messages returned for
it. Note that this excludes any SOA queries issued as part of the
overall AXFR mechanism. This requirement needs to be re-evaluated
when considering applying the same model to XoT since
o There is no guarantee that a XoT server (which is very likely, but
not necessarily, a purely authoritative server) will also support
DoT for regular queries. Requiring a purely authoritative server
to also respond to any query over a TLS connection would be
equivalent to defining a form of authoritative DoT. We consider
this to be out of scope for this document, which is focussed
purely on zone transfers.
o It would, however, be optimal for XoT to include the capability to
send SOA queries over an already open TLS connection.
Moreover, it is worth noting that [RFC7766] made general
implementation recommendations with regard to TCP/TLS connection
handling:
Toorop, et al. Expires January 14, 2021 [Page 9]
Internet-Draft XFR-over-TLS July 2020
"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)."
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.
5.3. Update to RFC7766
This specification for XoT updates the guidance in [RFC7766] 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.
We provide specific details in the following sections of reasons
where more than one connection might be required for zone transfers.
5.4. Connection Establishment
This specification additionally limits the scope of XoT as defined
here to be the use of dedicated TLS connections (XoT connections) to
exchange only traffic specific to enabling zone transfers. The set
of transactions supported on such connections is limited to:
o AXFR
o IXFR
o SOA
and is collectively referred to hereafter as 'XoT traffic'.
Such connections MUST use an ALPN token of 'xot' during the TLS
handshake (see Section 11).
Toorop, et al. Expires January 14, 2021 [Page 10]
Internet-Draft XFR-over-TLS July 2020
In the absence of DNS specific capability signaling mechanisms this
greatly simplifies the implementation of XoT such that a XoT exchange
can occur between any primary and secondary regardless of the role of
each (e.g. purely authoritative, recursive resolver also
authoritatively hosting zones, stub) or of other DNS transport
capability each may have. It also clearly makes XoT support
orthogonal to any set of zone transfer authentication mechanisms
chosen by the two parties.
XoT clients MUST only send XoT traffic on XoT connections. If a XoT
server receives traffic other than XoT traffic on a XoT connection it
MUST respond with the extended DNS error code 21 - Not Supported
[I-D.ietf-dnsop-extended-error]. It SHOULD treat this as protocol
error and close the connection.
With the update to [RFC7766] guidance above, clients are free to open
separate connections to the server to make any other queries they may
need over either TLS, TCP or UDP. A specification for connections
that support both XoT traffic and non-XoT traffic may be the subject
of a future work.
5.4.1. Draft Version Identification
_RFC Editor's Note:_ Please remove this section prior to publication
of a final version of this document.
Only implementations of the final, published RFC can identify
themselves as "xot". Until such an RFC exists, implementations MUST
NOT identify themselves using this string.
Implementations of draft versions of the protocol MUST add the string
"-" and the corresponding draft number to the identifier. For
example, draft-ietf-dprive-xfr-over-tls-02 is identified using the
string "xot-02".
5.5. Port selection
The connection for XoT SHOULD be established using port 853, as
specified in [RFC7858], unless there is mutual agreement between the
secondary and primary to use a port other than port 853 for XoT.
There MAY be agreement to use different ports for AXoT and IXoT.
5.6. AXoT mechanism
Toorop, et al. Expires January 14, 2021 [Page 11]
Internet-Draft XFR-over-TLS July 2020
5.6.1. Coverage and relationship to RFC5936
[RFC5936] re-specified AXFR providing additional guidance beyond that
provided in [RFC1034] and [RFC1035]. For example, sections 4.1,
4.1.1 and 4.1.2 of [RFC5936] provide improved guidance for AXFR
clients and servers with regard to re-use of connections for multiple
AXFRs and AXFRs of different zones. However [RFC5936] was
constrained by having to be backwards compatible with some very early
basic implementations of AXFR.
Here we specify some optimized behaviors for AXoT, based closely on
those in [RFC5936], but without the constraint of backwards
compatibility since it is expected that all implementations of AXoT
fully implement the behavior described here.
Where any behavior is not explicitly described here, the behavior
specified in [RFC5936] MUST be followed. Any behavior specified here
takes precedence for AXoT implementations over that in [RFC5936].
5.6.2. AXoT connection and message handling
The first paragraph of Section 4.1.1 of [RFC5936] says that clients
SHOULD close the connection when there is no 'apparent need' to use
the connection for some time period.
For AXoT this requirement is updated: AXoT clients and servers SHOULD
use EDNS0 Keepalive [RFC7828] to establish the connection timeouts to
be used. The client SHOULD send the EDNS0 Keepalive option on every
AXoT request sent so that the server has every opportunity to update
the Keepalive timeout. The AXoT server may use the frequency of
recent AXFRs to calculate an average update rate as input to the
decision of what EDNS0 Keepalive timeout to use. If the server does
not support EDNS0 Keepalive the client MAY keep the connection open
for a few seconds ([RFC7766] recommends that servers use timeouts of
at least a few seconds).
Whilst the specification for EDNS0 [RFC6891] does not specifically
mention AXFRs, it does say
"If an OPT record is present in a received request, compliant
responders MUST include an OPT record in their respective
responses."
We clarify here that if an OPT record is present in a received AXoT
request, compliant responders MUST include an OPT record in each of
the subsequent AXoT responses. Note that this requirement, combined
with the use of EDNS0 Keepalive, enables AXoT servers to signal the
desire to close a connection due to low resources by sending an EDNS0
Toorop, et al. Expires January 14, 2021 [Page 12]
Internet-Draft XFR-over-TLS July 2020
Keepalive option with a timeout of 0 on any AXoT response (in the
absence of another way to signal the abort of a AXoT transfer).
An AXoT server MUST be able to handle multiple AXFR requests on a
single XoT connection (for the same and different zones).
[RFC5936] says:
"An AXFR client MAY use an already opened TCP connection to
start an AXFR session. Using an existing open connection is
RECOMMENDED over opening a new connection. (Non-AXFR session
traffic can also use an open connection.)"
For AXoT this requirement is updated: AXoT clients SHOULD re-use an
existing open XoT connection when starting any new AXoT session to
the same primary, and for issuing SOA queries, instead of opening a
new connection. The number of XoT connections between a secondary
and primary SHOULD be minimized.
Valid reasons for not re-using existing connections might include:
o reaching a configured limit for the number of outstanding queries
allowed on a single XoT connection
o the message ID pool has already been exhausted on an open
connection
o a large number of timeouts or slow responses have occurred on an
open connection
o an EDNS0 Keepalive option with a timeout of 0 has been received
from the server and the client is in the process of closing the
connection
If no XoT connections are currently open, AXoT clients MAY send SOA
queries over UDP, TCP or TLS.
[RFC5936] says:
"Some old AXFR clients expect each response message to contain
only a single RR. To interoperate with such clients, the server
MAY restrict response messages to a single RR."
This is opposed to the normal behavior of containing a sufficient
number of RRs to reasonably amortize the per-message overhead. We
clarify here that AXoT clients MUST be able to handle responses that
include multiple RRs, up to the largest number that will fit within a
DNS message (taking the required content of the other sections into
Toorop, et al. Expires January 14, 2021 [Page 13]
Internet-Draft XFR-over-TLS July 2020
account, as described here and in [RFC5936]). This removes any
burden on AXoT servers of having to accommodate a configuration
option or support for restricting responses to containing only a
single RR.
An AXoT client SHOULD pipeline AXFR requests for different zones on a
single XoT connection. An AXoT server SHOULD respond to those
requests as soon as the response is available i.e. potentially out of
order.
5.6.3. Padding AXoT responses
The goal of padding AXoT responses would be two fold:
o to obfuscate the actual size of the transferred zone to minimize
information leakage about the entire contents of the zone.
o to obfuscate the incremental changes to the zone between SOA
updates to minimize information leakage about zone update activity
and growth.
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.
We note here that any requirement to obfuscate the total zone size is
likely to 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. 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.
[RFC5936] says:
"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)."
'Empty' AXoT responses generated in order to meet a padding
requirement will be exceptions to the above statement. 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.
Toorop, et al. Expires January 14, 2021 [Page 14]
Internet-Draft XFR-over-TLS July 2020
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.
5.7. IXoT mechanism
5.7.1. Coverage and relationship to RFC1995
[RFC1995] 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.
We provide new guidance here specific to IXoT that aligns with the
guidance in [RFC5936] for AXFR, that in section Section 5.6 for AXoT,
and with that for performant TCP/TLS usage in [RFC7766] and
[RFC7858].
Where any behavior is not explicitly described here, the behavior
specified in [RFC1995] MUST be followed. Any behavior specified here
takes precedence for IXoT implementations over that in [RFC1995].
5.7.2. IXoT connection and message handling
In a manner entirely analogous to that described in paragraph 2 of
Section 5.6.2 IXoT clients and servers SHOULD use EDNS0 Keepalive
[RFC7828] to establish the connection timeouts to be used.
An IXoT server MUST be able to handle multiple IXoT requests on a
single XoT connection (for the same and different zones).
IXoT clients SHOULD re-use an existing open XoT connection when
making any new IXoT request to the same primary, and for issuing SOA
queries, instead of opening a new connection. The number of XoT
connections between a secondary and primary SHOULD be minimized.
Valid reasons for not re-using existing connections are the same as
those described in Section 5.6.2
If no XoT connections are currently open, IXoT clients MAY send SOA
queries over UDP, TCP or TLS.
An IXoT client SHOULD pipeline IXFR requests for different zones on a
single XoT connection. An IXoT server SHOULD respond to those
Toorop, et al. Expires January 14, 2021 [Page 15]
Internet-Draft XFR-over-TLS July 2020
requests as soon as the response is available i.e. potentially out of
order.
5.7.3. Condensation of responses
[RFC1995] says condensation of responses is optional and MAY be done.
Whilst it does add complexity to generating responses it can
significantly reduce the size of responses. However any such
reduction might be offset by increased message size due to padding.
This specification does not update the optionality of condensation.
5.7.4. Fallback to AXFR
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.
After a failed IXFR a IXoT client SHOULD request the AXFR on the
already open XoT connection.
5.7.5. Padding of IXoT responses
The goal of padding IXoT responses would be to obfuscate the
incremental changes to the zone between SOA updates to minimize
information leakage about zone update activity and growth. Both the
size and timing of the IXoT responses could reveal information.
IXFR responses can vary in size greatly from the order of 100 bytes
for one or two record updates, to tens of thousands of bytes for
large dynamic DNSSEC signed zones. The frequency of IXFR responses
can also depend greatly on if and how the zone is DNSSEC signed.
In order to guarantee support for future padding policies, we state
here that secondary implementations MUST be resilient to receiving
padded IXoT responses.
Recommendation of specific policies for padding IXoT 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.
6. Multi-primary Configurations
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
Toorop, et al. Expires January 14, 2021 [Page 16]
Internet-Draft XFR-over-TLS July 2020
configured primaries. It can then choose to send an XFR request to
the primary with the highest SOA (or other criteria, e.g., RTT).
When using persistent connections the secondary may have a XoT
connection already open to one or more primaries. Should a secondary
preferentially request an XFR from a primary to which it already has
an open XoT connection or the one with the highest SOA (assuming it
doesn't have a connection open to it already)?
Two extremes can be envisaged here. The first one can be considered
a 'preferred primary connection' model. In this 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.
The other extreme can be considered a 'parallel primary connection'
model. Here a secondary could keep multiple persistent connections
open to all available primaries and only request XFRs 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.
Recommendation of a particular scheme is out of scope of this
document but implementations are encouraged to provide configuration
options that allow operators to make choices about this behavior.
7. Zone Transfer with DoT - Authentication
7.1. TSIG
TSIG [RFC2845] provides a mechanism for two or more parties to use
shared 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.
7.2. SIG(0)
SIG(0) [RFC2535] similarly also provides a mechanism to digitally
sign a DNS message but uses public key authentication, where the
public keys are stored in DNS as KEY RRs and a private key is stored
Toorop, et al. Expires January 14, 2021 [Page 17]
Internet-Draft XFR-over-TLS July 2020
at the signer. It also provides party-to-party data authentication,
but not hop-to-hop channel authentication or confidentiality.
7.3. TLS
7.3.1. Opportunistic
Opportunistic TLS [RFC8310] provides a defense against passive
surveillance, providing on-the-wire confidentiality.
7.3.2. Strict
Strict TLS [RFC8310] 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.
7.3.3. Mutual
This is an extension to Strict TLS [RFC8310] 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.
7.4. IP Based ACL on the Primary
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.
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.
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