-
Notifications
You must be signed in to change notification settings - Fork 7
/
draft-ietf-dprive-dnsoquic-08.xml
2287 lines (1916 loc) · 118 KB
/
draft-ietf-dprive-dnsoquic-08.xml
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
<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-dprive-dnsoquic-08" category="std">
<front>
<title abbrev="DNS over Dedicated QUIC">DNS over Dedicated QUIC Connections</title>
<author initials="C." surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus Inc.</organization>
<address>
<postal>
<street>427 Golfcourse Rd</street>
<city>Friday Harbor</city>
<code>WA 98250</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization>Sinodun IT</organization>
<address>
<postal>
<street>Oxford Science Park</street>
<city>Oxford</city>
<code>OX4 4GA</code>
<country>UK</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization>Salesforce</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2022" month="January" day="10"/>
<area>Transport</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes the use of QUIC to provide transport privacy for DNS.
The encryption provided by QUIC has similar properties to that provided by TLS,
while QUIC transport eliminates the head-of-line blocking issues inherent with
TCP and provides more efficient packet loss recovery than UDP. DNS over QUIC
(DoQ) has privacy properties similar to DNS over TLS (DoT) specified in
RFC7858, and latency characteristics similar to classic DNS over UDP. This
specification describes the use of DNS over QUIC as a general-purpose transport
for DNS and includes the use of DNS over QUIC for stub to recursive,
recursive to authoritative, and zone transfer scenarios.</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name>
<t>Domain Name System (DNS) concepts are specified in "Domain names - concepts and
facilities" <xref target="RFC1034"/>. The transmission of DNS queries and responses over
UDP and TCP is specified in "Domain names - implementation and specification"
<xref target="RFC1035"/>.</t>
<t>This document presents a mapping of the DNS protocol over the
QUIC transport <xref target="RFC9000"/> <xref target="RFC9001"/>. DNS over QUIC is referred here as DoQ,
in line with "DNS Terminology" <xref target="I-D.ietf-dnsop-rfc8499bis"/>.</t>
<t>The goals of the DoQ mapping are:</t>
<t><list style="numbers">
<t>Provide the same DNS privacy protection as DNS over TLS (DoT)
<xref target="RFC7858"/>. This includes an option for the client to
authenticate the server by means of an authentication domain
name as specified in "Usage Profiles for DNS over TLS and DNS
over DTLS" <xref target="RFC8310"/>.</t>
<t>Provide an improved level of source address validation for DNS
servers compared to classic DNS over UDP.</t>
<t>Provide a transport that is not constrained by path MTU limitations on the
size of DNS responses it can send.</t>
</list></t>
<t>In order to achieve these goals, and to support ongoing work on encryption of
DNS, the scope of this document includes</t>
<t><list style="symbols">
<t>the "stub to recursive resolver" scenario</t>
<t>the "recursive resolver to authoritative nameserver" scenario and</t>
<t>the "nameserver to nameserver" scenario (mainly used for zone transfers (XFR) <xref target="RFC1995"/>, <xref target="RFC5936"/>).</t>
</list></t>
<t>In other words, this document specifies QUIC as a general-purpose
transport for DNS.</t>
<t>The specific non-goals of this document are:</t>
<t><list style="numbers">
<t>No attempt is made to evade potential blocking of DNS over QUIC
traffic by middleboxes.</t>
<t>No attempt to support server-initiated transactions, which are used only in
DNS Stateful Operations (DSO) <xref target="RFC8490"/>.</t>
</list></t>
<t>Specifying the transmission of an application over QUIC requires specifying how
the application's messages are mapped to QUIC streams, and generally how the
application will use QUIC. This is done for HTTP in "Hypertext Transfer
Protocol Version 3 (HTTP/3)"<xref target="I-D.ietf-quic-http"/>. The purpose of this
document is to define the way DNS messages can be transmitted over QUIC.</t>
<t>DNS over HTTP <xref target="RFC8484"/> can be used with HTTP/3 to get some of the
benefits of QUIC. However, a lightweight direct mapping for DNS over QUIC can
be regarded as a more natural fit for both the recursive to authoritative and
zone transfer scenarios which rarely involve intermediaries. In these
scenarios, the additional overhead of HTTP is not offset by, e.g., benefits of
HTTP proxying and caching behavior.</t>
<t>In this document, <xref target="design-considerations"/> presents the reasoning that guided
the proposed design. <xref target="specifications"/> specifies the actual mapping of DoQ.
<xref target="implementation-requirements"/> presents guidelines on the implementation,
usage and deployment of DoQ.</t>
</section>
<section anchor="key-words"><name>Key Words</name>
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
</section>
<section anchor="document-work-via-github"><name>Document work via GitHub</name>
<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The Github
repository for this document is at https://github.com/huitema/dnsoquic.
Proposed text and editorial changes are very much welcomed there, but any
functional changes should always first be discussed on the IETF DPRIVE WG
(dns-privacy) mailing list.</t>
</section>
<section anchor="design-considerations"><name>Design Considerations</name>
<t>This section and its subsections present the design guidelines that were used
for DoQ. Whilst all other sections in this document are normative, this section
is informative in nature.</t>
<section anchor="provide-dns-privacy"><name>Provide DNS Privacy</name>
<t>DoT <xref target="RFC7858"/> defines how to mitigate some of the issues described in "DNS
Privacy Considerations" <xref target="RFC9076"/> by specifying how to transmit DNS messages
over TLS. The "Usage Profiles for DNS over TLS and DNS over DTLS" <xref target="RFC8310"/>
specify Strict and Opportunistic Usage Profiles for DoT including how stub
resolvers can authenticate recursive resolvers.</t>
<t>QUIC connection setup includes the negotiation of security parameters using
TLS, as specified in "Using TLS to Secure QUIC" <xref target="RFC9001"/>,
enabling encryption of the QUIC transport. Transmitting DNS messages over QUIC
will provide essentially the same privacy protections as DoT <xref target="RFC7858"/>
including Strict and Opportunistic Usage Profiles <xref target="RFC8310"/>. Further
discussion on this is provided in <xref target="privacy-considerations"/>.</t>
</section>
<section anchor="design-for-minimum-latency"><name>Design for Minimum Latency</name>
<t>QUIC is specifically designed to reduce protocol-induced delays, with features
such as:</t>
<t><list style="numbers">
<t>Support for 0-RTT data during session resumption.</t>
<t>Support for advanced packet loss recovery procedures as specified in
"QUIC Loss Detection and Congestion Control" <xref target="RFC9002"/>.</t>
<t>Mitigation of head-of-line blocking by allowing parallel
delivery of data on multiple streams.</t>
</list></t>
<t>This mapping of DNS to QUIC will take advantage of these features in
three ways:</t>
<t><list style="numbers">
<t>Optional support for sending 0-RTT data during session resumption
(the security and privacy implications of this are discussed
in later sections).</t>
<t>Long-lived QUIC connections over which multiple DNS transactions
are performed,
generating the sustained traffic required to benefit from
advanced recovery features.</t>
<t>Mapping of each DNS Query/Response transaction to a separate stream,
to mitigate head-of-line blocking. This enables servers to respond
to queries "out of order". It also enables clients to process
responses as soon as they arrive, without having to wait for in
order delivery of responses previously posted by the server.</t>
</list></t>
<t>These considerations are reflected in the mapping of DNS traffic
to QUIC streams in <xref target="stream-mapping-and-usage"/>.</t>
</section>
<section anchor="middlebox-considerations"><name>Middlebox Considerations</name>
<t>Using QUIC might allow a protocol to disguise its purpose from devices on the
network path using encryption and traffic analysis resistance techniques like
padding. This specification does not include any measures that are designed to
avoid such classification. Consequently, firewalls and other middleboxes might
be able to distinguish DoQ from other protocols that use QUIC, like HTTP, and
apply different treatment.</t>
<t>The lack of measures in this specification to avoid protocol classification is
not an endorsement of such practices.</t>
</section>
<section anchor="no-server-initiated-transactions"><name>No Server-Initiated Transactions</name>
<t>As stated in <xref target="introduction"/>, this document does not specify support for
server-initiated transactions within established DoQ connections. That is, only
the initiator of the DoQ connection may send queries over the connection.</t>
<t>DSO does support server-initiated transactions within existing connections.
However, DoQ as defined here does not meet the criteria for an applicable
transport for DSO because it does not guarantee in-order delivery of messages,
see <xref section="4.2" sectionFormat="of" target="RFC8490"/>.</t>
</section>
</section>
<section anchor="specifications"><name>Specifications</name>
<section anchor="connection-establishment"><name>Connection Establishment</name>
<t>DoQ connections are established as described in the QUIC transport
specification <xref target="RFC9000"/>. During connection establishment, DoQ support is
indicated by selecting the ALPN token "doq" in the crypto handshake.</t>
<section anchor="draft-version-identification"><name>Draft Version Identification</name>
<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only
implementations of the final, published RFC can identify themselves as "doq".
Until such an RFC exists, implementations MUST NOT identify themselves using
this string.</t>
<t>Implementations of draft versions of the protocol MUST add the string "-" and
the corresponding draft number to the identifier. For example,
draft-ietf-dprive-dnsoquic-00 is identified using the string "doq-i00".</t>
</section>
<section anchor="port-selection"><name>Port Selection</name>
<t>By default, a DNS server that supports DoQ MUST listen for and accept QUIC
connections on the dedicated UDP port TBD (number to be defined in
<xref target="iana-considerations"/>), unless there is a mutual agreement to
use another port.</t>
<t>By default, a DNS client desiring to use DoQ with a particular server MUST
establish a QUIC connection to UDP port TBD on the server, unless there is a
mutual agreement to use another port.</t>
<t>DoQ connections MUST NOT use UDP port 53. This recommendation against use of
port 53 for DoQ is to avoid confusion between DoQ and the use of DNS over UDP
<xref target="RFC1035"/>.</t>
<t>In the stub to recursive scenario, the use of port 443 as a mutually agreed
alternative port can be operationally beneficial, since port 443 is less likely
to be blocked than other ports. Several mechanisms for stubs to discover
recursives offering encrypted transports, including the use of custom ports, are
the subject of ongoing work.</t>
</section>
</section>
<section anchor="stream-mapping-and-usage"><name>Stream Mapping and Usage</name>
<t>The mapping of DNS traffic over QUIC streams takes advantage of the QUIC stream
features detailed in <xref section="2" sectionFormat="of" target="RFC9000"/>, the QUIC transport specification.</t>
<t>DNS traffic follows a simple pattern in which the client sends a query, and the
server provides one or more responses (multiple responses can occur in zone
transfers).</t>
<t>The mapping specified here requires that the client selects a separate QUIC
stream for each query. The server then uses the same stream to provide all the
response messages for that query. In order that multiple responses can be
parsed, a 2-octet length field is used in exactly the same way as the 2-octet
length field defined for DNS over TCP <xref target="RFC1035"/>. The practical result of this
is that the content of each QUIC stream is exactly the same as the content of a
TCP connection that would manage exactly one query.</t>
<t>All DNS messages (queries and responses) sent over DoQ connections MUST be
encoded as a 2-octet length field followed by the message content as specified
in <xref target="RFC1035"/>.</t>
<t>The client MUST select the next available client-initiated bidirectional stream
for each subsequent query on a QUIC connection, in conformance with the QUIC
transport specification <xref target="RFC9000"/>.</t>
<t>The client MUST send the DNS query over the selected stream, and MUST indicate
through the STREAM FIN mechanism that no further data will be sent on that
stream.</t>
<t>The server MUST send the response(s) on the same stream and MUST indicate, after
the last response, through the STREAM FIN mechanism that no further data will be
sent on that stream.</t>
<t>Therefore, a single client-initiated DNS transaction consumes a single stream.
This means that the client's first query occurs on QUIC stream 0, the second on
4, and so on.</t>
<t>Servers MAY defer processing of a query until the STREAM FIN has been indicated
on the stream selected by the client. Servers and clients MAY monitor the number
of "dangling" streams for which the expected queries or responses have been received but
not the STREAM FIN. Implementations MAY impose a limit on the number of
such dangling streams. If limits are encountered, implementations MAY close the connection.</t>
<section anchor="dns-message-ids"><name>DNS Message IDs</name>
<t>When sending queries over a QUIC connection, the DNS Message ID MUST be set to
zero. The stream mapping for DoQ allows for unambiguous correlation of queries
and responses and so the Message ID field is not required.</t>
<t>This has implications for proxying DoQ message to and from other transports.
For example, proxies may have to manage the fact that DoQ can support a larger
number of outstanding queries on a single connection than e.g., DNS over TCP
because DoQ is not limited by the Message ID space. This issue already exists for DoH,
where a Message ID of 0 is recommended.</t>
<t>When forwarding a DNS message from DoQ over another transport, a DNS Message ID
MUST be generated according to the rules of the protocol that is in use. When
forwarding a DNS message from another transport over DoQ, the Message ID MUST
be set to zero.</t>
</section>
</section>
<section anchor="doq-error-codes"><name>DoQ Error Codes</name>
<t>The following error codes are defined for use when abruptly terminating streams,
aborting reading of streams, or immediately closing connections:</t>
<dl>
<dt>
DOQ_NO_ERROR (0x0): </dt>
<dd>
<t>No error. This is used when the connection or stream needs to be closed, but
there is no error to signal.</t>
</dd>
<dt>
DOQ_INTERNAL_ERROR (0x1): </dt>
<dd>
<t>The DoQ implementation encountered an internal error and is incapable of
pursuing the transaction or the connection.</t>
</dd>
<dt>
DOQ_PROTOCOL_ERROR (0x2): </dt>
<dd>
<t>The DoQ implementation encountered an protocol error and is forcibly aborting
the connection.</t>
</dd>
<dt>
DOQ_REQUEST_CANCELLED (0x3): </dt>
<dd>
<t>A DoQ client uses this to signal that it wants to cancel an
outstanding transaction.</t>
</dd>
<dt>
DOQ_EXCESSIVE_LOAD (0x4): </dt>
<dd>
<t>A DoQ implementation uses this to signal when closing a connection due to excessive load.</t>
</dd>
<dt>
DOQ_ERROR_RESERVED (0xd098ea5e): </dt>
<dd>
<t>Alternative error code used for tests.</t>
</dd>
</dl>
<t>See <xref target="iana-error-codes"/> for details on registering new error codes.</t>
<section anchor="transaction-cancellation"><name>Transaction Cancellation</name>
<t>In QUIC, sending STOP_SENDING requests that a peer cease transmission on a
stream. If a DoQ client wishes to cancel an outstanding request, it MUST issue
a QUIC Stop Sending with error code DOQ_REQUEST_CANCELLED. This may be sent at
any time but will be ignored if the server response has already been
acknowledged. The corresponding DNS transaction MUST be abandoned.</t>
<t>Servers that receive STOP_SENDING act in accordance with <xref section="3.5" sectionFormat="of" target="RFC9000"/>.
Servers MAY impose implementation limits on the total number or rate of request cancellations.
If limits are encountered, servers MAY close the connection. In this case,
servers wanting to help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD.
There is always a trade-off between helping good faith clients debug issues
and allowing denial-of-service attackers to test server defenses, so depending
on circumstances servers might very well chose to send different error codes.</t>
<t>Note that this mechanism provides a way for secondaries to cancel a single zone
transfer occurring on a given stream without having to close the QUIC
connection.</t>
</section>
<section anchor="transaction-errors"><name>Transaction Errors</name>
<t>Servers normally complete transactions by sending a DNS response (or responses)
on the transaction's stream, including cases where the DNS response indicates a
DNS error. For example, a Server Failure (SERVFAIL, <xref target="RFC1035"/>) SHOULD be
notified to the client by sending back a response with the Response Code set to
SERVFAIL.</t>
<t>If a server is incapable of sending a DNS response due to an internal error, it
SHOULD issue a QUIC Stream Reset. The error code SHOULD be set to DOQ_INTERNAL_ERROR. The
corresponding DNS transaction MUST be abandoned. Clients MAY limit the number of
unsolicited QUIC Stream Resets received on a connection before choosing to close the
connection.</t>
<t>Note that this mechanism provides a way for primaries to abort a single zone
transfer occurring on a given stream without having to close the QUIC
connection.</t>
</section>
<section anchor="protocol-errors"><name>Protocol Errors</name>
<t>Other error scenarios can occur due to malformed, incomplete or unexpected
messages during a transaction. These include (but are not limited to)</t>
<t><list style="symbols">
<t>a client or server receives a message with a non-zero Message ID</t>
<t>a client or server receives a STREAM FIN before receiving all the bytes for a
message indicated in the 2-octet length field</t>
<t>a client receives a STREAM FIN before receiving all the expected responses</t>
<t>a server receives more than one query on a stream</t>
<t>a client receives a different number of responses on a stream than expected
(e.g. multiple responses to a query for an A record)</t>
<t>a client receives a STOP_SENDING request</t>
<t>the client or server does not indicate the expected STREAM FIN after
sending requests or responses (see <xref target="stream-mapping-and-usage"/>).</t>
<t>an implementation receives a message containing the edns-tcp-keepalive
EDNS(0) Option <xref target="RFC7828"/> (see
<xref target="resource-management"/>)</t>
<t>a client or a server attempts to open a unidirectional QUIC stream</t>
<t>a server attempts to open a server-initiated bidirectional QUIC stream</t>
</list></t>
<t>If a peer encounters such an error condition it is considered a fatal error. It
SHOULD forcibly abort the connection using QUIC's CONNECTION_CLOSE mechanism,
and SHOULD use the DoQ error code DOQ_PROTOCOL_ERROR.</t>
<t>It is noted that the restrictions on use of the above EDNS(0) options has
implications for proxying message from TCP/DoT/DoH over DoQ.</t>
</section>
<section anchor="alternative-error-codes"><name>Alternative error codes</name>
<t>This specification suggests specific error codes <xref target="transaction-cancellation"/>,
<xref target="transaction-errors"/>, and <xref target="protocol-errors"/>. These error codes are meant
to facilitate investigation of failures and other incidents. New error
codes may be defined in future versions of DoQ, or registered as specified
in <xref target="iana-error-codes"/>.</t>
<t>Because new error codes can be defined without negotiation, use of an error
code in an unexpected context or receipt of an unknown error code MUST be
treated as equivalent to DOQ_NO_ERROR.</t>
<t>Implementations MAY wish to test the support for the error code extension
mechanism by using error codes not listed in this document, or they MAY use
DOQ_ERROR_RESERVED.</t>
</section>
</section>
<section anchor="connection-management"><name>Connection Management</name>
<t><xref section="10" sectionFormat="of" target="RFC9000"/>, the QUIC transport specification, specifies that
connections can be closed in three ways:</t>
<t><list style="symbols">
<t>idle timeout</t>
<t>immediate close</t>
<t>stateless reset</t>
</list></t>
<t>Clients and servers implementing DoQ SHOULD negotiate use of the idle timeout.
Closing on idle timeout is done without any packet exchange, which minimizes
protocol overhead. Per <xref section="10.1" sectionFormat="of" target="RFC9000"/>, the QUIC transport specification, the
effective value of the idle timeout is computed as the minimum of the values
advertised by the two endpoints. Practical considerations on setting the idle
timeout are discussed in <xref target="resource-management"/>.</t>
<t>Clients SHOULD monitor the idle time incurred on their connection to the
server, defined by the time spent since the last packet from the server has
been received. When a client prepares to send a new DNS query to the server, it
will check whether the idle time is sufficient lower than the idle timer. If it
is, the client will send the DNS query over the existing connection. If not,
the client will establish a new connection and send the query over that
connection.</t>
<t>Clients MAY discard their connections to the server before the idle timeout
expires. A client that has outstanding queries SHOULD close the connection
explicitly using QUIC's CONNECTION_CLOSE mechanism and the DoQ error code
DOQ_NO_ERROR.</t>
<t>Clients and servers MAY close the connection for a variety of other
reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers
that send packets over a connection discarded by their peer MAY
receive a stateless reset indication. If a connection fails, all the
in progress transaction on that connection MUST be abandoned.</t>
</section>
<section anchor="session-resumption-and-0-rtt"><name>Session Resumption and 0-RTT</name>
<t>A client MAY take advantage of the session resumption mechanisms supported by
QUIC transport <xref target="RFC9000"/> and QUIC TLS <xref target="RFC9001"/>. Clients SHOULD consider
potential privacy issues associated with session resumption before deciding to use
this mechanism. These privacy issues are detailed in
<xref target="privacy-issues-with-session-resumption"/> and <xref target="privacy-issues-with-0-rtt-data"/>,
and the implementation considerations are discussed in
<xref target="using-0-rtt-and-session-resumption"/>.</t>
<t>The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are not
"replayable" transactions. In this specification, only transactions that have
an OPCODE of QUERY or NOTIFY are considered replayable and MAY be sent in 0-RTT
data. See <xref target="the-notify-service"/> for a detailed discussion of why NOTIFY is
included here.</t>
<t>Servers MUST NOT execute non replayable transactions received in 0-RTT
data. Servers MUST adopt one of the following behaviors:</t>
<t><list style="symbols">
<t>Queue the offending transaction and only execute it after the QUIC handshake
has been completed, as defined in <xref section="4.1.1" sectionFormat="of" target="RFC9001"/>.</t>
<t>Reply to the offending transaction with a response code REFUSED and
an Extended DNS Error Code (EDE) "Too Early", see
<xref target="reservation-of-extended-dns-error-code-too-early"/>.</t>
<t>Close the connection with the error code DOQ_PROTOCOL_ERROR.</t>
</list></t>
</section>
<section anchor="message-sizes"><name>Message Sizes</name>
<t>DoQ Queries and Responses are sent on QUIC streams, which in theory can carry
up to 2^62 bytes. However, DNS messages are restricted in practice to a maximum
size of 65535 bytes. This maximum size is enforced by the use of a two-octet
message length field in DNS over TCP <xref target="RFC1035"/> and DNS over TLS
<xref target="RFC7858"/>, and by the definition of the "application/dns-message" for DNS
over HTTP <xref target="RFC8484"/>. DoQ enforces the same restriction.</t>
<t>The Extension Mechanisms for DNS (EDNS) <xref target="RFC6891"/> allow peers to specify the
UDP message size. This parameter is ignored by DoQ. DoQ implementations always
assume that the maximum message size is 65535 bytes.</t>
</section>
</section>
<section anchor="implementation-requirements"><name>Implementation Requirements</name>
<section anchor="authentication"><name>Authentication</name>
<t>For the stub to recursive resolver scenario, the authentication requirements
are the same as described in DoT <xref target="RFC7858"/> and "Usage Profiles for DNS over
TLS and DNS over DTLS" <xref target="RFC8310"/>. <xref target="RFC8932"/> states that DNS privacy
services SHOULD provide credentials that clients can use to authenticate the
server. Given this, and to align with the authentication model for DoH, DoQ stubs
SHOULD use a Strict authentication profile. Client authentication for the encrypted
stub to recursive scenario is not described in any DNS RFC.</t>
<t>For zone transfer, the requirements are the same as described in
<xref target="RFC9103"/>.</t>
<t>For the recursive resolver to authoritative nameserver scenario, authentication
requirements are unspecified at the time of writing and are the subject on
ongoing work in the DPRIVE WG.</t>
</section>
<section anchor="fallback-to-other-protocols-on-connection-failure"><name>Fallback to Other Protocols on Connection Failure</name>
<t>If the establishment of the DoQ connection fails, clients MAY attempt to
fall back to DoT and then potentially clear text, as specified in DoT
<xref target="RFC7858"/> and "Usage Profiles for DNS over TLS and DNS over DTLS"
<xref target="RFC8310"/>, depending on their privacy profile.</t>
<t>DNS clients SHOULD remember server IP addresses that don't support DoQ.
Timeouts, connection refusals, and QUIC handshake failures are valid indicators
that a server does not support DoQ. Clients SHOULD NOT attempt DoQ queries to a
server that does not support DoQ for a reasonable period (such as one hour per
server). DNS clients following an out-of-band key-pinned privacy profile
(<xref target="RFC7858"/>) MAY be more aggressive about retrying DoQ connection failures.</t>
</section>
<section anchor="address-validation"><name>Address Validation</name>
<t><xref section="8" sectionFormat="of" target="RFC9000"/>, the QUIC transport specification, defines Address
Validation procedures to avoid servers being used in address amplification
attacks. DoQ implementations MUST conform to this specification, which limits
the worst case amplification to a factor 3.</t>
<t>DoQ implementations SHOULD consider configuring servers to use the Address
Validation using Retry Packets procedure defined in <xref section="8.1.2" sectionFormat="of" target="RFC9000"/>, the QUIC
transport specification. This procedure imposes a 1-RTT delay for
verifying the return routability of the source address of a client, similar to
the DNS Cookies mechanism <xref target="RFC7873"/>.</t>
<t>DoQ implementations that configure Address Validation using Retry Packets
SHOULD implement the Address Validation for Future Connections procedure
defined in <xref section="8.1.3" sectionFormat="of" target="RFC9000"/>, the QUIC transport specification.
This defines how servers can send NEW_TOKEN frames to clients after the client
address is validated, in order to avoid the 1-RTT penalty during subsequent
connections by the client from the same address.</t>
</section>
<section anchor="padding"><name>Padding</name>
<t>Implementations MUST protect against the traffic analysis attacks described in
<xref target="traffic-analysis"/> by the judicious injection of padding. This
could be done either by padding individual DNS messages using the
EDNS(0) Padding Option <xref target="RFC7830"/> or by padding QUIC packets (see
<xref section="8.6" sectionFormat="of" target="RFC9000"/>, the QUIC transport specification.</t>
<t>In theory, padding at the QUIC level could result in better performance for the equivalent
protection, because the amount of padding can take into account non-DNS frames
such as acknowledgements or flow control updates, and also because QUIC packets
can carry multiple DNS messages. However, applications can only control the
amount of padding in QUIC packets if the implementation of QUIC exposes adequate APIs. This leads
to the following recommendation:</t>
<t><list style="symbols">
<t>if the implementation of QUIC exposes APIs to set a padding policy,
DNS over QUIC SHOULD use that API to align the packet length to a small set of
fixed sizes.</t>
<t>if padding at the QUIC level is not available or not used,
DNS over QUIC MUST ensure that all DNS queries and responses are padded to
a small set of fixed sizes, using the EDNS(0) padding extension as specified
in <xref target="RFC7830"/>.</t>
</list></t>
<t>Implementation might choose not to use a QUIC API for padding if it is
significantly simpler to re-use existing DNS message padding logic which is
applied to other encrypted transports.</t>
<t>In the absence of a standard policy for padding sizes, implementations should
consider following the recommendations of the Experimental status "Padding
Policies for Extension Mechanisms for DNS (EDNS(0))" <xref target="RFC8467"/>.</t>
</section>
<section anchor="connection-handling"><name>Connection Handling</name>
<t>"DNS Transport over TCP - Implementation Requirements" <xref target="RFC7766"/> provides
updated guidance on DNS over TCP, some of which is applicable to DoQ. This
section provides similar advice on connection handling for DoQ.</t>
<section anchor="connection-reuse"><name>Connection Reuse</name>
<t>Historic implementations of DNS clients are known to open and close TCP
connections for each DNS query. To amortize connection setup costs, both
clients and servers SHOULD support connection reuse by sending multiple queries
and responses over a single persistent QUIC connection.</t>
<t>In order to achieve performance on par with UDP, DNS clients SHOULD send their
queries concurrently over the QUIC streams on a QUIC connection. That is, when
a DNS client sends multiple queries to a server over a QUIC connection, it
SHOULD NOT wait for an outstanding reply before sending the next query.</t>
</section>
<section anchor="resource-management"><name>Resource Management</name>
<t>Proper management of established and idle connections is important to the
healthy operation of a DNS server.</t>
<t>An implementation of DoQ SHOULD follow best practices similar to those
specified for DNS over TCP <xref target="RFC7766"/>, in particular with regard to:</t>
<t><list style="symbols">
<t>Concurrent Connections (<xref section="6.2.2" sectionFormat="of" target="RFC7766"/>, updated by <xref section="6.4" sectionFormat="of" target="RFC9103"/>)</t>
<t>Security Considerations (<xref section="10" sectionFormat="of" target="RFC7766"/>)</t>
</list></t>
<t>Failure to do so may lead to resource exhaustion and denial of service.</t>
<t>Clients that want to maintain long duration DoQ connections SHOULD use the idle
timeout mechanisms defined in <xref section="10.1" sectionFormat="of" target="RFC9000"/>, the QUIC transport
specification. Clients and servers MUST NOT send the edns-tcp-keepalive EDNS(0)
Option <xref target="RFC7828"/> in any messages sent on a DoQ connection (because it is
specific to the use of TCP/TLS as a transport).</t>
<t>This document does not make specific recommendations for timeout values on idle
connections. Clients and servers should reuse and/or close connections
depending on the level of available resources. Timeouts may be longer during
periods of low activity and shorter during periods of high activity.</t>
</section>
<section anchor="using-0-rtt-and-session-resumption"><name>Using 0-RTT and Session Resumption</name>
<t>Using 0-RTT for DNS over QUIC has many compelling advantages. Clients
can establish connections and send queries without incurring a connection
delay. Servers can thus negotiate low values of the connection
timers, which reduces the total number of connections that they need to
manage. They can do that because the clients that use 0-RTT will not incur
latency penalties if new connections are required for a query.</t>
<t>Session resumption and 0-RTT data transmission create
privacy risks detailed in detailed in
<xref target="privacy-issues-with-session-resumption"/> and <xref target="privacy-issues-with-0-rtt-data"/>.
The following recommendations are meant to reduce the privacy
risks while enjoying the performance benefits of 0-RTT data, with the
restriction specified in <xref target="session-resumption-and-0-rtt"/>.</t>
<t>Clients SHOULD use resumption tickets only once, as specified in Appendix C.4
to <xref target="RFC8446"/>. By default, clients SHOULD NOT use session resumption if the
client's connectivity has changed.</t>
<t>Clients could receive address validation tokens from the server using the
NEW_TOKEN mechanism; see <xref section="8" sectionFormat="of" target="RFC9000"/>. The associated tracking
risks are mentioned in <xref target="privacy-issues-with-address-validation-tokens"/>.
Clients SHOULD only use the address validation tokens when they are also using session
resumption, thus avoiding additional tracking risks.</t>
<t>Servers SHOULD issue session resumption tickets with a sufficiently long life time (e.g., 6 hours),
so that clients are not tempted to either keep connection alive or frequently poll the server
to renew session resumption tickets.
Servers SHOULD implement the anti-replay mechanisms specified in <xref section="8" sectionFormat="of" target="RFC8446"/>.</t>
</section>
<section anchor="controlling-connection-migration-for-privacy"><name>Controlling Connection Migration For Privacy</name>
<t>DoQ implementation might consider using the connection migration features defined
in <xref section="9" sectionFormat="of" target="RFC9000"/>. These features enable connections to continue operating
as the client's connectivity changes.
As detailed in <xref target="privacy-issues-with-long-duration-sessions"/>, these features
trade off privacy for latency. By default, clients SHOULD be configured
to prioritize privacy and start new sessions if their connectivity changes.</t>
</section>
</section>
<section anchor="processing-queries-in-parallel"><name>Processing Queries in Parallel</name>
<t>As specified in <xref section="7" sectionFormat="of" target="RFC7766"/> "DNS Transport over TCP - Implementation
Requirements", resolvers are RECOMMENDED to support the preparing
of responses in parallel and sending them out of order. In DoQ, they do that by
sending responses on their specific stream as soon as possible, without waiting
for availability of responses for previously opened streams.</t>
</section>
<section anchor="zone-transfer"><name>Zone transfer</name>
<t><xref target="RFC9103"/> specifies zone transfer over TLS (XoT)
and includes updates to <xref target="RFC1995"/> (IXFR), <xref target="RFC5936"/> (AXFR) and
<xref target="RFC7766"/>. Considerations relating to the re-use of XoT connections
described there apply analogously to zone transfers performed using DoQ
connections. For example:</t>
<t><list style="symbols">
<t>DoQ servers MUST be able to handle multiple concurrent IXFR requests on a
single QUIC connection</t>
<t>DoQ servers MUST be able to handle multiple concurrent AXFR requests on a
single QUIC connection</t>
<t>DoQ implementations SHOULD
<list style="symbols">
<t>use the same QUIC connection for both AXFR and IXFR requests to the same
primary</t>
<t>pipeline such requests (if they pipeline XFR requests in general) and
MAY intermingle them</t>
<t>send the response(s) for each request as soon as they are available i.e.
responses MAY be sent intermingled</t>
</list></t>
</list></t>
</section>
<section anchor="flow-control-mechanisms"><name>Flow Control Mechanisms</name>
<t>Servers and Clients manage flow control using the mechanisms defined in
<xref section="4" sectionFormat="of" target="RFC9000"/>. These mechanisms allow clients and servers to specify
how many streams can be created, how much data can be sent on a stream,
and how much data can be sent on the union of all streams. For DNS over QUIC,
controlling how many streams are created allows servers to control how many
new requests the client can send on a given connection.</t>
<t>Flow control exists to protect endpoint resources.
For servers, global and per-stream flow control limits control how much data can be sent by
clients. The same mechanisms
allow clients to control how much data can be sent by servers.
Values that are too small will unnecessarily limit performance.
Values that are too large might expose endpoints to overload or memory exhaustion.
Implementations or deployments will need to adjust flow control limits to
balance these concerns. In particular, zone transfer implementations will need to control
these limits carefully to ensure both large and concurrent zone transfers are well managed.</t>
<t>Initial values of parameters control how many requests and how much data can be
sent by clients and servers at the beginning of the connection. These values
are specified in transport parameters exchanged during the connection handshake.
The parameter values received in the initial connection also control how many requests and
how much data can be sent by clients using 0-RTT data in a resumed connection.
Using too small values of these initial parameters would restrict the
usefulness of allowing 0-RTT data.</t>
</section>
</section>
<section anchor="implementation-status"><name>Implementation Status</name>
<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) This section
records the status of known implementations of the protocol defined by this
specification at the time of posting of this Internet-Draft, and is based on a
proposal described in <xref target="RFC7942"/>.</t>
<t><list style="numbers">
<t>AdGuard launched a DoQ recursive resolver service in December 2020. They have
released a suite of open source tools that support DoQ:
<list style="numbers">
<t><eref target="https://github.com/AdguardTeam/DnsLibs">AdGuard C++ DNS libraries</eref> A
DNS proxy library that supports all existing DNS protocols including
DNS-over-TLS, DNS-over-HTTPS, DNSCrypt and DNS-over-QUIC (experimental).</t>
<t><eref target="https://github.com/AdguardTeam/dnsproxy">DNS Proxy</eref> A simple DNS proxy
server that supports all existing DNS protocols including DNS-over-TLS,
DNS-over-HTTPS, DNSCrypt, and DNS-over-QUIC. Moreover, it can work as a
DNS-over-HTTPS, DNS-over-TLS or DNS-over-QUIC server.</t>
<t><eref target="https://github.com/AdguardTeam/coredns">CoreDNS fork for AdGuard DNS</eref>
Includes DNS-over-QUIC server-side support.</t>
<t><eref target="https://github.com/ameshkov/dnslookup">dnslookup</eref> Simple command line
utility to make DNS lookups. Supports all known DNS protocols: plain DNS,
DoH, DoT, DoQ, DNSCrypt.</t>
</list></t>
<t><eref target="https://github.com/private-octopus/quicdoq">Quicdoq</eref> Quicdoq is a simple
open source implementation of DoQ. It is written in C, based on
<eref target="https://github.com/private-octopus/picoquic">Picoquic</eref>.</t>
<t><eref target="https://github.com/DNS-OARC/flamethrower/tree/dns-over-quic">Flamethrower</eref>
is an open source DNS performance and functional testing utility written in
C++ that has an experimental implementation of DoQ.</t>
<t><eref target="https://github.com/aiortc/aioquic">aioquic</eref> is an implementation of QUIC in
Python. It includes example client and server for DoQ.</t>
</list></t>
<section anchor="performance-measurements"><name>Performance Measurements</name>
<t>To the authors' knowledge, no benchmarking studies comparing DoT, DoH and DoQ
are published yet. However, anecdotal evidence from the <eref target="https://adguard.com/en/blog/dns-over-quic.html">AdGuard DoQ recursive
resolver deployment</eref> indicates
that it performs similarly (and possibly better) compared to the other
encrypted protocols, particularly in mobile environments. Reasons given for
this include that DoQ</t>
<t><list style="symbols">
<t>Uses less bandwidth due to a more efficient handshake (and due to less per
message overhead when compared to DoH).</t>
<t>Performs better in mobile environments due to the increased resilience to
packet loss</t>
<t>Can maintain connections as users move between mobile networks via its
connection management</t>
</list></t>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>The security considerations of DoQ should be comparable to those of DoT
<xref target="RFC7858"/>.</t>
</section>
<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<t>The general considerations of encrypted transports provided in "DNS Privacy
Considerations" <xref target="RFC9076"/> apply to DoQ. The specific
considerations provided there do not differ between DoT and DoQ, and are not
discussed further here. Similarly, "Recommendations for DNS Privacy Service
Operators" <xref target="RFC8932"/> (which covers operational, policy, and security
considerations for DNS privacy services) is also applicable to DoQ services.</t>
<t>QUIC incorporates the mechanisms of TLS 1.3 <xref target="RFC8446"/> and this enables QUIC
transmission of "0-RTT" data. This can provide interesting latency gains, but
it raises two concerns:</t>
<t><list style="numbers">
<t>Adversaries could replay the 0-RTT data and infer its content
from the behavior of the receiving server.</t>
<t>The 0-RTT mechanism relies on TLS session resumption, which can provide
linkability between successive client sessions.</t>
</list></t>
<t>These issues are developed in <xref target="privacy-issues-with-0-rtt-data"/> and
<xref target="privacy-issues-with-session-resumption"/>.</t>
<section anchor="privacy-issues-with-0-rtt-data"><name>Privacy Issues With 0-RTT data</name>
<t>The 0-RTT data can be replayed by adversaries. That data may trigger queries by
a recursive resolver to authoritative resolvers. Adversaries may be able to
pick a time at which the recursive resolver outgoing traffic is observable, and
thus find out what name was queried for in the 0-RTT data.</t>
<t>This risk is in fact a subset of the general problem of observing the behavior
of the recursive resolver discussed in "DNS Privacy Considerations"
<xref target="RFC9076"/>. The attack is partially mitigated by reducing the observability
of this traffic. The mandatory replay protection mechanisms in
TLS 1.3 <xref target="RFC8446"/> limit but do not eliminate the risk of replay.
0-RTT packets can only be replayed within a narrow window,
which is only wide enough to account for variations in clock skew and network transmission.</t>
<t>The recommendation for TLS 1.3 <xref target="RFC8446"/> is that the capability to use 0-RTT
data should be turned off by default, and only enabled if the user clearly
understands the associated risks. In the case of DoQ, allowing 0-RTT data
provides significant performance gains, and there is a concern that a
recommendation to not use it would simply be ignored. Instead, a set of
practical recommendations is provided in <xref target="session-resumption-and-0-rtt"/> and
<xref target="using-0-rtt-and-session-resumption"/>.</t>
<t>The prevention on allowing replayable transactions in 0-RTT data
expressed in <xref target="session-resumption-and-0-rtt"/> blocks the most obvious
risks of replay attacks, as it only allows for transactions that will
not change the long-term state of the server.</t>
<t>The attacks described above apply to the stub resolver to recursive
resolver scenario, but similar attacks might be envisaged in the
recursive resolver to authoritative resolver scenario, and the
same mitigations apply.</t>
</section>
<section anchor="privacy-issues-with-session-resumption"><name>Privacy Issues With Session Resumption</name>
<t>The QUIC session resumption mechanism reduces the cost of re-establishing sessions
and enables 0-RTT data. There is a linkability issue associated with session
resumption, if the same resumption token is used several times. Attackers on path
between client and server could observe repeated usage of the token and
use that to track the client over time or over multiple locations.</t>
<t>The session resumption mechanism allows servers to correlate the resumed sessions
with the initial sessions, and thus to track the client. This creates a virtual
long duration session. The series of queries in that session can be used by the
server to identify the client. Servers can most probably do that already if
the client address remains constant, but session resumption tickets also enable
tracking after changes of the client's address.</t>
<t>The recommendations in <xref target="using-0-rtt-and-session-resumption"/> are designed to
mitigate these risks. Using session tickets only once mitigates
the risk of tracking by third parties. Refusing to resume a session if addresses
change mitigates the risk of tracking by the server.</t>
<t>The privacy trade-offs here may be context specific. Stub resolvers will have a strong
motivation to prefer privacy over latency since they often change location. However,
recursive resolvers that use a small set of static IP addresses are more likely to prefer the reduced
latency provided by session resumption and may consider this a valid reason to use
resumption tickets even if the IP address changed between sessions.</t>
<t>Encrypted zone transfer (RFC9103) explicitly does
not attempt to hide the identity of the parties involved in the transfer, but at the
same time such transfers are not particularly latency sensitive. This means that
applications supporting zone transfers may decide to apply the same
protections as stub to recursive applications.</t>
</section>
<section anchor="privacy-issues-with-address-validation-tokens"><name>Privacy Issues With Address Validation Tokens</name>
<t>QUIC specifies address validation mechanisms in <xref section="8" sectionFormat="of" target="RFC9000"/>. Use
of an address validation token allows QUIC servers to avoid an extra RTT for
new connections. Address validation tokens are typically tied to an IP address.
QUIC clients normally only use these tokens when setting up a new connection
from a previously used address. However, clients are not always aware that they
are using a new address. This could be due to NAT, or because the client does
not have an API available to check if the IP address has changed (which can be
quite often for IPv6). There is a linkability risk if clients mistakenly use
address validation tokens after unknowingly moving to a new location.</t>
<t>The recommendations in <xref target="using-0-rtt-and-session-resumption"/> mitigates
this risk by tying the usage of the NEW_TOKEN to that of session resumption.</t>
</section>
<section anchor="privacy-issues-with-long-duration-sessions"><name>Privacy Issues With Long Duration Sessions</name>
<t>A potential alternative to session resumption is the use of long duration sessions:
if a session remains open for a long time, new queries can be sent without incurring
connection establishment delays. It is worth pointing out that the two solutions have
similar privacy characteristics. Session resumption may allow servers to keep track
of the IP addresses of clients, but long duration sessions have the same effect.</t>
<t>In particular, a DoQ implementation might take advantage of the connection migration
features of QUIC to maintain a session even if the client's connectivity changes,
for example if the client migrates from a Wi-Fi connection to a cellular network
connection, and then to another Wi-Fi connection. The server would be
able to track the client location by monitoring the succession of IP addresses
used by the long duration connection.</t>
<t>The recommendation in <xref target="controlling-connection-migration-for-privacy"/> mitigates
the privacy concerns related to long duration sessions using multiple client addresses.</t>
</section>
<section anchor="traffic-analysis"><name>Traffic Analysis</name>
<t>Even though QUIC packets are encrypted, adversaries can gain information from
observing packet lengths, in both queries and responses, as well as packet
timing. Many DNS requests are emitted by web browsers. Loading a specific web
page may require resolving dozen of DNS names. If an application adopts a
simple mapping of one query or response per packet, or "one QUIC STREAM frame
per packet", then the succession of packet lengths may provide enough
information to identify the requested site.</t>