rfc9199xml2.original.xml   rfc9199.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version="1.0" encoding="UTF-8"?>
<?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" [ <!DOCTYPE rfc [
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY nbsp "&#160;">
nce.RFC.2181.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY nbhy "&#8209;">
nce.RFC.1034.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC7094 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7094.xml">
<!ENTITY RFC1546 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1546.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1035.xml">
<!ENTITY RFC1995 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1995.xml">
<!ENTITY RFC5936 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5936.xml">
<!ENTITY RFC4786 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4786.xml">
<!ENTITY RFC1997 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1997.xml">
<!ENTITY RFC8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8499.xml">
<!ENTITY RFC8782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8782.xml">
<!ENTITY RFC8783 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8783.xml">
<!ENTITY RFC8955 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8955.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4035.xml">
<!ENTITY RFC4509 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4509.xml">
<!ENTITY RFC8811 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8811.xml">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc sortrefs="yes"?> -moura-dnsop-authoritative-recommendations-11" number="9199" submissionType="ind
<?rfc symrefs="yes"?> ependent" category="info" obsoletes="" updates="" xml:lang="en" tocInclude="true
" sortRefs="true" symRefs="true"
<rfc ipr="trust200902" docName="draft-moura-dnsop-authoritative-recommendations- version="3">
11" category="info">
<front> <front>
<title abbrev="Considerations-Large-Auth-DNS-Ops">Considerations for Large A <title abbrev="Considerations for Large Auth DNS Ops">Considerations for Lar
uthoritative DNS Servers Operators</title> ge Authoritative DNS Server Operators</title>
<seriesInfo name="RFC" value="9199"/>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura"> <author initials="G." surname="Moura" fullname="Giovane C. M. Moura">
<organization>SIDN Labs/TU Delft</organization> <organization>SIDN Labs/TU Delft</organization>
<address> <address>
<postal> <postal>
<street>Meander 501</street> <street>Meander 501</street>
<city>Arnhem</city> <city>Arnhem</city>
<code>6825 MD</code> <code>6825 MD</code>
<country>NL</country> <country>Netherlands</country>
</postal> </postal>
<phone>+31 26 352 5500</phone> <phone>+31 26 352 5500</phone>
<email>giovane.moura@sidn.nl</email> <email>giovane.moura@sidn.nl</email>
</address> </address>
</author> </author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker"> <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/Information Sciences Institute</organization> <organization>USC/Information Sciences Institute</organization>
<address> <address>
<postal> <postal>
<street>PO Box 382</street> <street>PO Box 382</street>
<city>Davis</city> <city>Davis</city>
<region>CA</region>
<code>95617-0382</code> <code>95617-0382</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 (530) 404-0099</phone> <phone>+1 (530) 404-0099</phone>
<email>ietf@hardakers.net</email> <email>ietf@hardakers.net</email>
</address> </address>
</author> </author>
<author initials="J." surname="Heidemann" fullname="John Heidemann"> <author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization>USC/Information Sciences Institute</organization> <organization>USC/Information Sciences Institute</organization>
<address> <address>
<postal> <postal>
<street>4676 Admiralty Way</street> <street>4676 Admiralty Way</street>
<city>Marina Del Rey</city> <city>Marina Del Rey</city>
<region>CA</region>
<code>90292-6695</code> <code>90292-6695</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 (310) 448-8708</phone> <phone>+1 (310) 448-8708</phone>
<email>johnh@isi.edu</email> <email>johnh@isi.edu</email>
</address> </address>
</author> </author>
<author initials="M." surname="Davids" fullname="Marco Davids"> <author initials="M." surname="Davids" fullname="Marco Davids">
<organization>SIDN Labs</organization> <organization>SIDN Labs</organization>
<address> <address>
<postal> <postal>
<street>Meander 501</street> <street>Meander 501</street>
<city>Arnhem</city> <city>Arnhem</city>
<code>6825 MD</code> <code>6825 MD</code>
<country>NL</country> <country>Netherlands</country>
</postal> </postal>
<phone>+31 26 352 5500</phone> <phone>+31 26 352 5500</phone>
<email>marco.davids@sidn.nl</email> <email>marco.davids@sidn.nl</email>
</address> </address>
</author> </author>
<date year="2022" month="March"/>
<date year="2022" month="January" day="04"/>
<area>Internet</area> <area>Internet</area>
<workgroup>DNSOP Working Group</workgroup> <workgroup></workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <keyword>Routing</keyword>
<keyword>DNS</keyword>
<keyword>Anycast</keyword>
<keyword>Domain</keyword>
<keyword>Name</keyword>
<keyword>System</keyword>
<keyword>BGP</keyword>
<t>Recent research work has explored the deployment characteristics and <abstract>
<t>Recent research work has explored the deployment characteristics and
configuration of the Domain Name System (DNS). This document configuration of the Domain Name System (DNS). This document
summarizes the conclusions from these research efforts and offers summarizes the conclusions from these research efforts and offers
specific, tangible considerations or advice to authoritative DNS specific, tangible considerations or advice to authoritative DNS
server operators. Authoritative server operators may wish to follow server operators. Authoritative server operators may wish to follow
these considerations to improve their DNS services.</t> these considerations to improve their DNS services.</t>
<t>It is possible that the results presented in this document could be
<t>It is possible that the results presented in this document could be
applicable in a wider context than just the DNS protocol, applicable in a wider context than just the DNS protocol,
as some of the results may generically apply to as some of the results may generically apply to
any stateless/short-duration, anycasted service.</t> any stateless/short-duration anycasted service.</t>
<t>This document is not an IETF consensus document: it is published for
<t>This document is not an IETF consensus document: it is published for
informational purposes.</t> informational purposes.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<section anchor="intro" title="Introduction"> <name>Introduction</name>
<t>This document summarizes recent research that explored the
<t>This document summarizes recent research work that explored the deployed DNS configurations and offers derived, specific, tangible
deployed DNS configurations and offers derived, specific tangible advice to DNS authoritative server operators (referred to as "DNS operators"
advice to DNS authoritative server operators (DNS operators hereafter). The considerations (<xref target="considerations" format="none">C1-C
hereafter). The considerations (C1--C5) presented in this document are 6</xref>) presented in this document are
backed by peer-reviewed research works, which used wide-scale Internet backed by peer-reviewed research, which used wide-scale Internet
measurements to draw their conclusions. This document summarizes the measurements to draw their conclusions. This document summarizes the
research results and describes the resulting key engineering options. research results and describes the resulting key engineering options.
In each section, it points readers to the pertinent publications where In each section, readers are pointed to the pertinent publications where
additional details are presented.</t> additional details are presented.</t>
<t>These considerations are designed for operators of "large"
<t>These considerations are designed for operators of "large" authoritative DNS servers, which, in this context, are servers with a significan
authoritative DNS servers. In this context, "large" authoritative t global user population, like top-level domain (TLD) operators, run by either a
servers refers to those with a significant global user population, single operator or
like top-level domain (TLD) operators, run by either a single or multiple operators. Typically, these networks are deployed on wide
multiple operators. Typically these networks are deployed on wide anycast networks <xref target="RFC1546" format="default"/> <xref target="AnyBest
anycast networks <xref target="RFC1546"/><xref target="AnyBest"/>. These conside " format="default"/>.
rations may not be These considerations may not be
appropriate for smaller domains, such as those used by an organization appropriate for smaller domains, such as those used by an organization
with users in one unicast network, or in one city or region, where with users in one unicast network or in a single city or region, where
operational goals such as uniform, global low latency are less operational goals such as uniform, global low latency are less
required.</t> required.</t>
<t>It is possible that the results presented in this document could be
<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 applicable in a wider context than just the DNS protocol, as some of
the results may generically apply to any stateless/short-duration, the results may generically apply to any stateless/short-duration
anycasted service. Because the conclusions of the reviewed studies anycasted service. Because the conclusions of the reviewed studies
don't measure smaller networks, the wording in this document don't measure smaller networks, the wording in this document
concentrates solely on disusing large-scale DNS authoritative services concentrates solely on discussing large-scale DNS authoritative services.</t>
only.</t> <t>This document is not an IETF consensus document: it is published for
<t>This document is not an IETF consensus document: it is published for
informational purposes.</t> informational purposes.</t>
</section>
</section> <section anchor="background" numbered="true" toc="default">
<section anchor="background" title="Background"> <name>Background</name>
<t>The DNS has two main types of DNS servers: authoritative servers and
<t>The DNS has main two types of DNS servers: authoritative servers and
recursive resolvers, shown by a representational deployment model in recursive resolvers, shown by a representational deployment model in
<xref target="recuath"/>. An authoritative server (shown as AT1--AT4 in <xref target="recuath" format="default"/>. An authoritative server (shown as AT
<xref target="recuath"/>) knows the content of a DNS zone, and is responsible fo 1-AT4 in
r <xref target="recuath" format="default"/>) knows the content of a DNS zone and i
s responsible for
answering queries about that zone. It runs using local (possibly answering queries about that zone. It runs using local (possibly
automatically updated) copies of the zone and does not need to query automatically updated) copies of the zone and does not need to query
other servers <xref target="RFC2181"/> in order to answer requests. A recursive other servers <xref target="RFC2181" format="default"/> in order to answer reque
resolver (Re1--Re3) is a server that iteratively queries authoritative sts. A recursive
resolver (Re1-Re3) is a server that iteratively queries authoritative
and other servers to answer queries received from client requests and other servers to answer queries received from client requests
<xref target="RFC1034"/>. A client typically employs a software library called a <xref target="RFC1034" format="default"/>. A client typically employs a software
stub library called a "stub
resolver (stub in <xref target="recuath"/>) to issue its query to the upstream resolver" ("stub" in <xref target="recuath" format="default"/>) to issue its que
recursive resolvers <xref target="RFC1034"/>.</t> ry to the upstream
recursive resolvers <xref target="RFC1034" format="default"/>.</t>
<figure title="Relationship between recursive resolvers (Re) and authoritative n <figure anchor="recuath">
ame servers (ATn)" anchor="recuath"><artwork><![CDATA[ <name>Relationship between Recursive Resolvers (Re) and Authoritative Na
me Servers (ATn)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| AT1 | | AT2 | | AT3 | | AT4 | | AT1 | | AT2 | | AT3 | | AT4 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| +-----+ | | | +-----+ | |
+------| Re1 |----+| | +------| Re1 |----+| |
| +-----+ | | +-----+ |
| ^ | | ^ |
| | | | | |
| +----+ +----+ | | +----+ +----+ |
+------|Re2 | |Re3 |------+ +------|Re2 | |Re3 |------+
+----+ +----+ +----+ +----+
^ ^ ^ ^
| | | |
| +------+ | | +------+ |
+-| stub |-+ +-| stub |-+
+------+ +------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>DNS queries issued by a client contribute to a user's perceived <t>DNS queries issued by a client contribute to a user's perceived latency
perceived latency and affect user experience <xref target="Singla2014"/> dependi and affect the user experience <xref target="Singla2014" format="default"/> dep
ng ending
on how long it takes for responses to be returned. The DNS system has 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, been subject to repeated Denial-of-Service (DoS) attacks (for example,
in November 2015 <xref target="Moura16b"/>) in order to specifically degrade use in November 2015 <xref target="Moura16b" format="default"/>) in order to specifi
r cally degrade the user
experience.</t> experience.</t>
<t>To reduce latency and improve resiliency against DoS attacks, the DNS
<t>To reduce latency and improve resiliency against DoS attacks, the DNS
uses several types of service replication. Replication at the uses several types of service replication. Replication at the
authoritative server level can be achieved with (i) the deployment of authoritative server level can be achieved with the following:
multiple servers for the same zone <xref target="RFC1035"/> (AT1---AT4 in </t>
<xref target="recuath"/>), (ii) the use of IP anycast <ol spacing="normal" type="i">
<xref target="RFC1546"/><xref target="RFC4786"/><xref target="RFC7094"/> that al <li> the deployment of
lows the same IP address to multiple servers for the same zone <xref target="RFC1035" format="default"/> (AT
1-AT4 in <xref target="recuath" format="default"/>);
</li>
<li> the use of IP anycast
<xref target="RFC1546" format="default"/> <xref target="RFC4786" format="default
"/> <xref target="RFC7094" format="default"/> that allows the same IP address to
be announced from multiple locations (each of referred to as an be announced from multiple locations (each of referred to as an
"anycast instance" <xref target="RFC8499"/>) and (iii) the use of load balancers "anycast instance" <xref target="RFC8499" format="default"/>); and
to </li>
<li> the use of load balancers to
support multiple servers inside a single (potentially anycasted) support multiple servers inside a single (potentially anycasted)
instance. As a consequence, there are many possible ways an instance. As a consequence, there are many possible ways an
authoritative DNS provider can engineer its production authoritative authoritative DNS provider can engineer its production authoritative
server network, with multiple viable choices and no necessarily single server network with multiple viable choices, and there is not necessarily a sing
optimal design.</t> le
optimal design.</li>
</section> </ol>
<section anchor="considerations" title="Considerations"> </section>
<section anchor="considerations" numbered="true" toc="default">
<t>In the next sections we cover the specific consideration (C1--C6) for <name>Considerations</name>
conclusions drawn within the academic papers about large authoritative <t>In the next sections, we cover the specific considerations (<xref targe
t="considerations" format="none">C1-C6</xref>) for
conclusions drawn within academic papers about large authoritative
DNS server operators. These considerations are conclusions reached DNS server operators. These considerations are conclusions reached
from academic works that authoritative server operators may wish to from academic work that authoritative server operators may wish to
consider in order to improve their DNS service. Each consideration consider in order to improve their DNS service. Each consideration
offers different improvements that may impact service latency, offers different improvements that may impact service latency,
routing, anycast deployment, and defensive strategies for example.</t> routing, anycast deployment, and defensive strategies, for example.</t>
<section anchor="c1" numbered="true" toc="default">
<section anchor="c1" title="C1: Deploy anycast in every authoritative server to <name>C1: Deploy Anycast in Every Authoritative Server to Enhance Distri
enhance distribution and latency"> bution and Latency</name>
<section anchor="research-background" numbered="true" toc="default">
<section anchor="research-background" title="Research background"> <name>Research Background</name>
<t>Authoritative DNS server operators announce their service using NS
<t>Authoritative DNS server operators announce their service using NS records <xref target="RFC1034" format="default"/>. Different authoritative serve
records<xref target="RFC1034"/>. Different authoritative servers for a given zon rs for a given zone
e should return the same content; typically, they stay synchronized using
should return the same content; typically they stay synchronized using DNS zone transfers (authoritative transfer (AXFR) <xref target="RFC5936" format=
DNS zone transfers (AXFR<xref target="RFC5936"/> and IXFR<xref target="RFC1995"/ "default"/> and incremental zone transfer (IXFR) <xref target="RFC1995" format="
>), coordinating default"/>), coordinating
the zone data they all return to their clients.</t> the zone data they all return to their clients.</t>
<t>As discussed above, the DNS heavily relies upon replication to supp
<t>As discussed above, the DNS heavily relies upon replication to support ort
high reliability, ensure capacity and to reduce latency <xref target="Moura16b"/ high reliability, ensure capacity, and reduce latency <xref target="Moura16b" fo
>. rmat="default"/>.
DNS has two complementary mechanisms for service replication: The DNS has two complementary mechanisms for service replication:
nameserver replication (multiple NS records) and anycast (multiple name server replication (multiple NS records) and anycast (multiple
physical locations). Nameserver replication is strongly recommended physical locations). Name server replication is strongly recommended
for all zones (multiple NS records), and IP anycast is used by many 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 larger zones such as the DNS root <xref target="AnyFRoot" format="default"/>, mo
domains<xref target="Moura16b"/> and many large commercial enterprises, governme st top-level
nts domains <xref target="Moura16b" format="default"/>, and many large commercial en
terprises, governments,
and other organizations.</t> and other organizations.</t>
<t>Most DNS operators strive to reduce service latency for users, whic
<t>Most DNS operators strive to reduce service latency for users, which h
is greatly affected by both of these replication techniques. However, is greatly affected by both of these replication techniques. However,
because operators only have control over their authoritative servers, because operators only have control over their authoritative servers
and not over the client's recursive resolvers, it is difficult to and not over the client's recursive resolvers, it is difficult to
ensure that recursives will be served by the closest authoritative ensure that recursives will be served by the closest authoritative
server. Server selection is ultimately up to the recursive resolver's server. Server selection is ultimately up to the recursive resolver's
software implementation, and different vendors and even different software implementation, and different vendors and even different
releases employ different criteria to chose the authoritative servers releases employ different criteria to choose the authoritative servers
with which to communicate.</t> with which to communicate.</t>
<t>Understanding how recursive resolvers choose authoritative servers
<t>Understanding how recursive resolvers choose authoritative servers is is
a key step in improving the effectiveness of authoritative server a key step in improving the effectiveness of authoritative server
deployments. To measure and evaluate server deployments, deployments. To measure and evaluate server deployments,
<xref target="Mueller17b"/> deployed seven unicast authoritative name servers in <xref target="Mueller17b" format="default"/> describes the deployment of seven u nicast authoritative name servers in
different global locations and then queried them from more than 9000 different global locations and then queried them from more than 9000
RIPE authoritative server operators and their respective recursive Reseaux IP Europeens (RIPE) authoritative server operators and their respective recursive
resolvers.</t> resolvers.</t>
<t>It was found in <xref target="Mueller17b" format="default"/> that r
<t><xref target="Mueller17b"/> found that recursive resolvers in the wild query ecursive resolvers in the wild query all
all
available authoritative servers, regardless of the observed available authoritative servers, regardless of the observed
latency. But the distribution of queries tends to be skewed towards latency. But the distribution of queries tends to be skewed towards
authoritatives with lower latency: the lower the latency between a authoritatives with lower latency: the lower the latency between a
recursive resolver and an authoritative server, the more often the recursive resolver and an authoritative server, the more often the
recursive will send queries to that server. These results were recursive will send queries to that server. These results were
obtained by aggregating results from all of the vantage points and obtained by aggregating results from all of the vantage points, and
were not specific to any specific vendor or version.</t> they were not specific to any vendor or version.</t>
<t>The authors believe this behavior is a consequence of combining the
<t>The authors believe this behavior is a consequence of combining the
two main criteria employed by resolvers when selecting authoritative two main criteria employed by resolvers when selecting authoritative
servers: resolvers regularly check all listed authoritative servers in servers: resolvers regularly check all listed authoritative servers in
an NS set to determine which is closer (the least latent) and when one an NS set to determine which is closer (the least latent), and when one
isn't available selects one of the alternatives.</t> isn't available, it selects one of the alternatives.</t>
</section>
</section> <section anchor="resulting-considerations" numbered="true" toc="default"
<section anchor="resulting-considerations" title="Resulting considerations"> >
<name>Resulting Considerations</name>
<t>For an authoritative DNS operator, this result means that the latency <t>For an authoritative DNS operator, this result means that the laten
cy
of all authoritative servers (NS records) matter, so they all must be of all authoritative servers (NS records) matter, so they all must be
similarly capable -- all available authoritatives will be queried by similarly capable -- all available authoritatives will be queried by
most recursive resolvers. Unicasted services, unfortunately, cannot most recursive resolvers. Unicasted services, unfortunately, cannot
deliver good latency worldwide (a unicast authoritative server in deliver good latency worldwide (a unicast authoritative server in
Europe will always have high latency to resolvers in California and Europe will always have high latency to resolvers in California and
Australia, for example, given its geographical Australia, for example, given its geographical
distance).</t> distance).</t>
<t><xref target="Mueller17b" format="default"/> recommends that DNS op
<t><xref target="Mueller17b"/> recommends that DNS operators deploy equally erators deploy equally
strong IP anycast instances for every authoritative server (i.e., for strong IP anycast instances for every authoritative server (i.e., for
each NS record). Each large authoritative DNS server provider should each NS record). Each large authoritative DNS server provider should
phase out their usage of unicast and deploy a well engineered number phase out its usage of unicast and deploy a number of well-engineered anycast in
of anycast instances with good peering strategies so they can provide stances with good peering strategies so they can provide
good latency to their global clients. good latency to their global clients.
<!-- This doesn't really say anything? what arch considerations? </t>
However, {{Mueller17b}} also <t>As a case study, the ".nl" TLD zone was originally served on seven
notes that DNS operators should take architectural considerations
into account when planning for deploying anycast {{RFC1546}}.
<t>As a case study, the ".nl" TLD zone was originally served on seven
authoritative servers with a mixed unicast/anycast setup. In early authoritative servers with a mixed unicast/anycast setup. In early
2018, .nl moved to a setup with 4 anycast authoritative 2018, .nl moved to a setup with 4 anycast authoritative
servers. servers.
<!-- XXX: NEED TO SHOW/DESCRIBE RESULTS --></t> </t>
<t>The contribution of <xref target="Mueller17b" format="default"/> to
<t><xref target="Mueller17b"/>'s contribution to DNS service engineering shows t DNS service engineering shows that
hat
because unicast cannot deliver good latency worldwide, anycast needs because unicast cannot deliver good latency worldwide, anycast needs
to be used to provide a low latency service worldwide.</t> to be used to provide a low-latency service worldwide.</t>
</section>
</section> </section>
</section> <section anchor="c2" numbered="true" toc="default">
<section anchor="c2-optimizing-routing-is-more-important-than-location-count-and <name>C2: Optimizing Routing is More Important than Location Count and D
-diversity" title="C2: Optimizing routing is more important than location count iversity</name>
and diversity"> <section anchor="research-background-1" numbered="true" toc="default">
<name>Research Background</name>
<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" fo
<t>When selecting an anycast DNS provider or setting up an anycast rmat="default"/> <xref target="RFC7094" format="default"/> to
service, choosing the best number of anycast instances<xref target="RFC4786"/><x deploy is a challenging problem. Selecting the right quantity and set of global
ref target="RFC7094"/> to locations that should send BGP announcements is tricky. Intuitively, one
deploy is a challenging problem. Selecting where and how many global could naively think that more instances are better and that simply
locations to announce from using BGP is tricky. Intuitively, one "more" will always lead to shorter response times.</t>
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"/> f <t>This is not necessarily true, however. In fact, proper route engine
ound ering can matter more than the total number of locations, as found in <xref targ
that proper route engineering can matter more than the total number of et="Schmidt17a" format="default"/>. To study the relationship between the number
locations. They analyzed the relationship between the number of of
anycast instances and service performance (measuring latency of the anycast instances and the associated service performance, the authors measured t
round-trip time (RTT)), measuring the overall performance of four DNS he round-trip time (RTT) latency of four DNS root servers. The root DNS servers
Root servers. The Root DNS servers are implemented by 12 separate are implemented by 12 separate
organizations serving the DNS root zone at 13 different IPv4/IPv6 organizations serving the DNS root zone at 13 different IPv4/IPv6
address pairs.</t> address pairs.</t>
<t>The results documented in <xref target="Schmidt17a" format="default
<t>The results documented in <xref target="Schmidt17a"/> measured the performanc "/> measured the performance of
e of the {c,f,k,l}.root-servers.net (referred to as "C", "F", "K", and "L" hereafter)
the {c,f,k,l}.root-servers.net (hereafter, "C", "F", "K" and "L") servers from more than 7,900 RIPE Atlas probes. RIPE Atlas is an
servers from more than 7.9k RIPE Atlas probes. RIPE Atlas is a Internet measurement platform with more than 12,000 global vantage
Internet measurement platform with more than 12000 global vantage points called "Atlas probes", and it is used regularly by both
points called "Atlas Probes" -- it is used regularly by both researchers and operators <xref target="RipeAtlas15a" format="default"/> <xref t
researchers and operators <xref target="RipeAtlas15a"/> <xref target="RipeAtlas1 arget="RipeAtlas19a" format="default"/>.</t>
9a"/>.</t> <t>In <xref target="Schmidt17a" format="default"/>, the authors found
that the C server, a smaller anycast deployment
<t><xref target="Schmidt17a"/> found that the C server, a smaller anycast deploy
ment
consisting of only 8 instances, provided very similar overall consisting of only 8 instances, provided very similar overall
performance in comparison to the much larger deployments of K and L, 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 with 33 and 144 instances, respectively. The median RTTs for the C, K, and L
root server were all between 30-32ms.</t> root servers were all between 30-32 ms.</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 <t>Because RIPE Atlas is known to have better coverage in Europe than
other regions, the authors specifically analyzed the results per other regions, the authors specifically analyzed the results per
region and per country (Figure 5 in <xref target="Schmidt17a"/>), and show that region and per country (Figure 5 in <xref target="Schmidt17a" format="default"/> ) and show that
known Atlas bias toward Europe does not change the conclusion that known Atlas bias toward Europe does not change the conclusion that
properly selected anycast locations is more important to latency than properly selected anycast locations are more important to latency than
the number of sites.</t> the number of sites.</t>
</section>
</section> <section anchor="resulting-considerations-1" numbered="true" toc="defaul
<section anchor="resulting-considerations-1" title="Resulting considerations"> t">
<name>Resulting Considerations</name>
<t>The important conclusion of <xref target="Schmidt17a"/> is that when engineer <t>The important conclusion from <xref target="Schmidt17a" format="def
ing ault"/> is that when engineering
anycast services for performance, factors other than just the number anycast services for performance, factors other than just the number
of instances (such as local routing connectivity) must be considered. of instances (such as local routing connectivity) must be considered.
Specifically, optimizing routing policies is more important than Specifically, optimizing routing policies is more important than
simply adding new instances. They showed that 12 instances can simply adding new instances. The authors showed that 12 instances can
provide reasonable latency, assuming they are globally distributed and provide reasonable latency, assuming they are globally distributed and
have good local interconnectivity. However, additional instances can have good local interconnectivity. However, additional instances can
still be useful for other reasons, such as when handling still be useful for other reasons, such as when handling
Denial-of-service (DoS) attacks <xref target="Moura16b"/>.</t> DoS attacks <xref target="Moura16b" format="default"/>.</t>
</section>
</section> </section>
</section> <section anchor="c3" numbered="true" toc="default">
<section anchor="c3-collecting-anycast-catchment-maps-to-improve-design" title=" <name>C3: Collect Anycast Catchment Maps to Improve Design</name>
C3: Collecting anycast catchment maps to improve design"> <section anchor="research-background-2" numbered="true" toc="default">
<name>Research Background</name>
<section anchor="research-background-2" title="Research background">
<t>An anycast DNS service may be deployed from anywhere from several <t>An anycast DNS service may be deployed from anywhere and from sever al
locations to hundreds of locations (for example, l.root-servers.net locations to hundreds of locations (for example, l.root-servers.net
has over 150 anycast instances at the time this was written). Anycast has over 150 anycast instances at the time this was written). Anycast
leverages Internet routing to distribute incoming queries to a leverages Internet routing to distribute incoming queries to a
service's hop-nearest distributed anycast locations. However, usually service's nearest distributed anycast locations measured by the number of routin
queries are not evenly distributed across all anycast locations, as g hops. However, queries are usually not evenly distributed across all anycast
found in the case of L-Root <xref target="IcannHedge18"/>.</t> locations, as
found in the case of L-Root when analyzed using Hedgehog <xref target="IcannHedg
<t>Adding locations to or removing locations from a deployed anycast ehog" format="default"/>.</t>
<t>Adding locations to or removing locations from a deployed anycast
network changes the load distribution across all of its network changes the load distribution across all of its
locations. When a new location is announced by BGP, locations may locations. When a new location is announced by BGP, locations may
receive more or less traffic than it was engineered for, leading to receive more or less traffic than it was engineered for, leading to
suboptimal service performance or even stressing some locations while suboptimal service performance or even stressing some locations while
leaving others underutilized. Operators constantly face this scenario leaving others underutilized. Operators constantly face this scenario
that when expanding an anycast service. Operators cannot easily when expanding an anycast service. Operators cannot easily
directly estimate future query distributions based on proposed anycast directly estimate future query distributions based on proposed anycast
network engineering decisions.</t> network engineering decisions.</t>
<t>To address this need and estimate the query loads based on changing, <t>To address this need and estimate the query loads of an anycast ser
in particular expanding, anycast service changes <xref target="Vries17b"/> vice undergoing changes (in particular expanding), <xref target="Vries17b" forma
developed a new technique enabling operators to carry out active t="default"/> describes the development of a new technique enabling operators to
measurements, using an open-source tool called Verfploeter (available carry out active
at <xref target="VerfSrc"></xref>). The results allow the creation of detailed measurements using an open-source tool called Verfploeter (available
anycast at <xref target="VerfSrc" format="default"/>). The results allow the creation o
maps and catchment estimates. By running verfploeter combined with a f detailed anycast
published IPv4 "hit list", DNS can precisely calculate which remote maps and catchment estimates. By running Verfploeter combined with a
published IPv4 "hit list", the DNS can precisely calculate which remote
prefixes will be matched to each anycast instance in a network. At 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 time of this writing, Verfploeter still does not support IPv6 as
the IPv4 hit lists used are generated via frequent large scale ICMP the IPv4 hit lists used are generated via frequent large-scale ICMP
echo scans, which is not possible using IPv6.</t> echo scans, which is not possible using IPv6.</t>
<t>As proof of concept, <xref target="Vries17b" format="default"/> doc
<t>As proof of concept, <xref target="Vries17b"/> documents how it verfploeter w uments how Verfploeter was used to predict both the catchment and query load dis
as tribution for a new anycast instance deployed for b.root-servers.net. Using two
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 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 echo query was sent from an IP anycast address to each IPv4 /24
network routing block on the Internet.</t> network routing block on the Internet.</t>
<t>The ICMP echo responses were recorded at both sites and analyzed and <t>The ICMP echo responses were recorded at both sites and analyzed an
overlayed onto a graphical world map, resulting in an Internet scale d
overlaid onto a graphical world map, resulting in an Internet-scale
catchment map. To calculate expected load once the production network catchment map. To calculate expected load once the production network
was enabled, the quantity of traffic received by b.root-servers.net's 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 single site at LAX was recorded based on a single day's traffic
(2017-04-12, DITL datasets <xref target="Ditl17"/>). <xref target="Vries17b"/> (2017-04-12, "day in the life" (DITL) datasets <xref target="Ditl17" format="def
predicted that ault"/>). In <xref target="Vries17b" format="default"/>, it was predicted that
81.6% of the traffic load would remain at the LAX site. This estimate 81.6% of the traffic load would remain at the LAX site. This Verfploeter estimat
by verfploeter turned out to be very accurate; the actual measured e
traffic volume when production service at MIA was enabled was 81.4%.</t> 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 D <t>Verfploeter can also be used to estimate traffic shifts based on ot
NS her
operators can make informed engineering choices when changing DNS BGP route engineering techniques (for example, Autonomous System (AS) path prepe
nding or
BGP community use) in advance of operational deployment. This was studied in <xr
ef target="Vries17b" format="default"/> using prepending with 1-3 hops at each i
nstance, and
the results were compared against real operational changes to validate the
accuracy of the techniques.</t>
</section>
<section anchor="resulting-considerations-2" numbered="true" toc="defaul
t">
<name>Resulting Considerations</name>
<t>An important operational takeaway <xref target="Vries17b" format="d
efault"/> provides is how DNS operators can make informed engineering choices wh
en changing DNS
anycast network deployments by using Verfploeter in advance. anycast network deployments by using Verfploeter in advance.
Operators can identify sub-optimal routing situations in advance with Operators can identify suboptimal routing situations in advance with
significantly better coverage than using other active measurement significantly better coverage rather than using other active measurement
platforms such as RIPE Atlas. To date, Verfploeter has been deployed platforms such as RIPE Atlas. To date, Verfploeter has been deployed
on a operational testbed (Anycast testbed) <xref target="AnyTest"/>, on a large on an operational testbed (anycast testbed) <xref target="AnyTest" format="defau
unnamed operator and is run daily at b.root-servers.net<xref target="Vries17b"/> lt"/> on a large
.</t> unnamed operator and is run daily at b.root-servers.net <xref target="Vries17b"
format="default"/>.</t>
<t>Operators should use active measurement techniques like Verfploeter in <t>Operators should use active measurement techniques like Verfploeter
in
advance of potential anycast network changes to accurately measure the advance of potential anycast network changes to accurately measure the
benefits and potential issues ahead of time.</t> benefits and potential issues ahead of time.</t>
</section>
</section> </section>
</section> <section anchor="c4" numbered="true" toc="default">
<section anchor="c4-when-under-stress-employ-two-strategies" title="C4: When und <name>C4: Employ Two Strategies When under Stress</name>
er stress, employ two strategies"> <section anchor="research-background-3" numbered="true" toc="default">
<name>Research Background</name>
<section anchor="research-background-3" title="Research background"> <t>DDoS attacks are becoming bigger, cheaper, and more frequent
<xref target="Moura16b" format="default"/>. The most powerful recorded DDoS atta
<t>DDoS attacks are becoming bigger, cheaper, and more frequent ck against DNS
<xref target="Moura16b"/>. The most powerful recorded DDoS attack against DNS servers to date reached 1.2 Tbps by using Internet of Things (IoT) devices
servers to date reached 1.2 Tbps by using IoT devices <xref target="Perlroth16" format="default"/>.
<xref target="Perlroth16"/>. How should a DNS operator engineer its anycast How should a DNS operator engineer its anycast
authoritative DNS server react to such a DDoS attack? <xref target="Moura16b"/> authoritative DNS server to react to such a DDoS attack? <xref target="Moura16b
" format="default"/>
investigates this question using empirical observations grounded with investigates this question using empirical observations grounded with
theoretical option evaluations.</t> theoretical option evaluations.</t>
<t>An authoritative DNS server deployed using anycast will have many <t>An authoritative DNS server deployed using anycast will have many
server instances distributed over many networks. Ultimately, the server instances distributed over many networks. Ultimately, the
relationship between the DNS provider's network and a client's ISP relationship between the DNS provider's network and a client's ISP
will determine which anycast instance will answer queries for a given will determine which anycast instance will answer queries for a given
client, given that BGP is the protocol that maps clients to specific client, given that the BGP protocol maps clients to specific
anycast instances by using routing information [RF:KDar02]. As a anycast instances using routing information. As a
consequence, when an anycast authoritative server is under attack, the consequence, when an anycast authoritative server is under attack, the
load that each anycast instance receives is likely to be unevenly load that each anycast instance receives is likely to be unevenly
distributed (a function of the source of the attacks), thus some distributed (a function of the source of the attacks); thus, some
instances may be more overloaded than others which is what was instances may be more overloaded than others, which is what was
observed analyzing the Root DNS events of Nov. 2015 observed when analyzing the root DNS events of November 2015
<xref target="Moura16b"/>. Given the fact that different instances may have <xref target="Moura16b" format="default"/>. Given the fact that different instan
different capacity (bandwidth, CPU, etc.), making a decision about how ces may have
to react to stress becomes even more difficult.</t> different capacities (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, <t>In practice, when an anycast instance is overloaded with incoming t raffic,
operators have two options:</t> operators have two options:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>They can withdraw its routes, pre-prepend its AS route to some o
<t>They can withdraw its routes, pre-prepend its AS route to some or r
all of its neighbors, perform other traffic shifting tricks (such as all of its neighbors, perform other traffic-shifting tricks (such as
reducing route announcement propagation using BGP reducing route announcement propagation using BGP
communities<xref target="RFC1997"/>), or by communicating with its upstream communities <xref target="RFC1997" format="default"/>), or communicate with its
network providers to apply filtering (potentially using FlowSpec upstream
<xref target="RFC8955"/> or DOTS protocol (<xref target="RFC8811"/>, <xref targe network providers to apply filtering (potentially using FlowSpec <xref target="R
t="RFC8782"/>, <xref target="RFC8783"/>). These FC8955" format="default"/> or the DDoS Open Threat Signaling (DOTS) protocol <xr
techniques shift both legitimate and attack traffic to other anycast ef target="RFC8811"
instances (with hopefully greater capacity) or to block traffic format="default"/> <xref target="RFC9132" format="default"/> <xref target="RFC87
entirely.</t> 83" format="default"/>). These techniques shift both legitimate and attack traff
<t>Alternatively, operators can be become a degraded absorber by ic to other anycast instances (with hopefully greater capacity) or block traffic
entirely.</li>
<li>Alternatively, operators can become degraded absorbers by
continuing to operate, knowing dropping incoming legitimate requests continuing to operate, knowing dropping incoming legitimate requests
due to queue overflow. However, this approach will also absorb due to queue overflow. However, this approach will also absorb
attack traffic directed toward its catchment, hopefully protecting attack traffic directed toward its catchment, hopefully protecting
the other anycast instances.</t> the other anycast instances.</li>
</list></t> </ul>
<t>
<t><xref target="Moura16b"/> saw both of these behaviors deployed in practice by <xref target="Moura16b" format="default"/> describes seeing both of t
studying instance reachability and route-trip time (RTTs) in the DNS hese behaviors deployed in practice when studying instance reachability and RTTs
in the DNS
root events. When withdraw strategies were deployed, the stress of root events. When withdraw strategies were deployed, the stress of
increased query loads were displaced from one instance to multiple increased query loads were displaced from one instance to multiple
other sites. In other observed events, one site was left to absorb other sites. In other observed events, one site was left to absorb
the brunt of an attack leaving the other sites to remain relatively the brunt of an attack, leaving the other sites to remain relatively
less affected.</t> less affected.</t>
</section>
</section> <section anchor="resulting-considerations-3" numbered="true" toc="defaul
<section anchor="resulting-considerations-3" title="Resulting considerations"> t">
<name>Resulting Considerations</name>
<t>Operators should consider having both a anycast site withdraw strategy <t>Operators should consider having both an anycast site withdraw stra
and a absorption strategy ready to be used before a network overload tegy
and an absorption strategy ready to be used before a network overload
occurs. Operators should be able to deploy one or both of these occurs. Operators should be able to deploy one or both of these
strategies rapidly. Ideally, these should be encoded into operating strategies rapidly. Ideally, these should be encoded into operating
playbooks with defined site measurement guidelines for which strategy playbooks with defined site measurement guidelines for which strategy
to employ based on measured data from past events.</t> to employ based on measured data from past events.</t>
<t><xref target="Moura16b" format="default"/> speculates that careful,
<t><xref target="Moura16b"/> speculates that careful, explicit, and automated explicit, and automated
management policies may provide stronger defenses to overload management policies may provide stronger defenses to overload
events. DNS operators should be ready to employ both traditional events. DNS operators should be ready to employ both common
filtering approaches and other routing load balancing techniques filtering approaches and other routing load-balancing techniques
(withdraw/prepend/communities or isolate instances), (such as withdrawing routes, prepending Autonomous Systems (ASes), adding commun
ities, or isolating instances),
where the best choice depends on the specifics of the attack.</t> where the best choice depends on the specifics of the attack.</t>
<t>Note that this consideration refers to the operation of just one
<t>Note that this consideration refers to the operation of just one
anycast service point, i.e., just one anycasted IP address block anycast service point, i.e., just one anycasted IP address block
covering one NS record. However, DNS zones with multiple authoritative covering one NS record. However, DNS zones with multiple authoritative
anycast servers may also expect loads to shift from one anycasted anycast servers may also expect loads to shift from one anycasted
server to another, as resolvers switch from on authoritative service server to another, as resolvers switch from one authoritative service
point to another when attempting to resolve a name <xref target="Mueller17b"/>.< point to another when attempting to resolve a name <xref target="Mueller17b" for
/t> mat="default"/>.</t>
</section>
</section> </section>
</section> <section anchor="c5" numbered="true" toc="default">
<section anchor="c5-consider-longer-time-to-live-values-whenever-possible" title <name>C5: Consider Longer Time-to-Live Values Whenever Possible</name>
="C5: Consider longer time-to-live values whenever possible"> <section anchor="research-background-4" numbered="true" toc="default">
<name>Research Background</name>
<section anchor="research-background-4" title="Research background"> <t>Caching is the cornerstone of good DNS performance and reliability.
A
<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 response of less
50 ms response to a new DNS query may be considered fast, but a less than 1 ms to a cached entry is far faster. In <xref target="Moura18b" format="de
than 1 ms response to a cached entry is far faster. <xref target="Moura18b"/> fault"/>, it was
showed that caching also protects users from short outages and even shown that caching also protects users from short outages and even
significant DDoS attacks.</t> significant DDoS attacks.</t>
<t>DNS record TTLs (time-to-live values) <xref target="RFC1034"/><xref target="R FC1035"/> directly <t>Time-to-live (TTL) values <xref target="RFC1034" format="default"/> <xref target="RFC1035" format="default"/> for DNS records directly
control cache durations and affect latency, resilience, and the role control cache durations and affect latency, resilience, and the role
of DNS in CDN server selection. Some early work modeled caches as a of DNS in Content Delivery Network (CDN) server selection. Some early work model
function of their TTLs <xref target="Jung03a"/>, and recent work has examined th ed caches as a
eir function of their TTLs <xref target="Jung03a" format="default"/>, and recent wor
interaction with DNS<xref target="Moura18b"/>, but until <xref target="Moura19b" k has examined cache
/> no research interactions with DNS <xref target="Moura18b" format="default"/>, but until <xre
provided considerations about the benefits of various TTL value f target="Moura19b" format="default"/>, no research
choices. To study this, Moura et. al. <xref target="Moura19b"/> carried out a had provided considerations about the benefits of various TTL value
choices. To study this, Moura et al.&nbsp;<xref target="Moura19b" format="defaul
t"/> carried out a
measurement study investigating TTL choices and their impact on user measurement study investigating TTL choices and their impact on user
experiences in the wild. They performed this study independent of experiences in the wild. They performed this study independent of
specific resolvers (and their caching architectures), vendors, or specific resolvers (and their caching architectures), vendors, or
setups.</t> setups.</t>
<t>First, they identified several reasons why operators and zone owner
<t>First, they identified several reasons why operators and zone-owners may s may
want to choose longer or shorter TTLs:</t> want to choose longer or shorter TTLs:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Longer TTLs, as discussed, lead to a longer cache life, resultin
<t>As discussed, longer TTLs lead to a longer cache life, resulting g
in faster responses. <xref target="Moura19b"/> measured this in the wild and in faster responses. In <xref target="Moura19b" format="default"/>, t
showed that by increasing the TTL for .uy TLD from 5 minutes his was measured this in the wild, and it
(300s) to 1 day (86400s) the latency measured from 15k Atlas showed that by increasing the TTL for the .uy TLD from 5 minutes
(300 s) to 1 day (86,400 s), the latency measured from 15,000 Atlas
vantage points changed significantly: the median RTT decreased vantage points changed significantly: the median RTT decreased
from 28.7ms to 8ms, and the 75%ile decreased from 183ms to 21ms.</t> from 28.7 ms to 8 ms, and the 75th percentile decreased from 183 ms to 21 ms.</l
<t>Longer caching times also results in lower DNS traffic: i>
<li>Longer caching times also result in lower DNS traffic:
authoritative servers will experience less traffic with extended authoritative servers will experience less traffic with extended
TTLs, as repeated queries are answered by resolver caches.</t> TTLs, as repeated queries are answered by resolver caches.</li>
<t>Consequently, longer caching results in a lower overall cost if <li>Longer caching consequently results in a lower overall cost if
DNS is metered: some DNS-As-A-Service providers charge a per query the DNS is metered: some providers that offer DNS as a Service charge a per-quer
(metered) cost (often in addition to a fixed monthly cost).</t> y
<t>Longer caching is more robust to DDoS attacks on DNS (metered) cost (often in addition to a fixed monthly cost).</li>
infrastructure. <xref target="Moura18b"/> also measured and show that DNS
caching can greatly reduce the effects of a DDoS on DNS, provided <li>Longer caching is more robust to DDoS attacks on DNS
that caches last longer than the attack.</t> infrastructure. DNS caching was also measured in <xref target="Moura18b" format
<t>However, shorter caching supports deployments that may require ="default"/>, and it showed that the effects of a DDoS on DNS can be greatly re
rapid operational changes: An easy way to transition from an old duced, provided
that the caches last longer than the attack.</li>
<li>Shorter caching, however, 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 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 there is no method to remotely remove cached DNS records, the TTL
duration represents a necessary transition delay to fully shift duration represents a necessary transition delay to fully shift
from one server to another. Thus, low TTLs allow for more rapid from one server to another. Thus, low TTLs allow for more rapid
transitions. However, when deployments are planned in advance transitions. However, when deployments are planned in advance
(that is, longer than the TTL), it is possible to lower the TTLs (that is, longer than the TTL), it is possible to lower the TTLs
just-before a major operational change and raise them again just before a major operational change and raise them again
afterward.</t> afterward.</li>
<t>Shorter caching can also help with a DNS-based response to DDoS <li>Shorter caching can also help with a DNS-based response to DDoS
attacks. Specifically, some DDoS-scrubbing services use the DNS to attacks. Specifically, some DDoS-scrubbing services use the DNS to
redirect traffic during an attack. Since DDoS attacks arrive redirect traffic during an attack. Since DDoS attacks arrive
unannounced, DNS-based traffic redirection requires the TTL be unannounced, DNS-based traffic redirection requires that the TTL be
kept quite low at all times to allow operators to suddenly have kept quite low at all times to allow operators to suddenly have
their zone served by a DDoS-scrubbing service.</t> their zone served by a DDoS-scrubbing service.</li>
<t>Shorter caching helps DNS-based load balancing. Many large <li>Shorter caching helps DNS-based load balancing. Many large
services are known to rotate traffic among their servers using services are known to rotate traffic among their servers using
DNS-based load balancing. Each arriving DNS request provides an DNS-based load balancing. Each arriving DNS request provides an
opportunity to adjust service load by rotating IP address records opportunity to adjust the service load by rotating IP address records
(A and AAAA) to the lowest unused server. Shorter TTLs may be (A and AAAA) to the lowest unused server. Shorter TTLs may be
desired in these architectures to react more quickly to traffic desired in these architectures to react more quickly to traffic
dynamics. Many recursive resolvers, however, have minimum caching dynamics. Many recursive resolvers, however, have minimum caching
times of tens of seconds, placing a limit on this form of agility.</t> times of tens of seconds, placing a limit on this form of agility.</li>
</list></t> </ul>
</section>
</section> <section anchor="resulting-considerations-4" numbered="true" toc="defaul
<section anchor="resulting-considerations-4" title="Resulting considerations"> t">
<name>Resulting Considerations</name>
<t>Given these considerations, the proper choice for a TTL depends in <t>Given these considerations, the proper choice for a TTL depends in
part on multiple external factors -- no single recommendation is part on multiple external factors -- no single recommendation is
appropriate for all scenarios. Organizations must weigh these appropriate for all scenarios. Organizations must weigh these
trade-offs and find a good balance for their situation. Still, some trade-offs and find a good balance for their situation. Still, some
guidelines can be reached when choosing TTLs:</t> guidelines can be reached when choosing TTLs:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>For general DNS zone owners, <xref target="Moura19b" format="default"/> reco
<t>For general DNS zone owners, <xref target="Moura19b"/> recommends a longer mmends a longer TTL
TTL of at least one hour and ideally 4, 8, or 24 hours. Assuming
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 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> TTLs have little cost and may even literally provide cost savings.</li>
<t>For registry operators: TLD and other public registration <li>For TLD and other public registration
operators (for example most ccTLDs and .com, .net, .org) that host operators (for example, most ccTLDs and .com, .net, and .org) that host
many delegations (NS records, DS records and "glue" records), many delegations (NS records, DS records, and "glue" records),
<xref target="Moura19b"/> demonstrates that most resolvers will use the TTL <xref target="Moura19b" format="default"/> demonstrates that most resolvers will
values provided by the child delegations while the others some use the TTL
values provided by the child delegations while some others
will choose the TTL provided by the parent's copy of the will choose the TTL provided by the parent's copy of the
record. As such, <xref target="Moura19b"/> recommends longer TTLs (at least an record. As such, <xref target="Moura19b" format="default"/> recommends longer TT Ls (at least an
hour or more) for registry operators as well for child NS and hour or more) for registry operators as well for child NS and
other records.</t> other records.</li>
<t>Users of DNS-based load balancing or DDoS-prevention services may <li>Users of DNS-based load balancing or DDoS-prevention services ma
y
require shorter TTLs: TTLs may even need to be as short as 5 require shorter TTLs: TTLs may even need to be as short as 5
minutes, although 15 minutes may provide sufficient agility for minutes, although 15 minutes may provide sufficient agility for
many operators. There is always a tussle between shorter TTLs many operators. There is always a tussle between using shorter TTLs
providing more agility against all the benefits listed above for that provide more agility and using longer TTLs that include all the benefits li
using longer TTLs.</t> sted above.</li>
<t>Use of A/AAAA and NS records: The TTLs for A/AAAA records should <li>Regarding the use of A/AAAA and NS records, the TTLs for A/AAAA
be shorter to or equal to the TTL for the corresponding NS records records should
for in-bailiwick authoritative DNS servers, since <xref target="Moura19b"/> be shorter than or equal to the TTL for the corresponding NS records
for in-bailiwick authoritative DNS servers, since <xref target="Moura19b" format
="default"/>
finds that once an NS record expires, their associated A/AAAA will 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 also be requeried when glue is required to be sent by the
parents. For out-of-bailiwick servers, A, AAAA and NS records are parents. For out-of-bailiwick servers, A, AAAA, and NS records are
usually all cached independently, so different TTLs can be used usually all cached independently, so different TTLs can be used
effectively if desired. In either case, short A and AAAA records effectively if desired. In either case, short A and AAAA records
may still be desired if DDoS-mitigation services are required.</t> may still be desired if DDoS mitigation services are required.</li>
</list></t> </ul>
</section>
</section> </section>
</section> <section anchor="c6" numbered="true" toc="default">
<section anchor="c6-consider-the-ttl-differences-between-parents-and-children" t <name>C6: Consider the Difference in Parent and Children's TTL Values</n
itle="C6: Consider the TTL differences between parents and children"> ame>
<section anchor="research-background-5" numbered="true" toc="default">
<section anchor="research-background-5" title="Research background"> <name>Research Background</name>
<t>Multiple record types exist or are related between the parent of a <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 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 identical in the parent (but often are not), as are corresponding IP
address in "glue" A/AAAA records that must exist for in-bailiwick addresses in "glue" A/AAAA records that must exist for in-bailiwick
authoritative servers. Additionally, if DNSSEC (<xref target="RFC4033"/> authoritative servers. Additionally, if DNSSEC <xref target="RFC4033" format="d
<xref target="RFC4034"/> <xref target="RFC4035"/> <xref target="RFC4509"/>) is d efault"/>
eployed for a zone the <xref target="RFC4034" format="default"/> <xref target="RFC4035" for
mat="default"/> <xref target="RFC4509" format="default"/> is deployed for a zone
, the
parent's DS record must cryptographically refer to a child's DNSKEY parent's DS record must cryptographically refer to a child's DNSKEY
record.</t> record.</t>
<t>Because some information exists in both the parent and a child, it
<t>Because some information exists in both the parent and a child, it is is
possible for the TTL values to differ between the parent's copy and possible for the TTL values to differ between the parent's copy and
the child's. <xref target="Moura19b"/> examines resolver behaviors when these the child's. <xref target="Moura19b" format="default"/> examines resolver behav
values differ in the wild, as they frequently do -- often parent zones iors when these
have defacto TTL values that a child has no control over. For values differed in the wild, as they frequently do -- often, parent zones
have de facto 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 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 (48 hours), but some TLDs have lower values within their published
records (the TTLs for .cl's NS records from their authoritative records (the TTLs for .cl's NS records from their authoritative
servers is 1 hour). <xref target="Moura19b"/> also examines the differences in the servers is 1 hour). <xref target="Moura19b" format="default"/> also examines th e differences in the
TTLs between the NS records and the corresponding A/AAAA records for TTLs between the NS records and the corresponding A/AAAA records for
the addresses of a nameserver. RIPE Atlas nodes are used to determine the addresses of a name server. RIPE Atlas nodes are used to determine
what resolvers in the wild do with different information, and whether 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 parent's TTL is used for cache lifetimes ("parent-centric") or
the child's is used ("child-centric").</t> the child's ("child-centric").</t>
<t><xref target="Moura19b" format="default"/> found that roughly 90% o
<t><xref target="Moura19b"/> finds that roughly 90% of resolvers follow the chil f resolvers follow the child's
d's view of the TTL, while 10% appear parent-centric. Additionally, it
view of the TTL, while 10% appear parent-centric. It additionally found that resolvers behave differently for cache lifetimes for
finds that resolvers behave differently for cache lifetimes for in-bailiwick vs. out-of-bailiwick NS/A/AAAA TTL combinations.
in-bailiwick vs out-of-bailiwick NS/A/AAAA TTL combinations.
Specifically, when NS TTLs are shorter than the corresponding address Specifically, when NS TTLs are shorter than the corresponding address
records, most resolvers will re-query for A/AAAA records for records, most resolvers will requery for A/AAAA records for the
in-bailiwick resolvers and switch to new address records even if the in-bailiwick resolvers and switch to new address records even if the
cache indicates the original A/AAAA records could be kept longer. On 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 other hand, the inverse is true for out-of-bailiwick resolvers: if
the NS record expires first resolvers will honor the original cache the NS record expires first, resolvers will honor the original cache
time of the nameserver's address.</t> time of the name server's address.</t>
</section>
</section> <section anchor="resulting-considerations-5" numbered="true" toc="defaul
<section anchor="resulting-considerations-5" title="Resulting considerations"> t">
<name>Resulting Considerations</name>
<t>The important conclusion from this study is that operators cannot <t>The important conclusion from this study is that operators cannot
depend on their published TTL values alone -- the parent's values are depend on their published TTL values alone -- the parent's values are
also used for timing cache entries in the wild. Operators that are also used for timing cache entries in the wild. Operators that are
planning on infrastructure changes should assume that older planning on infrastructure changes should assume that an older
infrastructure must be left on and operational for at least the infrastructure must be left on and operational for at least the
maximum of both the parent and child's TTLs.</t> maximum of both the parent and child's TTLs.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security considerations"> <name>Security Considerations</name>
<t>This document discusses applying measured research results to
<t>This document discusses applying measured research results to
operational deployments. Most of the considerations affect mostly operational deployments. Most of the considerations affect mostly
operational practice, though a few do have security related impacts.</t> operational practice, though a few do have security-related impacts.</t>
<t>Specifically, <xref target="c4" format="none">C4</xref> discusses a cou
<t>Specifically, C4 discusses a couple of strategies to employ when a ple of strategies to employ when a
service is under stress from DDoS attacks and offers operators service is under stress from DDoS attacks and offers operators
additional guidance when handling excess traffic.</t> additional guidance when handling excess traffic.</t>
<t>Similarly, <xref target="c5" format="none">C5</xref> identifies the tra
<t>Similarly, C5 identifies the trade-offs with respect to the de-offs with respect to the
operational and security benefits of using longer time-to-live values.</t> operational and security benefits of using longer TTL values.</t>
<!-- verified against RFC3552 - MD -->
</section> </section>
<section anchor="privacy-considerations" title="Privacy Considerations"> <section anchor="privacy-considerations" numbered="true" toc="default">
<name>Privacy Considerations</name>
<!-- 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 <t>This document does not add any new, practical privacy issues, aside
from possible benefits in deploying longer TTLs as suggested in C5. from possible benefits in deploying longer TTLs as suggested in <xref target="c5
" format="none">C5</xref>.
Longer TTLs may help preserve a user's privacy by reducing the number 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 of requests that get transmitted in both client-to-resolver and
resolver-to-authoritative cases.</t> resolver-to-authoritative cases.</t>
</section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2181.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7094.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1546.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1995.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5936.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4786.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1997.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8499.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8783.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8955.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9132.xml"/>
</section> </references>
<section anchor="iana-considerations" title="IANA considerations"> <references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4509.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8811.xml"/>
<t>This document has no IANA actions. <reference anchor="Moura16b" target="https://www.isi.edu/~johnh/PAPERS/M
<!-- RFC8126 style - MD --></t> oura16b.pdf">
<front>
<title>Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event
</title>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo
ura">
<organization/>
</author>
<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
. Schmidt">
<organization/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization/>
</author>
<author initials="W." surname="de Vries" fullname="Wouter de Vries">
<organization/>
</author>
<author initials="M." surname="Müller" fullname="Moritz Müller">
<organization/>
</author>
<author initials="L." surname="Wei" fullname="Lan Wei">
<organization/>
</author>
<author initials="C." surname="Hesselman" fullname="Cristian Hesselm
an">
<organization/>
</author>
<date year="2016" month="November"/>
</front>
<seriesInfo name="DOI" value="10.1145/2987443.2987446"/>
<refcontent>ACM 2016 Internet Measurement Conference</refcontent>
</reference>
</section> <reference anchor="Schmidt17a" target="https://www.isi.edu/%7ejohnh/PAPE
<section anchor="acknowledgements" title="Acknowledgements"> RS/Schmidt17a.pdf">
<front>
<title>Anycast Latency: How Many Sites Are Enough?</title>
<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
. Schmidt">
<organization/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization/>
</author>
<author initials="J." surname="Kuipers" fullname="Jan Harm Kuipers">
<organization/>
</author>
<date year="2017" month="March"/>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-319-54328-4_14"/>
<refcontent>PAM 2017 Passive and Active Measurement Conference</refcon
tent>
</reference>
<t>This document is a summary of the main considerations of six research <reference anchor="Moura18b" target="https://www.isi.edu/~johnh/PAPERS/M
works performed by the authors and others. This document would not oura18b.pdf">
have been possible without the hard work of these authors and co-authors:</t> <front>
<title>When the Dike Breaks: Dissecting DNS Defenses During DDoS</ti
tle>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo
ura">
<organization/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization/>
</author>
<author initials="M." surname="Müller" fullname="Moritz Müller">
<organization/>
</author>
<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
. Schmidt">
<organization/>
</author>
<author initials="M." surname="Davids" fullname="Marco Davids">
<organization/>
</author>
<date year="2018" month="October"/>
</front>
<seriesInfo name="DOI" value="10.1145/3278532.3278534"/>
<refcontent>ACM 2018 Internet Measurement Conference</refcontent>
</reference>
<t><list style="symbols"> <reference anchor="Singla2014" target="http://speedierweb.web.engr.illin
<t>Ricardo de O. Schmidt</t> ois.edu/cspeed/papers/hotnets14.pdf">
<t>Wouter B de Vries</t> <front>
<t>Moritz Mueller</t> <title>The Internet at the Speed of Light</title>
<t>Lan Wei</t> <author initials="A." surname="Singla" fullname="Ankit Singla">
<t>Cristian Hesselman</t> <organization/>
<t>Jan Harm Kuipers</t> </author>
<t>Pieter-Tjerk de Boer</t> <author initials="B." surname="Chandrasekaran" fullname="Balakrishna
<t>Aiko Pras</t> n Chandrasekaran">
</list></t> <organization/>
</author>
<author initials="P." surname="Godfrey" fullname="P. Brighten Godfre
y">
<organization/>
</author>
<author initials="B." surname="Maggs" fullname="Bruce Maggs">
<organization/>
</author>
<date year="2014" month="October"/>
</front>
<seriesInfo name="DOI" value="10.1145/2670518.2673876"/>
<refcontent>13th ACM Workshop on Hot Topics in Networks</refcontent>
</reference>
<t>We would like also to thank the reviewers of this draft that offered <reference anchor="Vries17b" target="https://www.isi.edu/%7ejohnh/PAPERS
valuable suggestions: Duane Wessels, Joe Abley, Toema Gavrichenkov, /Vries17b.pdf">
John Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus <front>
Darilion and Samir Jafferali, and comments provided at the IETF DNSOP <title>Broad and Load-Aware Anycast Mapping with Verfploeter</title>
session (IETF104).</t> <author initials="W." surname="de Vries" fullname="Wouter de Vries">
<organization/>
</author>
<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
. Schmidt">
<organization/>
</author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization/>
</author>
<author initials="P-T" surname="de Boer" fullname="Pieter-Tjerk de B
oer">
<organization/>
</author>
<author initials="A." surname="Pras" fullname="Aiko Pras">
<organization/>
</author>
<date year="2017" month="November"/>
</front>
<seriesInfo name="DOI" value="10.1145/3131365.3131371"/>
<refcontent>ACM 2017 Internet Measurement Conference</refcontent>
</reference>
<t>Besides those, we would like thank those acknowledged in the papers <reference anchor="Jung03a" target="http://www.ieee-infocom.org/2003/pap
this document summarizes for helping produce the results: RIPE NCC and ers/11_01.PDF">
DNS OARC for their tools and datasets used in this research, as well <front>
as the funding agencies sponsoring the individual research works.</t> <title>Modeling TTL-based Internet Caches</title>
<author initials="J." surname="Jung" fullname="Jaeyeon Jung">
<organization/>
</author>
<author initials="A." surname="Berger" fullname="Arthur W. Berger">
<organization/>
</author>
<author initials="H." surname="Balakrishnan" fullname="Hari Balakris
hnan">
<organization/>
</author>
<date year="2003" month="July"/>
</front>
<seriesInfo name="DOI" value="10.1109/INFCOM.2003.1208693"/>
<refcontent>ACM 2003 IEEE INFOCOM</refcontent>
</reference>
</section> <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>
<organization>RIPE Network Coordination Centre (RIPE NCC)</organiz
ation>
</author>
<date year="2015" month="October"/>
</front>
</reference>
</middle> <reference anchor="RipeAtlas19a" target="https://atlas.ripe.net">
<front>
<title>RIPE Atlas</title>
<author><organization>RIPE Network Coordination Centre (RIPE NCC)</o
rganization>
</author>
<date/>
</front>
</reference>
<back> <reference anchor="Mueller17b" target="https://www.isi.edu/%7ejohnh/PAPE
RS/Mueller17b.pdf">
<front>
<title>Recursives in the Wild: Engineering Authoritative DNS Servers
</title>
<author initials="M." surname="Müller" fullname="Moritz Müller">
<organization/>
</author>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo
ura">
<organization/>
</author>
<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
. Schmidt">
<organization/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization/>
</author>
<date year="2017" month="November"/>
</front>
<seriesInfo name="DOI" value="10.1145/3131365.3131366"/>
<refcontent>ACM 2017 Internet Measurement Conference</refcontent>
</reference>
<references title='Normative References'> <reference anchor="Moura19b" target="https://www.isi.edu/~hardaker/paper
s/2019-10-cache-me-ttls.pdf">
<front>
<title>Cache Me If You Can: Effects of DNS Time-to-Live</title>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo
ura">
<organization/>
</author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization/>
</author>
<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
. Schmidt">
<organization/>
</author>
<date month="October" year="2019"/>
</front>
<seriesInfo name="DOI" value="10.1145/3355369.3355568"/>
<refcontent>ACM 2019 Internet Measurement Conference</refcontent>
</reference>
&RFC2181; <reference anchor="IcannHedgehog" target="https://github.com/dns-stats/h
&RFC1034; edgehog">
&RFC7094; <front>
&RFC1546; <title>hedgehog</title>
&RFC1035; <author><organization></organization>
&RFC1995; </author>
&RFC5936; <date year="2021" month="May"/>
&RFC4786; </front>
&RFC1997; <refcontent>commit b136eb0</refcontent>
&RFC8499; </reference>
&RFC8782;
&RFC8783;
&RFC8955;
</references> <reference anchor="Ditl17" target="https://www.dns-oarc.net/oarc/data/di
tl/2017">
<front>
<title>2017 DITL Data</title>
<author><organization>DNS-OARC</organization>
</author>
<date year="2017" month="April"/>
</front>
</reference>
<references title='Informative References'> <reference anchor="Perlroth16" target="https://www.nytimes.com/2016/10/2
2/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/>
</author>
<date year="2016" month="October"/>
</front>
</reference>
&RFC4033; <reference anchor="VerfSrc" target="https://github.com/Woutifier/verfplo
&RFC4034; eter">
&RFC4035; <front>
&RFC4509; <title>Verfploeter Source Code</title>
&RFC8811; <author>
<reference anchor="Moura16b" target="https://www.isi.edu/~johnh/PAPERS/Moura16b. <organization/>
pdf"> </author>
<front> <date year="2019" month="May"/>
<title>Anycast vs DDoS Evaluating the November 2015 Root DNS Events.</title> </front>
<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura"> <refcontent>commit f4792dc</refcontent>
<organization></organization> </reference>
</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/Schmi
dt17a.pdf">
<front>
<title>Anycast Latency - How Many Sites Are Enough. In Proceedings of the Pa
ssive 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 Wo
rkshop 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 Chandr
asekaran">
<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/Vries17
b.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_0
1.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/Muell
er17b.pdf">
<front>
<title>Recursives in the Wild- Engineering Authoritative DNS Servers.</titl
e>
<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-1
0-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/busine
ss/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">
<organization></organization>
</author>
<date year="2018" month="November"/>
</front>
</reference>
<reference anchor="AnyTest" target="http://www.anycast-testbed.com/">
<front>
<title>Anycast Testbed</title>
<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt"
>
<organization></organization>
</author>
<date year="2018" month="December"/>
</front>
</reference>
<reference anchor="AnyBest" target="https://meetings.icann.org/en/marrakech55/sc
hedule/mon-tech/presentation-dns-service-provision-07mar16-en.pdf">
<front>
<title>Best Practices in DNS Service-Provision Architecture</title>
<author initials="B." surname="Woodcock" fullname="Bill Woodcock">
<organization></organization>
</author>
<date year="2016" month="March"/>
</front>
</reference>
<reference anchor="AnyFRoot" target="https://archive.nanog.org/meetings/nanog27/
presentations/suzanne.pdf">
<front>
<title>Anycasting f.root-serers.net</title>
<author initials="S." surname="Woolf" fullname="Suzanne Woolf">
<organization></organization>
</author>
<date year="2003" month="January"/>
</front>
</reference>
</references> <reference anchor="AnyTest" target="http://www.anycast-testbed.com/">
<front>
<title>Tangled Anycast Testbed</title>
<author><organization>Tangled</organization></author>
<date/>
</front>
</reference>
</back> <reference anchor="AnyBest" target="https://meetings.icann.org/en/marrak
ech55/schedule/mon-tech/presentation-dns-service-provision-07mar16-en.pdf">
<front>
<title>Best Practices in DNS Service-Provision Architecture</title>
<author initials="B." surname="Woodcock" fullname="Bill Woodcock">
<organization/>
</author>
<date year="2016" month="March"/>
</front>
<seriesInfo name="Version" value="1.2"/>
</reference>
<!-- ##markdown-source: <reference anchor="AnyFRoot" target="https://archive.nanog.org/meetings/
H4sIAJSt1GEAA8V963Lj1nbmfzzFHrlOWYpJStRdymRO1FK33XbfqiXHJ5Vk nanog27/presentations/suzanne.pdf">
UiC5ScICAQYAJdPtTuUd5l3mV/7lTeZJZn1rrX0BSMl9TiY1PnVsigQ29l73 <front>
O/r9ftJkTW4vzXVZ1NnEVmmT0SczLSvzJq1m1lytmnlZZQ398GDNzbtbc2ur <title>Anycasting f.root-servers.net</title>
B1vV5v0Sl5dVnaSjUWUfuov0eYE+FujTff33y9qYZFKOi3RBT5xU6bTpL8pV <author initials="S." surname="Woolf" fullname="Suzanne Woolf">
lfYnRV0u+2n8qH5lx+ViYYuJrjYcJvTRXibJV6Zu0mLyz2leFrRQU61skmTL <organization/>
ij/WzeHBwcXBYZJWNr00r4vGVoVtksfZJXb//oP5qazus2Jmvq3K1ZJ2dP8Y </author>
LuvfYFfJOG0uTVZMyyQZlxO6+NKs6n5aj7MsWWaXhv75yozTgr61Jq2qdG12 <date year="2003" month="January"/>
s6lJ89ysbb1nCHrztJ6bua0sbdf0TVOO5UNdVk1lp7X+tV7wHwYXXOJm+ugu </front>
ueTHTOw0XeVNTVe43+UmuTwRqF0mhv/p638NbZ+u+HZgrgdvB+YtwOx/EgR8 </reference>
m5UPaWHpArNxRVnRkW9f37wjKhjV+3c/mhubE2Dc7zVt0BKM3lpChK3MycHQ </references>
/zbOmvWluaqKuV2EL8sJPfL0/PDEvL2Jvl0VTUVXv3vjv1vOGavfHA3N4ak5 </references>
Ojk0JycHB/5nu0iz/NLMZPMDpp+/JaorBkW+HQY/Dcx3aTVJ723VgcBPtt78
iY/+4+31/mvCf7Vg6jO348wWY7r8dVETx6wauwGKD+/Ni/IXc3R+2IHETfqQ
1R1AXJycDs/6B62LHSx+vO3CwnwzNLsnRwd75vjguE/kfdEFR2ab6d/O9Sj1
AAS/FRbfEywssegiLYoOML4v58WWH/9ScByfnp2aq8kiq9K8WZuf0nUHLG/T
KitS0JX5aNdd+BwcXhz2T08vTr4YPkdDwOf4vH9+dnDehc/PdLj532Z1NrCT
lfutCyKGELECEDbxGBPo0G7HZeeXNpO4b7eR/zPsspUxtvDF82yhx1xgl4MJ
79IxhT9tUgj+HiBDjfn46vpweD68lI/Dg6Nj/Xh2cOE+Dk+OT8MFJ+7jxYX7
eHJxRBd8xZ+PD8/casdn56fh4jP9eH58ceE+np0fho9H7uPFyYlb7fT8glZL
Mkd1YdfHB0fuhuOw6+Owv+OTA/+c8yHviaXb8HTkxGQD1UQImTfNsr7c3398
fBwodez/KxPL/oerDy8/3u67OwfLydTdLCrzqliP07oxD7W5uSlvzcuHNF/R
Tkm1NHNr3pUPdjEiZB8eDE/Mx7JsWHu+fLBFUw/+X+yjLfljXv8SEb959cds
TBKkJI1j3g+Ix+eLbNJ0mGXbfU9Ijs0LfypJUlRY/++qDLqre8FbqP9fzdv/
+Pc8j0Ty5kpvSPf+ZLNnrriuMhJNKTZW1zanneklbEQYYOW0PzzoD4/1+9pi
T6C3ANGr67eXfKU3EMDC9aqyZJg0sHempOFJEvo7bt6/vjT7w4PBcHh8sn94
cX52fHw0kP+eJjixwnV4ll5up6c3tMFivCbr4LvykQRPsTa3WUPC9qqy5mVR
rmbzAe3HfKjKsbWwTmpTTpnmPqR1DTONpIy5GrPFFu8Xlk89L5dfQHx/OLMt
8gu7/rMI8L+cpL5PF1DhC/PDKiN7tG4hGUJ7DvydtR64DdMfrgjTvwO+CN2J
lynnKlP+XE4+D5ys+N/5aW4LRuNNdm/NC7Jf70kh3WREv2MWK5AfN3Zqi5qo
4WZV8Xc3Zb2TbGDDQ+p3BEHnum1w71zieHRlA492LtmK9faVW7RqEhBHKDsH
cx6JmtxEmGPM8y9kTGZLx5VHh2fnJ0eHA/nvMTMlgTJPacHjyxglxtwROvwj
0obRUy+J7cByeTabN0/x4vComWOfugPHe4bMp+9IF9yVy2xck81h3tnmET+a
3ffjBoc63ks2SIooih+b2erRjgb4vy1m1SDL86wos5rpbMyX7C9TcML+vGxo
0/Xw2BPaU66CIOOquM8ahcQTl7xI8/SeBOu8IMF6PSc+qdLa3qeVl67dOz4Q
HQNKRNnflpNp5S29jaWr1ZjYLZ3N6idwrlj/AkhGlEQgLVUJM6JZ8QzPRi00
/52tpsu8tFBOfdpJmU5YBryhD/2rR/IkvXB+my6XBKHfZfmu/HTP3Y6LDv90
9eQX85hesX3RDWfnz+f9Dxlg1L/72Vb3ePKLkra58UAlp+y+JL5In8DGmd71
NG+f/UW8PaT/nZ4M+L9nQxbU36+K2cFRV92+JcM7hwS9u3vTHxEZT8Lzxul4
7uDeZUPGsrW2jz2Py8WA3ID9w4ODI8d3w+E/HwwHH25ebdeSmzqMlJhdW6Jm
bPSZy66qZr6q4M++sLSl6ulLCc9Zm1ljwlBkfL/K1wYbN89qRkUHXfb65cuX
5vW7V++v37/1PwfoH1zs04/02wBXD4aHB+enF0eMgY+km6+aPK2HJ100fHz9
4aXh38yV+TYvR2m+He/K3NuRki1/HkxIYS7mZd3AAybE7D8u++OSliqa/RWx
dzqp90mXrmy9D5Mc95CWOXrantlizmCz766vzW2TTqctaN7aZRPs/c6pL9LL
aC13cvpZT97XleWIROJlRbpEfO1r2n9l49s7YifFEoOKVoPfvx9d2bXPNk61
5WjRr1sOdsGGj6h+L0XDiex4VcGCYmkMJfhTlk/6hqzWWVZYywbLkwHFL/GJ
umI1bOWL0Pi0BbPlsmecp41rn7VzzZO3bTVzt4nKL2DQL5aXz0nM09Ng2V50
0btzDbFIi5vXU/P35cpcp8WleTmdknnKZg+QeZctbL8p+28IuztfgNF/dVEr
Jz5BZbD9WAb3sViT1885HWaDTR3mfs/h3Rr/+084I8/Yvc9i7uIvxNzRycnR
6cUA/z05PQfmXo9ph9/ZycwOz7eIHIThb++u7m4JaoYvm5czczg4Hgzjizt2
J7FqPZgU9SDD6qzv5nrv70mbrrAROL2+vnr3bkPQRBR/zl/jQDe08eHZlqMw
wd+8vnuDu9Mndu+IjTbfL8nXYAGJD/u4aX9CS4Hezv6iU4Da31993JSY3YPg
HB9slVdlMx+ebjnLd+kYYVvzI4yQd/aRCDNdIg3TlHD/qtUShufPJel+O6ol
FjCuypruGNwOfufsxbohlhSNiFDG/vBg//Bwf7QiYrQ1qUSX+lhW5Si3i7qf
Ng1taDBvFvlfBJh32bjMrT/yc/BhcQPz+7YabwFMbJjXxMzkISBe+syJZxnZ
SCM+LKzobEoO0/5DWOYvOtBWezw6UBzqYzYkb+HO1s2WEzk/Aj+P7ORprgPq
Urm438jFfKo/8wBfIprCQW7suH0QOcuL7WfB17Dwx002FpXvtDn93SeX+IGE
PFkwV9V4TkQ7blYtO+bP2f4L8nMJDeVkXI7vN7bt4zynz1DGwloEUWIpZov9
BbJ393Y8PznZr0nhTFa53V+UBcF8PN9fVrYmScyGGJKU/VoPt3SH6x+c0RLD
074tWEcJwF4h3Ps09mEGTQcVXYMF2wmbJyFjngDN7epXOo8FdPLpM+cHjEgn
D8gbKGd8fAeRff7q8Kx13Hq/loUj1Rsg/n1arNJK3Ifox6Tf75t0VDcgiiQh
exB6DKsyhti4nZO9a38hdqxI2MFGnFj6Y80ab0zGAN1pOXZLPj054QmZ8NNs
tpKksguu3JSLFA4/QcDcrsnkX5hdIr69ASI2WW0m5XiFFZN6tSD8ZL8SfeI+
Wmycr2rJcVflAl/WNuzQTqdl1fCD6VFTBBTrpR2TGBn3CKJkxpKIxCpxspzk
cjoBWUBep13zNqnZvDWlS5fTHts2cPcCs0jX5pEcN6xnpmWel4+JbLTzZPo9
W4AWLQ6SVcyASqNkTyevG0PAWJKm4H03c41g0Xk5pawIJ0SwvR4BDimofGJG
NkmXy5xYBvfTRSltDBksdqx+wWrkXP68qmVdPJ6205BfnPcSQnRdEoIUZ+6h
ON3MFoTkcZqTC4oHrOkoCSLdMDZsDr1UE4Sa/kQR3zMqDGmvekA6XwvXOGpR
NnQheap3rxhWtqhX4YpLkwlAVqOcwEtLEbZDiqksyPdcriqCF0OPqZnk5CS3
BErywsrJasxUSP98+irDN5+Tv4n+6e4oor5qGy8wQmJmSIQZ6A+AskX6MVES
z1REOZOecdTpiTMJpIgl0ucpDUwT/kxQr5BOif+EkTbobfd6+H/+7X9dn+w9
RzkpSfkRLBoin7VZktvXr+xDZh/pi9bx6555nGf0xwp2D+iqXxNJhIBrsgjW
MBP7pEofldIjTh6YJ6EOkPpnOgIEHCe2HlfZSMWC/AKxfG/Xxkbearnkkw8I
/8aSR2I4Fg96JFJalhk2RjCbACm0QSxG0KSlsBGms7HC7pGLQdIJGZ1CaRPb
pFleA14BnEzUWzgdF9Ges1khVBvhkNhrJ4ew30k2hI9ivOYgNaNJGbfn7mlT
iAornGnqj0TsQNhp5sT82ADILaXTzSRYQ8irCBLLVS6MmuTIXjTlsp/bB0vH
FFG9e/fmZi/sumeqVQH6sLQwLYClixnhnhhyAVws8TkSmXfrpcoLkYSFi5oL
ZJRriDdBR4kKi3DVp0+azv78+dMnNWk+fwblbAE2JBQkiUi/qlxWGUklBnu9
SBE00FPRMeoVEUVaK5iYkulUJINIw6ZF9isvmTD4ACk2k0pS16sii3fYgxbR
n1BBgD8rO2NKE8oRYAjpzMqUCMc9mpaCBOs5jJC6MLkmEQEdiFPign9ZZRUT
2P9XrWCCVki+RCuYZ7VCsqkVDNml4xSFWV2F7/WQCqO6WU1gzk/K4uvGqKzx
GHak0+ObHjkiN9uACMwTCHbaj8XBcku7JiqcZDUcrJlhLlO5tl0gQ1cnZZGv
/8sV2lfmBcnlWVWuyK5iQcNbgkXGPEoHNs16aX0wR6XB5VY1IuZZ5WJ+wGSZ
43tiinn5yNyd0rexVcliz5t7C4TgCaTJp09YJm3mYEmykrerrV1ZFpHiu2G/
f3V33Ll3z9wX5aO39BD5xUlSPsuvxFo9lv0ZxFsNB5vpHyBLi/pRBP6/rDhQ
Q1YsOX3CG7iTtkVsQzKL2E3wWhJKza5y0RqitwTMhXpXS9jJkz3axjKznvSw
kqif0gpuC6QSicrx2HVSsix04GWZhRqdz59ZNFRgMeYIbNaAo0mKkXC8Mh4L
icOC2f1oCUgf7dEeDpw6IPKJyBurGLS0VX/glh5gW6O1m/BgdwdMGlghYkmP
80wMHNlVIhL34OgYOL1yPzdejNsF6IB3Vk4bTrLl2aiCV4ELaNkUHDqKToQ/
AYkWymEDI6pPh6oFjE4Rr5aou0oX22jUxNtLWq7VN338880zH1qX/wZqpH/z
h0P34ch9ODa//WdWN+Z/bn4KHzrX/rb5KXzYfq1/+nPXykX93wzRlPmNb/hz
1jW/c218pC+49jfT/ee5PXwTf9hyrTvbR8vIM/ThSM64iYv4lrDu9otaZ+oi
attZuhuLrtE9fvP0Nd8Qcpg9fnt6P/6s3ySfLs1XykMSm/ibnY9WDLh6ni1J
wzeP1hZmG+eQYNljIdYW0ohGeGGxe3VX7O18ThJIXicvmE3FPHLiAFKazPBV
I74zm0hf1zChRbQk/lOwaPBkzjmI6UnuE5YnLUw8Heo4SGaSprEFtDZpVzOH
UVRCg5MQSu+t1LirHrAs3kY4ZbMiz2Oi7g/rQAkvkJJMRgBJvRr9jIfTDaTb
LMS8ubFFRtqApLxGv8ixKm8JShxJJXDgWfaXlESe7SUIXLSKAz99ctV9EGix
qHfuHUvMiZ1V5GnwsZNwbJgN2MsEBRQxlFxogA6ZAdz4egartTGoV9TN9ZyN
lqwAh5qM9orO4u0ANVFwWOfMDEgO+D+0KibZqrLFBUClPAGX3KfMPrCrR2S3
m+11wz9kEnrb31ESIMdFNyAv1p9Ocp8QinfZEthmCvToAfoE2IJ0kNcfXAwh
aXkDWq+qH1H9SguzmkwReanD47HCZELgBLkkOFFRkC01dirQbx7GgXrM7DTS
09mhqkTZpzCdkh3npAAjKa2yI0dDmSzoACikM7QPgTS2ISMf17NSTurVckk2
sdmAXMY+TfCsyFaBRZSJee3s5r3EPZ60NLQxW5nEsvQNk0Zl2YlYwA73PsNj
uuYzbDqcHBllX4CQ7jxp1s3LED/Z5nMGT4jJwx/nIWMvYzwvOcoMqBQlXUx/
1OTl01nkfAlc9QUbmPBS2dxtN6QgiMOwLOCjqCNPjjmMRTGNbIintFxCBD76
/evTPTYWY58CEYmCd6wZ73RMLLqgBSSdqXYkewGdYwcDu+3oPuX+x4+tQFYk
Hpns/CPF1RXS/eIIY+Ie1RI8T4YVaYcvQdKtDSYuLJVNOWPZuPs1coMd4ZH0
bTpuvEhRYdVLKqRqipkP8kVCoafhGlQ98lHY1ZplKsBVqALbhO4hUhi40wTe
MhBo6+0AoYPaYg7ih8Mmmojpswj65tNX4+FnLP8VST2NJI0iN2qznmED2k5M
KDTd8cWRIMGLVqdqUrcs5hsPyu2+Fw6fmhl9VbBYTMg5gm8uGizILPWD/jqy
vOk3dqnpX+tiPK/KIvuVBBNvJ3GukiE4F/VUlPmfXn3kzaHcn4QjwPPafYdu
AJa3Y1+1Qst4bweJVnkiuqPc7koXxWMzAL7pFainHq9qRFCIaR6sV0xmbtMH
MHplc+B9RSo7VkesKEUKJvNsNufr0hHpvGbdM/CYwT0pkR4CK9h8s6EvYxU8
SJxXDId4XILAQIpwTRZ2TPSS1QvBwBbleJnAElIaiHe560Uara4oV0NKidVf
kSzn6xrYCpoEEdl32xcm945ol2wbBpF2zUE4gEQI6MBDvf3xwl1BM2ItF8OC
xE9YcFW6RIh1CV6Q5eJoGue7Pn/ukUePmI+L/SUaJYuByw9kZSIykbdbjWE+
IeZULauMzJCemUEkFyw/Imc0DqqBat7iea0YNkABPgko7kgbxhuH4jT8nNCZ
ZyRQG6hFNizl/CN6pDrutW3TGxFBkcHPJaR8Vz5CwvTIHpCwUxSZLWjJefog
XFiVZCGqniHS38rWvUT0W+OvVBb5ut5mi/c0/gO5m40Jv5DnSvAsdKtQkfWI
FOpIn8QHlNURG2q2auSBVmbRLbkoSyaPHGq2sRzlcK725t6+rhPv12eeg1wq
ZxKpCpJgE5GSE8jqIvxEgjG3KaxSCRZEN40rxDCyFBsYc+iVle82mErwVTIN
DfPzgoOvDbTGj+jH4nZSyGI4CdtcHnoCHrFdEmdEoJw3IHNqCYUjus/1AVkm
Kchp2I0IR21ZJQkKD+mM0kcjBSjcWOS1VnRtj0zZUAMnPo9EwmsGpYsyP+Oq
kd0cwOojyM5+ZWmJvgRx4viPhVq7pVBZYS4ODg4SLiD8HbNDV8vE8RKwbIld
gbM755pC2XZoOkKQGl9E4xONAZHgS9KHNMvZetzObIiwp9UkV8RghXIk/JGo
tBiYFyuJYrcMBLraebV02cS5j/U9B5abksh+Uret41rsWvIo4BfJ6pe8snzF
n1REOfc73RK6Uo2x9UiiMhkxxHvSTRItwSKgpv2GzZcCU8fwdy4dzjH5R847
jBqS4eq3z2YAGWfK3EVigua5g+BDSnxOgl2TY4gRYx0WaiFbqXF997fIACQ9
gBi4mBKelkPWBJAcrqPE3keWZGqGfEnHX8EWiL1HWaHMl0CBc2jbywuRJHKc
QD+PIHEVc3Tr1pzYZXQ9QWFF+otkIJnh43s+f55xHuIJIUG+UmHYOOTQwQTF
SAuCqwomZOYgiiuzy4RgwbVMDo3YCLxD2HlZjWxFIG3Zdc2ZI0VBmiN/KlQ3
8KarZjjHHZ/oFayELjnFKrUnUBd8QzAVdcgZKcUmpXS/bz/8bmzwkO5oQKl1
GczCBVJFI4J0tsgUrGSu4XSoJ8G62zk5aDUnnkbrhG2QLUJiYH4UaRiSRSQC
VkiWNKuCNVoPXisRaoLWAPDarCyDJ0DuVT5Bosvspk9IVpV4hO2Xq4oAKPtL
c/aX2RJgA9WtyEZKJMOu0xypvILoFHxztYK3Q7ZsL/Z1emr1w6ee2XJWpcs5
bMUEEgq+zN6m+PRmoaKubTKJ0jDERfAPEjEmW1ahhgjU53raodrNBnbAu004
8OERv+f8xi2ecOw0+fCBuDNkCKcwqUQGZzDcIFuI2jz82TsUn48EVp77oAOh
uVghyMbEuXESlsaM36Xm+iPX0hEnghi6paRFC96DUY3pHBmT/Pf/RjSreTzL
vEq2JdyuOmW3FJGC2R8NMTTc9KrrStd/TJxFaTpITPO6TIg67VYkqv+H2CYv
qxV32Fub40ksk/Qdc4+5iJVlTlTPRWmlsy5YCirMomjZIOn3/wc7ayR4gRnk
UNeidnYGRb5j7t7ciOP3mKIyKiNcyOnF7CwLsUy2hgtrV2awyH6BQyoo3nf7
ING5WiIRh1IMEhIJqhR7Bj3ui/JBQ2tylSx07I+wVaA7ZP3pT3+6NO9evrwx
d+/N7Xfvf9q/eXl7/fH1i5fm48vbH9+gXBqnbqPj6zpEr9UJjcIkrSIS5C0F
Z95JcOQr8sY8L29CXATpwjoRY4P9NPqo9ElHjxP/bh9+EQ2RHF6a9wiUZb+y
EpfAC9QPWw1kupI0RHUHG3bODpSBBGq3s4Zu1s+ERH7qaNPC778VIWT/ueFL
CGPhqkT33hO72xnSI/gpwtFmG0c/EcmFS6QCQuyFObKLwM7MaMkz0dSt3+2j
hDzpqPAG2FMVHk+CVczmi8Z02P6RUM6Lbz/gGUQT4/s1E2qzyiTN2mPdLeUT
RSqZV0iC+6BKBQFePsmRoSt5MzWcqHWyg6t2WmqFbAWmAy6NsCGnYaTuW4sK
MpdvDnFTDM7p4ZSWbT9iq2k6biB2Qre3M70T3iZqYfAE1EO3KBxyUhR75Bbg
BE3ZkATyWAswZFsTAjHN179qJWi1LQXFAVt//6YcZ+AosdPmuPQBeNkVF0pq
MIQnxDxKmEr7hKUlg8jsfry729vrmXADewKcB8lba9ICBA2OhyY80cFLEhir
fsaDr4+IfV8xOYeH9OsyhaJJWsEMOYM+G4ugPFgLBhozPIp839cfHo736V+n
ictGLNOsqtVkdna5qxGRMp4OTtW9nLiCteiEHLr7NO5Ne/e9/LOvUn7QMmWz
64sEe2bneof+9Qr/+mGHMbHzZmfPF5F13MSzwcV93O8H7kMIJfoKHJr4Zpio
/A86qsEuNTvgFx0ekvPptLD6Hon6HlpHsCNrf+DH7cCkzEKgK1jyGvLx9YJa
4RKpWBIrUSMjgTH+4iLlSoJtzBN4/No7aqkvNNqMeUtIXurEieQ4jHQeSL7n
ROjEsCWmVrOj2CTGJ1yfckEEl9Wli7uSue0MsVYwAc/6QRqfexI0OTriP4fH
xxHDBdc9XwvhL+wEkzaIjdiCuO65ZZIqMAl7k2zMO84+OugfHS5At0ENi1XE
OZNXf/wjm0kstzNQQwFOceFhk02RupHiLRIy96KkXfFXm6hQF8THZxtcxSpn
fWBOEpDUXAdJaRWOVN9petT5oa18bEd2afEc2ZtyK4Ngyc/haT5m9xWKea05
2WRIDcTCUBA7QTYs+x9liLlyTMHt09cPIRo965a6yRIirNn0yiWo6SgtKLIt
er8MNi6A0RK/hpuPftelBE2EFaN90Qod/sjUlmU7NNIoSTD6xFNjyooou8fK
iqOsjK52yWEw/APd7rrwtZRuOdOHtlcwOZNNs+c8UX8kFEzeRkjvcUVwx3pa
lnk2lgqHbWZUIrobuWNcXdjHsCtJ+K0Z81YFBemIsGvSrImz8EjuEhezG+xS
Z3SeerVQvSHlniILUS/gIlaM+knCtC8WJkOAO7/i4w98MNtEdcrtvZBUEo+b
mGy6yqUWWRkGu4tKYhmnGBKRc2KJayT65dQ10XRqJNoZGDFWjzBTMA925Fpt
5oZIiAsI02WrCUJSv88l69qmqNsJcpOjqIxYYlrFWmxB/kvrItpG4JwWJRKp
JTPvc/4tZz3fUKEJUksc3x+eHGzxTFVXsG3CoRe4Uo/kvRDKyY/WJqIktyK+
6tA96ggSASaPfFqZVEBc2wjz1RnZ5MbMy2W/IFjBvm7TTEdcRNkOQr8EC3z5
oIb44Nx1aU96FTmO010SBJyIktQYLruVBM83fbanPn2Ke1qZNK6Ej1qY4Fqe
hUTdww+Cx4BX52BoqYFKz1qjsOmkkwUO+4YgaerYemUfJ2Vm9l5SFlK9bOyR
P9CLdkNUlmjNpMZoK67NRqp1ylFRyDDSdMB3FMWYIgYHK19Qm9Srkat12Gb4
SoSm4KFzNfslXG8d9vE4z3JL5JMytJh5UURO0o7OnSMXTIj20z1ZFEKWEVZJ
5CpJ1mNbkFFRJpH0/mWpaZTI4fNVA9F64vKStCAnJJlkBBKsTdTHeSUzXaFR
UMP4MUJIE/KYjpJjMihq3sRo7JRMSGzXmii8K0PpDvbPdbecXHGPBQ3IM3lU
RHgWEwmqE1C4RZZUg0xbWoXz9rqn9XT16ZOb+/L5MzmhZDGRSp4o2fgsIm2a
ZLp0mzggIVGVVrQZWEIpW1utbpieupxoNFjaoq/dsU1Z5s7sjZtnd30ANSF0
/YN23P6Ta/PxnTEoeBIuREJUVbY0qkTAZrEL4AVJ7MAIGfFijUJpDihFnbca
mXflX2kSitbh0JidOVE+YujkTXDzE4fegELL8eAcUG9cvBzMTi4UXTDNfoni
wAvsSOIiHIDsSlfpVlBqQa15k4jvrQVoKnBJ2DJiWw3IrPm85eXqruCIQYhh
GT6IO4c6GKyS0djAlYIPWUpSifMVripIe56u335IiCJK/F341ih1233hlWAd
z5SaCWIEeAhTtrLskr33QHPeCaw5mJE1LYSQmElCEIls+HEjSW8Rww61aTGJ
GKMtIrnEIAE1bwA6KFO6ZrShBAn2P0po57H0xh4anSNFSLh6m6WLzOy+fX21
pyOZalKAMzSDmN03V39iwzkCnmwUAhQ9B06Rx7FsFQOiBplGGGv7h8deiDg1
OiKZeW9K0UtOyaqbjUcafmSoIWUPR+LdQLxCUxr2JWunDgOsMRgAeSpNSxy4
9IF8idnBuOlFnWkg3CKoeqaapGUKgZnLiFNQIsp2P+Ot1AKkuA5PD5yIwoF4
mPRUEJLA5zakqddOvtwfjvIGPpHvlzpDnBeHJ+wwIjxAvET1JYmTdP21V3/J
LkYx9A+O+8PDXhjtUNsGglQGQZCnRKdskbhSrhrPyflwcPoHlwhzW2cAPGp9
FOcD1cbCHrFf1zfsxFhCZ4xZRaqCJQ/BwVdJgYzHaESyf62Vfw2ZRD60kriH
P5Q58aBG2gPsna6gnRB1mwgF/JnOcfwHorVYAkEkIgkQR3+D/tLH1fNs2kTq
i/V7gtDkZtguFLJ0jNarW9J0RLvLytVQozEPi2j5BJEG7YCLldPJgwuOxT1q
IbDQwVgifVcTEbUi0KLnsHYY9o9glrItzDzqxYq0hCOi0XG8XWkzsi2tjXgj
rzQPaZ5NVNkn0eEFkeP173q2V0Xk28UPQdolfUzXXdpkx40dQwhgxA3L2BAi
tr23Rhq26DytkKoWvDLdOBuEV+g0N7ZCOKO1QjSmm4CkQdKywwxtjvh8ukZV
e98ZlU78EWOsXJwgoBn4SaI+0Hy9EU9hO1a2Ia6hGDBxPC9x8bxQVRYiNiLI
gKi2BobfxDX4TrckLExaeJBRGWb3KlIpI3RicaHaHbd99kQIsfpNyFJJAXuH
F98itqLnpIiTQ5BvyLsYz0Q277t5OJ4Mv3HsmOO4T7aNpiTiJV+tbbr4jgja
SaB87SuGQNojsjemmbY6h4Vk+plJ58gYQESSh6lpoeNL8WjYDVDXoefKrlBF
EZKjz7jXN1FfARs+I6uu5yibzeA2knGGumgJd7ET5KyhpBUAkLgiMvlLVMcg
0uD1SPSU0NDgBy1IoziYXIukzXBwaO5Gy4g5Xpd3REPSefnpU5jNgwdj6K7i
MG2lWNvV7M4WfjKTjac3UpoK+o53/UfTinaQX/EAMT5LJbWbcR9bzVpC9kt4
yLgxVuuTlCsF7GpRwwAleDZyGbetu8ox9YE2+iqj3XprzbkVQnJsVnPciKtB
fXmDs9BiN58jGpwvc62zA/OjLxbsaS3SExmeODH4de1Jna2mUAL5+vZDwlvq
ls9sWJ+SIGv3K0Yl04ks6Uop2Il12Tsxkbhb2VWuL2uX4I+bcrYkozyF+cRq
NDX/H//h46vLH27S6uDwH/9Jui2SVrcFi/rIed5eW6K+utKSwJUNHJkmsdXr
UduNFRHkjrRWw4woJGCTxJjcJR9lVYzjgSvqX7oCI2HxPTx8Jf3cSQCCRtMk
xAErlzYn5lnhog3eueF4PxwRV3inRrLLhPmcmn1wKYp35cNAhiy2Jca3ikrL
kWGBRtSQ0NoeSDoqe/TF4bsjorjHbNLMe+b6w48kAZvxAKnBlF8ZkvqYguYo
5pjMUka8zoJTxB7KVrEjhoOv0B1wF8pSpyb1YnQHH7WO4cYGkY/hqZnXi+wI
5k/IaB1WcZkkfyVRZah43M5zMyC12ATkBBJmGLHNxd9f3ap1iDNwdz4mZYXI
FzFkNpuPeHCDxppc3D02O2WDGbe8qVqnZbgO2zFFaJqStF5VLtNZGsk6YsPE
eDMz07w+XiPAaRI4k+uoiNebjNil7/g1XoI4oSLqkocKTDPUx+HGVkuUPP5V
Xj4i4J8Y7ca6OEGjGT325v1dmGNgduXX8+EQ9oT8cXZ+GP9xxN4Kl1TSapHm
Z1iJc5iTSlUDnmWdaDUfECydAaXaxsT5DD42WcmIw9P+uYadvQQhZn4NDbic
vVjnZBmU2WeV5XEDRCdXoVZQshuxeThSDW6Z8rn7ENm3uqyQDxqtGVG0XLHS
qLPcTmSN/BXH4Ai/SxGESsDRiX2vuDGTldU2+JUIjSnhIcpHsFbkYRyQb1r+
QJ6QbAa02oachBV9LS5Th3eWexHUgFDJLwBHyPvHAI8SNUlL3JiaOKrdIeDK
UuugTLPA6YAWF0sJMLxcpuNoqwoTALNIpzah3nOxcVg5nFIVaUh2MhttnsWj
CjaORbiNiFOvwqmckqxGfA8OYhzxlFuymkxz39KI+gO/W0KQ71DR4QCZhPxe
F65Bw4lx2SGXvUhEAE5tbqcsJhVrXOJSrXRKQ+Fw6CLTARsSQmFBy967mBGg
2IQD6K5tQ/JGzzlwG3a6736by0MZp2mI6PLWO/BdJ2KX8DHE0nK/8DAgr1y5
k8ZOoQB80NGL9qSE8V63Yu26KbSW8miW0tU2cnVv1aa4JEJ3lS6zSc5FRxMr
iUqhyrAi2RjlhInSMyqonrC9HpXlvRbfTchxQKiDDx57LrNVxgOz1ZASDe4B
gkiEOAs+8OBrTLgFjKlpCZAq7Xb5iWQuh600ITwm94E4tMfjsTKSZz3Xc44x
G+T6kaVJvqYoEZd/hWp3yVKpYmXTVt+YgGM72DsG2lpDyY3gikZ3Ko6LkgDU
rGgSlIiTShrk02So2n9Rv2474JLsOqraV0W8H+k8ngZUlxzG8yJor5dIQtJX
w0mMQBvdaxepdPZp3TbXCOLvysbP+5FZUFGPazzyyQanGotwXh0FbN1EBxfa
9IxU/bqrolFtUcc0q6GEYwQcGCiiRrRI0Lv+w7rTBtwdTxL2YbWflfWBxDxV
oHFRHFStF2V+Z86V4Uo+RhlPJgrV2DU9nghc79w+tkfqjKI11IJvGqIal4jV
JSEA0HbTLiJ1ie6T8PI8nlKAnekgZRSGInC10liQ5TJpzQckzzjjmNastZ1S
HlIVaHXSPgGuA2CvK0odsgYKzZPkoyQnB2bh5+XolAbE+91gh7Uz90PFBNnf
NRHFCJkrGT4llVqbC43FQbdcHkP7nKYV34xyRCcdzjlkGJVHjPVcjG9V37UO
15JUPQohEavl5LhrK4tjVrEzDkl04ykRbwMg02oL8PfikTHxDAKXwUxckx+f
ykxac/t0YoUv2/AzGXQmEUcyS+hVmbyEZoCbd87n8w14A3MLa4zLn2WEIM9Q
shN9ZQGPFkg6zltWyak+fdI3IcBIFVTzTMJoLGe6YOHPNyVcH5LKSsyMtLEY
K4JiUt9Z7rF1AVlelH7QX+JL1bod7TpfCZJMg1W02wfklMmjpP0K2BMNg3JT
HNtPLLp6MtvbII+U5oP245E4zTRan8ZZU10ghFv09Q+t4QICMO1UZ6+kNW2j
1WvmqneUh1xM2z1G5LJOtvC9TtEklfA8T9TRrFz419ocCb8n4cp2kOurrAKD
ccWPRnAzbflDvb8W4nDpXLv3DoK1Xz4WKjKTR6340v5GlTxl5WuJQTf83rW/
MnGDds9dynTlCpBT960wQJ5NbZTA4qk0WaH8HbJmHeRFlalZu68PkX+sEcuC
EcDMtqwzGIFO2CeD1Zp7EVginBiia3i+vMDu0cFBzYOjhshAmd3z02P5JmrB
8/vgBYYn9xKa5gU6LW4Sj52YVlBcWvuiysiJVZubl+BVD88HZwtWU+eLOsiB
s5M/ZEiOuRt0C+dHcu3hkGsmgZM3Ad58fhR8i1x0WZGs0PZCCBV1jmSw8FMN
GOigCSN1WvUpLATsL420l2MR4F8Vp47CieuBJP7W7rVTQaUHuHbhrwYWa94+
TnSGVE/hirLHiAxnMpeYxSXRM0KCdnIp8QtMur+q+1d9N5AnxAEwZBgtSFyb
KXPXmCp0gT1ZfFcaKDnxIUafkPiUW1MWJOrnKEugS/e2I8PVAlbliKsSy5bS
gWSBNydMMa2IKaoVc/3AtFSfoNNTY6tK1K/gngmf3bWya/d7aEGudRYediFP
D4XEvIrXrkhOSJWWWCKumN/bkXxeb7I5YeF2oZURdSsx5WeA6CBKfiJ7LduS
dRiVjQohpPKl2QrTKAQNLqdf5ioPgiXHlgm7rGL8Sd1lVCMbFD38rtvMvVuh
Ybuaiy1ASPNSZ0SgyIRhiQYjZ65Ei/SczOFVnMoPQw9r3pO0XKzjQ5DSloNJ
FILN1CAY2GnuGqisbFZ1j9t8WPBKuQ6knVAaoCnH8Q9q1eyxdRojhUfPovlL
YhWafRJ2kEGBdW+DCujRe27wQBgiWkZtzNgcLwKPoO8d4AW/wmAT22KLpJk0
8S8kpyMyCm0GiN8oi912KM0nxOc2X7rmMbC+OKGxsQmylzXV6jPtsl6RGnRR
vx5Xq9GICdnVHrtpoixESyFdK3ZfiDhJ64gPYwyEvEwnJ4bhFLzAqvC1gr1o
z6HaQtYXcmKWqb2CG8kS93bZkASDpw5CkIlVqgVAN0werZqyejWZWDeVwlF+
JvM9oskQ6ROQeAINgH4dnaHt9A7kHZaSbXUMK+YWkYWvzCdDPi5jSBelaPQs
jKCUCTUq8594FjeZMpg1Xe6ijCEZry+rK1lKSS0DoDVh/9VPC+F117KtTNth
1ZVV5hc+uWLyvaJ/9pzvDE6oYRlzAMj11nuwMe+K1yRig3yByk3btbVtG4HG
5xeYyQnd4/vcyUQN6dIaa/IuyeWnxzC0tw4LmTtBIBm9rMgWq4XDolAD0w7c
Blvo9Dey2yHnEBSUFEieLbJGYg0Zx4IWrFhm4jL+bgTOp2k2plz1XO6NmyYk
tCE5O9C8C3KQaEARJkeYXHAANkkFgeJ6Avp9SHKtMmq/SZ7ndXSmOoNtXEUr
gfB9qzGLWwIekf/QsBvCQGRGT6diVE8zDgayQ62T2dzUuqwKRRQkD1BAKJIm
iaJpGmh32Wqt99DGx8gAR6O+FBLmPkpixJjvtW3oqNs7jSx1ofop5ITMF8AC
c7pNx+JK4NCc9wwKsOhph8f8MybMapcBL+E0BkKxRCd8YD2Ee4XGJDwkZRs7
aBdRKN56FFok0mn4xQra0U3c0WOvvYef2OZbR42ufF3NAVtnSb7Sgdk1Qgle
5l2yDxDCcjKR3V0os8tEFviJ+FEdlBQgjMe0hqAab2BBw7El7wuv0NgTswYv
neNlOPsNf3zmWgFiU+HGf5ZWuRn5tzthFBOv0MLjhMyOotbZ0mJAyWwDP7YC
1rpTTg7DGivyjreb9DOHExVvjuvAQ5Rd87hYgtdVp9DpnO56qMDipPy4XPrW
StGMEtK7ktKep2kz9iF3A70IRkB4Ri2bPZ3V2cUuN5mg5R8/y/kwYVv9RNeV
ItaeUMmPHCWSGMtWBcKJPug+MuAepOEs6KuFvsRe9XHbSw5inbO+brAzQvm1
hqTog7zPXr3RHiZ1zPFCZ3Iw3ZftIPYKEp5HpaqA5dkKntY6gwPFhtW+4NQ0
5Kzn1tdZxNsVRuan4NSsWtwTXE0NGxNxgMZNOOH2O7cPNw7b4zKAGoC+2odq
ZIIPvHDJ5T0MMKBOr3HMoaMfsPgoAFmaPHhGhdOzztfX8KaYexMZqtdS0lMe
rk8IpwM+ZigbeupFCT0oDR4lG2hWlsj88IxSQqXhIXCYYZ/1VOandV2OM3aH
9WhgKLE+tXyzsn03soQFPmSBDCaXMf1uoBAwLwwnGGOmA7Yh78pVg36qcCx/
iKue2QJ2fjWH4GwlHYx57pyaKFol5nBUO8GIUgm/chEMP9eK1smmzojhNnJ9
pwM6edQ7NMFKaiEGtO47yrwdNBUWJDMj09KAlskYvcoAsfPTKHbuqMLtnWty
lPwVdtK4AGFBfz4TPn/rjAvFsQzEtb9kUJyVbiRnJMeFTPIUVrOJH/fu5S93
HPCAC7a9eh3kiOtcO/QnEtyTXr149V0EXiVAoX1Xe4bHbXTY4PUH3yJOC6jC
6XCb6BXYOHK2Lq9sn9SBg/gWQRBMxjL19uW1VkYcHxwdEeu4z8fSLc2fT/zn
kwOedJvV7W6BVCdQEtF7LeOVp+x1XK2XTZh9wz761EUBGNRfs0fyw8u/1/Ga
g9AbzL5eXJnFJ2cY+f4HhbQWoGFB9XkT7/M60eOD1VJ6yKS3hSacqkx5moJ1
uxx0lL4G4UMuKioseJw70znRB+rTojhpTyc0rn1lJdrxSpjEQjF6Mk6ySU/o
xLLd3DoI92GrUkVuoChbQwxFAiW+YDyiY4CFLSbdVDTIQBvAdQbWISzDOtk9
Phczc08SCowdWuBrZxtyXMFlwPyk3awKr71wE1RleJbXK4NxTovEW9NXfnXH
L/rSUaLEIW9mr4sWzS4qbpq5bckY2VLCT44x/65t8m0qqg4zQqlypM03qXDM
LkwUpW1Fne1FOVGZ6NoBfGFk8iiz8rZNyCNqkFx/VB3nmaHnxo1x30CLfEEf
bm4Cm1w+zt8Xx3F3R67t8ytRsvEOapBiYve37+7wN+HCqB6A4R3p2woWEhHx
xcEfZJK2O5O8Gs1E6yd4tYtLe9N2e2rkDulWcvpIypv2DuW9HmkkypL4yf5R
zIMB59wM2YKAAEBevxJp5Id6U0u/u91XtHPuidviXJFuOyjF/I6X6nK0L7I4
fTCuTU1KNol3Obb5C2p6rLeZXhv7D/dy5FmS4k3JgdZOOETs3kwcAQEMQZIH
bQrDuGlQ3Ye6lwpJPEssSVTFyPABMePRRi7xAWTvqlpCvNVKpPAGiP22L81r
mWiyYawRhVWbwJmXhUp1v1s+SsLVWEpYgR2JohUKf/lQBBVKIW/ozMxOx2wi
BppWecTiLxbcaQ5JS8K+xbnuR7yBDILMszBmGXAgFehiltjIcIbqJFEKtIYf
GIZwSit74ZsTXAk9Agdac1LmBI6kc70buMClYTo0Iw4Rsz3gfENQ1iL9hcNW
hIttytoJGvFEjEm+MreIhcGx2URJ/LYll92spUyU3SKXdtl4h1xTJtubnTgC
B65TWummvaUOAHxJoiZeIpQEq0uYmikx2URnltTuEM7olAw16K4tM66P45OA
ufhVatO4ODDUNUnBihsGEIrLtVaQabMdwQ4vIQzvDYymRSCwJRX48fQHYrpx
lEnEpt2oR9rxSchii6SIImysqHTkjPp9LbDJ+CeFTVxK0PJLt9RzuLEzqEfi
9Llze8kwPTo5OTR98/ZGZsp8ZT5U2UM6Xm+8UIBXIENYjBZUJ1b3DQ/Xq7Rb
H8udXpwdIaromOJRR/Ay0+98t1ogRZzN5k2nJKve2Vjq/PD8INpZh4JdbzLh
w/D7GoSmMIGLSGmph5A2INiJGGsohXnOpvUQzFymqOPdczRjNSMW18lS1yeD
5E30O5fXIx3DKbCKK5/ca110A6N1qAlvWtNaXEWwCIyZbSSVtcDsi0nLPpd+
DOA0HozrRwjjh7bjAm9UXoL2+urd1e/IArV4+UqpgKFbGdnAwfDwlBhkjfGk
EY1cjZHLyDGoQsaWb77NLdV3U7p4mc6m7bxOFmN2fgkVNPJWh1BiovE3N5LI
Bzc33oMpDa/QHDr1CMa/f4NHBjEjFThzVEhLbaorZo5XHztQSiTa/NUTb5OW
3/Rl2S/C67Ll+7dAxa/m7X/8O6rf9Ms3RPk/2Uz/uub3/tJX5jsYvznxhf7y
PX35XVotzA+rDK/V0K8/ZDB3+3c/W26DNC9Kv/JVdl/i5dR06U9WQcEdd6z/
ZO4xT9/zLwSsat//PyExpR0kLOvIw+BOKp63K8TPjRbmZpXi1cu8W+Ko70tr
rugiEmp3//G/F6n5Nn0gI5Mk4X350Eu+L+eFeUNPw5vo3tL3qc3NbYOv6eYf
cHrawd1qjZcdchzntiHXrDA/Igt3T5fk5L8mNxjf5wZM3ZJHUhF8sM00z3qK
sYUkeH3QVvud+T2C5Ba//0Aiv2bzYxffDQ+O99hBrjlDxi+z7EFORYBzAONJ
6IHWJyE2wZhpnnoXKzQ5BIMOXvTVCapSL8WxeXd9zYyMmNz7q4/XUSoFwy30
7a2uL5ztGPdORscxPRcXTvRdBdOVmscz8tZ4vCvSwqUf9QczlcC04tqp+AW1
g+T/AjzPtJ4jmQAA
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank the reviewers of this document who offered
valuable suggestions as well as comments at the IETF DNSOP
session (IETF 104): <contact fullname="Duane Wessels"/>, <contact fullname="Joe
Abley"/>, <contact fullname="Toema Gavrichenkov"/>,
<contact fullname="John Levine"/>, <contact fullname="Michael StJohns"/>, <conta
ct fullname="Kristof Tuyteleers"/>, <contact fullname="Stefan Ubbink"/>, <contac
t fullname="Klaus
Darilion"/>, and <contact fullname="Samir Jafferali"/>.</t>
<t>Additionally, 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.</t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>This document is a summary of the main considerations of six research
papers written by the authors and the following people who contributed sub
stantially to the content and should be considered coauthors; this document woul
d not
have been possible without their hard work:</t>
<ul spacing="normal">
<li><t><contact fullname="Ricardo de O. Schmidt"/></t></li>
<li><t><contact fullname="Wouter B. de Vries"/></t></li>
<li><t><contact fullname="Moritz Mueller"/></t></li>
<li><t><contact fullname="Lan Wei"/></t></li>
<li><t><contact fullname="Cristian Hesselman"/></t></li>
<li><t><contact fullname="Jan Harm Kuipers"/></t></li>
<li><t><contact fullname="Pieter-Tjerk de Boer"/></t></li>
<li><t><contact fullname="Aiko Pras"/></t></li>
</ul>
</section>
</back>
</rfc> </rfc>
 End of changes. 145 change blocks. 
1148 lines changed or deleted 866 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/