-
Notifications
You must be signed in to change notification settings - Fork 5
/
draft-ietf-dprive-bcp-op-11.html
2052 lines (1882 loc) · 125 KB
/
draft-ietf-dprive-bcp-op-11.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>Recommendations for DNS Privacy Service Operators</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 Scope"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Privacy-related documents"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Terminology"/>
<link href="#rfc.section.5" rel="Chapter" title="5 Recommendations for DNS privacy services"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 On the wire between client and server"/>
<link href="#rfc.section.5.1.1" rel="Chapter" title="5.1.1 Transport recommendations"/>
<link href="#rfc.section.5.1.2" rel="Chapter" title="5.1.2 Authentication of DNS privacy services"/>
<link href="#rfc.section.5.1.3" rel="Chapter" title="5.1.3 Protocol recommendations"/>
<link href="#rfc.section.5.1.4" rel="Chapter" title="5.1.4 DNSSEC"/>
<link href="#rfc.section.5.1.5" rel="Chapter" title="5.1.5 Availability"/>
<link href="#rfc.section.5.1.6" rel="Chapter" title="5.1.6 Service options"/>
<link href="#rfc.section.5.1.7" rel="Chapter" title="5.1.7 Impact of Encryption on Monitoring by DNS Privacy Service Operators"/>
<link href="#rfc.section.5.1.8" rel="Chapter" title="5.1.8 Limitations of fronting a DNS privacy service with a pure TLS proxy"/>
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Data at rest on the server"/>
<link href="#rfc.section.5.2.1" rel="Chapter" title="5.2.1 Data handling"/>
<link href="#rfc.section.5.2.2" rel="Chapter" title="5.2.2 Data minimization of network traffic"/>
<link href="#rfc.section.5.2.3" rel="Chapter" title="5.2.3 IP address pseudonymization and anonymization methods"/>
<link href="#rfc.section.5.2.4" rel="Chapter" title="5.2.4 Pseudonymization, anonymization, or discarding of other correlation data"/>
<link href="#rfc.section.5.2.5" rel="Chapter" title="5.2.5 Cache snooping"/>
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Data sent onwards from the server"/>
<link href="#rfc.section.5.3.1" rel="Chapter" title="5.3.1 Protocol recommendations"/>
<link href="#rfc.section.5.3.2" rel="Chapter" title="5.3.2 Client query obfuscation"/>
<link href="#rfc.section.5.3.3" rel="Chapter" title="5.3.3 Data sharing"/>
<link href="#rfc.section.6" rel="Chapter" title="6 DNS Recursive Operator Privacy (DROP) statement"/>
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Outline of a DROP statement"/>
<link href="#rfc.section.6.1.1" rel="Chapter" title="6.1.1 Policy"/>
<link href="#rfc.section.6.1.2" rel="Chapter" title="6.1.2 Practice"/>
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Enforcement/accountability"/>
<link href="#rfc.section.7" rel="Chapter" title="7 IANA considerations"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Security considerations"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Acknowledgements"/>
<link href="#rfc.section.10" rel="Chapter" title="10 Contributors"/>
<link href="#rfc.section.11" rel="Chapter" title="11 Changelog"/>
<link href="#rfc.references" rel="Chapter" title="12 References"/>
<link href="#rfc.references.1" rel="Chapter" title="12.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="12.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Documents"/>
<link href="#rfc.appendix.A.1" rel="Chapter" title="A.1 Potential increases in DNS privacy"/>
<link href="#rfc.appendix.A.2" rel="Chapter" title="A.2 Potential decreases in DNS privacy"/>
<link href="#rfc.appendix.A.3" rel="Chapter" title="A.3 Related operational documents"/>
<link href="#rfc.appendix.B" rel="Chapter" title="B IP address techniques"/>
<link href="#rfc.appendix.B.1" rel="Chapter" title="B.1 Categorization of techniques"/>
<link href="#rfc.appendix.B.2" rel="Chapter" title="B.2 Specific techniques"/>
<link href="#rfc.appendix.B.2.1" rel="Chapter" title="B.2.1 Google Analytics non-prefix filtering"/>
<link href="#rfc.appendix.B.2.2" rel="Chapter" title="B.2.2 dnswasher"/>
<link href="#rfc.appendix.B.2.3" rel="Chapter" title="B.2.3 Prefix-preserving map"/>
<link href="#rfc.appendix.B.2.4" rel="Chapter" title="B.2.4 Cryptographic Prefix-Preserving Pseudonymization"/>
<link href="#rfc.appendix.B.2.5" rel="Chapter" title="B.2.5 Top-hash Subtree-replicated Anonymization"/>
<link href="#rfc.appendix.B.2.6" rel="Chapter" title="B.2.6 ipcipher"/>
<link href="#rfc.appendix.B.2.7" rel="Chapter" title="B.2.7 Bloom filters"/>
<link href="#rfc.appendix.C" rel="Chapter" title="C Current policy and privacy statements"/>
<link href="#rfc.appendix.D" rel="Chapter" title="D Example DROP statement"/>
<link href="#rfc.appendix.D.1" rel="Chapter" title="D.1 Policy"/>
<link href="#rfc.appendix.D.2" rel="Chapter" title="D.2 Practice"/>
<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="Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-dprive-bcp-op-11" />
<meta name="dct.issued" scheme="ISO8601" content="2020-7-2" />
<meta name="dct.abstract" content="This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS Privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, and how the decisions and alternatives impact the privacy of users. " />
<meta name="description" content="This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS Privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, and how the decisions and alternatives impact the privacy of users. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">dprive</td>
<td class="right">S. Dickinson</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Sinodun IT</td>
</tr>
<tr>
<td class="left">Intended status: Best Current Practice</td>
<td class="right">B. Overeinder</td>
</tr>
<tr>
<td class="left">Expires: January 3, 2021</td>
<td class="right">R. van Rijswijk-Deij</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">NLnet Labs</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">July 2, 2020</td>
</tr>
</tbody>
</table>
<p class="title">Recommendations for DNS Privacy Service Operators<br />
<span class="filename">draft-ietf-dprive-bcp-op-11</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS Privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, and how the decisions and alternatives impact the privacy of users. </p>
<p>This document also presents a non-normative framework to assist writers of a DNS Recursive Operator Privacy Statement (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC6841). </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 January 3, 2021.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>2. <a href="#rfc.section.2">Scope</a></li>
<li>3. <a href="#rfc.section.3">Privacy-related documents</a></li>
<li>4. <a href="#rfc.section.4">Terminology</a></li>
<li>5. <a href="#rfc.section.5">Recommendations for DNS privacy services</a></li>
<ul><li>5.1. <a href="#rfc.section.5.1">On the wire between client and server</a></li>
<ul><li>5.1.1. <a href="#rfc.section.5.1.1">Transport recommendations</a></li>
<li>5.1.2. <a href="#rfc.section.5.1.2">Authentication of DNS privacy services</a></li>
<li>5.1.3. <a href="#rfc.section.5.1.3">Protocol recommendations</a></li>
<li>5.1.4. <a href="#rfc.section.5.1.4">DNSSEC</a></li>
<li>5.1.5. <a href="#rfc.section.5.1.5">Availability</a></li>
<li>5.1.6. <a href="#rfc.section.5.1.6">Service options</a></li>
<li>5.1.7. <a href="#rfc.section.5.1.7">Impact of Encryption on Monitoring by DNS Privacy Service Operators</a></li>
<li>5.1.8. <a href="#rfc.section.5.1.8">Limitations of fronting a DNS privacy service with a pure TLS proxy</a></li>
</ul><li>5.2. <a href="#rfc.section.5.2">Data at rest on the server</a></li>
<ul><li>5.2.1. <a href="#rfc.section.5.2.1">Data handling</a></li>
<li>5.2.2. <a href="#rfc.section.5.2.2">Data minimization of network traffic</a></li>
<li>5.2.3. <a href="#rfc.section.5.2.3">IP address pseudonymization and anonymization methods</a></li>
<li>5.2.4. <a href="#rfc.section.5.2.4">Pseudonymization, anonymization, or discarding of other correlation data</a></li>
<li>5.2.5. <a href="#rfc.section.5.2.5">Cache snooping</a></li>
</ul><li>5.3. <a href="#rfc.section.5.3">Data sent onwards from the server</a></li>
<ul><li>5.3.1. <a href="#rfc.section.5.3.1">Protocol recommendations</a></li>
<li>5.3.2. <a href="#rfc.section.5.3.2">Client query obfuscation</a></li>
<li>5.3.3. <a href="#rfc.section.5.3.3">Data sharing</a></li>
</ul></ul><li>6. <a href="#rfc.section.6">DNS Recursive Operator Privacy (DROP) statement</a></li>
<ul><li>6.1. <a href="#rfc.section.6.1">Outline of a DROP statement</a></li>
<ul><li>6.1.1. <a href="#rfc.section.6.1.1">Policy</a></li>
<li>6.1.2. <a href="#rfc.section.6.1.2">Practice</a></li>
</ul><li>6.2. <a href="#rfc.section.6.2">Enforcement/accountability</a></li>
</ul><li>7. <a href="#rfc.section.7">IANA considerations</a></li>
<li>8. <a href="#rfc.section.8">Security considerations</a></li>
<li>9. <a href="#rfc.section.9">Acknowledgements</a></li>
<li>10. <a href="#rfc.section.10">Contributors</a></li>
<li>11. <a href="#rfc.section.11">Changelog</a></li>
<li>12. <a href="#rfc.references">References</a></li>
<ul><li>12.1. <a href="#rfc.references.1">Normative References</a></li>
<li>12.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Documents</a></li>
<ul><li>A.1. <a href="#rfc.appendix.A.1">Potential increases in DNS privacy</a></li>
<li>A.2. <a href="#rfc.appendix.A.2">Potential decreases in DNS privacy</a></li>
<li>A.3. <a href="#rfc.appendix.A.3">Related operational documents</a></li>
</ul><li>Appendix B. <a href="#rfc.appendix.B">IP address techniques</a></li>
<ul><li>B.1. <a href="#rfc.appendix.B.1">Categorization of techniques</a></li>
<li>B.2. <a href="#rfc.appendix.B.2">Specific techniques</a></li>
<ul><li>B.2.1. <a href="#rfc.appendix.B.2.1">Google Analytics non-prefix filtering</a></li>
<li>B.2.2. <a href="#rfc.appendix.B.2.2">dnswasher</a></li>
<li>B.2.3. <a href="#rfc.appendix.B.2.3">Prefix-preserving map</a></li>
<li>B.2.4. <a href="#rfc.appendix.B.2.4">Cryptographic Prefix-Preserving Pseudonymization</a></li>
<li>B.2.5. <a href="#rfc.appendix.B.2.5">Top-hash Subtree-replicated Anonymization</a></li>
<li>B.2.6. <a href="#rfc.appendix.B.2.6">ipcipher</a></li>
<li>B.2.7. <a href="#rfc.appendix.B.2.7">Bloom filters</a></li>
</ul></ul><li>Appendix C. <a href="#rfc.appendix.C">Current policy and privacy statements</a></li>
<li>Appendix D. <a href="#rfc.appendix.D">Example DROP statement</a></li>
<ul><li>D.1. <a href="#rfc.appendix.D.1">Policy</a></li>
<li>D.2. <a href="#rfc.appendix.D.2">Practice</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">The Domain Name System (DNS) is at the core of the Internet; almost every activity on the Internet starts with a DNS query (and often several). However the DNS was not originally designed with strong security or privacy mechanisms. A number of developments have taken place in recent years which aim to increase the privacy of the DNS system and these are now seeing some deployment. This latest evolution of the DNS presents new challenges to operators and this document attempts to provide an overview of considerations for privacy focused DNS services. </p>
<p id="rfc.section.1.p.2">In recent years there has also been an increase in the availability of "public resolvers" <a href="#RFC8499">[RFC8499]</a> which users may prefer to use instead of the default network resolver either because they offer a specific feature (e.g., good reachability or encrypted transport) or because the network resolver lacks a specific feature (e.g., strong privacy policy or unfiltered responses). These open resolvers have tended to be at the forefront of adoption of privacy-related enhancements but it is anticipated that operators of other resolver services will follow. </p>
<p id="rfc.section.1.p.3">Whilst protocols that encrypt DNS messages on the wire provide protection against certain attacks, the resolver operator still has (in principle) full visibility of the query data and transport identifiers for each user. Therefore, a trust relationship (whether explicit or implicit) is assumed to exist between each user and the operator of the resolver(s) used by that user. The ability of the operator to provide a transparent, well documented, and secure privacy service will likely serve as a major differentiating factor for privacy conscious users if they make an active selection of which resolver to use. </p>
<p id="rfc.section.1.p.4">It should also be noted that the choice of a user to configure a single resolver (or a fixed set of resolvers) and an encrypted transport to use in all network environments has both advantages and disadvantages. For example, the user has a clear expectation of which resolvers have visibility of their query data. However, this resolver/transport selection may provide an added mechanism to track them as they move across network environments. Commitments from resolver operators to minimize such tracking as users move between networks are also likely to play a role in user selection of resolvers. </p>
<p id="rfc.section.1.p.5">More recently the global legislative landscape with regard to personal data collection, retention, and pseudonymization has seen significant activity. Providing detailed practice advice about these areas to the operator is out of scope, but <a href="#data-sharing">Section 5.3.3</a> describes some mitigations of data sharing risk. </p>
<p id="rfc.section.1.p.6">This document has two main goals: </p>
<p/>
<ul>
<li>To provide operational and policy guidance related to DNS over encrypted transports and to outline recommendations for data handling for operators of DNS privacy services.</li>
<li>To introduce the DNS Recursive Operator Privacy (DROP) statement and present a framework to assist writers of a DROP statement. A DROP statement is a document that an operator should publish which outlines their operational practices and commitments with regard to privacy, thereby providing a means for clients to evaluate both the measurable and claimed privacy properties of a given DNS privacy service. The framework identifies a set of elements and specifies an outline order for them. This document does not, however, define a particular Privacy statement, nor does it seek to provide legal advice as to the contents.</li>
</ul>
<p> </p>
<p id="rfc.section.1.p.8">A desired operational impact is that all operators (both those providing resolvers within networks and those operating large public services) can demonstrate their commitment to user privacy thereby driving all DNS resolution services to a more equitable footing. Choices for users would (in this ideal world) be driven by other factors, e.g., differing security policies or minor difference in operator policy, rather than gross disparities in privacy concerns. </p>
<p id="rfc.section.1.p.9">Community insight [or judgment?] about operational practices can change quickly, and experience shows that a Best Current Practice (BCP) document about privacy and security is a point-in-time statement. Readers are advised to seek out any updates that apply to this document. </p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#scope" id="scope">Scope</a></h1>
<p id="rfc.section.2.p.1">"DNS Privacy Considerations" <a href="#RFC7626">[RFC7626]</a> describes the general privacy issues and threats associated with the use of the DNS by Internet users and much of the threat analysis here is lifted from that document and from <a href="#RFC6973">[RFC6973]</a>. However this document is limited in scope to best practice considerations for the provision of DNS privacy services by servers (recursive resolvers) to clients (stub resolvers or forwarders). Choices that are made exclusively by the end user, or those for operators of authoritative nameservers are out of scope. </p>
<p id="rfc.section.2.p.2">This document includes (but is not limited to) considerations in the following areas: </p>
<p/>
<ol>
<li>Data "on the wire" between a client and a server.</li>
<li>Data "at rest" on a server (e.g., in logs).</li>
<li>Data "sent onwards" from the server (either on the wire or shared with a third party).</li>
</ol>
<p> </p>
<p id="rfc.section.2.p.4">Whilst the issues raised here are targeted at those operators who choose to offer a DNS privacy service, considerations for areas 2 and 3 could equally apply to operators who only offer DNS over unencrypted transports but who would otherwise like to align with privacy best practice. </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#privacyrelated-documents" id="privacyrelated-documents">Privacy-related documents</a></h1>
<p id="rfc.section.3.p.1">There are various documents that describe protocol changes that have the potential to either increase or decrease the privacy properties of the DNS in various ways. Note this does not imply that some documents are good or bad, better or worse, just that (for example) some features may bring functional benefits at the price of a reduction in privacy and conversely some features increase privacy with an accompanying increase in complexity. A selection of the most relevant documents are listed in <a href="#documents">Appendix A</a> for reference. </p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#terminology" id="terminology">Terminology</a></h1>
<p id="rfc.section.4.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> <a href="#RFC8174">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here. </p>
<p id="rfc.section.4.p.2">DNS terminology is as described in <a href="#RFC8499">[RFC8499]</a> with one modification: we restate the clause in the original definition of Privacy-enabling DNS server in <a href="#RFC8310">[RFC8310]</a> to include the requirement that a DNS over (D)TLS server should also offer at least one of the credentials described in Section 8 of <a href="#RFC8310">[RFC8310]</a> and implement the (D)TLS profile described in Section 9 of <a href="#RFC8310">[RFC8310]</a>. </p>
<p id="rfc.section.4.p.3">Other Terms: </p>
<p/>
<ul>
<li>DROP: DNS Recursive Operator Privacy statement, see <a href="#dns-recursive-operator-privacy-drop-statement">Section 6</a>.</li>
<li>DNS privacy service: The service that is offered via a privacy-enabling DNS server and is documented either in an informal statement of policy and practice with regard to users privacy or a formal DROP statement.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#recommendations-for-dns-privacy-services" id="recommendations-for-dns-privacy-services">Recommendations for DNS privacy services</a></h1>
<p id="rfc.section.5.p.1">In the following sections we first outline the threats relevant to the specific topic and then discuss the potential actions that can be taken to mitigate them. </p>
<p id="rfc.section.5.p.2">We describe two classes of threats: </p>
<p/>
<ul>
<li>Threats described in <a href="#RFC6973">[RFC6973]</a> 'Privacy Considerations for Internet Protocols' <ul><li>Privacy terminology, threats to privacy, and mitigations as described in Sections 3, 5, and 6 of <a href="#RFC6973">[RFC6973]</a>.</li></ul></li>
<li>DNS Privacy Threats <ul><li>These are threats to the users and operators of DNS privacy services that are not directly covered by <a href="#RFC6973">[RFC6973]</a>. These may be more operational in nature such as certificate management or service availability issues.</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.p.4">We describe three classes of actions that operators of DNS privacy services can take: </p>
<p/>
<ul>
<li>Threat mitigation for well understood and documented privacy threats to the users of the service and in some cases to the operators of the service.</li>
<li>Optimization of privacy services from an operational or management perspective.</li>
<li>Additional options that could further enhance the privacy and usability of the service.</li>
</ul>
<p> </p>
<p id="rfc.section.5.p.6">This document does not specify policy - only best practice, however for DNS Privacy services to be considered compliant with these best practice guidelines they SHOULD implement (where appropriate) all: </p>
<p/>
<ul>
<li>Threat mitigations to be minimally compliant.</li>
<li>Optimizations to be moderately compliant.</li>
<li>Additional options to be maximally compliant.</li>
</ul>
<p> </p>
<p id="rfc.section.5.p.8">The rest of this document does not use normative language but instead refers only to the three differing classes of action which correspond to the three named levels of compliance stated above. However, compliance (to the indicated level) remains a normative requirement. </p>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> <a href="#on-the-wire-between-client-and-server" id="on-the-wire-between-client-and-server">On the wire between client and server</a></h1>
<p id="rfc.section.5.1.p.1">In this section we consider both data on the wire and the service provided to the client. </p>
<h1 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1.</a> <a href="#transport-recommendations" id="transport-recommendations">Transport recommendations</a></h1>
<p><a href="#RFC6973">[RFC6973]</a> Threats: </p>
<p/>
<ul>
<li>Surveillance: <ul><li>Passive surveillance of traffic on the wire</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.1.1.p.3">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Active injection of spurious data or traffic.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.1.p.5">Mitigations: </p>
<p id="rfc.section.5.1.1.p.6">A DNS privacy service can mitigate these threats by providing service over one or more of the following transports </p>
<p/>
<ul>
<li>DNS over TLS (DoT) <a href="#RFC7858">[RFC7858]</a> and <a href="#RFC8310">[RFC8310]</a>.</li>
<li>DNS over HTTPS (DoH) <a href="#RFC8484">[RFC8484]</a>.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.1.p.8">It is noted that a DNS privacy service can also be provided over DNS-over-DTLS <a href="#RFC8094">[RFC8094]</a>, however this is an Experimental specification and there are no known implementations at the time of writing. </p>
<p id="rfc.section.5.1.1.p.9">It is also noted that DNS privacy service might be provided over IPSec, DNSCrypt, or VPNs. However, there are no specific RFCs that cover the use of these transports for DNS and any discussion of best practice for providing such a service is out of scope for this document. </p>
<p id="rfc.section.5.1.1.p.10">Whilst encryption of DNS traffic can protect against active injection this does not diminish the need for DNSSEC, see <a href="#dnssec">Section 5.1.4</a>. </p>
<h1 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2.</a> <a href="#authentication-of-dns-privacy-services" id="authentication-of-dns-privacy-services">Authentication of DNS privacy services</a></h1>
<p><a href="#RFC6973">[RFC6973]</a> Threats: </p>
<p/>
<ul>
<li>Surveillance: <ul><li>Active attacks on client resolver configuration</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.1.2.p.3">Mitigations: </p>
<p id="rfc.section.5.1.2.p.4">DNS privacy services should ensure clients can authenticate the server. Note that this, in effect, commits the DNS privacy service to a public identity users will trust. </p>
<p id="rfc.section.5.1.2.p.5">When using DoT, clients that select a 'Strict Privacy' usage profile <a href="#RFC8310">[RFC8310]</a> (to mitigate the threat of active attack on the client) require the ability to authenticate the DNS server. To enable this, DNS privacy services that offer DNS-over-TLS need to provide credentials that will be accepted by the client's trust model, in the form of either X.509 certificates <a href="#RFC5280">[RFC5280]</a> or Subject Public Key Info (SPKI) pin sets <a href="#RFC8310">[RFC8310]</a>. </p>
<p id="rfc.section.5.1.2.p.6">When offering DoH <a href="#RFC8484">[RFC8484]</a>, HTTPS requires authentication of the server as part of the protocol. </p>
<p id="rfc.section.5.1.2.p.7">Server operators should also follow the best practices with regard to certificate revocation as described in <a href="#RFC7525">[RFC7525]</a>. </p>
<h1 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1.</a> <a href="#certificate-management" id="certificate-management">Certificate management</a></h1>
<p id="rfc.section.5.1.2.1.p.1">Anecdotal evidence to date highlights the management of certificates as one of the more challenging aspects for operators of traditional DNS resolvers that choose to additionally provide a DNS privacy service as management of such credentials is new to those DNS operators. </p>
<p id="rfc.section.5.1.2.1.p.2">It is noted that SPKI pin set management is described in <a href="#RFC7858">[RFC7858]</a> but that key pinning mechanisms in general have fallen out of favor operationally for various reasons such as the logistical overhead of rolling keys. </p>
<p id="rfc.section.5.1.2.1.p.3">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Invalid certificates, resulting in an unavailable service which might force a user to fallback to cleartext.</li>
<li>Mis-identification of a server by a client e.g., typos in DoH URL templates <a href="#RFC8484">[RFC8484]</a> or authentication domain names <a href="#RFC8310">[RFC8310]</a> which accidentally direct clients to attacker controlled servers.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.2.1.p.5">Mitigations: </p>
<p id="rfc.section.5.1.2.1.p.6">It is recommended that operators: </p>
<p/>
<ul>
<li>Follow the guidance in Section 6.5 of <a href="#RFC7525">[RFC7525]</a> with regards to certificate revocation.</li>
<li>Automate the generation, publication, and renewal of certificates. For example, ACME <a href="#RFC8555">[RFC8555]</a> provides a mechanism to actively manage certificates through automation and has been implemented by a number of certificate authorities.</li>
<li>Monitor certificates to prevent accidental expiration of certificates.</li>
<li>Choose a short, memorable authentication domain name for the service.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3.</a> <a href="#protocol-recommendations" id="protocol-recommendations">Protocol recommendations</a></h1>
<h1 id="rfc.section.5.1.3.1"><a href="#rfc.section.5.1.3.1">5.1.3.1.</a> <a href="#dot" id="dot">DoT</a></h1>
<p id="rfc.section.5.1.3.1.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Known attacks on TLS such as those described in <a href="#RFC7457">[RFC7457]</a>.</li>
<li>Traffic analysis, for example: <a href="#Pitfalls-of-DNS-Encryption">[Pitfalls-of-DNS-Encryption]</a>.</li>
<li>Potential for client tracking via transport identifiers.</li>
<li>Blocking of well known ports (e.g., 853 for DoT).</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.3.1.p.3">Mitigations: </p>
<p id="rfc.section.5.1.3.1.p.4">In the case of DoT, TLS profiles from Section 9 of <a href="#RFC8310">[RFC8310]</a> and the Countermeasures to DNS Traffic Analysis from section 11.1 of <a href="#RFC8310">[RFC8310]</a> provide strong mitigations. This includes but is not limited to: </p>
<p/>
<ul>
<li>Adhering to <a href="#RFC7525">[RFC7525]</a>.</li>
<li>Implementing only (D)TLS 1.2 or later as specified in <a href="#RFC8310">[RFC8310]</a>.</li>
<li>Implementing EDNS(0) Padding <a href="#RFC7830">[RFC7830]</a> using the guidelines in <a href="#RFC8467">[RFC8467]</a> or a successor specification.</li>
<li>Servers should not degrade in any way the query service level provided to clients that do not use any form of session resumption mechanism, such as TLS session resumption <a href="#RFC5077">[RFC5077]</a> with TLS 1.2, section 2.2 of <a href="#RFC8446">[RFC8446]</a>, or Domain Name System (DNS) Cookies <a href="#RFC7873">[RFC7873]</a>.</li>
<li>A DoT privacy service on both port 853 and 443. If the operator deploys DoH on the same IP address this requires the use of the 'dot' ALPN value <a href="#dot-ALPN">[dot-ALPN]</a>.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.3.1.p.6">Optimizations: </p>
<p/>
<ul>
<li>Concurrent processing of pipelined queries, returning responses as soon as available, potentially out of order as specified in <a href="#RFC7766">[RFC7766]</a>. This is often called 'OOOR' - out-of-order responses (providing processing performance similar to HTTP multiplexing).</li>
<li>Management of TLS connections to optimize performance for clients using <a href="#RFC7766">[RFC7766]</a> and EDNS(0) Keepalive <a href="#RFC7828">[RFC7828]</a></li>
</ul>
<p> </p>
<p id="rfc.section.5.1.3.1.p.8">Additional Options: </p>
<p id="rfc.section.5.1.3.1.p.9">Management of TLS connections to optimize performance for clients using DNS Stateful Operations <a href="#RFC8490">[RFC8490]</a>. </p>
<h1 id="rfc.section.5.1.3.2"><a href="#rfc.section.5.1.3.2">5.1.3.2.</a> <a href="#doh" id="doh">DoH</a></h1>
<p id="rfc.section.5.1.3.2.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Known attacks on TLS such as those described in <a href="#RFC7457">[RFC7457]</a>.</li>
<li>Traffic analysis, for example: <a href="#DNS-Privacy-not-so-private">[DNS-Privacy-not-so-private]</a>.</li>
<li>Potential for client tracking via transport identifiers.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.3.2.p.3">Mitigations: </p>
<p/>
<ul>
<li>Clients must be able to forgo the use of HTTP Cookies <a href="#RFC6265">[RFC6265]</a> and still use the service.</li>
<li>Use of HTTP/2 padding and/or EDNS(0) padding as described in Section 9 of <a href="#RFC8484">[RFC8484]</a></li>
<li>Clients should not be required to include any headers beyond the absolute minimum to obtain service from a DoH server. (See Section 6.1 of <a href="#I-D.ietf-httpbis-bcp56bis">[I-D.ietf-httpbis-bcp56bis]</a>.)</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.1.4"><a href="#rfc.section.5.1.4">5.1.4.</a> <a href="#dnssec" id="dnssec">DNSSEC</a></h1>
<p id="rfc.section.5.1.4.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Users may be directed to bogus IP addresses which, depending on the application, protocol and authentication method, might lead users to reveal personal information to attackers. One example is a website that doesn't use TLS or its TLS authentication can somehow be subverted.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.4.p.3">Mitigations: </p>
<p/>
<ul>
<li>All DNS privacy services must offer a DNS privacy service that performs Domain Name System Security Extensions (DNSSEC) validation. In addition they must be able to provide the DNSSEC RRs to the client so that it can perform its own validation.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.4.p.5">The addition of encryption to DNS does not remove the need for DNSSEC <a href="#RFC4033">[RFC4033]</a> - they are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other. </p>
<p id="rfc.section.5.1.4.p.6">While the use of an authenticated and encrypted transport protects origin authentication and data integrity between a client and a DNS privacy service it provides no proof (for a non-validating client) that the data provided by the DNS privacy service was actually DNSSEC authenticated. As with cleartext DNS the user is still solely trusting the AD bit (if present) set by the resolver. </p>
<p id="rfc.section.5.1.4.p.7">It should also be noted that the use of an encrypted transport for DNS actually solves many of the practical issues encountered by DNS validating clients e.g. interference by middleboxes with cleartext DNS payloads is completely avoided. In this sense a validating client that uses a DNS privacy service which supports DNSSEC has a far simpler task in terms of DNSSEC Roadblock avoidance <a href="#RFC8027">[RFC8027]</a>. </p>
<h1 id="rfc.section.5.1.5"><a href="#rfc.section.5.1.5">5.1.5.</a> <a href="#availability" id="availability">Availability</a></h1>
<p id="rfc.section.5.1.5.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>A failed DNS privacy service could force the user to switch providers, fallback to cleartext or accept no DNS service for the outage.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.5.p.3">Mitigations: </p>
<p id="rfc.section.5.1.5.p.4">A DNS privacy service should strive to engineer encrypted services to the same availability level as any unencrypted services they provide. Particular care should to be taken to protect DNS privacy services against denial-of-service attacks, as experience has shown that unavailability of DNS resolving because of attacks is a significant motivation for users to switch services. See, for example Section IV-C of <a href="#Passive-Observations-of-a-Large-DNS">[Passive-Observations-of-a-Large-DNS]</a>. </p>
<p id="rfc.section.5.1.5.p.5">Techniques such as those described in Section 10 of <a href="#RFC7766">[RFC7766]</a> can be of use to operators to defend against such attacks. </p>
<h1 id="rfc.section.5.1.6"><a href="#rfc.section.5.1.6">5.1.6.</a> <a href="#service-options" id="service-options">Service options</a></h1>
<p id="rfc.section.5.1.6.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Unfairly disadvantaging users of the privacy service with respect to the services available. This could force the user to switch providers, fallback to cleartext or accept no DNS service for the outage.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.6.p.3">Mitigations: </p>
<p id="rfc.section.5.1.6.p.4">A DNS privacy service should deliver the same level of service as offered on un-encrypted channels in terms of options such as filtering (or lack thereof), DNSSEC validation, etc. </p>
<h1 id="rfc.section.5.1.7"><a href="#rfc.section.5.1.7">5.1.7.</a> <a href="#impact-of-encryption-on-monitoring-by-dns-privacy-service-operators" id="impact-of-encryption-on-monitoring-by-dns-privacy-service-operators">Impact of Encryption on Monitoring by DNS Privacy Service Operators</a></h1>
<p id="rfc.section.5.1.7.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Increased use of encryption can impact DNS privacy service operator ability to monitor traffic and therefore manage their DNS servers <a href="#RFC8404">[RFC8404]</a>.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.7.p.3">Many monitoring solutions for DNS traffic rely on the plain text nature of this traffic and work by intercepting traffic on the wire, either using a separate view on the connection between clients and the resolver, or as a separate process on the resolver system that inspects network traffic. Such solutions will no longer function when traffic between clients and resolvers is encrypted. Many DNS privacy service operators still have need to inspect DNS traffic, e.g., to monitor for network security threats. Operators may therefore need to invest in alternative means of monitoring that relies on either the resolver software directly, or exporting DNS traffic from the resolver using e.g., <a href="#dnstap">[dnstap]</a>. </p>
<p id="rfc.section.5.1.7.p.4">Optimization: </p>
<p id="rfc.section.5.1.7.p.5">When implementing alternative means for traffic monitoring, operators of a DNS privacy service should consider using privacy conscious means to do so (see section <a href="#data-at-rest-on-the-server">Section 5.2</a> for more details on data handling and also the discussion on the use of Bloom Filters in <a href="#ip-address-techniques">Appendix B</a>. </p>
<h1 id="rfc.section.5.1.8"><a href="#rfc.section.5.1.8">5.1.8.</a> <a href="#limitations-of-fronting-a-dns-privacy-service-with-a-pure-tls-proxy" id="limitations-of-fronting-a-dns-privacy-service-with-a-pure-tls-proxy">Limitations of fronting a DNS privacy service with a pure TLS proxy</a></h1>
<p id="rfc.section.5.1.8.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Limited ability to manage or monitor incoming connections using DNS specific techniques.</li>
<li>Misconfiguration (e.g., of the target server address in the proxy configuration) could lead to data leakage if the proxy to target server path is not encrypted.</li>
</ul>
<p> </p>
<p id="rfc.section.5.1.8.p.3">Optimization: </p>
<p id="rfc.section.5.1.8.p.4">Some operators may choose to implement DoT using a TLS proxy (e.g. <a href="#nginx">[nginx]</a>, <a href="#haproxy">[haproxy]</a>, or <a href="#stunnel">[stunnel]</a>) in front of a DNS nameserver because of proven robustness and capacity when handling large numbers of client connections, load balancing capabilities and good tooling. Currently, however, because such proxies typically have no specific handling of DNS as a protocol over TLS or DTLS using them can restrict traffic management at the proxy layer and at the DNS server. For example, all traffic received by a nameserver behind such a proxy will appear to originate from the proxy and DNS techniques such as ACLs, RRL, or DNS64 will be hard or impossible to implement in the nameserver. </p>
<p id="rfc.section.5.1.8.p.5">Operators may choose to use a DNS aware proxy such as <a href="#dnsdist">[dnsdist]</a> which offers custom options (similar to that proposed in <a href="#I-D.bellis-dnsop-xpf">[I-D.bellis-dnsop-xpf]</a>) to add source information to packets to address this shortcoming. It should be noted that such options potentially significantly increase the leaked information in the event of a misconfiguration. </p>
<h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> <a href="#data-at-rest-on-the-server" id="data-at-rest-on-the-server">Data at rest on the server</a></h1>
<h1 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1.</a> <a href="#data-handling" id="data-handling">Data handling</a></h1>
<p><a href="#RFC6973">[RFC6973]</a> Threats: </p>
<p/>
<ul>
<li>Surveillance.</li>
<li>Stored data compromise.</li>
<li>Correlation.</li>
<li>Identification.</li>
<li>Secondary use.</li>
<li>Disclosure.</li>
</ul>
<p> </p>
<p id="rfc.section.5.2.1.p.3">Other Threats </p>
<p/>
<ul>
<li>Contravention of legal requirements not to process user data.</li>
</ul>
<p> </p>
<p id="rfc.section.5.2.1.p.5">Mitigations: </p>
<p id="rfc.section.5.2.1.p.6">The following are recommendations relating to common activities for DNS service operators and in all cases data retention should be minimized or completely avoided if possible for DNS privacy services. If data is retained it should be encrypted and either aggregated, pseudonymized, or anonymized whenever possible. In general the principle of data minimization described in <a href="#RFC6973">[RFC6973]</a> should be applied. </p>
<p/>
<ul>
<li>Transient data (e.g., that is used for real time monitoring and threat analysis which might be held only in memory) should be retained for the shortest possible period deemed operationally feasible.</li>
<li>The retention period of DNS traffic logs should be only those required to sustain operation of the service and, to the extent that such exists, meet regulatory requirements.</li>
<li>DNS privacy services should not track users except for the particular purpose of detecting and remedying technically malicious (e.g., DoS) or anomalous use of the service.</li>
<li>Data access should be minimized to only those personnel who require access to perform operational duties. It should also be limited to anonymized or pseudonymized data where operationally feasible, with access to full logs (if any are held) only permitted when necessary.</li>
</ul>
<p> </p>
<p id="rfc.section.5.2.1.p.8">Optimizations: </p>
<p/>
<ul>
<li>Consider use of full disk encryption for logs and data capture storage.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2.</a> <a href="#data-minimization-of-network-traffic" id="data-minimization-of-network-traffic">Data minimization of network traffic</a></h1>
<p id="rfc.section.5.2.2.p.1">Data minimization refers to collecting, using, disclosing, and storing the minimal data necessary to perform a task, and this can be achieved by removing or obfuscating privacy-sensitive information in network traffic logs. This is typically personal data, or data that can be used to link a record to an individual, but may also include revealing other confidential information, for example on the structure of an internal corporate network. </p>
<p id="rfc.section.5.2.2.p.2">The problem of effectively ensuring that DNS traffic logs contain no or minimal privacy-sensitive information is not one that currently has a generally agreed solution or any standards to inform this discussion. This section presents an overview of current techniques to simply provide reference on the current status of this work. </p>
<p id="rfc.section.5.2.2.p.3">Research into data minimization techniques (and particularly IP address pseudonymization/anonymization) was sparked in the late 1990s/early 2000s, partly driven by the desire to share significant corpuses of traffic captures for research purposes. Several techniques reflecting different requirements in this area and different performance/resource tradeoffs emerged over the course of the decade. Developments over the last decade have been both a blessing and a curse; the large increase in size between an IPv4 and an IPv6 address, for example, renders some techniques impractical, but also makes available a much larger amount of input entropy, the better to resist brute force re-identification attacks that have grown in practicality over the period. </p>
<p id="rfc.section.5.2.2.p.4">Techniques employed may be broadly categorized as either anonymization or pseudonymization. The following discussion uses the definitions from <a href="#RFC6973">[RFC6973]</a> Section 3, with additional observations from <a href="#van-Dijkhuizen-et-al.">[van-Dijkhuizen-et-al.]</a> </p>
<p/>
<ul>
<li>Anonymization. To enable anonymity of an individual, there must exist a set of individuals that appear to have the same attribute(s) as the individual. To the attacker or the observer, these individuals must appear indistinguishable from each other.</li>
<li>Pseudonymization. The true identity is deterministically replaced with an alternate identity (a pseudonym). When the pseudonymization schema is known, the process can be reversed, so the original identity becomes known again.</li>
</ul>
<p> </p>
<p id="rfc.section.5.2.2.p.6">In practice there is a fine line between the two; for example, how to categorize a deterministic algorithm for data minimization of IP addresses that produces a group of pseudonyms for a single given address. </p>
<h1 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3.</a> <a href="#ip-address-pseudonymization-and-anonymization-methods" id="ip-address-pseudonymization-and-anonymization-methods">IP address pseudonymization and anonymization methods</a></h1>
<p id="rfc.section.5.2.3.p.1">A major privacy risk in DNS is connecting DNS queries to an individual and the major vector for this in DNS traffic is the client IP address. </p>
<p id="rfc.section.5.2.3.p.2">There is active discussion in the space of effective pseudonymization of IP addresses in DNS traffic logs, however there seems to be no single solution that is widely recognized as suitable for all or most use cases. There are also as yet no standards for this that are unencumbered by patents. </p>
<p><a href="#ip-address-techniques">Appendix B</a> provides a more detailed survey of various techniques employed or under development in 2019. </p>
<h1 id="rfc.section.5.2.4"><a href="#rfc.section.5.2.4">5.2.4.</a> <a href="#pseudonymization-anonymization-or-discarding-of-other-correlation-data" id="pseudonymization-anonymization-or-discarding-of-other-correlation-data">Pseudonymization, anonymization, or discarding of other correlation data</a></h1>
<p id="rfc.section.5.2.4.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Fingerprinting of the client OS via various means including: IP TTL/Hoplimit, TCP parameters (e.g., window size, ECN support, SACK), OS specific DNS query patterns (e.g., for network connectivity, captive portal detection, or OS specific updates).</li>
<li>Fingerprinting of the client application or TLS library by, e.g., HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS version/Cipher suite combinations, or other connection parameters.</li>
<li>Correlation of queries on multiple TCP sessions originating from the same IP address.</li>
<li>Correlating of queries on multiple TLS sessions originating from the same client, including via session resumption mechanisms.</li>
<li>Resolvers <em>might</em> receive client identifiers, e.g., MAC addresses in EDNS(0) options - some Customer-premises equipment (CPE) devices are known to add them <a href="#MAC-address-EDNS">[MAC-address-EDNS]</a>.</li>
</ul>
<p> </p>
<p id="rfc.section.5.2.4.p.3">Mitigations: </p>
<p/>
<ul>
<li>Data minimization or discarding of such correlation data.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.2.5"><a href="#rfc.section.5.2.5">5.2.5.</a> <a href="#cache-snooping" id="cache-snooping">Cache snooping</a></h1>
<p><a href="#RFC6973">[RFC6973]</a> Threats: </p>
<p/>
<ul>
<li>Surveillance: <ul><li>Profiling of client queries by malicious third parties.</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.2.5.p.3">Mitigations: </p>
<p/>
<ul>
<li>See <a href="#ISC-Knowledge-database-on-cache-snooping">[ISC-Knowledge-database-on-cache-snooping]</a> for an example discussion on defending against cache snooping.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> <a href="#data-sent-onwards-from-the-server" id="data-sent-onwards-from-the-server">Data sent onwards from the server</a></h1>
<p id="rfc.section.5.3.p.1">In this section we consider both data sent on the wire in upstream queries and data shared with third parties. </p>
<h1 id="rfc.section.5.3.1"><a href="#rfc.section.5.3.1">5.3.1.</a> <a href="#protocol-recommendations-1" id="protocol-recommendations-1">Protocol recommendations</a></h1>
<p><a href="#RFC6973">[RFC6973]</a> Threats: </p>
<p/>
<ul>
<li>Surveillance: <ul><li>Transmission of identifying data upstream.</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.3.1.p.3">Mitigations: </p>
<p id="rfc.section.5.3.1.p.4">As specified in <a href="#RFC8310">[RFC8310]</a> for DoT but applicable to any DNS Privacy services the server should: </p>
<p/>
<ul>
<li>Implement QNAME minimization <a href="#RFC7816">[RFC7816]</a>.</li>
<li>Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the EDNS(0) Client Subnet (ECS) option (<a href="#RFC7871">[RFC7871]</a> Section 7.1.2).</li>
</ul>
<p> </p>
<p id="rfc.section.5.3.1.p.6">Optimizations: </p>
<p/>
<ul>
<li>As per Section 2 of <a href="#RFC7871">[RFC7871]</a> the server should either: <ul><li>not use the ECS option in upstream queries at all, or</li><li>offer alternative services, one that sends ECS and one that does not.</li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.3.1.p.8">If operators do offer a service that sends the ECS options upstream they should use the shortest prefix that is operationally feasible and ideally use a policy of allowlisting upstream servers to send ECS to in order to reduce data leakage. Operators should make clear in any policy statement what prefix length they actually send and the specific policy used. </p>
<p id="rfc.section.5.3.1.p.9">Allowlisting has the benefit that not only does the operator know which upstream servers can use ECS but also allows the operator to decide which upstream servers apply privacy policies that the operator is happy with. However some operators consider allowlisting to incur significant operational overhead compared to dynamic detection of ECS support on authoritative servers. </p>
<p id="rfc.section.5.3.1.p.10">Additional options: </p>
<p/>
<ul>
<li>Aggressive Use of DNSSEC-Validated Cache <a href="#RFC8198">[RFC8198]</a> and <a href="#RFC8020">[RFC8020]</a> (NXDOMAIN: There Really Is Nothing Underneath) to reduce the number of queries to authoritative servers to increase privacy.</li>
<li>Run a copy of the root zone on loopback <a href="#RFC7706">[RFC7706]</a> to avoid making queries to the root servers that might leak information.</li>
</ul>
<p> </p>
<h1 id="rfc.section.5.3.2"><a href="#rfc.section.5.3.2">5.3.2.</a> <a href="#client-query-obfuscation" id="client-query-obfuscation">Client query obfuscation</a></h1>
<p id="rfc.section.5.3.2.p.1">Additional options: </p>
<p id="rfc.section.5.3.2.p.2">Since queries from recursive resolvers to authoritative servers are performed using cleartext (at the time of writing), resolver services need to consider the extent to which they may be directly leaking information about their client community via these upstream queries and what they can do to mitigate this further. Note, that even when all the relevant techniques described above are employed there may still be attacks possible, e.g. <a href="#Pitfalls-of-DNS-Encryption">[Pitfalls-of-DNS-Encryption]</a>. For example, a resolver with a very small community of users risks exposing data in this way and ought to obfuscate this traffic by mixing it with 'generated' traffic to make client characterization harder. The resolver could also employ aggressive pre-fetch techniques as a further measure to counter traffic analysis. </p>
<p id="rfc.section.5.3.2.p.3">At the time of writing there are no standardized or widely recognized techniques to perform such obfuscation or bulk pre-fetches. </p>
<p id="rfc.section.5.3.2.p.4">Another technique that particularly small operators may consider is forwarding local traffic to a larger resolver (with a privacy policy that aligns with their own practices) over an encrypted protocol so that the upstream queries are obfuscated among those of the large resolver. </p>
<h1 id="rfc.section.5.3.3"><a href="#rfc.section.5.3.3">5.3.3.</a> <a href="#data-sharing" id="data-sharing">Data sharing</a></h1>
<p><a href="#RFC6973">[RFC6973]</a> Threats: </p>
<p/>
<ul>
<li>Surveillance.</li>
<li>Stored data compromise.</li>
<li>Correlation.</li>
<li>Identification.</li>
<li>Secondary use.</li>
<li>Disclosure.</li>