-
Notifications
You must be signed in to change notification settings - Fork 5
/
draft-ietf-dprive-bcp-op-03.html
1532 lines (1384 loc) · 97 KB
/
draft-ietf-dprive-bcp-op-03.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>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 on Operators"/>
<link href="#rfc.section.5.1.8" rel="Chapter" title="5.1.8 Limitations of using 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 privacy policy and practice statement"/>
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Recommended contents of a DPPPS"/>
<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 Current policy and privacy statements"/>
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 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 Google Analytics non-prefix filtering"/>
<link href="#rfc.appendix.B.2" rel="Chapter" title="B.2 dnswasher"/>
<link href="#rfc.appendix.B.3" rel="Chapter" title="B.3 Prefix-preserving map"/>
<link href="#rfc.appendix.B.4" rel="Chapter" title="B.4 Cryptographic Prefix-Preserving Pseudonymisation"/>
<link href="#rfc.appendix.B.5" rel="Chapter" title="B.5 Top-hash Subtree-replicated Anonymisation"/>
<link href="#rfc.appendix.B.6" rel="Chapter" title="B.6 ipcipher"/>
<link href="#rfc.appendix.B.7" rel="Chapter" title="B.7 Bloom filters"/>
<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-03" />
<meta name="dct.issued" scheme="ISO8601" content="2019-7-8" />
<meta name="dct.abstract" content="This document presents operational, policy and security considerations for DNS 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 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 9, 2020</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 8, 2019</td>
</tr>
</tbody>
</table>
<p class="title">Recommendations for DNS Privacy Service Operators<br />
<span class="filename">draft-ietf-dprive-bcp-op-03</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This document presents operational, policy and security considerations for DNS 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 framework to assist writers of DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in <a href="#RFC6841">[RFC6841]</a>). </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 9, 2020.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2019 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 on Operators</a></li>
<li>5.1.8. <a href="#rfc.section.5.1.8">Limitations of using 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 privacy policy and practice statement</a></li>
<ul><li>6.1. <a href="#rfc.section.6.1">Recommended contents of a DPPPS</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">Current policy and privacy statements</a></li>
<li>6.3. <a href="#rfc.section.6.3">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">Google Analytics non-prefix filtering</a></li>
<li>B.2. <a href="#rfc.appendix.B.2">dnswasher</a></li>
<li>B.3. <a href="#rfc.appendix.B.3">Prefix-preserving map</a></li>
<li>B.4. <a href="#rfc.appendix.B.4">Cryptographic Prefix-Preserving Pseudonymisation</a></li>
<li>B.5. <a href="#rfc.appendix.B.5">Top-hash Subtree-replicated Anonymisation</a></li>
<li>B.6. <a href="#rfc.appendix.B.6">ipcipher</a></li>
<li>B.7. <a href="#rfc.appendix.B.7">Bloom filters</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="#I-D.ietf-dnsop-terminology-bis">[I-D.ietf-dnsop-terminology-bis]</a> which users may prefer to use instead of the default network resolver because they offer a specific feature (e.g. good reachability, encrypted transport, strong privacy policy, filtering (or lack of), etc.). 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 exists. 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 operators to minimize such tracking 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. It is an untested area that simply using a DNS resolution service constitutes consent from the user for the operator to process their query data. The impact of recent legislative changes on data pertaining to the users of both Internet Service Providers and public DNS resolvers is not fully understood at the time of writing. </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 Privacy Policy and Practice Statement (DPPPS) and present a framework to assist writers of this document. A DPPPS is a document that an operator can publish outlining their operational practices and commitments with regard to privacy thereby providing a means for clients to evaluate the privacy properties of a given DNS privacy service. In particular, the framework identifies the elements that should be considered in formulating a DPPPS. This document does not, however, define a particular Policy or Practice Statement, nor does it seek to provide legal advice or recommendations 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 anycast 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 errata or 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="#I-D.bortzmeyer-dprive-rfc7626-bis">[I-D.bortzmeyer-dprive-rfc7626-bis]</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). Privacy considerations specifically from the perspective of an 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 (taken from <a href="#I-D.bortzmeyer-dprive-rfc7626-bis">[I-D.bortzmeyer-dprive-rfc7626-bis]</a>): </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 like to align with privacy best practice. </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#privacy-related-documents" id="privacy-related-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 of the DNS. 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> and <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="#I-D.ietf-dnsop-terminology-bis">[I-D.ietf-dnsop-terminology-bis]</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 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>DPPPS: DNS Privacy Policy and Practice Statement, see <a href="#dns-privacy-policy-and-practice-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 DPPPS.</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">We describe two classes of threats: </p>
<p/>
<ul>
<li>'Privacy Considerations for Internet Protocols' <a href="#RFC6973">[RFC6973]</a> Threats <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.3">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.5">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>
<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 <a href="#I-D.bortzmeyer-dprive-rfc7626-bis">[I-D.bortzmeyer-dprive-rfc7626-bis]</a> Section 2.4.2.</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 <a href="#RFC7858">[RFC7858]</a> and <a href="#RFC8310">[RFC8310]</a></li>
<li>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, use of these transports for DNS are not standardized 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 that can redirect traffic to rogue servers <a href="#I-D.bortzmeyer-dprive-rfc7626-bis">[I-D.bortzmeyer-dprive-rfc7626-bis]</a> Section 2.5.3.</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 DNS-over-TLS 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 should provide credentials in the form of either X.509 certificates or SPKI pinsets. </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">NOTE: At this time the reference to the TLS DNSSEC chain extension draft has been removed as it is no longer considered an active TLS WG document. </p>
<p id="rfc.section.5.1.2.p.8">Optimizations: </p>
<p id="rfc.section.5.1.2.p.9">DNS privacy services can also consider the following capabilities/options: </p>
<p/>
<ul>
<li>As recommended in <a href="#RFC8310">[RFC8310]</a> providing DANE TLSA records for the nameserver <ul><li>In particular, the service could provide TLSA records such that authenticating solely via the PKIX infrastructure can be avoided.</li></ul></li>
</ul>
<p> </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 pinset 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.</li>
<li>Mis-identification of a server by a client e.g. typos in URLs or authentication domain names</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>Choose a short, memorable authentication name for the service</li>
<li>Automate the generation and publication of certificates</li>
<li>Monitor certificates to prevent accidental expiration of certificates</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="#dnsovertls" id="dnsovertls">DNS-over-TLS</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="https://www.ietf.org/mail-archive/web/dns-privacy/current/pdfWqAIUmEl47.pdf">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 DNS-over-TLS)</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 DNS-over-TLS, TLS profiles from Section 9 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></li>
<li>Clients should not be required to use TLS session resumption <a href="#RFC5077">[RFC5077]</a> or Domain Name System (DNS) Cookies <a href="#RFC7873">[RFC7873]</a>.</li>
<li>A DNS-over-TLS privacy service on both port 853 and 443. This practice may not be possible if e.g. the operator deploys DoH on the same IP address.</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 either <ul><li><a href="#RFC7766">[RFC7766]</a> and EDNS(0) Keepalive <a href="#RFC7828">[RFC7828]</a> and/or</li><li>DNS Stateful Operations <a href="#I-D.ietf-dnsop-session-signal">[I-D.ietf-dnsop-session-signal]</a></li></ul></li>
</ul>
<p> </p>
<p id="rfc.section.5.1.3.1.p.8">Additional options that providers may consider: </p>
<p/>
<ul>
<li>Offer a .onion <a href="#RFC7686">[RFC7686]</a> service endpoint</li>
</ul>
<p> </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="https://petsymposium.org/2018/files/hotpets/4-siby.pdf">DNS Privacy not so private: the traffic analysis perspective</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 forego the use of HTTP Cookies <a href="#RFC6265">[RFC6265]</a> and still use the service</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 for e.g. websites where they might reveal personal information to attackers.</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 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 DNS Roadblock avoidance. </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 must be engineered for high availability. 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="http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper30.pdf">Passive Observations of a Large DNS Service: 2.5 Years in the Life of Google</a>. </p>
<p id="rfc.section.5.1.5.p.5">Techniques such as those described in Section 10 of [RFC7766] 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 such options 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-on-operators" id="impact-on-operators">Impact on Operators</a></h1>
<p id="rfc.section.5.1.7.p.1">DNS Privacy Threats: </p>
<p/>
<ul>
<li>Increased use of encryption impacts operator ability to manage their network <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. There are, however, legitimate reasons for operators 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="http://dnstap.info">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, for example, the discussion on the use of Bloom Filters in the #documents appendix in this document). </p>
<h1 id="rfc.section.5.1.8"><a href="#rfc.section.5.1.8">5.1.8.</a> <a href="#limitations-of-using-a-pure-tls-proxy" id="limitations-of-using-a-pure-tls-proxy">Limitations of using 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 of the target server 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 DNS-over-TLS using a TLS proxy (e.g. <a href="https://nginx.org/">nginx</a>, <a href="https://www.haproxy.org/">haproxy</a> or <a href="https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html">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="https://dnsdist.org">dnsdist</a> which offer 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 common activities for DNS service operators and in all cases 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 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.</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 and 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="https://doi.org/10.1145/3182660">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">As <a href="#I-D.bortzmeyer-dprive-rfc7626-bis">[I-D.bortzmeyer-dprive-rfc7626-bis]</a> makes clear, the big 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. The following table presents a high level comparison of various techniques employed or under development today and classifies them according to categorization of technique and other properties. The list of techniques includes the main techniques in current use, but does not claim to be comprehensive. <a href="#ip-address-techniques">Appendix B</a> provides a more detailed survey of these techniques and definitions for the categories and properties listed below. </p>
<p><a href="https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/draft-00/ip_techniques_table.svg">Figure showing comparison of IP address techniques (SVG)</a> </p>
<p id="rfc.section.5.2.3.p.4">The choice of which method to use for a particular application will depend on the requirements of that application and consideration of the threat analysis of the particular situation. </p>
<p id="rfc.section.5.2.3.p.5">For example, a common goal is that distributed packet captures must be in an existing data format such as PCAP <a href="#pcap">[pcap]</a> or C-DNS <a href="#I-D.ietf-dnsop-dns-capture-format">[I-D.ietf-dnsop-dns-capture-format]</a> that can be used as input to existing analysis tools. In that case, use of a format-preserving technique is essential. This, though, is not cost-free - several authors (e.g. <a href="https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda164fb2138a44.pdf">Brenker & Arnes</a>) have observed that, as the entropy in an IPv4 address is limited, given a de-identified log from a target, if an attacker is capable of ensuring packets are captured by the target and the attacker can send forged traffic with arbitrary source and destination addresses to that target, any format-preserving pseudonymization is vulnerable to an attack along the lines of a cryptographic chosen plaintext attack. </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>IP TTL/Hoplimit can be used to fingerprint client OS</li>
<li>TLS version/Cipher suite combinations can be used to fingerprint the client application or TLS library</li>
<li>Tracking of TCP sessions</li>
<li>Tracking of TLS sessions and session resumption mechanisms</li>
<li>Resolvers <em>might</em> receive client identifiers e.g. MAC addresses in EDNS(0) options - some CPE devices are known to add them.</li>
<li>HTTP headers</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="https://kb.isc.org/docs/aa-00482">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 DNS-over-TLS 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 and not send an ECS option in upstream queries.</li>
</ul>
<p> </p>
<p id="rfc.section.5.3.1.p.6">Optimizations: </p>
<p/>
<ul>
<li>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 (NOTE: the authors believe they will be able to add a reference for advice here soon) and ideally use a policy of whitelisting upstream servers to send ECS to in order to minimize 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">Whitelisting 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 whitelisting to incur significant operational overhead compared to dynamic detection of ECS 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> 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 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>