-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-moura-dnsop-authoritative-recommendations.xml
1360 lines (1234 loc) · 66.9 KB
/
draft-moura-dnsop-authoritative-recommendations.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.3.32 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC7094 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7094.xml">
<!ENTITY RFC1546 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1546.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1995 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml">
<!ENTITY RFC5936 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml">
<!ENTITY RFC4786 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml">
<!ENTITY RFC1997 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!ENTITY RFC8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml">
<!ENTITY RFC8782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8782.xml">
<!ENTITY RFC8783 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml">
<!ENTITY RFC8955 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4509 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml">
<!ENTITY RFC8811 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8811.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-moura-dnsop-authoritative-recommendations-11" category="info">
<front>
<title abbrev="Considerations-Large-Auth-DNS-Ops">Considerations for Large Authoritative DNS Servers Operators</title>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
<organization>SIDN Labs/TU Delft</organization>
<address>
<postal>
<street>Meander 501</street>
<city>Arnhem</city>
<code>6825 MD</code>
<country>NL</country>
</postal>
<phone>+31 26 352 5500</phone>
<email>[email protected]</email>
</address>
</author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>PO Box 382</street>
<city>Davis</city>
<code>95617-0382</code>
<country>US</country>
</postal>
<phone>+1 (530) 404-0099</phone>
<email>[email protected]</email>
</address>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina Del Rey</city>
<code>90292-6695</code>
<country>US</country>
</postal>
<phone>+1 (310) 448-8708</phone>
<email>[email protected]</email>
</address>
</author>
<author initials="M." surname="Davids" fullname="Marco Davids">
<organization>SIDN Labs</organization>
<address>
<postal>
<street>Meander 501</street>
<city>Arnhem</city>
<code>6825 MD</code>
<country>NL</country>
</postal>
<phone>+31 26 352 5500</phone>
<email>[email protected]</email>
</address>
</author>
<date year="2022" month="January" day="04"/>
<area>Internet</area>
<workgroup>DNSOP Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Recent research work has explored the deployment characteristics and
configuration of the Domain Name System (DNS). This document
summarizes the conclusions from these research efforts and offers
specific, tangible considerations or advice to authoritative DNS
server operators. Authoritative server operators may wish to follow
these considerations to improve their DNS services.</t>
<t>It is possible that the results presented in this document could be
applicable in a wider context than just the DNS protocol,
as some of the results may generically apply to
any stateless/short-duration, anycasted service.</t>
<t>This document is not an IETF consensus document: it is published for
informational purposes.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document summarizes recent research work that explored the
deployed DNS configurations and offers derived, specific tangible
advice to DNS authoritative server operators (DNS operators
hereafter). The considerations (C1--C5) presented in this document are
backed by peer-reviewed research works, which used wide-scale Internet
measurements to draw their conclusions. This document summarizes the
research results and describes the resulting key engineering options.
In each section, it points readers to the pertinent publications where
additional details are presented.</t>
<t>These considerations are designed for operators of "large"
authoritative DNS servers. In this context, "large" authoritative
servers refers to those with a significant global user population,
like top-level domain (TLD) operators, run by either a single or
multiple operators. Typically these networks are deployed on wide
anycast networks <xref target="RFC1546"/><xref target="AnyBest"/>. These considerations may not be
appropriate for smaller domains, such as those used by an organization
with users in one unicast network, or in one city or region, where
operational goals such as uniform, global low latency are less
required.</t>
<t>It is possible that the results presented in this document could be
applicable in a wider context than just the DNS protocol, as some of
the results may generically apply to any stateless/short-duration,
anycasted service. Because the conclusions of the reviewed studies
don't measure smaller networks, the wording in this document
concentrates solely on disusing large-scale DNS authoritative services
only.</t>
<t>This document is not an IETF consensus document: it is published for
informational purposes.</t>
</section>
<section anchor="background" title="Background">
<t>The DNS has main two types of DNS servers: authoritative servers and
recursive resolvers, shown by a representational deployment model in
<xref target="recuath"/>. An authoritative server (shown as AT1--AT4 in
<xref target="recuath"/>) knows the content of a DNS zone, and is responsible for
answering queries about that zone. It runs using local (possibly
automatically updated) copies of the zone and does not need to query
other servers <xref target="RFC2181"/> in order to answer requests. A recursive
resolver (Re1--Re3) is a server that iteratively queries authoritative
and other servers to answer queries received from client requests
<xref target="RFC1034"/>. A client typically employs a software library called a stub
resolver (stub in <xref target="recuath"/>) to issue its query to the upstream
recursive resolvers <xref target="RFC1034"/>.</t>
<figure title="Relationship between recursive resolvers (Re) and authoritative name servers (ATn)" anchor="recuath"><artwork><![CDATA[
+-----+ +-----+ +-----+ +-----+
| AT1 | | AT2 | | AT3 | | AT4 |
+-----+ +-----+ +-----+ +-----+
^ ^ ^ ^
| | | |
| +-----+ | |
+------| Re1 |----+| |
| +-----+ |
| ^ |
| | |
| +----+ +----+ |
+------|Re2 | |Re3 |------+
+----+ +----+
^ ^
| |
| +------+ |
+-| stub |-+
+------+
]]></artwork></figure>
<t>DNS queries issued by a client contribute to a user's perceived
perceived latency and affect user experience <xref target="Singla2014"/> depending
on how long it takes for responses to be returned. The DNS system has
been subject to repeated Denial of Service (DoS) attacks (for example,
in November 2015 <xref target="Moura16b"/>) in order to specifically degrade user
experience.</t>
<t>To reduce latency and improve resiliency against DoS attacks, the DNS
uses several types of service replication. Replication at the
authoritative server level can be achieved with (i) the deployment of
multiple servers for the same zone <xref target="RFC1035"/> (AT1---AT4 in
<xref target="recuath"/>), (ii) the use of IP anycast
<xref target="RFC1546"/><xref target="RFC4786"/><xref target="RFC7094"/> that allows the same IP address to
be announced from multiple locations (each of referred to as an
"anycast instance" <xref target="RFC8499"/>) and (iii) the use of load balancers to
support multiple servers inside a single (potentially anycasted)
instance. As a consequence, there are many possible ways an
authoritative DNS provider can engineer its production authoritative
server network, with multiple viable choices and no necessarily single
optimal design.</t>
</section>
<section anchor="considerations" title="Considerations">
<t>In the next sections we cover the specific consideration (C1--C6) for
conclusions drawn within the academic papers about large authoritative
DNS server operators. These considerations are conclusions reached
from academic works that authoritative server operators may wish to
consider in order to improve their DNS service. Each consideration
offers different improvements that may impact service latency,
routing, anycast deployment, and defensive strategies for example.</t>
<section anchor="c1" title="C1: Deploy anycast in every authoritative server to enhance distribution and latency">
<section anchor="research-background" title="Research background">
<t>Authoritative DNS server operators announce their service using NS
records<xref target="RFC1034"/>. Different authoritative servers for a given zone
should return the same content; typically they stay synchronized using
DNS zone transfers (AXFR<xref target="RFC5936"/> and IXFR<xref target="RFC1995"/>), coordinating
the zone data they all return to their clients.</t>
<t>As discussed above, the DNS heavily relies upon replication to support
high reliability, ensure capacity and to reduce latency <xref target="Moura16b"/>.
DNS has two complementary mechanisms for service replication:
nameserver replication (multiple NS records) and anycast (multiple
physical locations). Nameserver replication is strongly recommended
for all zones (multiple NS records), and IP anycast is used by many
larger zones such as the DNS Root<xref target="AnyFRoot"/>, most top-level
domains<xref target="Moura16b"/> and many large commercial enterprises, governments
and other organizations.</t>
<t>Most DNS operators strive to reduce service latency for users, which
is greatly affected by both of these replication techniques. However,
because operators only have control over their authoritative servers,
and not over the client's recursive resolvers, it is difficult to
ensure that recursives will be served by the closest authoritative
server. Server selection is ultimately up to the recursive resolver's
software implementation, and different vendors and even different
releases employ different criteria to chose the authoritative servers
with which to communicate.</t>
<t>Understanding how recursive resolvers choose authoritative servers is
a key step in improving the effectiveness of authoritative server
deployments. To measure and evaluate server deployments,
<xref target="Mueller17b"/> deployed seven unicast authoritative name servers in
different global locations and then queried them from more than 9000
RIPE authoritative server operators and their respective recursive
resolvers.</t>
<t><xref target="Mueller17b"/> found that recursive resolvers in the wild query all
available authoritative servers, regardless of the observed
latency. But the distribution of queries tends to be skewed towards
authoritatives with lower latency: the lower the latency between a
recursive resolver and an authoritative server, the more often the
recursive will send queries to that server. These results were
obtained by aggregating results from all of the vantage points and
were not specific to any specific vendor or version.</t>
<t>The authors believe this behavior is a consequence of combining the
two main criteria employed by resolvers when selecting authoritative
servers: resolvers regularly check all listed authoritative servers in
an NS set to determine which is closer (the least latent) and when one
isn't available selects one of the alternatives.</t>
</section>
<section anchor="resulting-considerations" title="Resulting considerations">
<t>For an authoritative DNS operator, this result means that the latency
of all authoritative servers (NS records) matter, so they all must be
similarly capable -- all available authoritatives will be queried by
most recursive resolvers. Unicasted services, unfortunately, cannot
deliver good latency worldwide (a unicast authoritative server in
Europe will always have high latency to resolvers in California and
Australia, for example, given its geographical
distance).</t>
<t><xref target="Mueller17b"/> recommends that DNS operators deploy equally
strong IP anycast instances for every authoritative server (i.e., for
each NS record). Each large authoritative DNS server provider should
phase out their usage of unicast and deploy a well engineered number
of anycast instances with good peering strategies so they can provide
good latency to their global clients.
<!-- This doesn't really say anything? what arch considerations?
However, {{Mueller17b}} also
notes that DNS operators should take architectural considerations
into account when planning for deploying anycast {{RFC1546}}.
--></t>
<t>As a case study, the ".nl" TLD zone was originally served on seven
authoritative servers with a mixed unicast/anycast setup. In early
2018, .nl moved to a setup with 4 anycast authoritative
servers.
<!-- XXX: NEED TO SHOW/DESCRIBE RESULTS --></t>
<t><xref target="Mueller17b"/>'s contribution to DNS service engineering shows that
because unicast cannot deliver good latency worldwide, anycast needs
to be used to provide a low latency service worldwide.</t>
</section>
</section>
<section anchor="c2-optimizing-routing-is-more-important-than-location-count-and-diversity" title="C2: Optimizing routing is more important than location count and diversity">
<section anchor="research-background-1" title="Research background">
<t>When selecting an anycast DNS provider or setting up an anycast
service, choosing the best number of anycast instances<xref target="RFC4786"/><xref target="RFC7094"/> to
deploy is a challenging problem. Selecting where and how many global
locations to announce from using BGP is tricky. Intuitively, one
could naively think that the more instances the better and simply
"more" will always lead to shorter response times.</t>
<t>This is not necessarily true, however. In fact, <xref target="Schmidt17a"/> found
that proper route engineering can matter more than the total number of
locations. They analyzed the relationship between the number of
anycast instances and service performance (measuring latency of the
round-trip time (RTT)), measuring the overall performance of four DNS
Root servers. The Root DNS servers are implemented by 12 separate
organizations serving the DNS root zone at 13 different IPv4/IPv6
address pairs.</t>
<t>The results documented in <xref target="Schmidt17a"/> measured the performance of
the {c,f,k,l}.root-servers.net (hereafter, "C", "F", "K" and "L")
servers from more than 7.9k RIPE Atlas probes. RIPE Atlas is a
Internet measurement platform with more than 12000 global vantage
points called "Atlas Probes" -- it is used regularly by both
researchers and operators <xref target="RipeAtlas15a"/> <xref target="RipeAtlas19a"/>.</t>
<t><xref target="Schmidt17a"/> found that the C server, a smaller anycast deployment
consisting of only 8 instances, provided very similar overall
performance in comparison to the much larger deployments of K and L,
with 33 and 144 instances respectively. The median RTT for C, K and L
root server were all between 30-32ms.</t>
<!-- XXX: what about F??? why is it mentioned above if we don't talk -->
<t>Because RIPE Atlas is known to have better coverage in Europe than
other regions, the authors specifically analyzed the results per
region and per country (Figure 5 in <xref target="Schmidt17a"/>), and show that
known Atlas bias toward Europe does not change the conclusion that
properly selected anycast locations is more important to latency than
the number of sites.</t>
</section>
<section anchor="resulting-considerations-1" title="Resulting considerations">
<t>The important conclusion of <xref target="Schmidt17a"/> is that when engineering
anycast services for performance, factors other than just the number
of instances (such as local routing connectivity) must be considered.
Specifically, optimizing routing policies is more important than
simply adding new instances. They showed that 12 instances can
provide reasonable latency, assuming they are globally distributed and
have good local interconnectivity. However, additional instances can
still be useful for other reasons, such as when handling
Denial-of-service (DoS) attacks <xref target="Moura16b"/>.</t>
</section>
</section>
<section anchor="c3-collecting-anycast-catchment-maps-to-improve-design" title="C3: Collecting anycast catchment maps to improve design">
<section anchor="research-background-2" title="Research background">
<t>An anycast DNS service may be deployed from anywhere from several
locations to hundreds of locations (for example, l.root-servers.net
has over 150 anycast instances at the time this was written). Anycast
leverages Internet routing to distribute incoming queries to a
service's hop-nearest distributed anycast locations. However, usually
queries are not evenly distributed across all anycast locations, as
found in the case of L-Root <xref target="IcannHedge18"/>.</t>
<t>Adding locations to or removing locations from a deployed anycast
network changes the load distribution across all of its
locations. When a new location is announced by BGP, locations may
receive more or less traffic than it was engineered for, leading to
suboptimal service performance or even stressing some locations while
leaving others underutilized. Operators constantly face this scenario
that when expanding an anycast service. Operators cannot easily
directly estimate future query distributions based on proposed anycast
network engineering decisions.</t>
<t>To address this need and estimate the query loads based on changing,
in particular expanding, anycast service changes <xref target="Vries17b"/>
developed a new technique enabling operators to carry out active
measurements, using an open-source tool called Verfploeter (available
at <xref target="VerfSrc"></xref>). The results allow the creation of detailed anycast
maps and catchment estimates. By running verfploeter combined with a
published IPv4 "hit list", DNS can precisely calculate which remote
prefixes will be matched to each anycast instance in a network. At
the moment of this writing, Verfploeter still does not support IPv6 as
the IPv4 hit lists used are generated via frequent large scale ICMP
echo scans, which is not possible using IPv6.</t>
<t>As proof of concept, <xref target="Vries17b"/> documents how it verfploeter was
used to predict both the catchment and query load distribution for a
new anycast instance deployed for b.root-servers.net. Using two
anycast test instances in Miami (MIA) and Los Angeles (LAX), an ICMP
echo query was sent from an IP anycast addresses to each IPv4 /24
network routing block on the Internet.</t>
<t>The ICMP echo responses were recorded at both sites and analyzed and
overlayed onto a graphical world map, resulting in an Internet scale
catchment map. To calculate expected load once the production network
was enabled, the quantity of traffic received by b.root-servers.net's
single site at LAX was recorded based on a single day's traffic
(2017-04-12, DITL datasets <xref target="Ditl17"/>). <xref target="Vries17b"/> predicted that
81.6% of the traffic load would remain at the LAX site. This estimate
by verfploeter turned out to be very accurate; the actual measured
traffic volume when production service at MIA was enabled was 81.4%.</t>
<t>Verfploeter can also be used to estimate traffic shifts based on other
BGP route engineering techniques (for example, AS path prepending or
BGP community use) in advance of operational deployment. <xref target="Vries17b"/>
studied this using prepending with 1-3 hops at each instance and
compared the results against real operational changes to validate the
techniques accuracy.</t>
</section>
<section anchor="resulting-considerations-2" title="Resulting considerations">
<t>An important operational takeaway <xref target="Vries17b"/> provides is how DNS
operators can make informed engineering choices when changing DNS
anycast network deployments by using Verfploeter in advance.
Operators can identify sub-optimal routing situations in advance with
significantly better coverage than using other active measurement
platforms such as RIPE Atlas. To date, Verfploeter has been deployed
on a operational testbed (Anycast testbed) <xref target="AnyTest"/>, on a large
unnamed operator and is run daily at b.root-servers.net<xref target="Vries17b"/>.</t>
<t>Operators should use active measurement techniques like Verfploeter in
advance of potential anycast network changes to accurately measure the
benefits and potential issues ahead of time.</t>
</section>
</section>
<section anchor="c4-when-under-stress-employ-two-strategies" title="C4: When under stress, employ two strategies">
<section anchor="research-background-3" title="Research background">
<t>DDoS attacks are becoming bigger, cheaper, and more frequent
<xref target="Moura16b"/>. The most powerful recorded DDoS attack against DNS
servers to date reached 1.2 Tbps by using IoT devices
<xref target="Perlroth16"/>. How should a DNS operator engineer its anycast
authoritative DNS server react to such a DDoS attack? <xref target="Moura16b"/>
investigates this question using empirical observations grounded with
theoretical option evaluations.</t>
<t>An authoritative DNS server deployed using anycast will have many
server instances distributed over many networks. Ultimately, the
relationship between the DNS provider's network and a client's ISP
will determine which anycast instance will answer queries for a given
client, given that BGP is the protocol that maps clients to specific
anycast instances by using routing information [RF:KDar02]. As a
consequence, when an anycast authoritative server is under attack, the
load that each anycast instance receives is likely to be unevenly
distributed (a function of the source of the attacks), thus some
instances may be more overloaded than others which is what was
observed analyzing the Root DNS events of Nov. 2015
<xref target="Moura16b"/>. Given the fact that different instances may have
different capacity (bandwidth, CPU, etc.), making a decision about how
to react to stress becomes even more difficult.</t>
<t>In practice, an anycast instance is overloaded with incoming traffic,
operators have two options:</t>
<t><list style="symbols">
<t>They can withdraw its routes, pre-prepend its AS route to some or
all of its neighbors, perform other traffic shifting tricks (such as
reducing route announcement propagation using BGP
communities<xref target="RFC1997"/>), or by communicating with its upstream
network providers to apply filtering (potentially using FlowSpec
<xref target="RFC8955"/> or DOTS protocol (<xref target="RFC8811"/>, <xref target="RFC8782"/>, <xref target="RFC8783"/>). These
techniques shift both legitimate and attack traffic to other anycast
instances (with hopefully greater capacity) or to block traffic
entirely.</t>
<t>Alternatively, operators can be become a degraded absorber by
continuing to operate, knowing dropping incoming legitimate requests
due to queue overflow. However, this approach will also absorb
attack traffic directed toward its catchment, hopefully protecting
the other anycast instances.</t>
</list></t>
<t><xref target="Moura16b"/> saw both of these behaviors deployed in practice by
studying instance reachability and route-trip time (RTTs) in the DNS
root events. When withdraw strategies were deployed, the stress of
increased query loads were displaced from one instance to multiple
other sites. In other observed events, one site was left to absorb
the brunt of an attack leaving the other sites to remain relatively
less affected.</t>
</section>
<section anchor="resulting-considerations-3" title="Resulting considerations">
<t>Operators should consider having both a anycast site withdraw strategy
and a absorption strategy ready to be used before a network overload
occurs. Operators should be able to deploy one or both of these
strategies rapidly. Ideally, these should be encoded into operating
playbooks with defined site measurement guidelines for which strategy
to employ based on measured data from past events.</t>
<t><xref target="Moura16b"/> speculates that careful, explicit, and automated
management policies may provide stronger defenses to overload
events. DNS operators should be ready to employ both traditional
filtering approaches and other routing load balancing techniques
(withdraw/prepend/communities or isolate instances),
where the best choice depends on the specifics of the attack.</t>
<t>Note that this consideration refers to the operation of just one
anycast service point, i.e., just one anycasted IP address block
covering one NS record. However, DNS zones with multiple authoritative
anycast servers may also expect loads to shift from one anycasted
server to another, as resolvers switch from on authoritative service
point to another when attempting to resolve a name <xref target="Mueller17b"/>.</t>
</section>
</section>
<section anchor="c5-consider-longer-time-to-live-values-whenever-possible" title="C5: Consider longer time-to-live values whenever possible">
<section anchor="research-background-4" title="Research background">
<t>Caching is the cornerstone of good DNS performance and reliability. A
50 ms response to a new DNS query may be considered fast, but a less
than 1 ms response to a cached entry is far faster. <xref target="Moura18b"/>
showed that caching also protects users from short outages and even
significant DDoS attacks.</t>
<t>DNS record TTLs (time-to-live values) <xref target="RFC1034"/><xref target="RFC1035"/> directly
control cache durations and affect latency, resilience, and the role
of DNS in CDN server selection. Some early work modeled caches as a
function of their TTLs <xref target="Jung03a"/>, and recent work has examined their
interaction with DNS<xref target="Moura18b"/>, but until <xref target="Moura19b"/> no research
provided considerations about the benefits of various TTL value
choices. To study this, Moura et. al. <xref target="Moura19b"/> carried out a
measurement study investigating TTL choices and their impact on user
experiences in the wild. They performed this study independent of
specific resolvers (and their caching architectures), vendors, or
setups.</t>
<t>First, they identified several reasons why operators and zone-owners may
want to choose longer or shorter TTLs:</t>
<t><list style="symbols">
<t>As discussed, longer TTLs lead to a longer cache life, resulting
in faster responses. <xref target="Moura19b"/> measured this in the wild and
showed that by increasing the TTL for .uy TLD from 5 minutes
(300s) to 1 day (86400s) the latency measured from 15k Atlas
vantage points changed significantly: the median RTT decreased
from 28.7ms to 8ms, and the 75%ile decreased from 183ms to 21ms.</t>
<t>Longer caching times also results in lower DNS traffic:
authoritative servers will experience less traffic with extended
TTLs, as repeated queries are answered by resolver caches.</t>
<t>Consequently, longer caching results in a lower overall cost if
DNS is metered: some DNS-As-A-Service providers charge a per query
(metered) cost (often in addition to a fixed monthly cost).</t>
<t>Longer caching is more robust to DDoS attacks on DNS
infrastructure. <xref target="Moura18b"/> also measured and show that DNS
caching can greatly reduce the effects of a DDoS on DNS, provided
that caches last longer than the attack.</t>
<t>However, shorter caching supports deployments that may require
rapid operational changes: An easy way to transition from an old
server to a new one is to simply change the DNS records. Since
there is no method to remotely remove cached DNS records, the TTL
duration represents a necessary transition delay to fully shift
from one server to another. Thus, low TTLs allow for more rapid
transitions. However, when deployments are planned in advance
(that is, longer than the TTL), it is possible to lower the TTLs
just-before a major operational change and raise them again
afterward.</t>
<t>Shorter caching can also help with a DNS-based response to DDoS
attacks. Specifically, some DDoS-scrubbing services use the DNS to
redirect traffic during an attack. Since DDoS attacks arrive
unannounced, DNS-based traffic redirection requires the TTL be
kept quite low at all times to allow operators to suddenly have
their zone served by a DDoS-scrubbing service.</t>
<t>Shorter caching helps DNS-based load balancing. Many large
services are known to rotate traffic among their servers using
DNS-based load balancing. Each arriving DNS request provides an
opportunity to adjust service load by rotating IP address records
(A and AAAA) to the lowest unused server. Shorter TTLs may be
desired in these architectures to react more quickly to traffic
dynamics. Many recursive resolvers, however, have minimum caching
times of tens of seconds, placing a limit on this form of agility.</t>
</list></t>
</section>
<section anchor="resulting-considerations-4" title="Resulting considerations">
<t>Given these considerations, the proper choice for a TTL depends in
part on multiple external factors -- no single recommendation is
appropriate for all scenarios. Organizations must weigh these
trade-offs and find a good balance for their situation. Still, some
guidelines can be reached when choosing TTLs:</t>
<t><list style="symbols">
<t>For general DNS zone owners, <xref target="Moura19b"/> recommends a longer TTL
of at least one hour, and ideally 8, 12, or 24 hours. Assuming
planned maintenance can be scheduled at least a day in advance, long
TTLs have little cost and may, even, literally provide a cost savings.</t>
<t>For registry operators: TLD and other public registration
operators (for example most ccTLDs and .com, .net, .org) that host
many delegations (NS records, DS records and "glue" records),
<xref target="Moura19b"/> demonstrates that most resolvers will use the TTL
values provided by the child delegations while the others some
will choose the TTL provided by the parent's copy of the
record. As such, <xref target="Moura19b"/> recommends longer TTLs (at least an
hour or more) for registry operators as well for child NS and
other records.</t>
<t>Users of DNS-based load balancing or DDoS-prevention services may
require shorter TTLs: TTLs may even need to be as short as 5
minutes, although 15 minutes may provide sufficient agility for
many operators. There is always a tussle between shorter TTLs
providing more agility against all the benefits listed above for
using longer TTLs.</t>
<t>Use of A/AAAA and NS records: The TTLs for A/AAAA records should
be shorter to or equal to the TTL for the corresponding NS records
for in-bailiwick authoritative DNS servers, since <xref target="Moura19b"/>
finds that once an NS record expires, their associated A/AAAA will
also be re-queried when glue is required to be sent by the
parents. For out-of-bailiwick servers, A, AAAA and NS records are
usually all cached independently, so different TTLs can be used
effectively if desired. In either case, short A and AAAA records
may still be desired if DDoS-mitigation services are required.</t>
</list></t>
</section>
</section>
<section anchor="c6-consider-the-ttl-differences-between-parents-and-children" title="C6: Consider the TTL differences between parents and children">
<section anchor="research-background-5" title="Research background">
<t>Multiple record types exist or are related between the parent of a
zone and the child. At a minimum, NS records are supposed to be
identical in the parent (but often are not) as or corresponding IP
address in "glue" A/AAAA records that must exist for in-bailiwick
authoritative servers. Additionally, if DNSSEC (<xref target="RFC4033"/>
<xref target="RFC4034"/> <xref target="RFC4035"/> <xref target="RFC4509"/>) is deployed for a zone the
parent's DS record must cryptographically refer to a child's DNSKEY
record.</t>
<t>Because some information exists in both the parent and a child, it is
possible for the TTL values to differ between the parent's copy and
the child's. <xref target="Moura19b"/> examines resolver behaviors when these
values differ in the wild, as they frequently do -- often parent zones
have defacto TTL values that a child has no control over. For
example, NS records for TLDs in the root zone are all set to 2 days
(48 hours), but some TLD's have lower values within their published
records (the TTLs for .cl's NS records from their authoritative
servers is 1 hour). <xref target="Moura19b"/> also examines the differences in the
TTLs between the NS records and the corresponding A/AAAA records for
the addresses of a nameserver. RIPE Atlas nodes are used to determine
what resolvers in the wild do with different information, and whether
the parent's TTL is used for cache life-times ("parent-centric") or
the child's is used ("child-centric").</t>
<t><xref target="Moura19b"/> finds that roughly 90% of resolvers follow the child's
view of the TTL, while 10% appear parent-centric. It additionally
finds that resolvers behave differently for cache lifetimes for
in-bailiwick vs out-of-bailiwick NS/A/AAAA TTL combinations.
Specifically, when NS TTLs are shorter than the corresponding address
records, most resolvers will re-query for A/AAAA records for
in-bailiwick resolvers and switch to new address records even if the
cache indicates the original A/AAAA records could be kept longer. On
the other hand, the inverse is true for out-of-bailiwick resolvers: If
the NS record expires first resolvers will honor the original cache
time of the nameserver's address.</t>
</section>
<section anchor="resulting-considerations-5" title="Resulting considerations">
<t>The important conclusion from this study is that operators cannot
depend on their published TTL values alone -- the parent's values are
also used for timing cache entries in the wild. Operators that are
planning on infrastructure changes should assume that older
infrastructure must be left on and operational for at least the
maximum of both the parent and child's TTLs.</t>
</section>
</section>
</section>
<section anchor="security-considerations" title="Security considerations">
<t>This document discusses applying measured research results to
operational deployments. Most of the considerations affect mostly
operational practice, though a few do have security related impacts.</t>
<t>Specifically, C4 discusses a couple of strategies to employ when a
service is under stress from DDoS attacks and offers operators
additional guidance when handling excess traffic.</t>
<t>Similarly, C5 identifies the trade-offs with respect to the
operational and security benefits of using longer time-to-live values.</t>
<!-- verified against RFC3552 - MD -->
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">
<!-- Add some remarkt according to RFC6973. Or should we name this "Human Rights considerations" according to RFC8280 - MD -->
<t>This document does not add any practical new privacy issues, aside
from possible benefits in deploying longer TTLs as suggested in C5.
Longer TTLs may help preserve a user's privacy by reducing the number
of requests that get transmitted in both the client-to-resolver and
resolver-to-authoritative cases.</t>
</section>
<section anchor="iana-considerations" title="IANA considerations">
<t>This document has no IANA actions.
<!-- RFC8126 style - MD --></t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This document is a summary of the main considerations of six research
works performed by the authors and others. This document would not
have been possible without the hard work of these authors and co-authors:</t>
<t><list style="symbols">
<t>Ricardo de O. Schmidt</t>
<t>Wouter B de Vries</t>
<t>Moritz Mueller</t>
<t>Lan Wei</t>
<t>Cristian Hesselman</t>
<t>Jan Harm Kuipers</t>
<t>Pieter-Tjerk de Boer</t>
<t>Aiko Pras</t>
</list></t>
<t>We would like also to thank the reviewers of this draft that offered
valuable suggestions: Duane Wessels, Joe Abley, Toema Gavrichenkov,
John Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus
Darilion and Samir Jafferali, and comments provided at the IETF DNSOP
session (IETF104).</t>
<t>Besides those, we would like thank those acknowledged in the papers
this document summarizes for helping produce the results: RIPE NCC and
DNS OARC for their tools and datasets used in this research, as well
as the funding agencies sponsoring the individual research works.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2181;
&RFC1034;
&RFC7094;
&RFC1546;
&RFC1035;
&RFC1995;
&RFC5936;
&RFC4786;
&RFC1997;
&RFC8499;
&RFC8782;
&RFC8783;
&RFC8955;
</references>
<references title='Informative References'>
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4509;
&RFC8811;
<reference anchor="Moura16b" target="https://www.isi.edu/~johnh/PAPERS/Moura16b.pdf">
<front>
<title>Anycast vs DDoS Evaluating the November 2015 Root DNS Events.</title>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
<organization></organization>
</author>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
<organization></organization>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization></organization>
</author>
<author initials="M." surname="Mueller" fullname="Moritz Mueller">
<organization></organization>
</author>
<author initials="L." surname="Wei" fullname="Lan Wei">
<organization></organization>
</author>
<author initials="C." surname="Hesselman" fullname="Cristian Hesselman">
<organization></organization>
</author>
<date year="2016" month="October" day="14"/>
</front>
<seriesInfo name="ACM" value="2016 Internet Measurement Conference"/>
<seriesInfo name="DOI" value="/10.1145/2987443.2987446"/>
</reference>
<reference anchor="Schmidt17a" target="https://www.isi.edu/%7ejohnh/PAPERS/Schmidt17a.pdf">
<front>
<title>Anycast Latency - How Many Sites Are Enough. In Proceedings of the Passive and Active Measurement Workshop</title>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
<organization></organization>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization></organization>
</author>
<author initials="J.H." surname="Kuipers" fullname="Jam Harm Kuipers">
<organization></organization>
</author>
<date year="2017" month="March"/>
</front>
<seriesInfo name="PAM" value="Passive and Active Measurement Conference"/>
</reference>
<reference anchor="Moura18b" target="https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf">
<front>
<title>When the Dike Breaks: Dissecting DNS Defenses During DDos</title>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
<organization></organization>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization></organization>
</author>
<author initials="M." surname="Mueller" fullname="Moritz Mueller">
<organization></organization>
</author>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
<organization></organization>
</author>
<author initials="M." surname="Davids" fullname="Marco Davids">
<organization></organization>
</author>
<date year="2018" month="October" day="31"/>
</front>
<seriesInfo name="ACM" value="2018 Internet Measurement Conference"/>
<seriesInfo name="DOI" value="10.1145/3278532.3278534"/>
</reference>
<reference anchor="Singla2014" target="http://speedierweb.web.engr.illinois.edu/cspeed/papers/hotnets14.pdf">
<front>
<title>The Internet at the speed of light. In Proceedings of the 13th ACM Workshop on Hot Topics in Networks (Oct 2014)</title>
<author initials="A." surname="Singla" fullname="Ankit Singla">
<organization></organization>
</author>
<author initials="B." surname="Chandrasekaran" fullname="Balakrishnan Chandrasekaran">
<organization></organization>
</author>
<author initials="P.B." surname="Godfrey" fullname="P Brighten Godfrey">
<organization></organization>
</author>
<author initials="B." surname="Maggs" fullname="Bruce Maggs">
<organization></organization>
</author>
<date year="2014" month="October"/>
</front>
<seriesInfo name="ACM" value="Workshop on Hot Topics in Networks"/>
</reference>
<reference anchor="Vries17b" target="https://www.isi.edu/%7ejohnh/PAPERS/Vries17b.pdf">
<front>
<title>Verfploeter - Broad and Load-Aware Anycast Mapping</title>
<author initials="W.d." surname="Vries" fullname="Wouter de Vries">
<organization></organization>
</author>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
<organization></organization>
</author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization></organization>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization></organization>
</author>
<author initials="P.d." surname="Boer" fullname="Pieter-Tjerk de Boer">
<organization></organization>
</author>
<author initials="A." surname="Pras" fullname="Aiko Pras">
<organization></organization>
</author>
<date year="2017" month="October"/>
</front>
<seriesInfo name="ACM" value="2017 Internet Measurement Conference"/>
<seriesInfo name="DOI" value="10.1145/3131365.3131371"/>
</reference>
<reference anchor="Jung03a" target="http://www.ieee-infocom.org/2003/papers/11_01.PDF">
<front>
<title>Modeling TTL-based Internet caches</title>
<author initials="J." surname="Jung" fullname="Jaeyeon Jung">
<organization></organization>
</author>
<author initials="A.W." surname="Berger" fullname="Arthur W. Berger">
<organization></organization>
</author>
<author initials="H." surname="Balakrishnan" fullname="Hari Balakrishnan">
<organization></organization>
</author>
<date year="2003" month="July"/>
</front>
<seriesInfo name="ACM" value="2003 IEEE INFOCOM"/>
<seriesInfo name="DOI" value="10.1109/INFCOM.2003.1208693"/>
</reference>
<reference anchor="RipeAtlas15a" target="http://ipj.dreamhosters.com/wp-content/uploads/issues/2015/ipj18-3.pdf">
<front>
<title>RIPE Atlas A Global Internet Measurement Network</title>
<author initials="R.N." surname="Staff" fullname="RIPE NCC Staff">
<organization></organization>
</author>
<date year="2015" month="September"/>
</front>
</reference>
<reference anchor="RipeAtlas19a" target="https://atlas.ripe.net/">
<front>
<title>Ripe Atlas - RIPE Network Coordination Centre</title>
<author initials="R." surname="NCC" fullname="RIPE NCC">
<organization></organization>
</author>
<date year="2019" month="September"/>
</front>
</reference>
<reference anchor="Mueller17b" target="https://www.isi.edu/%7ejohnh/PAPERS/Mueller17b.pdf">
<front>
<title>Recursives in the Wild- Engineering Authoritative DNS Servers.</title>
<author initials="M." surname="Mueller" fullname="Moritz Mueller">
<organization></organization>
</author>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
<organization></organization>
</author>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
<organization></organization>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization></organization>
</author>
<date year="2017" month="October"/>
</front>
<seriesInfo name="ACM" value="2017 Internet Measurement Conference"/>
<seriesInfo name="DOI" value="10.1145/3131365.3131366"/>
</reference>
<reference anchor="Moura19b" target="https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf">
<front>
<title>Cache Me If You Can: Effects of DNS Time-to-Live</title>
<author initials="G." surname="Moura" fullname="Giovane Moura">
<organization></organization>
</author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization></organization>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization></organization>
</author>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
<organization></organization>
</author>
<date year="n.d."/>
</front>
<seriesInfo name="ACM" value="2019 Internet Measurement Conference"/>
<seriesInfo name="DOI" value="10.1145/3355369.3355568"/>
</reference>
<reference anchor="IcannHedge18" target="http://stats.dns.icann.org/hedgehog/">
<front>
<title>DNS-STATS - Hedgehog 2.4.1</title>
<author initials="." surname="ICANN" fullname="ICANN">
<organization></organization>
</author>
<date year="2018" month="October"/>
</front>
</reference>
<reference anchor="Ditl17" target="https://www.dns-oarc.net/oarc/data/ditl/2017">
<front>
<title>2017 DITL data</title>
<author initials="D." surname="OARC" fullname="DNS OARC">
<organization></organization>
</author>
<date year="2018" month="October"/>
</front>
</reference>
<reference anchor="Perlroth16" target="https://www.nytimes.com/2016/10/22/business/internet-problems-attack.html">
<front>
<title>Hackers Used New Weapons to Disrupt Major Websites Across U.S.</title>
<author initials="N." surname="Perlroth" fullname="Nicole Perlroth">
<organization></organization>
</author>
<date year="2016" month="October"/>
</front>
</reference>
<reference anchor="VerfSrc" target="https://github.com/Woutifier/verfploeter">
<front>
<title>Verfploeter source code</title>
<author initials="W.d." surname="Vries" fullname="Wouter de Vries">