<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.32 --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC7094 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7094.xml">
<!ENTITY RFC1546 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1546.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1995 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml">
<!ENTITY RFC5936 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml">
<!ENTITY RFC4786 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml">
<!ENTITY RFC1997 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!ENTITY RFC8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml">
<!ENTITY RFC8782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8782.xml">
<!ENTITY RFC8783 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml">
<!ENTITY RFC8955 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"> nbsp    "&#160;">
  <!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"> zwsp   "&#8203;">
  <!ENTITY RFC4034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"> nbhy   "&#8209;">
  <!ENTITY RFC4035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4509 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml">
<!ENTITY RFC8811 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8811.xml"> wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-moura-dnsop-authoritative-recommendations-11" category="info"> number="9199" submissionType="independent" category="info" obsoletes="" updates="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"
version="3">

  <front>
    <title abbrev="Considerations-Large-Auth-DNS-Ops">Considerations abbrev="Considerations for Large Auth DNS Ops">Considerations for Large Authoritative DNS Servers Server Operators</title>
    <seriesInfo name="RFC" value="9199"/>
    <author initials="G.C.M." initials="G." surname="Moura" fullname="Giovane C. M. Moura">
      <organization>SIDN Labs/TU Delft</organization>
      <address>
        <postal>
          <street>Meander 501</street>
          <city>Arnhem</city>
          <code>6825 MD</code>
          <country>NL</country>
          <country>Netherlands</country>
        </postal>
        <phone>+31 26 352 5500</phone>
        <email>giovane.moura@sidn.nl</email>
      </address>
    </author>
    <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization>USC/Information Sciences Institute</organization>
      <address>
        <postal>
          <street>PO Box 382</street>
          <city>Davis</city>
	  <region>CA</region>
          <code>95617-0382</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 (530) 404-0099</phone>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization>USC/Information Sciences Institute</organization>
      <address>
        <postal>
          <street>4676 Admiralty Way</street>
          <city>Marina Del Rey</city>
	  <region>CA</region>
          <code>90292-6695</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 (310) 448-8708</phone>
        <email>johnh@isi.edu</email>
      </address>
    </author>
    <author initials="M." surname="Davids" fullname="Marco Davids">
      <organization>SIDN Labs</organization>
      <address>
        <postal>
          <street>Meander 501</street>
          <city>Arnhem</city>
          <code>6825 MD</code>
          <country>NL</country>
          <country>Netherlands</country>
        </postal>
        <phone>+31 26 352 5500</phone>
        <email>marco.davids@sidn.nl</email>
      </address>
    </author>
    <date year="2022" month="January" day="04"/> month="March"/>
    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <workgroup></workgroup>

<keyword>Routing</keyword>
<keyword>DNS</keyword>
<keyword>Anycast</keyword>
<keyword>Domain</keyword>
<keyword>Name</keyword>
<keyword>System</keyword>
<keyword>BGP</keyword>

    <abstract>
      <t>Recent research work has explored the deployment characteristics and
configuration of the Domain Name System (DNS).  This document
summarizes the conclusions from these research efforts and offers
specific, tangible considerations or advice to authoritative DNS
server operators.  Authoritative server operators may wish to  follow
these considerations to improve their DNS services.</t>
      <t>It is possible that the results presented in this document could be
applicable in a wider context than just the DNS protocol,
as some of the results may generically apply to
any stateless/short-duration, stateless/short-duration anycasted service.</t>
      <t>This document is not an IETF consensus document: it is published for
informational purposes.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document summarizes recent research work that explored the
deployed DNS configurations and offers derived, specific specific, tangible
advice to DNS authoritative server operators (DNS operators (referred to as "DNS operators"
hereafter). The considerations (C1--C5) (<xref target="considerations" format="none">C1-C6</xref>) presented in this document are
backed by peer-reviewed research works, research, which used wide-scale Internet
measurements to draw their conclusions. This document summarizes the
research results and describes the resulting key engineering options.
In each section, it points readers are pointed to the pertinent publications where
additional details are presented.</t>
      <t>These considerations are designed for operators of "large"
authoritative DNS servers. In servers, which, in this context, "large" authoritative are servers refers to those with a significant global user population, like top-level domain (TLD) operators, run by either a single operator or
multiple operators.  Typically  Typically, these networks are deployed on wide
anycast networks <xref target="RFC1546"/><xref target="AnyBest"/>. target="RFC1546" format="default"/> <xref target="AnyBest" format="default"/>.
These considerations may not be
appropriate for smaller domains, such as those used by an organization
with users in one unicast network, network or in one a single city or region, where
operational goals such as uniform, global low latency are less
required.</t>
      <t>It is possible that the results presented in this document could be
applicable in a wider context than just the DNS protocol, as some of
the results may generically apply to any stateless/short-duration, stateless/short-duration
anycasted service. Because the conclusions of the reviewed studies
don't measure smaller networks, the wording in this document
concentrates solely on disusing discussing large-scale DNS authoritative services
only.</t> services.</t>
      <t>This document is not an IETF consensus document: it is published for
informational purposes.</t>
    </section>
    <section anchor="background" title="Background"> numbered="true" toc="default">
      <name>Background</name>
      <t>The DNS has main two main types of DNS servers: authoritative servers and
recursive resolvers, shown by a representational deployment model in
<xref target="recuath"/>. target="recuath" format="default"/>.  An authoritative server (shown as AT1--AT4 AT1-AT4 in
<xref target="recuath"/>) target="recuath" format="default"/>) knows the content of a DNS zone, zone and is responsible for
answering queries about that zone.  It runs using local (possibly
automatically updated) copies of the zone and does not need to query
other servers <xref target="RFC2181"/> target="RFC2181" format="default"/> in order to answer requests. A recursive
resolver (Re1--Re3) (Re1-Re3) is a server that iteratively queries authoritative
and other servers to answer queries received from client requests
<xref target="RFC1034"/>. target="RFC1034" format="default"/>. A client typically employs a software library called a stub
resolver (stub "stub
resolver" ("stub" in <xref target="recuath"/>) target="recuath" format="default"/>) to issue its query to the upstream
recursive resolvers <xref target="RFC1034"/>.</t> target="RFC1034" format="default"/>.</t>
      <figure title="Relationship anchor="recuath">
        <name>Relationship between recursive resolvers Recursive Resolvers (Re) and authoritative name servers (ATn)" anchor="recuath"><artwork><![CDATA[ Authoritative Name Servers (ATn)</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        +-----+  +-----+  +-----+  +-----+
        | AT1 |  | AT2 |  | AT3 |  | AT4 |
        +-----+  +-----+  +-----+  +-----+
          ^         ^        ^        ^
          |         |        |        |
          |      +-----+     |        |
          +------| Re1 |----+|        |
          |      +-----+              |
          |         ^                 |
          |         |                 |
          |      +----+   +----+      |
          +------|Re2 |   |Re3 |------+
                 +----+   +----+
                   ^          ^
                   |          |
                   | +------+ |
                   +-| stub |-+
                     +------+
]]></artwork></figure>
]]></artwork>
      </figure>
      <t>DNS queries issued by a client contribute to a user's perceived
perceived latency and affect the user experience <xref target="Singla2014"/> target="Singla2014" format="default"/> depending
on how long it takes for responses to be returned.  The DNS system has
been subject to repeated Denial of Service Denial-of-Service (DoS) attacks (for example,
in November 2015 <xref target="Moura16b"/>) target="Moura16b" format="default"/>) in order to specifically degrade the user
experience.</t>
      <t>To reduce latency and improve resiliency against DoS attacks, the DNS
uses several types of service replication. Replication at the
authoritative server level can be achieved with (i) the following:
      </t>
      <ol spacing="normal" type="i">
<li> the deployment of
multiple servers for the same zone <xref target="RFC1035"/> (AT1---AT4 target="RFC1035" format="default"/> (AT1-AT4 in <xref target="recuath"/>), (ii) target="recuath" format="default"/>);
</li>
<li> the use of IP anycast
<xref target="RFC1546"/><xref target="RFC4786"/><xref target="RFC7094"/> 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
"anycast instance" <xref target="RFC8499"/>) target="RFC8499" format="default"/>); and (iii)
</li>
<li> the use of load balancers to
support multiple servers inside a single (potentially anycasted)
instance. As a consequence, there are many possible ways an
authoritative DNS provider can engineer its production authoritative
server network, network with multiple viable choices choices, and no there is not necessarily a single
optimal design.</t> design.</li>
</ol>
    </section>
    <section anchor="considerations" title="Considerations"> numbered="true" toc="default">
      <name>Considerations</name>
      <t>In the next sections sections, we cover the specific consideration (C1--C6) considerations (<xref target="considerations" format="none">C1-C6</xref>) for
conclusions drawn within the academic papers about large authoritative
DNS server operators.  These considerations are conclusions reached
from academic works work that authoritative server operators may wish to
consider in order to improve their DNS service.  Each consideration
offers different improvements that may impact service latency,
routing, anycast deployment, and defensive strategies strategies, for example.</t>
      <section anchor="c1" title="C1: numbered="true" toc="default">
        <name>C1: Deploy anycast Anycast in every authoritative server Every Authoritative Server to enhance distribution Enhance Distribution and latency"> Latency</name>
        <section anchor="research-background" title="Research background"> numbered="true" toc="default">
          <name>Research Background</name>
          <t>Authoritative DNS server operators announce their service using NS
records<xref target="RFC1034"/>.
records <xref target="RFC1034" format="default"/>. Different authoritative servers for a given zone
should return the same content; typically typically, they stay synchronized using
DNS zone transfers (AXFR<xref target="RFC5936"/> (authoritative transfer (AXFR) <xref target="RFC5936" format="default"/> and IXFR<xref target="RFC1995"/>), incremental zone transfer (IXFR) <xref target="RFC1995" format="default"/>), coordinating
the zone data they all return to their clients.</t>
          <t>As discussed above, the DNS heavily relies upon replication to support
high reliability, ensure capacity capacity, and to reduce latency <xref target="Moura16b"/>. target="Moura16b" format="default"/>.
The DNS has two complementary mechanisms for service replication:
nameserver
name server replication (multiple NS records) and anycast (multiple
physical locations).  Nameserver  Name server replication is strongly recommended
for all zones (multiple NS records), and IP anycast is used by many
larger zones such as the DNS Root<xref target="AnyFRoot"/>, root <xref target="AnyFRoot" format="default"/>, most top-level
domains<xref target="Moura16b"/>
domains <xref target="Moura16b" format="default"/>, and many large commercial enterprises, governments governments,
and other organizations.</t>
          <t>Most DNS operators strive to reduce service latency for users, which
is greatly affected by both of these replication techniques.  However,
because operators only have control over their authoritative servers, servers
and not over the client's recursive resolvers, it is difficult to
ensure that recursives will be served by the closest authoritative
server. Server selection is ultimately up to the recursive resolver's
software implementation, and different vendors and even different
releases employ different criteria to chose choose the authoritative servers
	  with which to communicate.</t>
          <t>Understanding how recursive resolvers choose authoritative servers is
a key step in improving the effectiveness of authoritative server
deployments. To measure and evaluate server deployments,
<xref target="Mueller17b"/> deployed target="Mueller17b" format="default"/> describes the deployment of seven unicast authoritative name servers in
different global locations and then queried them from more than 9000
RIPE
Reseaux IP Europeens (RIPE) authoritative server operators and their respective recursive
resolvers.</t>

<t><xref target="Mueller17b"/>
          <t>It was found in <xref target="Mueller17b" format="default"/> that recursive resolvers in the wild query all
available authoritative servers, regardless of the observed
latency. But the distribution of queries tends to be skewed towards
authoritatives with lower latency: the lower the latency between a
recursive resolver and an authoritative server, the more often the
recursive will send queries to that server. These results were
obtained by aggregating results from all of the vantage points points, and
they were not specific to any specific vendor or version.</t>
          <t>The authors believe this behavior is a consequence of combining the
two main criteria employed by resolvers when selecting authoritative
servers: resolvers regularly check all listed authoritative servers in
an NS set to determine which is closer (the least latent) latent), and when one
isn't available available, it selects one of the alternatives.</t>
        </section>
        <section anchor="resulting-considerations" title="Resulting considerations"> numbered="true" toc="default">
          <name>Resulting Considerations</name>
          <t>For an authoritative DNS operator, this result means that the latency
of all authoritative servers (NS records) matter, so they all must be
similarly capable -- all available authoritatives will be queried by
most recursive resolvers. Unicasted services, unfortunately, cannot
deliver good latency worldwide (a unicast authoritative server in
Europe will always have high latency to resolvers in California and
Australia, for example, given its geographical
distance).</t>
          <t><xref target="Mueller17b"/> target="Mueller17b" format="default"/> recommends that DNS operators deploy equally
strong IP anycast instances for every authoritative server (i.e., for
each NS record).  Each large authoritative DNS server provider should
phase out their its usage of unicast and deploy a well engineered number of well-engineered anycast instances with good peering strategies so they can provide
good latency to their global clients.
<!-- This doesn't really say anything?  what arch considerations?
However, {{Mueller17b}} also
notes that DNS operators should take architectural considerations
into account when planning for deploying anycast {{RFC1546}}.
--></t>
          </t>
          <t>As a case study, the ".nl" TLD zone was originally served on seven
authoritative servers with a mixed unicast/anycast setup.  In early
2018, .nl moved to a setup with 4 anycast authoritative
servers.
<!-- XXX: NEED TO SHOW/DESCRIBE RESULTS --></t>

<t><xref target="Mueller17b"/>'s
          </t>
          <t>The contribution of <xref target="Mueller17b" format="default"/> to DNS service engineering shows that
because unicast cannot deliver good latency worldwide, anycast needs
to be used to provide a low latency low-latency service worldwide.</t>
        </section>
      </section>
      <section anchor="c2-optimizing-routing-is-more-important-than-location-count-and-diversity" title="C2: anchor="c2" numbered="true" toc="default">
        <name>C2: Optimizing routing Routing is more important More Important than location count Location Count and diversity"> Diversity</name>
        <section anchor="research-background-1" title="Research background"> numbered="true" toc="default">
          <name>Research Background</name>
          <t>When selecting an anycast DNS provider or setting up an anycast
service, choosing the best number of anycast instances<xref target="RFC4786"/><xref target="RFC7094"/> instances <xref target="RFC4786" format="default"/> <xref target="RFC7094" format="default"/>  to
deploy is a challenging problem. Selecting where the right quantity and how many set of global locations to announce from using that should send BGP announcements is tricky.  Intuitively, one
could naively think that the more instances the are better and that simply
	  "more" will always lead to shorter response times.</t>

          <t>This is not necessarily true, however. In fact, <xref target="Schmidt17a"/> found
that proper route engineering can matter more than the total number of
locations. They analyzed locations, as found in <xref target="Schmidt17a" format="default"/>. To study the relationship between the number of
anycast instances and the associated service performance (measuring latency of performance, the authors measured the round-trip time (RTT)), measuring the overall performance (RTT) latency of four DNS
Root root servers. The Root root DNS servers are implemented by 12 separate
organizations serving the DNS root zone at 13 different IPv4/IPv6
address pairs.</t>
          <t>The results documented in <xref target="Schmidt17a"/> target="Schmidt17a" format="default"/> measured the performance of
the {c,f,k,l}.root-servers.net (hereafter, (referred to as "C", "F", "K" "K", and "L") "L" hereafter)
servers from more than 7.9k 7,900 RIPE Atlas probes. RIPE Atlas is a an
Internet measurement platform with more than 12000 12,000 global vantage
points called "Atlas Probes" -- probes", and it is used regularly by both
researchers and operators <xref target="RipeAtlas15a"/> target="RipeAtlas15a" format="default"/> <xref target="RipeAtlas19a"/>.</t>

<t><xref target="Schmidt17a"/> target="RipeAtlas19a" format="default"/>.</t>
          <t>In <xref target="Schmidt17a" format="default"/>, the authors found that the C server, a smaller anycast deployment
consisting of only 8 instances, provided very similar overall
performance in comparison to the much larger deployments of K and L,
with 33 and 144 instances instances, respectively. The median RTT RTTs for the C, K K, and L
root server servers were all between 30-32ms.</t>

<!-- XXX: what about F???  why is it mentioned above if we don't talk --> 30-32 ms.</t>

<t>Because RIPE Atlas is known to have better coverage in Europe than
other regions, the authors specifically analyzed the results per
region and per country (Figure 5 in <xref target="Schmidt17a"/>), target="Schmidt17a" format="default"/>) and show that
known Atlas bias toward Europe does not change the conclusion that
properly selected anycast locations is are more important to latency than
the number of sites.</t>
        </section>
        <section anchor="resulting-considerations-1" title="Resulting considerations"> numbered="true" toc="default">
          <name>Resulting Considerations</name>
          <t>The important conclusion of from <xref target="Schmidt17a"/> target="Schmidt17a" format="default"/> is that when engineering
anycast services for performance, factors other than just the number
of instances (such as local routing connectivity) must be considered.
Specifically, optimizing routing policies is more important than
simply adding new instances.  They  The authors showed that 12 instances can
provide reasonable latency, assuming they are globally distributed and
have good local interconnectivity. However, additional instances can
still be useful for other reasons, such as when handling
Denial-of-service (DoS)
DoS attacks <xref target="Moura16b"/>.</t> target="Moura16b" format="default"/>.</t>
        </section>
      </section>
      <section anchor="c3-collecting-anycast-catchment-maps-to-improve-design" title="C3: Collecting anycast catchment maps anchor="c3" numbered="true" toc="default">
        <name>C3: Collect Anycast Catchment Maps to improve design"> Improve Design</name>
        <section anchor="research-background-2" title="Research background"> numbered="true" toc="default">
          <name>Research Background</name>

          <t>An anycast DNS service may be deployed from anywhere and from several
locations to hundreds of locations (for example, l.root-servers.net
has over 150 anycast instances at the time this was written). Anycast
leverages Internet routing to distribute incoming queries to a
service's hop-nearest nearest distributed anycast locations. locations measured by the number of routing hops.  However, usually queries are usually not evenly distributed across all anycast locations, as
found in the case of L-Root when analyzed using Hedgehog <xref target="IcannHedge18"/>.</t> target="IcannHedgehog" format="default"/>.</t>
          <t>Adding locations to or removing locations from a deployed anycast
network changes the load distribution across all of its
locations. When a new location is announced by BGP, locations may
receive more or less traffic than it was engineered for, leading to
suboptimal service performance or even stressing some locations while
leaving others underutilized.  Operators constantly face this scenario
that
 when expanding an anycast service. Operators cannot easily
directly estimate future query distributions based on proposed anycast
	  network engineering decisions.</t>

          <t>To address this need and estimate the query loads based on changing,
in particular expanding, of an anycast service undergoing changes (in particular expanding), <xref target="Vries17b"/>
developed target="Vries17b" format="default"/> describes the development of a new technique enabling operators to carry out active
measurements,
measurements using an open-source tool called Verfploeter (available
at <xref target="VerfSrc"></xref>). target="VerfSrc" format="default"/>).  The results allow the creation of detailed anycast
maps and catchment estimates.  By running verfploeter 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
the moment time of this writing, Verfploeter still does not support IPv6 as
the IPv4 hit lists used are generated via frequent large scale large-scale ICMP
echo scans, which is not possible using IPv6.</t>
          <t>As proof of concept, <xref target="Vries17b"/> target="Vries17b" format="default"/> documents how it verfploeter Verfploeter was used to predict both the catchment and query load distribution for a new anycast instance deployed for b.root-servers.net.  Using two
anycast test instances in Miami (MIA) and Los Angeles (LAX), an ICMP
echo query was sent from an IP anycast addresses address to each IPv4 /24
	  network routing block on the Internet.</t>

          <t>The ICMP echo responses were recorded at both sites and analyzed and
overlayed
overlaid onto a graphical world map, resulting in an Internet scale Internet-scale
catchment map.  To calculate expected load once the production network
was enabled, the quantity of traffic received by b.root-servers.net's
single site at LAX was recorded based on a single day's traffic
(2017-04-12, DITL "day in the life" (DITL) datasets <xref target="Ditl17"/>). target="Ditl17" format="default"/>).  In <xref target="Vries17b"/> target="Vries17b" format="default"/>, it was predicted that
81.6% of the traffic load would remain at the LAX site. This Verfploeter estimate
by verfploeter
turned out to be very accurate; the actual measured
	  traffic volume when production service at MIA was enabled was 81.4%.</t>

          <t>Verfploeter can also be used to estimate traffic shifts based on other
BGP route engineering techniques (for example, AS Autonomous System (AS) path prepending or
BGP community use) in advance of operational deployment.  <xref target="Vries17b"/> This was studied this in <xref target="Vries17b" format="default"/> using prepending with 1-3 hops at each instance instance, and
compared
the results were compared against real operational changes to validate the
techniques accuracy.</t>
accuracy of the techniques.</t>
        </section>
        <section anchor="resulting-considerations-2" title="Resulting considerations"> numbered="true" toc="default">
          <name>Resulting Considerations</name>
          <t>An important operational takeaway <xref target="Vries17b"/> target="Vries17b" format="default"/> provides is how DNS operators can make informed engineering choices when changing DNS
anycast network deployments by using Verfploeter in advance.
Operators can identify sub-optimal suboptimal routing situations in advance with
significantly better coverage rather than using other active measurement
platforms such as RIPE Atlas.  To date, Verfploeter has been deployed
on a an operational testbed (Anycast (anycast testbed) <xref target="AnyTest"/>, target="AnyTest" format="default"/> on a large
unnamed operator and is run daily at b.root-servers.net<xref target="Vries17b"/>.</t> b.root-servers.net <xref target="Vries17b" format="default"/>.</t>
          <t>Operators should use active measurement techniques like Verfploeter in
advance of potential anycast network changes to accurately measure the
benefits and potential issues ahead of time.</t>
        </section>
      </section>
      <section anchor="c4-when-under-stress-employ-two-strategies" title="C4: anchor="c4" numbered="true" toc="default">
        <name>C4: Employ Two Strategies When under stress, employ two strategies"> Stress</name>
        <section anchor="research-background-3" title="Research background"> numbered="true" toc="default">
          <name>Research Background</name>
          <t>DDoS attacks are becoming bigger, cheaper, and more frequent
<xref target="Moura16b"/>. target="Moura16b" format="default"/>. The most powerful recorded DDoS attack against DNS
servers to date reached 1.2 Tbps by using IoT Internet of Things (IoT) devices
<xref target="Perlroth16"/>. target="Perlroth16" format="default"/>.
How should a DNS operator engineer its anycast
authoritative DNS server to react to such a DDoS attack?  <xref target="Moura16b"/> target="Moura16b" format="default"/>
investigates this question using empirical observations grounded with
	  theoretical option evaluations.</t>

          <t>An authoritative DNS server deployed using anycast will have many
server instances distributed over many networks. Ultimately, the
relationship between the DNS provider's network and a client's ISP
will determine which anycast instance will answer queries for a given
client, given that BGP is the BGP protocol that maps clients to specific
anycast instances by using routing information [RF:KDar02]. information. As a
consequence, when an anycast authoritative server is under attack, the
load that each anycast instance receives is likely to be unevenly
distributed (a function of the source of the attacks), thus attacks); thus, some
instances may be more overloaded than others others, which is what was
observed when analyzing the Root root DNS events of Nov. November 2015
<xref target="Moura16b"/>. target="Moura16b" format="default"/>. Given the fact that different instances may have
different capacity capacities (bandwidth, CPU, etc.), making a decision about how
	  to react to stress becomes even more difficult.</t>

          <t>In practice, when an anycast instance is overloaded with incoming traffic,
operators have two options:</t>

<t><list style="symbols">
  <t>They
<ul spacing="normal">

            <li>They can withdraw its routes, pre-prepend its AS route to some or
all of its neighbors, perform other traffic shifting traffic-shifting tricks (such as
reducing route announcement propagation using BGP
communities<xref target="RFC1997"/>),
communities <xref target="RFC1997" format="default"/>), or by communicating communicate with its upstream
network providers to apply filtering (potentially using FlowSpec <xref target="RFC8955"/> target="RFC8955" format="default"/> or DOTS the DDoS Open Threat Signaling (DOTS) protocol (<xref target="RFC8811"/>, <xref target="RFC8782"/>, target="RFC8811"
format="default"/> <xref target="RFC9132" format="default"/> <xref target="RFC8783"/>). target="RFC8783" format="default"/>). These techniques shift both legitimate and attack traffic to other anycast instances (with hopefully greater capacity) or to block traffic
entirely.</t>
  <t>Alternatively,
entirely.</li>
            <li>Alternatively, operators can be become a degraded absorber absorbers by
continuing to operate, knowing dropping incoming legitimate requests
due to queue overflow. However, this approach will also absorb
attack traffic directed toward its catchment, hopefully protecting
the other anycast instances.</t>
</list></t>

<t><xref target="Moura16b"/> saw instances.</li>
          </ul>
          <t>
	    <xref target="Moura16b" format="default"/> describes seeing both of these behaviors deployed in practice by when studying instance reachability and route-trip time (RTTs) RTTs in the DNS
root events.  When withdraw strategies were deployed, the stress of
increased query loads were displaced from one instance to multiple
other sites.  In other observed events, one site was left to absorb
the brunt of an attack attack, leaving the other sites to remain relatively
less affected.</t>
        </section>
        <section anchor="resulting-considerations-3" title="Resulting considerations"> numbered="true" toc="default">
          <name>Resulting Considerations</name>
          <t>Operators should consider having both a an anycast site withdraw strategy
and a an absorption strategy ready to be used before a network overload
occurs.  Operators should be able to deploy one or both of these
strategies rapidly.  Ideally, these should be encoded into operating
playbooks with defined site measurement guidelines for which strategy
to employ based on measured data from past events.</t>
          <t><xref target="Moura16b"/> target="Moura16b" format="default"/> speculates that careful, explicit, and automated
management policies may provide stronger defenses to overload
events. DNS operators should be ready to employ both traditional common
filtering approaches and other routing load balancing load-balancing techniques
(withdraw/prepend/communities
(such as withdrawing routes, prepending Autonomous Systems (ASes), adding communities, or isolate isolating instances),
where the best choice depends on the specifics of the attack.</t>
          <t>Note that this consideration refers to the operation of just one
anycast service point, i.e., just one anycasted IP address block
covering one NS record. However, DNS zones with multiple authoritative
anycast servers may also expect loads to shift from one anycasted
server to another, as resolvers switch from on one authoritative service
point to another when attempting to resolve a name <xref target="Mueller17b"/>.</t> target="Mueller17b" format="default"/>.</t>
        </section>
      </section>
      <section anchor="c5-consider-longer-time-to-live-values-whenever-possible" title="C5: anchor="c5" numbered="true" toc="default">
        <name>C5: Consider longer time-to-live values whenever possible"> Longer Time-to-Live Values Whenever Possible</name>
        <section anchor="research-background-4" title="Research background"> numbered="true" toc="default">
          <name>Research Background</name>
          <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
than 1 ms response to a cached entry is far faster. In <xref target="Moura18b"/>
showed target="Moura18b" format="default"/>, it was
shown that caching also protects users from short outages and even
	  significant DDoS attacks.</t>

<t>DNS record TTLs (time-to-live values)

          <t>Time-to-live (TTL) values <xref target="RFC1034"/><xref target="RFC1035"/> target="RFC1034" format="default"/> <xref target="RFC1035" format="default"/> for DNS records directly
control cache durations and affect latency, resilience, and the role
of DNS in CDN Content Delivery Network (CDN) server selection. Some early work modeled caches as a
function of their TTLs <xref target="Jung03a"/>, target="Jung03a" format="default"/>, and recent work has examined their
interaction cache
interactions with DNS<xref target="Moura18b"/>, DNS <xref target="Moura18b" format="default"/>, but until <xref target="Moura19b"/> target="Moura19b" format="default"/>, no research
had provided considerations about the benefits of various TTL value
choices. To study this, Moura et. al. <xref target="Moura19b"/> et al.&nbsp;<xref target="Moura19b" format="default"/> carried out a
measurement study investigating TTL choices and their impact on user
experiences in the wild.  They performed this study independent of
specific resolvers (and their caching architectures), vendors, or
setups.</t>
          <t>First, they identified several reasons why operators and zone-owners zone owners may
want to choose longer or shorter TTLs:</t>

<t><list style="symbols">
  <t>As
          <ul spacing="normal">
            <li>Longer TTLs, as discussed, longer TTLs lead to a longer cache life, resulting
	    in faster responses. In <xref target="Moura19b"/> target="Moura19b" format="default"/>, this was measured this in the wild wild, and it
showed that by increasing the TTL for the .uy TLD from 5 minutes
(300s)
(300 s) to 1 day (86400s) (86,400 s), the latency measured from 15k 15,000 Atlas
vantage points changed significantly: the median RTT decreased
from 28.7ms 28.7 ms to 8ms, 8 ms, and the 75%ile 75th percentile decreased from 183ms 183 ms to 21ms.</t>
  <t>Longer 21 ms.</li>
            <li>Longer caching times also results result in lower DNS traffic:
authoritative servers will experience less traffic with extended
TTLs, as repeated queries are answered by resolver caches.</t>
  <t>Consequently, longer caches.</li>
            <li>Longer caching consequently results in a lower overall cost if
the DNS is metered: some DNS-As-A-Service providers that offer DNS as a Service charge a per query per-query
	    (metered) cost (often in addition to a fixed monthly cost).</t>
  <t>Longer cost).</li>

            <li>Longer caching is more robust to DDoS attacks on DNS
infrastructure.  <xref target="Moura18b"/> DNS caching was also measured in  <xref target="Moura18b" format="default"/>, and show it  showed that DNS
caching can greatly reduce the effects of a DDoS on DNS, DNS can be greatly reduced, provided
that the caches last longer than the attack.</t>
  <t>However, shorter caching attack.</li>
            <li>Shorter caching, however, supports deployments that may require
rapid operational changes: An an easy way to transition from an old
server to a new one is to simply change the DNS records.  Since
there is no method to remotely remove cached DNS records, the TTL
duration represents a necessary transition delay to fully shift
from one server to another.  Thus, low TTLs allow for more rapid
transitions.  However, when deployments are planned in advance
(that is, longer than the TTL), it is possible to lower the TTLs
just-before
just before a major operational change and raise them again
afterward.</t>
  <t>Shorter
afterward.</li>
            <li>Shorter caching can also help with a DNS-based response to DDoS
attacks. Specifically, some DDoS-scrubbing services use the DNS to
redirect traffic during an attack. Since DDoS attacks arrive
unannounced, DNS-based traffic redirection requires that the TTL be
kept quite low at all times to allow operators to suddenly have
their zone served by a DDoS-scrubbing service.</t>
  <t>Shorter service.</li>
            <li>Shorter caching helps DNS-based load balancing. Many large
services are known to rotate traffic among their servers using
DNS-based load balancing. Each arriving DNS request provides an
opportunity to adjust the service load by rotating IP address records
(A and AAAA) to the lowest unused server.  Shorter TTLs may be
desired in these architectures to react more quickly to traffic
dynamics.  Many recursive resolvers, however, have minimum caching
times of tens of seconds, placing a limit on this form of agility.</t>
</list></t> agility.</li>
          </ul>
        </section>
        <section anchor="resulting-considerations-4" title="Resulting considerations"> numbered="true" toc="default">
          <name>Resulting Considerations</name>
          <t>Given these considerations, the proper choice for a TTL depends in
part on multiple external factors -- no single recommendation is
appropriate for all scenarios. Organizations must weigh these
trade-offs and find a good balance for their situation. Still, some
guidelines can be reached when choosing TTLs:</t>

<t><list style="symbols">
  <t>For
<ul spacing="normal">

<li>For general DNS zone owners, <xref target="Moura19b"/> target="Moura19b" format="default"/> recommends a longer TTL
of at least one hour, hour and ideally 4, 8, 12, or 24 hours. Assuming
planned maintenance can be scheduled at least a day in advance, long
TTLs have little cost and may, even, may even literally provide a cost savings.</t>
  <t>For registry operators: savings.</li>
            <li>For TLD and other public registration
operators (for example example, most ccTLDs and .com, .net, and .org) that host
many delegations (NS records, DS records records, and "glue" records),
<xref target="Moura19b"/> target="Moura19b" format="default"/> demonstrates that most resolvers will use the TTL
values provided by the child delegations while the others some others
will choose the TTL provided by the parent's copy of the
record. As such, <xref target="Moura19b"/> target="Moura19b" format="default"/> recommends longer TTLs (at least an
hour or more) for registry operators as well for child NS and
other records.</t>
  <t>Users records.</li>
            <li>Users of DNS-based load balancing or DDoS-prevention services may
require shorter TTLs: TTLs may even need to be as short as 5
minutes, although 15 minutes may provide sufficient agility for
many operators. There is always a tussle between using shorter TTLs
providing
that provide more agility against and using longer TTLs that include all the benefits listed above for
using longer TTLs.</t>
  <t>Use above.</li>
            <li>Regarding the use of A/AAAA and NS records: The records, the TTLs for A/AAAA records should
be shorter to than or equal to the TTL for the corresponding NS records
for in-bailiwick authoritative DNS servers, since <xref target="Moura19b"/> target="Moura19b" format="default"/>
finds that once an NS record expires, their associated A/AAAA will
also be re-queried requeried when glue is required to be sent by the
parents.  For out-of-bailiwick servers, A, AAAA AAAA, and NS records are
usually all cached independently, so different TTLs can be used
effectively if desired. In either case, short A and AAAA records
may still be desired if DDoS-mitigation DDoS mitigation services are required.</t>
</list></t> required.</li>
          </ul>
        </section>
      </section>
      <section anchor="c6-consider-the-ttl-differences-between-parents-and-children" title="C6: anchor="c6" numbered="true" toc="default">
        <name>C6: Consider the TTL differences between parents Difference in Parent and children"> Children's TTL Values</name>
        <section anchor="research-background-5" title="Research background"> numbered="true" toc="default">
          <name>Research Background</name>

          <t>Multiple record types exist or are related between the parent of a
zone and the child.  At a minimum, NS records are supposed to be
identical in the parent (but often are not) not), as or are corresponding IP
address
addresses in "glue" A/AAAA records that must exist for in-bailiwick
authoritative servers.  Additionally, if DNSSEC (<xref target="RFC4033"/> <xref target="RFC4034"/> target="RFC4033" format="default"/>
            <xref target="RFC4034" format="default"/> <xref target="RFC4035"/> target="RFC4035" format="default"/> <xref target="RFC4509"/>) target="RFC4509" format="default"/> is deployed for a zone zone, the
parent's DS record must cryptographically refer to a child's DNSKEY
record.</t>
          <t>Because some information exists in both the parent and a child, it is
possible for the TTL values to differ between the parent's copy and
the child's.  <xref target="Moura19b"/> target="Moura19b" format="default"/> examines resolver behaviors when these
values differ differed in the wild, as they frequently do -- often often, parent zones
have defacto 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
(48 hours), but some TLD's TLDs have lower values within their published
records (the TTLs for .cl's NS records from their authoritative
servers is 1 hour).  <xref target="Moura19b"/> target="Moura19b" format="default"/> also examines the differences in the
TTLs between the NS records and the corresponding A/AAAA records for
the addresses of a nameserver. name server.  RIPE Atlas nodes are used to determine
what resolvers in the wild do with different information, information and whether
the parent's TTL is used for cache life-times lifetimes ("parent-centric") or
the child's is used ("child-centric").</t>
          <t><xref target="Moura19b"/> finds target="Moura19b" format="default"/> found that roughly 90% of resolvers follow the child's
view of the TTL, while 10% appear parent-centric.  It additionally
finds  Additionally, it
found that resolvers behave differently for cache lifetimes for
in-bailiwick vs vs. out-of-bailiwick NS/A/AAAA TTL combinations.
Specifically, when NS TTLs are shorter than the corresponding address
records, most resolvers will re-query requery for A/AAAA records for 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
the other hand, the inverse is true for out-of-bailiwick resolvers: If if
the NS record expires first first, resolvers will honor the original cache
time of the nameserver's name server's address.</t>
        </section>
        <section anchor="resulting-considerations-5" title="Resulting considerations"> numbered="true" toc="default">
          <name>Resulting Considerations</name>
          <t>The important conclusion from this study is that operators cannot
depend on their published TTL values alone -- the parent's values are
also used for timing cache entries in the wild.  Operators that are
planning on infrastructure changes should assume that an older
infrastructure must be left on and operational for at least the
maximum of both the parent and child's TTLs.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations" title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document discusses applying measured research results to
operational deployments.  Most of the considerations affect mostly
operational practice, though a few do have security related security-related impacts.</t>
      <t>Specifically, C4 <xref target="c4" format="none">C4</xref> discusses a couple of strategies to employ when a
service is under stress from DDoS attacks and offers operators
additional guidance when handling excess traffic.</t>
      <t>Similarly, C5 <xref target="c5" format="none">C5</xref> identifies the trade-offs with respect to the
operational and security benefits of using longer time-to-live TTL values.</t>

<!-- verified against RFC3552 - MD -->
</section>
    <section anchor="privacy-considerations" title="Privacy Considerations">

<!-- Add some remarkt according to RFC6973. Or should we name this "Human Rights considerations" according to RFC8280 - MD --> numbered="true" toc="default">
      <name>Privacy Considerations</name>

<t>This document does not add any new, practical new privacy issues, aside
from possible benefits in deploying longer TTLs as suggested in C5. <xref target="c5" format="none">C5</xref>.
Longer TTLs may help preserve a user's privacy by reducing the number
of requests that get transmitted in both the client-to-resolver and
resolver-to-authoritative cases.</t>
    </section>
    <section anchor="iana-considerations" title="IANA considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.
<!-- RFC8126 style - MD --></t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>This document is a summary of the main considerations of six research
works performed by the authors and others. This document would not
have been possible without the hard work of these authors and co-authors:</t>

<t><list style="symbols">
  <t>Ricardo de O. Schmidt</t>
  <t>Wouter B de Vries</t>
  <t>Moritz Mueller</t>
  <t>Lan Wei</t>
  <t>Cristian  Hesselman</t>
  <t>Jan Harm Kuipers</t>
  <t>Pieter-Tjerk de Boer</t>
  <t>Aiko Pras</t>
</list></t>

<t>We would like also to thank the reviewers of this draft that offered
valuable suggestions: Duane Wessels, Joe Abley, Toema Gavrichenkov,
John Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus
Darilion and Samir Jafferali, and comments provided at the IETF DNSOP
session (IETF104).</t>

<t>Besides those, we would like thank those acknowledged in the papers
this document summarizes for helping produce the results: RIPE NCC and
DNS OARC for their tools and datasets used in this research, as well
as the funding agencies sponsoring the individual research works.</t>
      </t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

&RFC2181;
&RFC1034;
&RFC7094;
&RFC1546;
&RFC1035;
&RFC1995;
&RFC5936;
&RFC4786;
&RFC1997;
&RFC8499;
&RFC8782;
&RFC8783;
&RFC8955;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7094.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1546.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9132.xml"/>

      </references>

    <references title='Informative References'>

&RFC4033;
&RFC4034;
&RFC4035;
&RFC4509;
&RFC8811;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8811.xml"/>

        <reference anchor="Moura16b" target="https://www.isi.edu/~johnh/PAPERS/Moura16b.pdf">
          <front>
            <title>Anycast vs DDoS vs. DDoS: Evaluating the November 2015 Root DNS Events.</title> Event</title>
            <author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R.d.O." initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization></organization>
              <organization/>
            </author>
	    <author initials="W." surname="de Vries" fullname="Wouter de Vries">
              <organization/>
            </author>
            <author initials="M." surname="Mueller" surname="Müller" fullname="Moritz Mueller">
      <organization></organization> Müller">
              <organization/>
            </author>
            <author initials="L." surname="Wei" fullname="Lan Wei">
      <organization></organization>
              <organization/>
            </author>
            <author initials="C." surname="Hesselman" fullname="Cristian Hesselman">
      <organization></organization>
              <organization/>
            </author>
            <date year="2016" month="October" day="14"/> month="November"/>
          </front>
          <seriesInfo name="ACM" value="2016 name="DOI" value="10.1145/2987443.2987446"/>
	<refcontent>ACM 2016 Internet Measurement Conference"/>
  <seriesInfo name="DOI" value="/10.1145/2987443.2987446"/> Conference</refcontent>
        </reference>

        <reference anchor="Schmidt17a" target="https://www.isi.edu/%7ejohnh/PAPERS/Schmidt17a.pdf">
          <front>
            <title>Anycast Latency - Latency: How Many Sites Are Enough. In Proceedings of the Passive and Active Measurement Workshop</title> Enough?</title>
            <author initials="R.d.O." initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J.H." initials="J." surname="Kuipers" fullname="Jam fullname="Jan Harm Kuipers">
      <organization></organization>
              <organization/>
            </author>
            <date year="2017" month="March"/>
          </front>
	  <seriesInfo name="PAM" value="Passive name="DOI" value="10.1007/978-3-319-54328-4_14"/>
          <refcontent>PAM 2017 Passive and Active Measurement Conference"/> Conference</refcontent>
        </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> DDoS</title>
            <author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization></organization>
              <organization/>
            </author>
            <author initials="M." surname="Mueller" surname="Müller" fullname="Moritz Mueller">
      <organization></organization> Müller">
              <organization/>
            </author>
            <author initials="R.d.O." initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
              <organization/>
            </author>
            <author initials="M." surname="Davids" fullname="Marco Davids">
      <organization></organization>
              <organization/>
            </author>
            <date year="2018" month="October" day="31"/> month="October"/>
          </front>
          <seriesInfo name="ACM" value="2018 Internet Measurement Conference"/>
  <seriesInfo name="DOI" value="10.1145/3278532.3278534"/>
	  <refcontent>ACM 2018 Internet Measurement Conference</refcontent>
        </reference>

        <reference anchor="Singla2014" target="http://speedierweb.web.engr.illinois.edu/cspeed/papers/hotnets14.pdf">
          <front>
            <title>The Internet at the speed Speed of light. In Proceedings of the 13th ACM Workshop on Hot Topics in Networks (Oct 2014)</title> Light</title>
            <author initials="A." surname="Singla" fullname="Ankit Singla">
      <organization></organization>
              <organization/>
            </author>
            <author initials="B." surname="Chandrasekaran" fullname="Balakrishnan Chandrasekaran">
      <organization></organization>
              <organization/>
            </author>
            <author initials="P.B." initials="P." surname="Godfrey" fullname="P fullname="P. Brighten Godfrey">
      <organization></organization>
              <organization/>
            </author>
            <author initials="B." surname="Maggs" fullname="Bruce Maggs">
      <organization></organization>
              <organization/>
            </author>
            <date year="2014" month="October"/>
          </front>
	  <seriesInfo name="ACM" value="Workshop name="DOI" value="10.1145/2670518.2673876"/>
          <refcontent>13th ACM Workshop on Hot Topics in Networks"/> Networks</refcontent>
        </reference>

        <reference anchor="Vries17b" target="https://www.isi.edu/%7ejohnh/PAPERS/Vries17b.pdf">
          <front>
    <title>Verfploeter - Broad
            <title>Broad and Load-Aware Anycast Mapping</title> Mapping with Verfploeter</title>
            <author initials="W.d." surname="Vries" initials="W." surname="de Vries" fullname="Wouter de Vries">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R.d.O." initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
              <organization/>
            </author>
            <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization></organization>
              <organization/>
            </author>
            <author initials="P.d." surname="Boer" initials="P-T" surname="de Boer" fullname="Pieter-Tjerk de Boer">
      <organization></organization>
              <organization/>
            </author>
            <author initials="A." surname="Pras" fullname="Aiko Pras">
      <organization></organization>
              <organization/>
            </author>
            <date year="2017" month="October"/> month="November"/>
          </front>
          <seriesInfo name="ACM" value="2017 Internet Measurement Conference"/>
  <seriesInfo name="DOI" value="10.1145/3131365.3131371"/>
	  <refcontent>ACM 2017 Internet Measurement Conference</refcontent>
        </reference>

        <reference anchor="Jung03a" target="http://www.ieee-infocom.org/2003/papers/11_01.PDF">
          <front>
            <title>Modeling TTL-based Internet caches</title> Caches</title>
            <author initials="J." surname="Jung" fullname="Jaeyeon Jung">
      <organization></organization>
              <organization/>
            </author>
            <author initials="A.W." initials="A." surname="Berger" fullname="Arthur W. Berger">
      <organization></organization>
              <organization/>
            </author>
            <author initials="H." surname="Balakrishnan" fullname="Hari Balakrishnan">
      <organization></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"/>
	 <refcontent>ACM 2003 IEEE INFOCOM</refcontent>
        </reference>

        <reference anchor="RipeAtlas15a" target="http://ipj.dreamhosters.com/wp-content/uploads/issues/2015/ipj18-3.pdf">
          <front>
            <title>RIPE Atlas Atlas: A Global Internet Measurement Network</title>
    <author initials="R.N." surname="Staff" fullname="RIPE NCC Staff">
      <organization></organization>
            <author>
              <organization>RIPE Network Coordination Centre (RIPE NCC)</organization>
            </author>
            <date year="2015" month="September"/> month="October"/>
          </front>
        </reference>

        <reference anchor="RipeAtlas19a" target="https://atlas.ripe.net/"> target="https://atlas.ripe.net">
          <front>
    <title>Ripe Atlas - RIPE
            <title>RIPE Atlas</title>
            <author><organization>RIPE Network Coordination Centre</title>
    <author initials="R." surname="NCC" fullname="RIPE NCC">
      <organization></organization> Centre (RIPE NCC)</organization>
            </author>
    <date year="2019" month="September"/>
            <date/>
          </front>
        </reference>

        <reference anchor="Mueller17b" target="https://www.isi.edu/%7ejohnh/PAPERS/Mueller17b.pdf">
          <front>
            <title>Recursives in the Wild- Wild: Engineering Authoritative DNS Servers.</title> Servers</title>
            <author initials="M." surname="Mueller" surname="Müller" fullname="Moritz Mueller">
      <organization></organization> Müller">
              <organization/>
            </author>
            <author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R.d.O." initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization></organization>
              <organization/>
            </author>
            <date year="2017" month="October"/> month="November"/>
          </front>
          <seriesInfo name="ACM" value="2017 Internet Measurement Conference"/>
  <seriesInfo name="DOI" value="10.1145/3131365.3131366"/>
	  <refcontent>ACM 2017 Internet Measurement Conference</refcontent>
        </reference>

        <reference anchor="Moura19b" target="https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf">
          <front>
            <title>Cache Me If You Can: Effects of DNS Time-to-Live</title>
            <author initials="G." initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">
      <organization></organization>
              <organization/>
            </author>
            <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization></organization>
              <organization/>
            </author>
            <author initials="J." surname="Heidemann" fullname="John Heidemann">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R.d.O." initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
              <organization/>
            </author>
            <date year="n.d."/> month="October" year="2019"/>
          </front>
          <seriesInfo name="ACM" value="2019 Internet Measurement Conference"/>
  <seriesInfo name="DOI" value="10.1145/3355369.3355568"/>
	  <refcontent>ACM 2019 Internet Measurement Conference</refcontent>
        </reference>

        <reference anchor="IcannHedge18" target="http://stats.dns.icann.org/hedgehog/"> anchor="IcannHedgehog" target="https://github.com/dns-stats/hedgehog">
          <front>
    <title>DNS-STATS -  Hedgehog 2.4.1</title>
    <author initials="." surname="ICANN" fullname="ICANN">
      <organization></organization>
            <title>hedgehog</title>
            <author><organization></organization>
            </author>
            <date year="2018" month="October"/> year="2021" month="May"/>
          </front>
	 <refcontent>commit b136eb0</refcontent>
        </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> Data</title>
            <author><organization>DNS-OARC</organization>
            </author>
            <date year="2018" month="October"/> year="2017" month="April"/>
          </front>
        </reference>

        <reference anchor="Perlroth16" target="https://www.nytimes.com/2016/10/22/business/internet-problems-attack.html">
          <front>
            <title>Hackers Used New Weapons to Disrupt Major Websites Across U.S.</title>
            <author initials="N." surname="Perlroth" fullname="Nicole Perlroth">
      <organization></organization>
              <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> Source Code</title>
            <author>
              <organization/>
            </author>
            <date year="2018" month="November"/> year="2019" month="May"/>
          </front>
	  <refcontent>commit f4792dc</refcontent>
        </reference>

        <reference anchor="AnyTest" target="http://www.anycast-testbed.com/">
          <front>
    <title>Anycast
            <title>Tangled Anycast Testbed</title>
    <author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt">
      <organization></organization>
    </author>
    <date year="2018" month="December"/>
            <author><organization>Tangled</organization></author>
            <date/>
          </front>
        </reference>

        <reference anchor="AnyBest" target="https://meetings.icann.org/en/marrakech55/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></organization>
              <organization/>
            </author>
            <date year="2016" month="March"/>
          </front>
	   <seriesInfo name="Version" value="1.2"/>
        </reference>

        <reference anchor="AnyFRoot" target="https://archive.nanog.org/meetings/nanog27/presentations/suzanne.pdf">
          <front>
            <title>Anycasting f.root-serers.net</title> f.root-servers.net</title>
            <author initials="S." surname="Woolf" fullname="Suzanne Woolf">
      <organization></organization>
              <organization/>
            </author>
            <date year="2003" month="January"/>
          </front>
        </reference>
      </references>
</references>

    <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"/>, <contact fullname="Kristof Tuyteleers"/>, <contact fullname="Stefan Ubbink"/>, <contact 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 substantially to the content and should be considered coauthors; this document would 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>

<!-- ##markdown-source:
H4sIAJSt1GEAA8V963Lj1nbmfzzFHrlOWYpJStRdymRO1FK33XbfqiXHJ5Vk
UiC5ScICAQYAJdPtTuUd5l3mV/7lTeZJZn1rrX0BSMl9TiY1PnVsigQ29l73
O/r9ftJkTW4vzXVZ1NnEVmmT0SczLSvzJq1m1lytmnlZZQ398GDNzbtbc2ur
B1vV5v0Sl5dVnaSjUWUfuov0eYE+FujTff33y9qYZFKOi3RBT5xU6bTpL8pV
lfYnRV0u+2n8qH5lx+ViYYuJrjYcJvTRXibJV6Zu0mLyz2leFrRQU61skmTL
ij/WzeHBwcXBYZJWNr00r4vGVoVtksfZJXb//oP5qazus2Jmvq3K1ZJ2dP8Y
LuvfYFfJOG0uTVZMyyQZlxO6+NKs6n5aj7MsWWaXhv75yozTgr61Jq2qdG12
s6lJ89ysbb1nCHrztJ6bua0sbdf0TVOO5UNdVk1lp7X+tV7wHwYXXOJm+ugu
ueTHTOw0XeVNTVe43+UmuTwRqF0mhv/p638NbZ+u+HZgrgdvB+YtwOx/EgR8
m5UPaWHpArNxRVnRkW9f37wjKhjV+3c/mhubE2Dc7zVt0BKM3lpChK3MycHQ
/zbOmvWluaqKuV2EL8sJPfL0/PDEvL2Jvl0VTUVXv3vjv1vOGavfHA3N4ak5
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

-->

</rfc>