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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
|
<pre>Internet Engineering Task Force (IETF) S. Dickinson
Request for Comments: 8310 Sinodun
Updates: <a href="./rfc7858">7858</a> D. Gillmor
Category: Standards Track ACLU
ISSN: 2070-1721 T. Reddy
McAfee
March 2018
<span class="h1">Usage Profiles for DNS over TLS and DNS over DTLS</span>
Abstract
This document discusses usage profiles, based on one or more
authentication mechanisms, which can be used for DNS over Transport
Layer Security (TLS) or Datagram TLS (DTLS). These profiles can
increase the privacy of DNS transactions compared to using only
cleartext DNS. This document also specifies new authentication
mechanisms -- it describes several ways that a DNS client can use an
authentication domain name to authenticate a (D)TLS connection to a
DNS server. Additionally, it defines (D)TLS protocol profiles for
DNS clients and servers implementing DNS over (D)TLS. This document
updates <a href="./rfc7858">RFC 7858</a>.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8310">https://www.rfc-editor.org/info/rfc8310</a>.
<span class="grey">Dickinson, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Dickinson, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Scope ...........................................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Discussion ......................................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Usage Profiles ..................................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. DNS Resolution ............................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Authentication in DNS over (D)TLS ..............................<a href="#page-11">11</a>
<a href="#section-6.1">6.1</a>. DNS-over-(D)TLS Startup Configuration Problems ............<a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. Credential Verification ...................................<a href="#page-12">12</a>
<a href="#section-6.3">6.3</a>. Summary of Authentication Mechanisms ......................<a href="#page-12">12</a>
<a href="#section-6.4">6.4</a>. Combining Authentication Mechanisms .......................<a href="#page-15">15</a>
<a href="#section-6.5">6.5</a>. Authentication in Opportunistic Privacy ...................<a href="#page-15">15</a>
<a href="#section-6.6">6.6</a>. Authentication in Strict Privacy ..........................<a href="#page-16">16</a>
<a href="#section-6.7">6.7</a>. Implementation Guidance ...................................<a href="#page-16">16</a>
<a href="#section-7">7</a>. Sources of Authentication Domain Names .........................<a href="#page-17">17</a>
<a href="#section-7.1">7.1</a>. Full Direct Configuration .................................<a href="#page-17">17</a>
<a href="#section-7.2">7.2</a>. Direct Configuration of ADN Only ..........................<a href="#page-17">17</a>
<a href="#section-7.3">7.3</a>. Dynamic Discovery of ADN ..................................<a href="#page-17">17</a>
<a href="#section-7.3.1">7.3.1</a>. DHCP ...............................................<a href="#page-18">18</a>
<a href="#section-8">8</a>. Credential Verification Based on Authentication Domain Name ....<a href="#page-18">18</a>
<a href="#section-8.1">8.1</a>. Authentication Based on PKIX Certificate ..................<a href="#page-18">18</a>
<a href="#section-8.2">8.2</a>. DANE ......................................................<a href="#page-19">19</a>
<a href="#section-8.2.1">8.2.1</a>. Direct DNS Meta-Queries ............................<a href="#page-20">20</a>
<a href="#section-8.2.2">8.2.2</a>. TLS DNSSEC Chain Extension .........................<a href="#page-20">20</a>
<a href="#section-9">9</a>. (D)TLS Protocol Profile ........................................<a href="#page-20">20</a>
<a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-21">21</a>
<a href="#section-11">11</a>. Security Considerations .......................................<a href="#page-21">21</a>
<a href="#section-11.1">11.1</a>. Countermeasures to DNS Traffic Analysis ..................<a href="#page-22">22</a>
<a href="#section-12">12</a>. References ....................................................<a href="#page-22">22</a>
<a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-22">22</a>
<a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-24">24</a>
<a href="#appendix-A">Appendix A</a>. Server Capability Probing and Caching by DNS Clients ..26
Acknowledgments ...................................................<a href="#page-27">27</a>
Authors' Addresses ................................................<a href="#page-27">27</a>
<span class="grey">Dickinson, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
DNS privacy issues are discussed in [<a href="./rfc7626" title=""DNS Privacy Considerations"">RFC7626</a>]. The specific issues
described in [<a href="./rfc7626" title=""DNS Privacy Considerations"">RFC7626</a>] that are most relevant to this document are
o Passive attacks that eavesdrop on cleartext DNS transactions on
the wire (<a href="./rfc7626#section-2.4">Section 2.4 of [RFC7626]</a>) and
o Active attacks that redirect clients to rogue servers to monitor
DNS traffic (<a href="./rfc7626#section-2.5.3">Section 2.5.3 of [RFC7626]</a>).
Mitigating these attacks increases the privacy of DNS transactions;
however, many of the other issues raised in [<a href="./rfc7626" title=""DNS Privacy Considerations"">RFC7626</a>] still apply.
Two documents that provide ways to increase DNS privacy between DNS
clients and DNS servers are
o "Specification for DNS over Transport Layer Security (TLS)"
[<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>], referred to here as simply "DNS over TLS".
o "DNS over Datagram Transport Layer Security (DTLS)" [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>],
referred to here as simply "DNS over DTLS". Note that [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>]
is an Experimental specification.
Both documents are limited in scope to communications between stub
clients and recursive resolvers, and the same scope is applied to
this document (see Sections <a href="#section-2">2</a> and <a href="#section-3">3</a>). The proposals here might be
adapted or extended in future to be used for recursive clients and
authoritative servers, but this application was out of scope for the
DNS PRIVate Exchange (dprive) Working Group charter at the time this
document was published.
This document specifies two usage profiles (Strict Privacy and
Opportunistic Privacy) for DTLS [<a href="./rfc6347" title=""Datagram Transport Layer Security Version 1.2"">RFC6347</a>] and TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] that
provide improved levels of mitigation for the attacks described above
compared to using only cleartext DNS.
<a href="#section-5">Section 5</a> presents a generalized discussion of usage profiles by
separating the usage profile, which is based purely on the security
properties it offers the user, from the specific mechanism or
mechanisms that are used for DNS server authentication. The profiles
described are
o A Strict Privacy profile, which requires an encrypted connection
and successful authentication of the DNS server; this mitigates
both passive eavesdropping and client redirection (at the expense
of providing no DNS service if an encrypted, authenticated
connection is not available).
<span class="grey">Dickinson, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
o An Opportunistic Privacy profile, which will attempt, but does not
require, encryption and successful authentication; it therefore
provides limited or no mitigation for such attacks but maximizes
the chance of DNS service.
The above usage profiles attempt authentication of the server using
at least one authentication mechanism. <a href="#section-6.4">Section 6.4</a> discusses how to
combine authentication mechanisms to determine the overall
authentication result. Depending on that overall authentication
result (and whether encryption is available), the usage profile will
determine if the connection should proceed, fall back, or fail.
One authentication mechanism is already described in [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>].
[<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] specifies an authentication mechanism for DNS over TLS that
is based on Subject Public Key Info (SPKI) in the context of a
specific case of a Strict Privacy profile using that single
authentication mechanism. Therefore, the "out-of-band key-pinned
privacy profile" described in [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] would qualify as a "Strict
Privacy profile" that used SPKI pinning for authentication.
This document extends the use of authentication based on SPKI
pin sets, so that it is considered a general authentication mechanism
that can be used with either DNS-over-(D)TLS usage profile. That is,
the mechanism for SPKI pin sets as described in [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] MAY be used
with DNS over (D)TLS.
This document also describes a number of additional authentication
mechanisms, all of which specify how a DNS client should authenticate
a DNS server based on an "authentication domain name". In
particular, the following topics are described:
o How a DNS client can obtain the combination of an authentication
domain name and IP address for a DNS server. See <a href="#section-7">Section 7</a>.
o What acceptable credentials a DNS server can present to prove its
identity for (D)TLS authentication based on a given authentication
domain name. See <a href="#section-8">Section 8</a>.
o How a DNS client can verify that any given credential matches the
authentication domain name obtained for a DNS server. See
<a href="#section-8">Section 8</a>.
This document defines a (D)TLS protocol profile for use with DNS; see
<a href="#section-9">Section 9</a>. This profile defines the configuration options and
protocol extensions required of both parties to (1) optimize
connection establishment and session resumption for transporting DNS
and (2) support all currently specified authentication mechanisms.
<span class="grey">Dickinson, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
Several terms are used specifically in the context of this document:
o DNS client: A DNS stub resolver or forwarder. In the case of a
forwarder, the term "DNS client" is used to discuss the side that
sends queries.
o DNS server: A DNS recursive resolver or forwarder. In the case of
a forwarder, the term "DNS server" is used to discuss the side
that responds to queries. Note that, as used in this document,
this term does not apply to authoritative servers.
o Privacy-enabling DNS server: A DNS server that implements
DNS over TLS [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] and may optionally implement DNS over DTLS
[<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>]. The server should also offer at least one of the
credentials described in <a href="#section-8">Section 8</a> and implement the (D)TLS
profile described in <a href="#section-9">Section 9</a>.
o (D)TLS: Used for brevity; refers to both Transport Layer Security
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] and Datagram Transport Layer Security [<a href="./rfc6347" title=""Datagram Transport Layer Security Version 1.2"">RFC6347</a>].
Specific terms will be used for any text that applies to either
protocol alone.
o DNS over (D)TLS: Used for brevity; refers to both DNS over TLS
[<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] and DNS over DTLS [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>]. Specific terms will be
used for any text that applies to either protocol alone.
o Authentication domain name: A domain name that can be used to
authenticate a privacy-enabling DNS server. Sources of
authentication domain names are discussed in <a href="#section-7">Section 7</a>.
o SPKI pin sets: [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] describes the use of cryptographic
digests to "pin" public key information in a manner similar to
HTTP Public Key Pinning (HPKP) [<a href="./rfc7469" title=""Public Key Pinning Extension for HTTP"">RFC7469</a>]. An SPKI pin set is a
collection of these pins that constrains a DNS server.
<span class="grey">Dickinson, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
o Authentication information: Information a DNS client may use as
the basis of an authentication mechanism. In this context, this
information can be either
* an SPKI pin set or
* an authentication domain name
o Reference identifier: A reference identifier as described in
[<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>], constructed by the DNS client when performing TLS
authentication of a DNS server.
o Credential: Information available for a DNS server that proves its
identity for authentication purposes. Credentials discussed here
include
* a PKIX certificate
* a DNSSEC-validated chain to a TLSA record
but may also include SPKI pin sets.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Scope</span>
This document is limited to describing
o Usage profiles based on general authentication mechanisms.
o The details of domain-name-based authentication of DNS servers by
DNS clients (as defined in <a href="#section-2">Section 2</a>).
o The (D)TLS profiles needed to support authentication in
DNS over (D)TLS.
As such, the following topics are out of scope for this document:
o Authentication of authoritative servers by recursive resolvers.
o Authentication of DNS clients by DNS servers.
o The details of how to perform authentication based on SPKI
pin sets. This is defined in [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>].
o Any server identifier other than domain names, including IP
addresses, organizational names, country of origin, etc.
<span class="grey">Dickinson, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Discussion</span>
One way to mitigate eavesdropping on cleartext DNS transactions by
passive attackers is to encrypt the query (and response). Such
encryption typically provides integrity protection as a side effect;
this means that on-path attackers cannot simply inject bogus DNS
responses. To also mitigate active attackers pretending to be the
server, the client must authenticate the (D)TLS connection to the
server.
This document discusses usage profiles, which provide differing
levels of attack mitigation to DNS clients, based on the requirements
for authentication and encryption, regardless of the context (for
example, which network the client is connected to). A usage profile
is a concept distinct from a usage policy or usage model; a usage
policy or usage model might dictate which profile should be used in a
particular context (enterprise vs. coffee shop), with a particular
set of DNS servers or with reference to other external factors. A
description of the variety of usage policies is out of scope for this
document but may be the subject of future work.
The term "privacy-enabling DNS server" is used throughout this
document. This is a DNS server that
o MUST implement DNS over TLS [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>].
o MAY implement DNS over DTLS [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>].
o SHOULD offer at least one of the credentials described in
<a href="#section-8">Section 8</a>.
o Implements the (D)TLS profile described in <a href="#section-9">Section 9</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Usage Profiles</span>
A DNS client has a choice of usage profiles available to increase the
privacy of DNS transactions. This choice is briefly discussed in
both [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] and [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>]. These usage profiles are
o Strict Privacy profile: The DNS client requires both an encrypted
and authenticated connection to a privacy-enabling DNS server. A
hard failure occurs if this is not available. This requires the
client to securely obtain authentication information it can use to
authenticate the server. This profile mitigates both passive and
active attacks, thereby providing the client with the best
available privacy for DNS. This profile is discussed in detail in
<a href="#section-6.6">Section 6.6</a>.
<span class="grey">Dickinson, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
o Opportunistic Privacy profile: The DNS client uses Opportunistic
Security as described in [<a href="./rfc7435" title=""Opportunistic Security: Some Protection Most of the Time"">RFC7435</a>].
* "... the use of cleartext as the baseline communication
security policy, with encryption and authentication negotiated
and applied to the communication when available."
As described in [<a href="./rfc7435" title=""Opportunistic Security: Some Protection Most of the Time"">RFC7435</a>], it might result in
* an encrypted and authenticated connection
* an encrypted connection
* a cleartext connection
depending on the fallback logic of the client, the available
authentication information, and the capabilities of the DNS
server. In all these cases, the DNS client is willing to continue
with a connection to the DNS server and perform resolution of
queries. The use of Opportunistic Privacy is intended to support
incremental deployment of increased privacy with a view to
widespread adoption of the Strict Privacy profile. It should be
employed when the DNS client might otherwise settle for cleartext;
it provides the maximum protection available, depending on the
combination of factors described above. If all the configured DNS
servers are DNS privacy servers, then it can provide protection
against passive attacks and might protect against active ones.
Both profiles can include an initial meta-query (performed using
Opportunistic Privacy) to obtain the IP address for the privacy-
enabling DNS server to which the DNS client will subsequently
connect. The rationale for permitting this for the Strict Privacy
profile is that requiring such meta-queries to also be performed
using the Strict Privacy profile would introduce significant
deployment obstacles. However, it should be noted that in this
scenario an active attack on the meta-query is possible. Such an
attack could result in a Strict Privacy profile client connecting to
a server it cannot authenticate (and therefore not obtaining DNS
service) or an Opportunistic Privacy client connecting to a server
controlled by the attacker. DNSSEC validation can detect the attack
on the meta-query, which may result in the client not obtaining DNS
service (for both usage profiles), depending on its DNSSEC validation
policy. See <a href="#section-7.2">Section 7.2</a> for more discussion.
To compare the two usage profiles, Table 1 below shows a successful
Strict Privacy profile alongside the three possible outcomes of an
Opportunistic Privacy profile. In the best-case scenario for the
Opportunistic Privacy profile (an authenticated and encrypted
<span class="grey">Dickinson, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
connection), it is equivalent to the Strict Privacy profile. In the
worst-case scenario, it is equivalent to cleartext. Clients using
the Opportunistic Privacy profile SHOULD try for the best case but
MAY fall back to the intermediate case and, eventually, the worst-
case scenario, in order to obtain a response. One reason to fall
back without trying every available privacy-enabling DNS server is if
latency is more important than attack mitigation; see <a href="#appendix-A">Appendix A</a>.
The Opportunistic Privacy profile therefore provides varying
protection, depending on what kind of connection is actually used,
including no attack mitigation at all.
Note that there is no requirement in Opportunistic Security to notify
the user regarding what type of connection is actually used; the
"detection" described below is only possible if such connection
information is available. However, if it is available and the user
is informed that an unencrypted connection was used to connect to a
server, then the user should assume (detect) that the connection is
subject to both active and passive attacks, since the DNS queries are
sent in cleartext. This might be particularly useful if a new
connection to a certain server is unencrypted when all previous
connections were encrypted. Similarly, if the user is informed that
an encrypted but unauthenticated connection was used, then the user
can detect that the connection may be subject to active attacks. In
other words, for the cases where no protection is provided against an
attacker (N), it is possible to detect that an attack might be
happening (D). This is discussed in <a href="#section-6.5">Section 6.5</a>.
+---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+
| Strict | A, E | P | P |
| Opportunistic | A, E | P | P |
| Opportunistic | E | P | N, D |
| Opportunistic | | N, D | N, D |
+---------------+------------+------------------+-----------------+
P == Protection; N == No protection; D == Detection is possible;
A == Authenticated connection; E == Encrypted connection
Table 1: Attack Protection by Usage Profile and Type of Attacker
The Strict Privacy profile provides the best attack mitigation and
therefore SHOULD always be implemented in DNS clients that implement
the Opportunistic Privacy profile.
A DNS client that implements DNS over (D)TLS SHOULD NOT be configured
by default to use only cleartext.
<span class="grey">Dickinson, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
The choice between the two profiles depends on a number of factors,
including which is more important to the particular client:
o DNS service, at the cost of no attack mitigation (Opportunistic
Privacy) or
o Best available attack mitigation, at the potential cost of no DNS
service (Strict Privacy).
Additionally, the two profiles require varying levels of
configuration (or a trusted relationship with a provider) and DNS
server capabilities; therefore, DNS clients will need to carefully
select which profile to use based on their communication needs.
A DNS server that implements DNS over (D)TLS SHOULD provide at least
one credential (<a href="#section-2">Section 2</a>) so that those DNS clients that wish to use
the Strict Privacy profile are able to do so.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. DNS Resolution</span>
A DNS client SHOULD select a particular usage profile when resolving
a query. A DNS client MUST NOT fall back from Strict Privacy to
Opportunistic Privacy during the resolution of a given query, as this
could invalidate the protection offered against attackers. It is
anticipated that DNS clients will use a particular usage profile for
all queries to all configured servers until an operational issue or
policy update dictates a change in the profile used.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Authentication in DNS over (D)TLS</span>
This section describes authentication mechanisms and how they can be
used in either Strict or Opportunistic Privacy for DNS over (D)TLS.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. DNS-over-(D)TLS Startup Configuration Problems</span>
Many (D)TLS clients use PKIX authentication [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>] based on an
authentication domain name for the server they are contacting. These
clients typically first look up the server's network address in the
DNS before making this connection. Such a DNS client therefore has a
bootstrap problem, as it will typically only know the IP address of
its DNS server.
In this case, before connecting to a DNS server, a DNS client needs
to learn the authentication domain name it should associate with the
IP address of a DNS server for authentication purposes. Sources of
authentication domain names are discussed in <a href="#section-7">Section 7</a>.
<span class="grey">Dickinson, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
One advantage of this domain-name-based approach is that it
encourages the association of stable, human-recognizable identifiers
with secure DNS service providers.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Credential Verification</span>
Verification of SPKI pin sets is discussed in [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>].
In terms of domain-name-based verification, once an authentication
domain name is known for a DNS server, a choice of authentication
mechanisms can be used for credential verification. <a href="#section-8">Section 8</a>
discusses these mechanisms -- namely, PKIX certificate-based
authentication and DNS-Based Authentication of Named Entities (DANE)
-- in detail.
Note that the use of DANE adds requirements on the ability of the
client to get validated DNSSEC results. This is discussed in more
detail in <a href="#section-8.2">Section 8.2</a>.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Summary of Authentication Mechanisms</span>
This section provides an overview of the various authentication
mechanisms. Table 2 below indicates how the DNS client obtains
information to use for authentication for each option: either
statically via direct configuration or dynamically. Of course, the
Opportunistic Privacy profile does not require authentication, and so
a client using that profile may choose to connect to a
privacy-enabling DNS server on the basis of just an IP address.
<span class="grey">Dickinson, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
+---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description |
| | Config | Obtained | |
+---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pin set(s) and IP |
| | | | address obtained out of band |
| | | | [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] |
| | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see <a href="#section-7.1">Section 7.1</a>) |
| | | | |
| 3 | ADN | IP | ADN only: Opportunistic Privacy |
| | | | meta-queries to a NP DNS server |
| | | | for A/AAAA (see <a href="#section-7.2">Section 7.2</a>) |
| | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | <a href="#section-7.3.1">Section 7.3.1</a>) |
| | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic Privacy meta-queries |
| | | | to NP DNS server (see Section |
| | | | 8.2.1) |
| | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see |
| | | | <a href="#section-8.2.2">Section 8.2.2</a>) |
+---+------------+-------------+------------------------------------+
SPKI == SPKI pin set(s); IP == IP Address;
ADN == Authentication Domain Name; NP == Network-Provided;
PE == Privacy-Enabling; [ ] == Data may be obtained either
statically or dynamically
Table 2: Overview of Authentication Mechanisms
The following summary attempts to present some key attributes of each
of the mechanisms (using the "Short name" from Table 2), indicating
attractive attributes with a "+" and undesirable attributes
with a "-".
1. SPKI
+ Minimal leakage (note that the ADN is always leaked in the
Server Name Indication (SNI) field in the ClientHello in TLS
when communicating with a privacy-enabling DNS server)
- Overhead of ongoing key management required
<span class="grey">Dickinson, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
2. ADN
+ Minimal leakage
+ One-off direct configuration only
3. ADN only
+ Minimal one-off direct configuration; only a human-recognizable
domain name needed
- A/AAAA meta-queries leaked to network-provided DNS server that
may be subject to active attack (attack can be mitigated by
DNSSEC validation)
4. DHCP
+ No static config
- Requires a non-standard or future DHCP option in order to
provide the ADN
- Requires secure and trustworthy connection to DHCP server if
used with a Strict Privacy profile
5. DANE
The ADN and/or IP may be obtained statically or dynamically, and
the relevant attributes of that method apply.
+ DANE options (e.g., matching on entire certificate)
- Requires a DNSSEC-validating stub implementation (the
deployment of which is limited at the time of this writing)
- DNSSEC chain meta-queries leaked to network-provided DNS server
that may be subject to active attack
6. TLS extension
The ADN and/or IP may be obtained statically or dynamically, and
the relevant attributes of that method apply.
+ Reduced latency compared with DANE
+ No network-provided DNS server required if ADN and IP
statically configured
<span class="grey">Dickinson, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
+ DANE options (e.g., matching on entire certificate)
- Requires a DNSSEC-validating stub implementation
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Combining Authentication Mechanisms</span>
This document does not make explicit recommendations about how an
authentication mechanism based on SPKI pin sets should be combined
with a domain-based mechanism from an operator perspective. However,
it can be envisaged that a DNS server operator may wish to make both
an SPKI pin set and an authentication domain name available to allow
clients to choose which mechanism to use. Therefore, the following
text provides guidance on how clients ought to behave if they choose
to configure both, as is possible in HPKP [<a href="./rfc7469" title=""Public Key Pinning Extension for HTTP"">RFC7469</a>].
A DNS client that is configured with both an authentication domain
name and an SPKI pin set for a DNS server SHOULD match on both a
valid credential for the authentication domain name and a valid SPKI
pin set (if both are available) when connecting to that DNS server.
In this case, the client SHOULD treat individual SPKI pins as
specified in <a href="./rfc7469#section-2.6">Section 2.6 of [RFC7469]</a> with regard to user-defined
trust anchors. The overall authentication result SHOULD only be
considered successful if both authentication mechanisms are
successful.
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Authentication in Opportunistic Privacy</span>
An Opportunistic Privacy Profile (based on Opportunistic Security
[<a href="./rfc7435" title=""Opportunistic Security: Some Protection Most of the Time"">RFC7435</a>]) that MAY be used for DNS over (D)TLS is described in
[<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] and is further specified in this document.
DNS clients that issue queries under an Opportunistic Privacy profile
and that know authentication information for a given privacy-enabling
DNS server SHOULD try to authenticate the server using the mechanisms
described here. This is useful for detecting (but not preventing)
active attacks, since the fact that authentication information is
available indicates that the server in question is a privacy-enabling
DNS server to which it should be possible to establish an
authenticated and encrypted connection. In this case, whilst a
client cannot know the reason for an authentication failure, from a
security standpoint the client should consider an active attack in
progress and proceed under that assumption. For example, a client
that implements a nameserver selection algorithm that preferentially
uses nameservers that successfully authenticated (see <a href="#section-5">Section 5</a>)
might not continue to use the failing server if there were
alternative servers available.
<span class="grey">Dickinson, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
Attempting authentication is also useful for debugging or diagnostic
purposes if there are means to report the result. This information
can provide a basis for a DNS client to switch to (preferred) Strict
Privacy where it is viable, e.g., where all the configured servers
support DNS over (D)TLS and successfully authenticate.
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Authentication in Strict Privacy</span>
To authenticate a privacy-enabling DNS server, a DNS client needs to
know authentication information for each server it is willing to
contact. This is necessary to protect against active attacks that
attempt to redirect clients to rogue DNS servers.
A DNS client requiring Strict Privacy MUST use either (1) one of the
sources listed in <a href="#section-7">Section 7</a>, to obtain an authentication domain name
for the server it contacts or (2) an SPKI pin set as described in
[<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>].
A DNS client requiring Strict Privacy MUST only attempt to connect to
DNS servers for which at least one piece of authentication
information is known. The client MUST use the available verification
mechanisms described in <a href="#section-8">Section 8</a> to authenticate the server and MUST
abort connections to a server when no verification mechanism
succeeds.
With Strict Privacy, the DNS client MUST NOT commence sending DNS
queries until at least one of the privacy-enabling DNS servers
becomes available.
A privacy-enabling DNS server may be temporarily unavailable when
configuring a network. For example, for clients on networks that
require registration through web-based login (a.k.a. "captive
portals"), such registration may rely on DNS interception and
spoofing. Techniques such as those used by dnssec-trigger
[<a href="#ref-dnssec-trigger">dnssec-trigger</a>] MAY be used during network configuration, with the
intent to transition to the designated privacy-enabling DNS servers
after captive-portal registration. If using a Strict Privacy
profile, the system MUST alert by some means that the DNS is not
private during such a bootstrap operation.
<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>. Implementation Guidance</span>
<a href="#section-9">Section 9</a> describes the (D)TLS profile for DNS over (D)TLS.
Additional considerations relating to general implementation
guidelines are discussed in both <a href="#section-11">Section 11</a> and <a href="#appendix-A">Appendix A</a>.
<span class="grey">Dickinson, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Sources of Authentication Domain Names</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Full Direct Configuration</span>
DNS clients may be directly and securely provisioned with the
authentication domain name of each privacy-enabling DNS server -- for
example, using a client-specific configuration file or API.
In this case, direct configuration for a DNS client would consist of
both an IP address and an authentication domain name for each DNS
server that were obtained via an out-of-band mechanism.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Direct Configuration of ADN Only</span>
A DNS client may be configured directly and securely with only the
authentication domain name of each of its privacy-enabling DNS
servers -- for example, using a client-specific configuration file
or API.
A DNS client might learn of a default recursive DNS resolver from an
untrusted source (such as DHCP's DNS Recursive Name Server option
[<a href="./rfc3646" title=""DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3646</a>]). It can then use meta-queries performed using an
Opportunistic Privacy profile to an untrusted recursive DNS resolver
to establish the IP address of the intended privacy-enabling DNS
resolver by doing a lookup of A/AAAA records. A DNSSEC-validating
client SHOULD apply the same validation policy to the A/AAAA
meta-queries as it does to other queries. A client that does not
validate DNSSEC SHOULD apply the same policy (if any) to the A/AAAA
meta-queries as it does to other queries. Private DNS resolution can
now be done by the DNS client against the pre-configured privacy-
enabling DNS resolver, using the IP address obtained from the
untrusted DNS resolver.
A DNS client so configured that successfully connects to a privacy-
enabling DNS server MAY choose to locally cache the server host IP
addresses in order to not have to repeat the meta-query.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Dynamic Discovery of ADN</span>
This section discusses the general case of a DNS client discovering
both the authentication domain name and IP address dynamically. At
the time of this writing, this is not possible by any standard means.
However, since, for example, a future DHCP extension could (in
principle) provide this mechanism, the required security properties
of such mechanisms are outlined here.
<span class="grey">Dickinson, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
When using a Strict Privacy profile, the dynamic discovery technique
used as a source of authentication domain names MUST be considered
secure and trustworthy. This requirement does not apply when using
an Opportunistic Privacy profile, given the security expectation of
that profile.
<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>. DHCP</span>
In the typical case today, a DHCP server [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>] [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] provides
a list of IP addresses for DNS resolvers (see <a href="./rfc2132#section-3.8">Section 3.8 of
[RFC2132]</a>) but does not provide an authentication domain name for the
DNS resolver, thus preventing the use of most of the authentication
methods described here (all of those that are based on a mechanism
with ADN; see Table 2).
This document does not specify or request any DHCP extension to
provide authentication domain names. However, if one is developed in
future work, the issues outlined in <a href="./rfc7227#section-8">Section 8 of [RFC7227]</a> should be
taken into account, as should the security considerations discussed
in <a href="./rfc3315#section-23">Section 23 of [RFC3315]</a>.
This document does not attempt to describe secured and trusted
relationships to DHCP servers, as this is purely a DHCP issue (and
still open, at the time of this writing). Whilst some implementation
work is in progress to secure IPv6 connections for DHCP, IPv4
connections have received little or no implementation attention in
this area.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Credential Verification Based on Authentication Domain Name</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Authentication Based on PKIX Certificate</span>
When a DNS client configured with an authentication domain name
connects to its configured DNS server over (D)TLS, the server may
present it with a PKIX certificate. In order to ensure proper
authentication, DNS clients MUST verify the entire certification path
per [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]. The DNS client additionally uses validation
techniques as described in [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>] to compare the domain name to
the certificate provided.
A DNS client constructs one reference identifier for the server based
on the authentication domain name: a DNS-ID, which is simply the
authentication domain name itself.
If the reference identifier is found (as described in <a href="./rfc6125#section-6">Section 6 of
[RFC6125]</a>) in the PKIX certificate's subjectAltName extension, the
DNS client should accept the certificate for the server.
<span class="grey">Dickinson, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
A compliant DNS client MUST only inspect the certificate's
subjectAltName extension for the reference identifier. In
particular, it MUST NOT inspect the Subject field itself.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. DANE</span>
DANE [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>] provides various mechanisms using DNSSEC to anchor
trust for certificates and raw public keys. However, this requires
the DNS client to have an authentication domain name (which must be
obtained via a trusted source) for the DNS privacy server.
This section assumes a solid understanding of both DANE [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>] and
DANE operations [<a href="./rfc7671" title=""The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance"">RFC7671</a>]. A few pertinent issues covered in these
documents are outlined here as useful pointers, but familiarity with
both of these documents in their entirety is expected.
Note that [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>] says
Clients that validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on
another entity to perform the DNSSEC signature validation MUST use
a secure mechanism between themselves and the validator.
Note that [<a href="./rfc7671" title=""The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance"">RFC7671</a>] covers the following topics:
o Sections <a href="#section-4.1">4.1</a> ("Opportunistic Security and PKIX Usages") and 14
("Security Considerations") of [<a href="./rfc7671" title=""The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance"">RFC7671</a>], which both discuss the
use of schemes based on trust anchors and end entities (PKIX-TA(0)
and PKIX-EE(1), respectively) for Opportunistic Security.
o <a href="#section-5">Section 5</a> ("Certificate-Usage-Specific DANE Updates and
Guidelines") of [<a href="./rfc7671" title=""The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance"">RFC7671</a>] -- specifically, <a href="./rfc7671#section-5.1">Section 5.1 of
[RFC7671]</a>, which outlines the combination of certificate usage
DANE-EE(3) and selector SPKI(1) with raw public keys [<a href="./rfc7250" title=""Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7250</a>].
<a href="./rfc7671#section-5.1">Section 5.1 of [RFC7671]</a> also discusses the security implications
of this mode; for example, it discusses key lifetimes and
specifies that validity period enforcement is based solely on the
TLSA RRset properties for this case.
o <a href="#section-13">Section 13</a> ("Operational Considerations") of [<a href="./rfc7671" title=""The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance"">RFC7671</a>], which
discusses TLSA TTLs and signature validity periods.
The specific DANE record for a DNS privacy server would take the form
_853._tcp.[authentication-domain-name] for TLS
_853._udp.[authentication-domain-name] for DTLS
<span class="grey">Dickinson, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h4"><a class="selflink" id="section-8.2.1" href="#section-8.2.1">8.2.1</a>. Direct DNS Meta-Queries</span>
The DNS client MAY choose to perform the DNS meta-queries to retrieve
the required DANE records itself. The DNS meta-queries for such DANE
records MAY use the Opportunistic Privacy profile or be in the clear
to avoid trust recursion. The records MUST be validated using DNSSEC
as described in [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>].
<span class="h4"><a class="selflink" id="section-8.2.2" href="#section-8.2.2">8.2.2</a>. TLS DNSSEC Chain Extension</span>
The DNS client MAY offer the TLS extension described in
[<a href="#ref-TLS-DNSSEC-Chain-Ext">TLS-DNSSEC-Chain-Ext</a>]. If the DNS server supports this extension,
it can provide the full chain to the client in the handshake.
If the DNS client offers the TLS DNSSEC chain extension, it MUST be
capable of validating the full DNSSEC authentication chain down to
the leaf. If the supplied DNSSEC chain does not validate, the client
MUST ignore the DNSSEC chain and validate only via other supplied
credentials.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. (D)TLS Protocol Profile</span>
This section defines the (D)TLS protocol profile of DNS over (D)TLS.
Clients and servers MUST adhere to the (D)TLS implementation
recommendations and security considerations of [<a href="./rfc7525" title=""Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7525</a>], except with
respect to the (D)TLS version.
Since encryption of DNS using (D)TLS is a greenfield deployment, DNS
clients and servers MUST implement only (D)TLS 1.2 or later. For
example, implementing (D)TLS 1.3 [<a href="#ref-TLS-1.3" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">TLS-1.3</a>] [<a href="#ref-DTLS-1.3">DTLS-1.3</a>] is also an
option.
Implementations MUST NOT offer or provide TLS compression, since
compression can leak significant amounts of information, especially
to a network observer capable of forcing the user to do an arbitrary
DNS lookup in the style of the Compression Ratio Info-leak Made Easy
(CRIME) attacks [<a href="#ref-CRIME" title=""The CRIME Attack"">CRIME</a>].
<span class="grey">Dickinson, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
Implementations compliant with this profile MUST implement the
following items:
o TLS session resumption without server-side state [<a href="./rfc5077" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC5077</a>], which
eliminates the need for the server to retain cryptographic state
for longer than necessary. (This statement updates [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>].)
o Raw public keys [<a href="./rfc7250" title=""Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7250</a>], which reduce the size of the
ServerHello and can be used by servers that cannot obtain
certificates (e.g., DNS servers on private networks). A client
MUST only indicate support for raw public keys if it has an SPKI
pin set pre-configured (for interoperability reasons).
Implementations compliant with this profile SHOULD implement the
following items:
o TLS False Start [<a href="./rfc7918" title=""Transport Layer Security (TLS) False Start"">RFC7918</a>], which reduces round trips by allowing
the TLS second flight of messages (ChangeCipherSpec) to also
contain the (encrypted) DNS query.
o The Cached Information Extension [<a href="./rfc7924" title=""Transport Layer Security (TLS) Cached Information Extension"">RFC7924</a>], which avoids
transmitting the server's certificate and certificate chain if the
client has cached that information from a previous TLS handshake.
Guidance specific to TLS is provided in [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>], and guidance
specific to DTLS is provided in [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>].
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
This document does not require any IANA actions.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Security Considerations</span>
Security considerations discussed in [<a href="./rfc7525" title=""Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7525</a>], [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>], and
[<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] apply to this document.
DNS clients SHOULD implement (1) support for the mechanisms described
in <a href="#section-8.2">Section 8.2</a> and (2) offering a configuration option that limits
authentication to using only those mechanisms (i.e., with no fallback
to pure PKIX-based authentication) such that authenticating solely
via the PKIX infrastructure can be avoided.
<span class="grey">Dickinson, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Countermeasures to DNS Traffic Analysis</span>
This section makes suggestions for measures that can reduce the
ability of attackers to infer information pertaining to encrypted
client queries by other means (e.g., via an analysis of encrypted
traffic size or via monitoring of the unencrypted traffic from a DNS
recursive resolver to an authoritative server).
DNS-over-(D)TLS clients and servers SHOULD implement the following
relevant DNS extensions:
o Extension Mechanisms for DNS (EDNS(0)) padding [<a href="./rfc7830" title=""The EDNS(0) Padding Option"">RFC7830</a>], which
allows encrypted queries and responses to hide their size, making
analysis of encrypted traffic harder.
Guidance on padding policies for EDNS(0) is provided in
[<a href="#ref-EDNS0-Pad-Policies">EDNS0-Pad-Policies</a>].
DNS-over-(D)TLS clients SHOULD implement the following relevant DNS
extensions:
o Privacy election per [<a href="./rfc7871" title=""Client Subnet in DNS Queries"">RFC7871</a>] ("Client Subnet in DNS Queries").
If a DNS client does not include an edns-client-subnet EDNS0
option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS
server may potentially leak client address information to the
upstream authoritative DNS servers. A DNS client ought to be able
to inform the DNS resolver that it does not want any address
information leaked, and the DNS resolver should honor that
request.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5077">RFC5077</a>] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", <a href="./rfc5077">RFC 5077</a>, DOI 10.17487/RFC5077,
January 2008, <<a href="https://www.rfc-editor.org/info/rfc5077">https://www.rfc-editor.org/info/rfc5077</a>>.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
DOI 10.17487/RFC5246, August 2008,
<<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>>.
<span class="grey">Dickinson, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", <a href="./rfc5280">RFC 5280</a>, DOI 10.17487/RFC5280, May 2008,
<<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>>.
[<a id="ref-RFC6125">RFC6125</a>] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", <a href="./rfc6125">RFC 6125</a>, DOI 10.17487/RFC6125,
March 2011, <<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>>.
[<a id="ref-RFC6347">RFC6347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", <a href="./rfc6347">RFC 6347</a>, DOI 10.17487/RFC6347,
January 2012, <<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>>.
[<a id="ref-RFC6698">RFC6698</a>] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", <a href="./rfc6698">RFC 6698</a>, DOI 10.17487/RFC6698,
August 2012, <<a href="https://www.rfc-editor.org/info/rfc6698">https://www.rfc-editor.org/info/rfc6698</a>>.
[<a id="ref-RFC7250">RFC7250</a>] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", <a href="./rfc7250">RFC 7250</a>, DOI 10.17487/RFC7250,
June 2014, <<a href="https://www.rfc-editor.org/info/rfc7250">https://www.rfc-editor.org/info/rfc7250</a>>.
[<a id="ref-RFC7525">RFC7525</a>] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>, <a href="./rfc7525">RFC 7525</a>, DOI 10.17487/RFC7525,
May 2015, <<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>>.
[<a id="ref-RFC7671">RFC7671</a>] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", <a href="./rfc7671">RFC 7671</a>, DOI 10.17487/RFC7671,
October 2015, <<a href="https://www.rfc-editor.org/info/rfc7671">https://www.rfc-editor.org/info/rfc7671</a>>.
[<a id="ref-RFC7830">RFC7830</a>] Mayrhofer, A., "The EDNS(0) Padding Option", <a href="./rfc7830">RFC 7830</a>,
DOI 10.17487/RFC7830, May 2016,
<<a href="https://www.rfc-editor.org/info/rfc7830">https://www.rfc-editor.org/info/rfc7830</a>>.
[<a id="ref-RFC7858">RFC7858</a>] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", <a href="./rfc7858">RFC 7858</a>, DOI 10.17487/RFC7858,
May 2016, <<a href="https://www.rfc-editor.org/info/rfc7858">https://www.rfc-editor.org/info/rfc7858</a>>.
<span class="grey">Dickinson, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
[<a id="ref-RFC7918">RFC7918</a>] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", <a href="./rfc7918">RFC 7918</a>,
DOI 10.17487/RFC7918, August 2016,
<<a href="https://www.rfc-editor.org/info/rfc7918">https://www.rfc-editor.org/info/rfc7918</a>>.
[<a id="ref-RFC7924">RFC7924</a>] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", <a href="./rfc7924">RFC 7924</a>,
DOI 10.17487/RFC7924, July 2016,
<<a href="https://www.rfc-editor.org/info/rfc7924">https://www.rfc-editor.org/info/rfc7924</a>>.
[<a id="ref-RFC8094">RFC8094</a>] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", <a href="./rfc8094">RFC 8094</a>,
DOI 10.17487/RFC8094, February 2017,
<<a href="https://www.rfc-editor.org/info/rfc8094">https://www.rfc-editor.org/info/rfc8094</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
<a href="./rfc2119">RFC 2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>,
DOI 10.17487/RFC8174, May 2017,
<<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-CRIME">CRIME</a>] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty
Security Conference, 2012,
<<a href="https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf">https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf</a>>.
[<a id="ref-dnssec-trigger">dnssec-trigger</a>]
NLnetLabs, "Dnssec-Trigger", December 2017,
<<a href="https://www.nlnetlabs.nl/projects/dnssec-trigger/">https://www.nlnetlabs.nl/projects/dnssec-trigger/</a>>.
[<a id="ref-DTLS-1.3">DTLS-1.3</a>]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol
Version 1.3", Work in Progress, <a href="./draft-ietf-tls-dtls13-26">draft-ietf-tls-dtls13-26</a>,
March 2018.
[<a id="ref-EDNS0-Pad-Policies">EDNS0-Pad-Policies</a>]
Mayrhofer, A., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Padding+Policy+for+EDNS%280%29%22'>"Padding Policy for EDNS(0)"</a>, Work in
Progress, <a href="./draft-ietf-dprive-padding-policy-04">draft-ietf-dprive-padding-policy-04</a>,
February 2018.
[<a id="ref-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol",
<a href="./rfc2131">RFC 2131</a>, DOI 10.17487/RFC2131, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2131">https://www.rfc-editor.org/info/rfc2131</a>>.
[<a id="ref-RFC2132">RFC2132</a>] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", <a href="./rfc2132">RFC 2132</a>, DOI 10.17487/RFC2132, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2132">https://www.rfc-editor.org/info/rfc2132</a>>.
<span class="grey">Dickinson, et al. Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, DOI 10.17487/RFC3315,
July 2003, <<a href="https://www.rfc-editor.org/info/rfc3315">https://www.rfc-editor.org/info/rfc3315</a>>.
[<a id="ref-RFC3646">RFC3646</a>] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", <a href="./rfc3646">RFC 3646</a>,
DOI 10.17487/RFC3646, December 2003,
<<a href="https://www.rfc-editor.org/info/rfc3646">https://www.rfc-editor.org/info/rfc3646</a>>.
[<a id="ref-RFC7227">RFC7227</a>] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
<a href="https://www.rfc-editor.org/bcp/bcp187">BCP 187</a>, <a href="./rfc7227">RFC 7227</a>, DOI 10.17487/RFC7227, May 2014,
<<a href="https://www.rfc-editor.org/info/rfc7227">https://www.rfc-editor.org/info/rfc7227</a>>.
[<a id="ref-RFC7435">RFC7435</a>] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", <a href="./rfc7435">RFC 7435</a>, DOI 10.17487/RFC7435,
December 2014, <<a href="https://www.rfc-editor.org/info/rfc7435">https://www.rfc-editor.org/info/rfc7435</a>>.
[<a id="ref-RFC7469">RFC7469</a>] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", <a href="./rfc7469">RFC 7469</a>, DOI 10.17487/RFC7469,
April 2015, <<a href="https://www.rfc-editor.org/info/rfc7469">https://www.rfc-editor.org/info/rfc7469</a>>.
[<a id="ref-RFC7626">RFC7626</a>] Bortzmeyer, S., "DNS Privacy Considerations", <a href="./rfc7626">RFC 7626</a>,
DOI 10.17487/RFC7626, August 2015,
<<a href="https://www.rfc-editor.org/info/rfc7626">https://www.rfc-editor.org/info/rfc7626</a>>.
[<a id="ref-RFC7871">RFC7871</a>] Contavalli, C., van der Gaast, W., Lawrence, D., and
W. Kumari, "Client Subnet in DNS Queries", <a href="./rfc7871">RFC 7871</a>,
DOI 10.17487/RFC7871, May 2016,
<<a href="https://www.rfc-editor.org/info/rfc7871">https://www.rfc-editor.org/info/rfc7871</a>>.
[<a id="ref-TLS-1.3">TLS-1.3</a>] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, <a href="./draft-ietf-tls-tls13-27">draft-ietf-tls-tls13-27</a>,
March 2018.
[<a id="ref-TLS-DNSSEC-Chain-Ext">TLS-DNSSEC-Chain-Ext</a>]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
Record and DNSSEC Authentication Chain Extension for TLS",
Work in Progress, <a href="./draft-ietf-tls-dnssec-chain-extension-06">draft-ietf-tls-dnssec-chain-</a>
<a href="./draft-ietf-tls-dnssec-chain-extension-06">extension-06</a>, January 2018.
<span class="grey">Dickinson, et al. Standards Track [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Server Capability Probing and Caching by DNS Clients</span>
This section presents a non-normative discussion of how DNS clients
might probe for, and cache capabilities of, privacy-enabling DNS
servers.
Deployment of both DNS over TLS and DNS over DTLS will be gradual.
Not all servers will support one or both of these protocols, and the
well-known port might be blocked by some middleboxes. Clients will
be expected to keep track of servers that support DNS over TLS and/or
DNS over DTLS, as well as those that have been previously
authenticated.
If no server capability information is available, then (unless
otherwise specified by the configuration of the DNS client) DNS
clients that implement both TLS and DTLS should try to authenticate
using both protocols before failing or falling back to an
unauthenticated or cleartext connection. DNS clients using an
Opportunistic Privacy profile should try all available servers
(possibly in parallel) in order to obtain an authenticated and
encrypted connection before falling back. (RATIONALE: This approach
can increase latency while discovering server capabilities but
maximizes the chance of sending the query over an authenticated and
encrypted connection.)
<span class="grey">Dickinson, et al. Standards Track [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc8310">RFC 8310</a> Usage Profiles for DNS over (D)TLS March 2018</span>
Acknowledgments
Thanks to the authors of both [<a href="./rfc8094" title=""DNS over Datagram Transport Layer Security (DTLS)"">RFC8094</a>] and [<a href="./rfc7858" title=""Specification for DNS over Transport Layer Security (TLS)"">RFC7858</a>] for laying the
groundwork for this document and for reviewing the contents. The
authors would also like to thank John Dickinson, Shumon Huque,
Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer,
Jinmei Tatuya, Paul Hoffman, Christian Huitema, and John Levine for
review and discussion of the ideas presented here.
Authors' Addresses
Sara Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: sara@sinodun.com
URI: <a href="https://www.sinodun.com/">https://www.sinodun.com/</a>
Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY 10004
United States of America
Email: dkg@fifthhorseman.net
Tirumaleswar Reddy
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: TirumaleswarReddy_Konda@McAfee.com
Dickinson, et al. Standards Track [Page 27]
</pre>
|
