<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.2.2) -->
<?rfc stand-alone="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-mud-iot-dns-considerations-19" number="9726" category="bcp" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.0 version="3" xml:lang="en" updates="" obsoletes="" submissionType="IETF">

<!--[rfced] This document has been assigned a new BCP number. Please
let us know if this is not correct (i.e., it should be part of an existing BCP).

See the complete list of BCPs here: https://www.rfc-editor.org/bcps
-->

  <front>
    <title abbrev="mud-iot-dns">Operational abbrev="DNS in IoT Devices">Operational Considerations for Use of DNS in IoT Internet of Things (IoT) Devices</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-mud-iot-dns-considerations-19"/> name="RFC" value="9726"/>
    <seriesInfo name="BCP" value="241"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="W." surname="Pan" fullname="Wei Pan">
      <organization>Huawei Technologies</organization>
      <address>
        <email>william.panwei@huawei.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="03"/>
    <area>Operations</area>
    <workgroup>OPSAWG Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2025" month="March"/>
    <area>OPS</area>
    <workgroup>opsawg</workgroup>

<keyword>DNS</keyword>
<keyword>MUD</keyword>
<keyword>round-robin</keyword>
<keyword>tailored response</keyword>
<keyword>DNSSEC</keyword>
<keyword>IoT security</keyword>
<keyword>Device Identity</keyword>

<!--[rfced] FYI, this sentence has been updated as follows for clarity.
Please review whether these terms convey the same meaning:
"Manufacturer Usage Description (MUD) definitions"
replaced with "Manufacturer Usage Descriptions (MUDs)" (plural).
We note the plural is used in the abstract of RFC 8520.

Original:
   These concerns become
   acute as network operators begin deploying RFC 8520 Manufacturer
   Usage Description (MUD) definitions to control device access.

Current:
   These concerns become
   acute as network operators begin deploying Manufacturer
   Usage Descriptions (MUDs), as specified in RFC 8520, to control
   device access.
-->
    <abstract>
      <?line 74?>
      <t>This document details considerations about how Internet of Things
      (IoT) devices use IP addresses and DNS names.  These concerns become
      acute as network operators begin deploying RFC 8520 Manufacturer Usage Description (MUD) definitions
      Descriptions (MUD), as specified in RFC 8520, to control device access.</t>
      <t>Also, this document makes recommendations on when and how to use DNS
      names in MUD files.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        opsawg Working Group mailing list (<eref target="mailto:opsawg@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/opsawg/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/mcr/iot-mud-dns-considerations"/>.</t>
    </note>
  </front>
  <middle>
    <?line 82?>

<section anchor="introduction">
      <name>Introduction</name>
<!--[rfced] Please clarify "a specific purpose device".
This term has not been used in past documents;
perhaps it is in contrast to "a general-purpose device", a term
used in RFC 8520. May it be rephrased as below, or
does it mean the same as "a single-purpose device"?

Original:
   [RFC8520] provides a standardized way to describe how a specific
   purpose device makes use of Internet resources.

Perhaps:
   [RFC8520] provides a standardized way to describe how a device
   for a specific purpose makes use of Internet resources.
-->
      <t><xref target="RFC8520"/> provides a standardized way to describe how
      a specific purpose device makes use of Internet resources.  Access
      Control Lists (ACLs) can be defined in an RFC 8520 a Manufacturer Usage Description
      (MUD) file <xref target="RFC8520" format="default"/> that permit permits a
      device to access Internet resources by their DNS names or IP
      addresses.</t>
      <t>Use
      <t>The use of a DNS name rather than an IP address in an ACL has many
      advantages: not Not only does the layer of indirection permit the mapping of
      a name to IP address(es) addresses to be changed over time, but it also generalizes
      automatically to IPv4 and IPv6 addresses, addresses as well as permitting permits a
      variety of load balancing load-balancing strategies, including multi-CDN deployments
      wherein load balancing load-balancing can account for geography and load.</t>
      <t>However, the use of DNS names has implications on how ACL ACLs are
      executed at the MUD policy enforcement point (typically, a firewall).
      Concretely, the firewall has access only to the Layer 3 headers of the
      packet.  This includes the source and destination IP address, and addresses and, if not
      encrypted by IPsec, the destination UDP or TCP port number present in
      the transport header.  The DNS name is not present!</t>
      <t>So
      <t>So, in order to implement these name based name-based ACLs, there must be a
      mapping between the names in the ACLs and IP addresses.</t>
      <t>In order for manufacturers to understand how to configure DNS
      associated with name based name-based ACLs, a model of how the DNS resolution will
      be done by MUD controllers is necessary.  <xref target="mapping"/>
      models some good strategies that are could be used.</t>
      <t>This model is non-normative: non-normative but is included so that IoT device
      manufacturers can understand how the DNS will be used to resolve the
      names they use.</t>
      <t>There are some ways of using DNS that will present problems for MUD
      controllers, which <xref target="dns-anti-p"/> explains.</t>
      <t><xref target="sec-priv-out"/> details how current trends in DNS
      resolution such as public DNS servers, DNS over TLS (DoT) <xref
      target="RFC7858"/>, DNS over HTTPS (DoH) <xref target="RFC8484"/>, or
      DNS over QUIC (DoQ) <xref target="RFC9250"/> can cause problems with the
      strategies employed.</t>
      <t>The
<!--[rfced] Please clarify "with MUD supporting IoT devices".
Does it mean (A) "with IoT devices that support MUD"
or (B) "with MUD to support IoT devices" or otherwise?

Original:
   The core of this document, is <xref target="sec-reco"/>, Section 6, which makes a series of
   recommendations ("best current practices") for manufacturers on how
   to use DNS and IP addresses with MUD supporting IoT devices.</t> devices.

Perhaps (if A):
   The core of this document is Section 6, which makes a series of
   recommendations ("best current practices") for manufacturers on how
   to use DNS and IP addresses with IoT devices that support MUD.
-->
      <t>The core of this document is <xref target="sec-reco"/>, which makes a
      series of recommendations ("best current practices") for manufacturers
      on how to use DNS and IP addresses with IoT devices described by MUD.</t>
      <t><xref target="sec-privacy"/> discusses a set of privacy issues that
      encrypted DNS (DoT, DoH, for example) (for example, DoT and DoH) are frequently used to deal
      with.  How these concerns apply to IoT devices located within a
      residence or enterprise is a key concern.</t>
      <t><xref target="sec-security"/> also covers some of the negative outcomes should MUD/firewall managers and IoT manufacturers choose not to cooperate.</t>
    </section>
    <section anchor="Terminology">
      <name>Terminology</name>
      <t>This document makes use of terms defined in <xref target="RFC8520"/>
      and <xref target="I-D.ietf-dnsop-rfc8499bis"/>.</t> target="RFC9499"/>.</t>
      <t>The term "anti-pattern" comes from agile software design literature,
      as per <xref target="antipatterns"/>.</t>
      <t>CDN target="antipattern"/>.</t>
      <t>"CDNs" refers to Content Distribution Networks, such as those described by in
      <xref section="1.1" sectionFormat="comma" target="RFC6707"/>.</t>
    </section>
    <section anchor="mapping">
      <name>A model Model for MUD controller mapping Controller Mapping of DNS names Names to addresses</name> Addresses</name>
      <t>This section details a strategy that a MUD controller could take.
      Within the limits of the DNS use detailed in <xref target="sec-reco"/>,
      this process can could work.  The methods detailed in <xref
      target="failingstrategy"/> just will not work.</t>
      <t>The simplest successful strategy for translating DNS names for a MUD controller to take translate
      DNS names is to do a DNS lookup on the name (a forward lookup), lookup) and then
      use the resulting IP addresses to populate the actual ACLs.</t>

<!--[rfced] May this be rephrased for simplicity?

Original:
   The simplest successful strategy for translating DNS names for a MUD
   controller to take is to do a DNS lookup on the name ...

Perhaps:
   The simplest successful strategy for a MUD controller
   to translate DNS names is to do a DNS lookup on the name ...
-->
      <t>There are a number of possible failures, and the goal of this section is
      to explain how some common DNS usages may fail.</t>
      <section anchor="non-deterministic-mappings">
        <name>Non-Deterministic Mappings</name>
        <t>The most important one is that
        <t>Most importantly, the mapping of the DNS names to IP addresses may
        could be non-deterministic.</t>
        <t><xref target="RFC1794"/> describes the very common mechanism that
        returns DNS A (or reasonably AAAA) records in a permuted order.  This
        is known as Round Robin DNS, "round-robin DNS" and it has been used for many decades.  The
        historical intent is that the requestor will tend to use the first IP
        address that is returned.  As each query results in addresses being in a
        different ordering, order, the effect is to split the load among many
        servers.</t>
        <t>This situation does not result in failures as long as all possible
        A/AAAA records are returned.  The MUD controller and the device get a
        matching set, and the ACLs that are set up cover all
        possibilities.</t>
        <t>There are a number of circumstances in which the list is not
        exhaustive.  The simplest is when the round-robin DNS does not return
        all addresses.  This is routinely done by geographical DNS load balancing
        load-balancing systems: only Only the addresses that the balancing system
        wishes to be used are returned.</t>
        <t>It
        <t>Failure can also happen occur if there are more addresses than what will
        conveniently fit into a DNS reply.  The reply will be marked as
        truncated.  (If DNSSEC resolution will be done, then the entire RR
        must be retrieved over TCP (or using a larger EDNS(0) size) before
        being validated)</t> validated.)</t>
        <t>However, in a geographical DNS load balancing load-balancing system, different
        answers are given based upon the locality of the system asking.  There
        may also be further layers of round-robin indirection.</t>
        <t>Aside from the list of records being incomplete, the list may have
        changed between the time that the MUD controller did the lookup and
        the time that the IoT device did the lookup, and this change can
        result in a failure for the ACL to match.  If the IoT device did not
        use the same recursive servers as the MUD controller, then tailored
        DNS replies and/or truncated round-robin results could return a different,
        different and non-overlapping set of addresses.</t>
        <t>In order to compensate for this, the MUD controller performs
        regular DNS lookups in order to never have stale data.  These lookups
        must be rate limited rate-limited to avoid excessive load on the DNS servers, and
        it may be necessary to avoid local recursive resolvers.  A MUD
        controller that incorporates its own recursive caching DNS client will
        be able to observe the TTL on the entries, entries and expire cause them to expire
        appropriately.  This cached cache will last for at least some number of minutes,
        minutes and up to some number of days (respecting the TTL), while the
        underlying DNS data can change at a higher frequency, providing
        different answers to different queries!</t>
        <t>A MUD controller that is aware of which recursive DNS server the
        IoT device will use can instead query that server on a periodic basis.
        Doing so provides three advantages:</t>
        <ol spacing="normal" type="1"><li> type="1">
	  <li>
            <t>Any geographic load balancing load-balancing will base the decision on the
            geolocation of the recursive DNS server, and the recursive name
            server will provide the same answer to the MUD controller as to
            the IoT device.</t>
          </li>
          <li>
            <t>The resulting mapping (of name to IP address mapping address) in the recursive
            name server will be cached, cached and will remain the same for the entire
            advertised Time-To-Live TTL reported in the DNS query return.  This
            also allows the MUD controller to avoid doing unnecessary
            queries.</t>
          </li>
          <li>
            <t>if
            <t>If any addresses have been omitted in a round-robin DNS
            process, the cache will have the same set of addresses that were
            returned.</t>
          </li>
        </ol>
        <t>The solution of using the same caching recursive resolver as the
        target device is very simple when the MUD controller is located in a
        residential CPE Customer Premises Equipment (CPE) device.  The device is usually also the policy enforcement
        policy-enforcement point for the ACLs, and a caching resolver is
        typically located on the same device.  In addition to convenience,
        there is a shared fate advantage: as As all three components are running
        on the same device, if the device is rebooted, clearing rebooted (which clears the cache, cache),
        then all three components will get restarted when the device is
        restarted.</t>
        <t>Where the
        <t>The solution is more complex and sometimes more fragile is when the
        MUD controller is located elsewhere in an Enterprise, enterprise or remotely in a cloud
        cloud, such as when a Software Defined Software-Defined Network (SDN) is used to manage
        the ACLs.  The DNS servers for a particular device may not be known to
        the MUD controller, nor and the MUD controller be may not even be permitted
        to make recursive queries to that server if it is known.  In this
        case, additional installation specific installation-specific mechanisms are probably needed
        to get the right view of the DNS.</t>
        <t>A critical failure can occur when the device makes a new DNS
        request and receives a new set of IP addresses, but the MUD
        controller's copy of the addresses has not yet reached their time to live. TTL.  In that case, the MUD controller still has the old address(es) addresses
        implemented in the ACLs, but the IoT device has a new address not
        previously returned to the MUD controller.  This can result in a
        connectivity failure.</t>
      </section>
    </section>
    <section anchor="dns-anti-p">
      <name>DNS and IP Anti-Patterns for IoT Device Manufacturers</name>
      <t>In many design fields, there are good patterns that should be
      emulated, and often there are patterns that should not be emulated.  The
      latter are called anti-patterns, as per <xref target="antipatterns"/>.</t>
      target="antipattern"/>.</t>
      <t>This section describes a number of things which that IoT manufacturers have
      been observed to do in the field, each of which presents difficulties for
      MUD enforcement points.</t>
      <section anchor="inprotocol">
        <name>Use of IP Address Literals</name>
        <t>A common pattern for a number of devices is to look for firmware
        updates in a two-step process.  An initial query is made (often over
        HTTPS, sometimes with a POST, but the method is immaterial) to a
        vendor system that knows whether an update is required.</t>
        <t>The current firmware model of the device is sometimes provided provided, and
        then the vendor's authoritative server provides a determination if a
        new version is required and, if so, what version.  In simpler cases,
        an HTTPS endpoint is queried queried, which provides the name and URL of the
        most recent firmware.</t>
        <t>The authoritative upgrade server then responds with a URL of a
        firmware blob that the device should download and install.  Best
        practice is that either firmware is either signed internally (<xref target="RFC9019"/>) <xref
        target="RFC9019"/> so that it can be verified, or a hash of the blob
        is provided.</t>
        <t>An authoritative server might be tempted to provide an IP address
        literal inside the protocol.  An argument for doing this is that it
        eliminates problems with firmware updates that might be caused by a
        lack of DNS, DNS or by incompatibilities with DNS.  For instance instance, a bug
        that causes interoperability issues with some recursive servers would
        become unpatchable for devices that were forced to use that recursive
        resolver type.</t>
        <t>But, there are several problems with the use of IP address literals
        for the location of the firmware.</t>
        <t>The first is that the update service server must decide whether to
        provide an IPv4 or an IPv6 literal, assuming that only one URL can be
        provided.  A DNS name can contain both kinds of addresses, addresses and can
        also contain many different IP addresses of each kind.
<!--[rfced] Please review; does the updated sentence convey the intended
meaning? It has been rephrased to avoid the use of two "but" phrases
in a row. (Also, "literate" was changed to "literal".)

Original:
   An update
   server might believe that if the connection was on IPv4, that an IPv4
   literate would be acceptable, but due to NAT64 [RFC6146] a device
   with only IPv6 connectivity will often be able to reach an IPv4
   firmware update server by name (through DNS64 [RFC6147]), but not be
   able to reach arbitrary IPv4 address.

Current:
   An update
   server might believe that if the connection were on IPv4, then an IPv4
   literal would be acceptable.  However, due to NAT64 [RFC6146], a
   device with only IPv6 connectivity will often be able to reach an
   IPv4 firmware update server by name (through DNS64 [RFC6147]) but not
   be able to reach an arbitrary IPv4 address.
-->
An update
        server might believe that if the connection were on IPv4, then an IPv4
        literal would be acceptable. However, due to NAT64 <xref target="RFC6146"/>
        target="RFC6146"/>, a device with only IPv6 connectivity will often be
        able to reach an IPv4 firmware update server by name (through DNS64
        <xref target="RFC6147"/>), target="RFC6147"/>) but not be able to reach an arbitrary IPv4
        address.</t>
        <t>A
<!--[rfced] May we change "A MUD file definition" to simply "A MUD file"?
We see zero usage of "MUD file definition" in RFC 8520 or other RFCs.

Original:
  A MUD file definition for this access would need to resolve ...

Original:
  A MUD file for this access would need to resolve ...
-->
        <t>A MUD file for this access would need to resolve to the
        set of IP addresses that might be returned by the update server.  This
        can be done with IP address literals in the MUD file, but this may
        require continuing updates to the MUD file if the addresses change
        frequently.  A DNS name in the MUD could resolve to the set of all
        possible IPv4 and IPv6 addresses that would be used, with DNS
        providing a level of indirection that obviates the need to update the
        MUD file itself.</t>
        <t>A third problem involves the use of HTTPS.  It is often more
        difficult to get TLS certificates for an IP address, and so it is less
        likely that the firmware download will be protected by TLS.  An IP
        address literal in the TLS ServerNameIndicator <xref target="RFC6066"/>,
        target="RFC6066"/> might not provide enough context for a web server
        to distinguish which of potentially
many tenants, the (potentially many) tenants the client wishes to
        reach.  This then drives the use of an IP address per-tenant, per tenant, and for
        IPv4 (at least), this is no longer a sustainable use of IP
        addresses.</t>
        <t>Finally, it is common in some Content Distribution Networks (CDNs) CDNs
        to use multiple layers of DNS CNAMEs in order to isolate the content-owner's content
        owner's naming system from changes in how the distribution network is
        organized.</t>
        <t>When a name or address is returned within an update protocol for
        which a MUD rule cannot be written, then the MUD controller is unable
        to authorize the connection.  In order for the connection to be
        authorized, the set of names returned within the update protocol needs
        to be known ahead of time, time and must be from a finite set of
        possibilities.  Such a set of names or addresses can be placed into
        the MUD file as an ACL in advance, and the connections can be
        authorized.</t>
      </section>
      <section anchor="use-of-non-deterministic-dns-names-in-protocols">
        <name>Use of Non-deterministic Non-Deterministic DNS Names in protocols</name> Protocols</name>
        <t>A second pattern is for a control protocol to connect to a known
        HTTP endpoint.  This is easily described in MUD.  References within
        that control protocol are made to additional content at other URLs.
        The values of those URLs do not fit any easily described pattern and
        may point at to arbitrary DNS names.</t>
        <t>Those DNS names are often within some third-party CDN system, system or may
        be arbitrary DNS names in a cloud-provider storage system (e.g., <xref target="AmazonS3"/>,
        target="AmazonS3"/> or <xref target="Akamai"/>).  Some of the name
        components may be specified by the third party third-party CDN provider.</t>
        <t>Such DNS names may be unpredictably chosen by the CDN, CDN and not the
        device manufacturer, manufacturer and so therefore impossible to insert into a MUD
        file.  Implementation of the CDN system may also involve HTTP
        redirections to downstream CDN systems.</t>
        <t>Even if the CDN provider's chosen DNS names are deterministic deterministic, they
        may change at a rate much faster than MUD files can be updated.</t>
        <t>This situation applies to firmware updates, updates but also applies to many
        other kinds of content: video content, in-game content, etc.</t>
        <t>A solution may be to use a deterministic DNS name, name within the
        control of the device manufacturer.
<!--[rfced] Should "CDN vendor's DNS" be "CDN provider's DNS" here,
because that phrase is used earlier within this section?
(Note: The apostrophe was added because it seems possessive was intended.)

Original:  the CDN vendors DNS will do all the appropriate work
Current:   the CDN vendor's DNS will do all the appropriate work
Perhaps:   the CDN provider's DNS will do all the appropriate work
-->
 The device manufacturer is asked
        to point a CNAME to the CDN, to a name that might look like
        "g7.a.example", with the expectation that the CDN vendors provider's DNS will do
        all the appropriate work to geolocate the transfer.  This can be fine
        for a MUD file, as the MUD controller, if located in the same
        geography as the IoT device, can follow the CNAME, CNAME and can collect the set
        of resulting IP addresses, addresses along with the TTL for each.
The  Then, the MUD
        controller can then take charge of refreshing that mapping at intervals
        driven by the TTL.</t>
        <t>In some cases, a complete set of geographically distributed servers
        may be known ahead of time (or that it changes very slowly), and the
        device manufacturer can list all those IP addresses in the DNS for the the
        name that it lists in the MUD file.  As long as the active set of
        addresses used by the CDN is a strict subset of that list, then the
        geolocated name can be used for the content download itself.</t>
      </section>
      <section anchor="use-of-a-too-generic-dns-name">
        <name>Use of a Too Generic DNS Name</name>
        <t>Some CDNs make all customer content available at a single URL (such
        as "s3.example.com").  This seems to be ideal from a MUD point of
        view: a completely predictable URL.</t>
        <t>The problem is that a compromised device could then connect to the
        contents of any bucket, potentially attacking the data from other
        customers.</t>
        <t>Exactly what the risk is depends upon what the other customers are
        doing: it It could be limited to simply causing a distributed
        denial-of-service attack resulting in high costs to those customers,
        or such an attack could potentially include writing
        content.</t>
        <t>Amazon has recognized the problems associated with this practice, practice
        and aims to change it to a virtual hosting model, as per <xref
        target="awss3virtualhosting"/>.</t>
        <t>The MUD ACLs provide only for permitting end points endpoints (hostnames and ports),
        ports) but do not filter URLs (nor could filtering be enforced within
        HTTPS).</t>
      </section>
    </section>
    <section anchor="sec-priv-out">
      <name>DNS Privacy and Outsourcing versus MUD Controllers</name>
      <t><xref target="RFC7858"/> and <xref target="RFC8094"/> provide for DoT
      and DoH.  <xref target="I-D.ietf-dnsop-rfc8499bis"/> target="RFC9499"/> details the terms.  But, even with
      the unencrypted DNS (a.k.a. Do53), it is possible to outsource DNS
      queries to other public services, such as those operated by Google,
      CloudFlare, Verisign, etc.</t>
      <t>For some users and classes of devices, revealing the DNS queries to
      those outside entities may constitute a privacy concern.  For other users
      users, the use of an insecure local resolver may constitute a privacy
      concern.</t>
      <t>As described above in <xref target="mapping"/> target="mapping"/>, the MUD controller
      needs to have access to the same resolver(s) resolver or resolvers as the IoT device.  If the
      IoT device does not use the DNS servers provided to it via DHCP or
      Router Advertisements, then the MUD controller will need to be told
      which servers will in fact be used.  As yet, there is no protocol to do
      this, but future work could provide this as an extension to MUD.</t>
      <t>Until such time as such a protocol exists, the best practice is for
      the IoT device to always use the DNS servers provided by DHCP or Router
      Advertisements.</t>
    </section>
    <section anchor="sec-reco">
      <name>Recommendations To to IoT Device Manufacturers on MUD and DNS Usage</name>
      <t>Inclusion of a MUD file with IoT devices is operationally quite
      simple.  It requires only a few small changes to the DHCP client code to
      express the MUD URL.  It can even be done without code changes via the
      use of a QR code affixed to the packaging (see <xref target="RFC9238"/>)</t>
      target="RFC9238"/>).</t>
      <t>The difficult part is determining what to put into the MUD file
      itself.  There are currently tools that help with the definition and
      analysis of MUD files, files; see <xref target="mudmaker"/>.
<!--[rfced] May "now" be removed from these two sentences,
or do you want to use a different phrase? (The preceding sentence is
included for context.)

Original:
   There are currently tools that help with the definition and
   analysis of MUD files, see [mudmaker].  The remaining difficulty is
   now the actual list of expected connections to put in the MUD file.
   An IoT manufacturer must now spend some time reviewing the network
   communications by their device.

Perhaps (if removing two instances of "now"):
   There are currently tools that help with the definition and
   analysis of MUD files; see [mudmaker].  The remaining difficulty is
   the actual list of expected connections to put in the MUD file.
   An IoT manufacturer must spend some time reviewing the network
   communications by their device.
-->

The remaining
      difficulty is the actual list of expected connections to put in the
      MUD file.  An IoT manufacturer must spend some time reviewing the
      network communications by their device.</t>
      <t>This document discusses a number of challenges that occur relating to
      how DNS requests are made and resolved, and the goal of this section is
      to make recommendations on how to modify IoT systems to work well with
      MUD.</t>
      <section anchor="consistently-use-dns">
        <name>Consistently use Use DNS</name>
        <t>For the reasons explained in <xref target="inprotocol"/>, the most
        important recommendation is to avoid using IP address literals in any
        protocol.  DNS names should always be used.</t>
      </section>
      <section anchor="use-primary-dns-names-controlled-by-the-manufacturer">
        <name>Use Primary DNS Names Controlled By The by the Manufacturer</name>
        <t>The second recommendation is to allocate and use DNS names within
        zones controlled by the manufacturer.  These DNS names can be
        populated with an alias (see <xref target="I-D.ietf-dnsop-rfc8499bis"/> section 2) target="RFC9499" section="2"
        sectionFormat="comma"/>) that points to the production system.
        Ideally, a different name is used for each logical function, allowing for
        different rules in the MUD file to be enabled and disabled.</t>
        <t>While it used to be costly to have a large number of aliases in a
        web server certificate, this is no longer the case.  Wildcard
        certificates are also commonly available which available; they allow for an infinite
        number of possible DNS names.</t>
      </section>
      <section anchor="use-content-distribution-network-with-stable-dns-names">
        <name>Use Content-Distribution a Content Distribution Network with Stable DNS Names</name>
        <t>When aliases point to a CDN, prefer give preference to stable DNS names
        that point to appropriately load balanced load-balanced targets.  CDNs that employ
        very low time-to-live (TTL) TTL values for DNS make it harder for the MUD
        controller to get the same answer as the IoT Device. device.  A CDN that
        always returns the same set of A and AAAA records, but permutes them to
        provide the best one first first, provides a more reliable answer.</t>
      </section>
      <section anchor="tailorednames">
        <name>Do Not Use Tailored Responses to answer Answer DNS Names</name>
        <t><xref target="RFC7871"/> defines the edns-client-subnet (ECS) EDNS0 option,
        option and explains how authoritative servers sometimes answer queries
        differently based upon the IP address of the end system making the
        request.  Ultimately, the decision is based upon some topological
        notion of closeness.  This is often used to provide tailored responses
        to clients, providing them with a geographically advantageous
        answer.</t>
        <t>When the MUD controller makes its DNS query, it is critical that it receive
        receives an answer which that is based upon the same topological decision as
        when the IoT device makes its query.</t>
        <t>There are probably ways in which the MUD controller could use the
        edns-client-subnet option to make a query that would get the same
        treatment as when the IoT device makes its query.  If this worked worked,
        then it would receive the same answer as the IoT device.</t>
        <t>In practice it could be quite difficult if the IoT device uses a
        different Internet connection, a different firewall, or a different
        recursive DNS server.  The edns-client-server might be ignored or
        overridden by any of the DNS infrastructure.</t>
        <t>Some tailored responses might only re-order reorder the replies so that the
        most preferred address is first.  Such a system would be acceptable if
        the MUD controller had a way to know that the list was complete.</t>
        <t>But, due to the above problems, a strong recommendation is to avoid
        using tailored responses as part of the DNS names in the MUD file.</t>
      </section>
      <section anchor="prefer-dns-servers-learnt-from-dhcprouter-advertisements"> anchor="prefer-dns-servers-learned-from-dhcprouter-advertisements">
        <name>Prefer DNS Servers Learnt From Learned from DHCP/Router Advertisements</name>
        <t>The best practice is for IoT Devices devices to do DNS with the DHCP provided
        DHCP-provided DNS servers, servers or with DNS servers learnt learned from Router
        Advertisements <xref target="RFC8106"/>.</t>
        <t>The ADD WG Adaptive DNS Discovery (ADD) Working Group has written <xref target="RFC9463"/> target="RFC9462"/> and <xref target="RFC9462"/>
        target="RFC9463"/> to provide information to end devices on how to
        find locally provisioned secure/private DNS servers.</t>
        <t>Use of public resolvers instead of the locally provided DNS
        resolver, whether Do53, DoQ, DoT DoT, or  DoH DoH, is discouraged.</t>
        <t>Some manufacturers would like to have a fallback to using a public
        resolver to mitigate against local misconfiguration.  There are a
        number of reasons to avoid this, detailed in <xref
        target="tailorednames"/>.  The public resolver might not return the
        same tailored names that the MUD controller would get.</t>
        <t>It is recommended that use of non-local resolvers is are only done used when
        the locally provided resolvers provide no answers to any queries at all,
        all and do so repeatedly.  The status of the operator provided operator-provided
        resolvers needs to be re-evaluated on a periodic basis.</t>
        <t>Finally,
<!--[rfced] FYI, this sentence has been updated to use singular "resolver"
and "destination". Please let us know if that was not the intention.

Original:
   Finally, if a device will ever attempt to use a non-local resolvers,
   then the address of that resolver needs to be listed in the MUD file
   as destinations that are to be permitted.

Current:
   Finally, if a device will ever attempt to use a non-local resolver,
   then the address of that resolver needs to be listed in the MUD file
   as a destination that is to be permitted.
-->
        <t>Finally, if a device will ever attempt to use non-local resolvers,
        then the addresses of those resolvers need to be listed in the MUD
        file as destinations that are to be permitted. This needs to include
        the port numbers (i.e., 53, 853 for DoT, 443 for DoH) that will be
        used as well.</t>
      </section>
    </section>
    <section anchor="interactions-with-mdns-and-dnssd">
      <name>Interactions with mDNS and DNSSD</name> DNS-SD</name>
      <t>Unicast DNS requests are not the only way to map names to IP
      addresses.  IoT devices might also use mDNS Multicast DNS (mDNS) <xref target="RFC6762"/>,
      both to be discovered by other devices, devices and also to discover other
      devices.</t>
      <t>mDNS replies include A and AAAA records, and it is conceivable that
      these replies contain addresses which that are not local to the link on which
      they are made.  This could be the result of another device which that contains
      malware.  An unsuspecting IoT device could be led to contact some
      external host as a result.  Protecting against such things is one of the
      benefits of MUD.</t>
      <t>In the unlikely case that the external host has been listed as a
      legitimate destination in a MUD file, then communication will
      continue as expected.  As an example of this, example, an IoT device might look
      for a name like "update.local" in order to find a source of firmware
      updates.  It could be led to connect to some external host that was
      listed as "update.example" in the MUD file.  This should work fine if
      the name "update.example" does not require any kind of tailored
      reply.</t>
      <t>In residential networks networks, there has typically not been more than one
      network (although this is changing through work like <xref
      target="I-D.ietf-snac-simple"/>), but on campus or enterprise networks,
      having more than one network is not unusual.  In such networks, mDNS is
      being replaced with DNS-SD DNS-based Service Discovery (DNS-SD) <xref target="RFC8882"/>, and in such a
      situation, connections could be initiated to other parts of the network.
      Such connections might traverse the MUD policy enforcement point (an
      intra-department firewall), firewall) and could very well be rejected because the
      MUD controller did not know about that interaction.</t>
      <t><xref target="RFC8250"/> includes a number of provisions for
      controlling internal communications, including complex communications
      like same manufacturer ACLs.  To date, this aspect of MUD has been
      difficult to describe.  This document does not consider internal
      communications to be in scope.</t>
    </section>
    <section anchor="sec-privacy">
      <name>Privacy Considerations</name>
      <t>The use of non-local DNS servers exposes the list of DNS names
      resolved to a third party, including passive eavesdroppers.</t>
      <t>The use of DoT and DoH eliminates the threat from passive eavesdropping,
      eavesdropping but still exposes the list to the operator of the DoT or
      DoH server.  There are additional methods to help preserve privacy, such
      as that described by <xref target="RFC9230"/>.</t>
      <t>The use of unencrypted (Do53) requests to a local DNS server exposes
      the list to any internal passive eavesdroppers, and for eavesdroppers. For some situations situations,
      that may be significant, particularly if unencrypted Wi-Fi WiFi is used.</t>
      <t>Use of Encrypted an encrypted DNS connection to a local DNS recursive resolver
      is the preferred choice.</t>
      <t>IoT devices that reach out to the manufacturer at regular intervals
      to check for firmware updates are informing passive eavesdroppers of the
      existence of a specific manufacturer's device being present at the
      origin location.</t>
      <t>Identifying the IoT device type empowers the attacker to launch
      targeted attacks to the IoT device (e.g., Attacker the attacker can take
      advantage of any known vulnerability on the device).</t>
      <t>While possession of a Large (Kitchen) Appliance "large kitchen appliance" at a residence may be
      uninteresting to most, possession of intimate personal devices (e.g.,
      "sex toys") may be a cause for embarrassment.</t>
      <t>IoT device manufacturers are encouraged to find ways to anonymize
      their update queries.  For instance, contracting out the update
      notification service to a third party that deals with a large variety of
      devices would provide a level of defense against passive eavesdropping.
      Other update mechanisms should be investigated, including use of DNSSEC signed
      DNSSEC-signed TXT records with current version information.  This would
      permit DoT or DoH to convey the update notification in a private
      fashion.  This is particularly powerful if a local recursive DoT server
      is used, which then communicates using DoT over the Internet.</t>
      <t>The more complex case of <xref target="inprotocol"/> postulates that
      the version number needs to be provided to an intelligent agent that can
      decide the correct route to do upgrades.  <xref target="RFC9019"/>
      provides a wide variety of ways to accomplish the same thing without
      having to divulge the current version number.</t>
    </section>
    <section anchor="sec-security">
      <name>Security Considerations</name>
      <t>This document deals with conflicting Security security requirements:</t>
      <ol spacing="normal" type="1"><li>
      <ul spacing="normal">
	<li>
          <t>devices which that an operator wants to manage using <xref target="RFC8520"/></t>
        </li>
        <li>
          <t>requirements for the devices to get access to network resources
          that may be critical to their continued safe operation.</t> operation</t>
        </li>
      </ol>
      </ul>
      <t>This document takes the view that the two requirements do not need to
      be in conflict, but resolving the conflict requires careful planning on
      how the DNS can be safely and effectively be used by MUD controllers and
      IoT devices.</t>
      <t>When an IoT device with an inaccurate MUD file is deployed into a
      network that uses MUD, there is a significant possibility that the
      device will cause a spurious security exception to be raised.  There is
      significant evidence that such spurious exceptions can cause significant
      overhead to personnel.  In particular, repeated spurious exceptions are
      likely to cause the entire exception process to be turned off.  When MUD
      alerts are turned off, then even legitimate exceptions are ignored.
      This is very much a Boy Who Calls Wolf <xref target="boywhocriedwolf"/>
      situation.</t>
      <t>In order to avoid this situation, and for MUD alerts to be given
      appropriate attention, it is key that IoT device manufacturers create
      accurate MUD files.  This may require some significant thought, thought and even
      rework of key systems, systems so that all network access required by the IoT
      device can be described by a MUD file.  This level of informed
      cooperation within the IoT device vendor and with MUD controller
      manufacturers is key to getting significant return on investment from
      MUD.</t>
      <t>Manufacturers are encouraged to write MUD files that are good enough, enough
      rather than perfect.  If in doubt, they should write MUD files that are
      somewhat more permissive if it results the files result in no spurious alerts.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-snac-simple" to="AUTO-STUB-NETWORKS"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8520" target="https://www.rfc-editor.org/info/rfc8520" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml">
          <front>
            <title>Manufacturer Usage Description Specification</title>
            <author fullname="E. Lear" initials="E." surname="Lear"/>
            <author fullname="R. Droms" initials="R." surname="Droms"/>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.</t>
              <t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8520"/>
          <seriesInfo name="DOI" value="10.17487/RFC8520"/>
        </reference>
        <reference anchor="RFC1794" target="https://www.rfc-editor.org/info/rfc1794" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1794.xml">
          <front>
            <title>DNS Support
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1794.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9019.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8250.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- [rfced] FYI, for Load Balancing</title>
            <author fullname="T. Brisco" initials="T." surname="Brisco"/>
            <date month="April" year="1995"/>
            <abstract>
              <t>This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and references to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1794"/>
          <seriesInfo name="DOI" value="10.17487/RFC1794"/>
        </reference>
        <reference anchor="I-D.ietf-dnsop-rfc8499bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8499bis-10" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-rfc8499bis.xml">
          <front>
            <title>DNS Terminology</title>
            <author fullname="Paul E. Hoffman" initials="P. E." surname="Hoffman">
              <organization>ICANN</organization>
            </author>
            <author fullname="Kazunori Fujiwara" initials="K." surname="Fujiwara">
              <organization>Japan Registry Services Co., Ltd.</organization>
            </author>
            <date day="25" month="September" year="2023"/>
            <abstract>
              <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc8499bis-10"/>
        </reference>
        <reference anchor="RFC9019" target="https://www.rfc-editor.org/info/rfc9019" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9019.xml">
          <front>
            <title>A Firmware Update Architecture for Internet of Things</title>
            <author fullname="B. Moran" initials="B." surname="Moran"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="D. Brown" initials="D." surname="Brown"/>
            <author fullname="M. Meriac" initials="M." surname="Meriac"/>
            <date month="April" year="2021"/>
            <abstract>
              <t>Vulnerabilities in Internet of Things (IoT) devices Wikipedia pages - [AmazonS3], [Akamai]
[boywhocriedwolf] - we have raised updated the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.</t>
              <t>In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9019"/>
          <seriesInfo name="DOI" value="10.17487/RFC9019"/>
        </reference>
        <reference anchor="RFC8094" target="https://www.rfc-editor.org/info/rfc8094" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml">
          <front>
            <title>DNS over Datagram Transport Layer Security (DTLS)</title>
            <author fullname="T. Reddy" initials="T." surname="Reddy"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <author fullname="P. Patil" initials="P." surname="Patil"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>DNS queries and responses are visible data to network elements on the path between the DNS client and its server. These queries most current revision
and responses can contain privacy-sensitive information, which is valuable to protect.</t>
              <t>This document proposes updated the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms URL to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8094"/>
          <seriesInfo name="DOI" value="10.17487/RFC8094"/>
        </reference>
        <reference anchor="RFC8250" target="https://www.rfc-editor.org/info/rfc8250" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8250.xml">
          <front>
            <title>IPv6 Performance and Diagnostic Metrics (PDM) Destination Option</title>
            <author fullname="N. Elkins" initials="N." surname="Elkins"/>
            <author fullname="R. Hamilton" initials="R." surname="Hamilton"/>
            <author fullname="M. Ackermann" initials="M." surname="Ackermann"/>
            <date month="September" year="2017"/>
            <abstract>
              <t>To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8250"/>
          <seriesInfo name="DOI" value="10.17487/RFC8250"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name> date-specific URL. Please let us know if you
prefer otherwise.
-->
        <reference anchor="AmazonS3" target="https://en.wikipedia.org/wiki/Amazon_S3"> target="https://en.wikipedia.org/w/index.php?title=Amazon_S3&amp;oldid=1280379498">
          <front>
            <title>Amazon S3</title>
            <author>
              <organization/>
              <organization>Wikipedia</organization>
            </author>
            <date year="2019"/> day="14" month="March" year="2025"/>
          </front>
        </reference>

        <reference anchor="Akamai" target="https://en.wikipedia.org/wiki/Akamai_Technologies"> target="https://en.wikipedia.org/w/index.php?title=Akamai_Technologies&amp;oldid=1277665363">
          <front>
            <title>Akamai</title>
            <title>Akamai Technologies</title>
            <author>
              <organization/>
              <organization>Wikipedia</organization>
            </author>
            <date year="2019"/> day="26" month="February" year="2025"/>
          </front>
        </reference>

        <reference anchor="mudmaker" target="https://mudmaker.org">
          <front>
            <title>Mud
            <title>MUD Maker</title>
            <author>
              <organization/>
            </author>
            <date year="2019"/>
            <date/>
          </front>
        </reference>

        <reference anchor="antipatterns" anchor="antipattern" target="https://www.agilealliance.org/glossary/antipattern">
          <front>
            <title>AntiPattern</title>
            <author>
              <organization/>
              <organization>Agile Alliance</organization>
            </author>
            <date year="2021" month="July" day="12"/>
            <date/>
          </front>
        </reference>

        <reference anchor="boywhocriedwolf" target="https://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf"> target="https://en.wikipedia.org/w/index.php?title=The_Boy_Who_Cried_Wolf&amp;oldid=1274257821">
          <front>
            <title>Boy who
            <title>The Boy Who Cried Wolf</title>
            <author>
              <organization/>
              <organization>Wikipedia</organization>
            </author>
            <date year="2024" month="August" day="15"/> year="2025" month="February" day="6"/>
          </front>
        </reference>

        <reference anchor="awss3virtualhosting" target="https://techmonitor.ai/techonology/cloud/aws-s3-path-deprecation">
          <front>
            <title>Down to the Wire: AWS Delays 'Path-Style' S3 Deprecation at Last Minute</title>
            <author>
              <organization/>
              <organization>Tech Monitor</organization>
            </author>
            <date year="2021" month="July" day="12"/>
          </front>
        </reference>
        <reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7858" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="D. Wessels" initials="D." surname="Wessels"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
              <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RFC9250" target="https://www.rfc-editor.org/info/rfc9250" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml">
          <front>
            <title>DNS over Dedicated QUIC Connections</title>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9250"/>
          <seriesInfo name="DOI" value="10.17487/RFC9250"/>
        </reference>
        <reference anchor="RFC6707" target="https://www.rfc-editor.org/info/rfc6707" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml">
          <front>
            <title>Content Distribution Network Interconnection (CDNI) Problem Statement</title>
            <author fullname="B. Niven-Jenkins" initials="B." surname="Niven-Jenkins"/>
            <author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <date year="2020" month="September" year="2012"/>
            <abstract>
              <t>Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.</t>
              <t>The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6707"/>
          <seriesInfo name="DOI" value="10.17487/RFC6707"/>
        </reference>
        <reference anchor="RFC6146" target="https://www.rfc-editor.org/info/rfc6146" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml">
          <front>
            <title>Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers</title>
            <author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
            <author fullname="P. Matthews" initials="P." surname="Matthews"/>
            <author fullname="I. van Beijnum" initials="I." surname="van Beijnum"/>
            <date month="April" year="2011"/>
          </front>
          <seriesInfo name="RFC" value="6146"/>
          <seriesInfo name="DOI" value="10.17487/RFC6146"/>
        </reference>
        <reference anchor="RFC6147" target="https://www.rfc-editor.org/info/rfc6147" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml">
          <front>
            <title>DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers</title>
            <author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
            <author fullname="P. Matthews" initials="P." surname="Matthews"/>
            <author fullname="I. van Beijnum" initials="I." surname="van Beijnum"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6147"/>
          <seriesInfo name="DOI" value="10.17487/RFC6147"/>
        </reference>
        <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="January" year="2011"/>
            <abstract>
              <t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6066"/>
          <seriesInfo name="DOI" value="10.17487/RFC6066"/>
        </reference>
        <reference anchor="RFC9238" target="https://www.rfc-editor.org/info/rfc9238" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9238.xml">
          <front>
            <title>Loading Manufacturer Usage Description (MUD) URLs from QR Codes</title>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="J. Latour" initials="J." surname="Latour"/>
            <author fullname="H. Habibi Gharakheili" initials="H." surname="Habibi Gharakheili"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>This informational document details a protocol to load Manufacturer Usage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.</t>
              <t>This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9238"/>
          <seriesInfo name="DOI" value="10.17487/RFC9238"/>
        </reference>
        <reference anchor="RFC7871" target="https://www.rfc-editor.org/info/rfc7871" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml">
          <front>
            <title>Client Subnet in DNS Queries</title>
            <author fullname="C. Contavalli" initials="C." surname="Contavalli"/>
            <author fullname="W. van der Gaast" initials="W." surname="van der Gaast"/>
            <author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.</t>
            </abstract> day="24"/>
          </front>
          <seriesInfo name="RFC" value="7871"/>
          <seriesInfo name="DOI" value="10.17487/RFC7871"/>
        </reference>
        <reference anchor="RFC8106" target="https://www.rfc-editor.org/info/rfc8106" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml">
          <front>
            <title>IPv6 Router Advertisement Options for DNS Configuration</title>
            <author fullname="J. Jeong" initials="J." surname="Jeong"/>
            <author fullname="S. Park" initials="S." surname="Park"/>
            <author fullname="L. Beloeil" initials="L." surname="Beloeil"/>
            <author fullname="S. Madanapalli" initials="S." surname="Madanapalli"/>
            <date month="March" year="2017"/>
            <abstract>
              <t>This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.</t>
              <t>This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8106"/>
          <seriesInfo name="DOI" value="10.17487/RFC8106"/>
        </reference>
        <reference anchor="RFC9463" target="https://www.rfc-editor.org/info/rfc9463" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml">
          <front>
            <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <author fullname="N. Cook" initials="N." surname="Cook"/>
            <author fullname="T. Jensen" initials="T." surname="Jensen"/>
            <date month="November" year="2023"/>
            <abstract>
              <t>This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9463"/>
          <seriesInfo name="DOI" value="10.17487/RFC9463"/>
        </reference>
        <reference anchor="RFC9462" target="https://www.rfc-editor.org/info/rfc9462" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml">
          <front>
            <title>Discovery of Designated Resolvers</title>
            <author fullname="T. Pauly" initials="T." surname="Pauly"/>
            <author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
            <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <author fullname="T. Jensen" initials="T." surname="Jensen"/>
            <date month="November" year="2023"/>
            <abstract>
              <t>This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9462"/>
          <seriesInfo name="DOI" value="10.17487/RFC9462"/>
        </reference>
        <reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6762" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
          <front>
            <title>Multicast DNS</title>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
            <date month="February" year="2013"/>
            <abstract>
              <t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t>
              <t>Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t>
              <t>The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6762"/>
          <seriesInfo name="DOI" value="10.17487/RFC6762"/>
        </reference>
        <reference anchor="I-D.ietf-snac-simple" target="https://datatracker.ietf.org/doc/html/draft-ietf-snac-simple-05" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-snac-simple.xml">
          <front>
            <title>Automatically Connecting Stub Networks to Unmanaged Infrastructure</title>
            <author fullname="Ted Lemon" initials="T." surname="Lemon">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Jonathan Hui" initials="J." surname="Hui">
              <organization>Google LLC</organization>
            </author>
            <date day="8" month="July" year="2024"/>
            <abstract>
              <t>This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9238.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>

<!-- [I-D.ietf-snac-simple] IESG State: I-D Exists as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network).</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-snac-simple-05"/>
        </reference>
        <reference anchor="RFC8882" target="https://www.rfc-editor.org/info/rfc8882" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8882.xml">
          <front>
            <title>DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements</title>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <author fullname="D. Kaiser" initials="D." surname="Kaiser"/>
            <date month="September" year="2020"/>
            <abstract>
              <t>DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8882"/>
          <seriesInfo name="DOI" value="10.17487/RFC8882"/>
        </reference>
        <reference anchor="RFC9230" target="https://www.rfc-editor.org/info/rfc9230" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9230.xml">
          <front>
            <title>Oblivious DNS over HTTPS</title>
            <author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <author fullname="T. Pauly" initials="T." surname="Pauly"/>
            <author fullname="T. Verma" initials="T." surname="Verma"/>
            <author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.</t>
              <t>This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9230"/>
          <seriesInfo name="DOI" value="10.17487/RFC9230"/>
        </reference> 02/26/25 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-snac-simple.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8882.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9230.xml"/>
      </references>
    </references>
    <?line 468?>

<section anchor="failingstrategy">
      <name>A Failing Strategy --- Strategy: Anti-Patterns</name>
      <t>Attempts to map IP addresses to DNS names in real time often fails fail for a number of reasons:</t>
      <ol spacing="normal" type="1"><li>
          <t>it type="1">
	<li>
          <t>It can not be done fast enough,</t> enough.</t>
        </li>
        <li>
          <t>it
          <t>It reveals usage patterns of the devices,</t> devices.</t>
        </li>
        <li>
          <t>the
          <t>The mappings are often incomplete,</t> incomplete.</t>
        </li>
        <li>
          <t>Even if the mapping is present, due to virtual hosting, it may
          not map back to the name used in the ACL.</t>
        </li>
      </ol>

      <t>This is not a successful strategy: strategy for the reasons explained below.</t>
      <section anchor="too-slow">
        <name>Too Slow</name>
        <t>Mappings of IP addresses to DNS names requires require a DNS lookup in the
        in-addr.arpa or ip6.arpa space.  For a cold DNS cache, this will
        typically require 2 to 3 NS record lookups to locate the DNS server
        that holds the information required.  At 20 to 100 ms per round trip,
        this easily adds up to a significant amount of time before the packet
        that caused the lookup can be released.</t>
        <t>While subsequent connections to the same site (and subsequent
        packets in the same flow) will not be affected if the results are
        cached, the effects will be felt.  The ACL results can be cached for a
        period of time given by the TTL of the DNS results, but the DNS lookup
        must be repeated, e.g, e.g., in a few hours or days,when days, when the cached binding (of IP
        address to name binding name) expires.</t>
      </section>
      <section anchor="reveals-patterns-of-usage">
        <name>Reveals Patterns of Usage</name>
        <t>By doing the DNS lookups when the traffic occurs, then a passive
        attacker can see when the device is active, active and may be able to derive
        usage patterns.  They could determine when a home was occupied or not.
        This does not require access to all on-path data, just to the DNS
        requests to the bottom level of the DNS tree.</t>
      </section>
      <section anchor="mappings-are-often-incomplete">
        <name>Mappings Are Often Incomplete</name>
        <t>An IoT manufacturer with a cloud service provider that fails to
        include an A or AAAA record as part of their forward name publication
        will find that the new server is simply not used.  The operational
        feedback for that mistake is immediate.  The same is not true for
        reverse DNS mappings: they They can often be incomplete or incorrect for
        months or even years without a visible effect on operations.</t>
        <t>IoT manufacturer cloud service providers often find it difficult to
        update reverse DNS maps in a timely fashion, assuming that they can do
        it at all.  Many cloud based cloud-based solutions dynamically assign IP addresses
        to services, often as the service grows and shrinks, reassigning those
        IP addresses to other services quickly.  The use of HTTP 1.1 Virtual
        Hosting may allow addresses and entire front-end systems to be re-used reused
        dynamically without even reassigning the IP addresses.</t>
        <t>In some cases cases, there are multiple layers of CNAME between the
        original name and the target service name.  This is often due to a load balancing
        load-balancing layer in the DNS, DNS followed by a load balancing load-balancing layer at
        the HTTP level.</t>
        <t>The reverse DNS mapping for the IP address of the load balancer
        usually does not change.  If hundreds of web services are funneled
        through the load balancer, it would require hundreds of PTR records to
        be deployed.  This would easily exceed the UDP/DNS and EDNS0 limits, limits
        and require all queries to use TCP, which would further slow
        down loading of the records.</t>
        <t>The enumeration of all services/sites that have been at that
        load balancer might also constitute a security concern.  To limit
        the churn of DNS PTR records, records and reduce failures of the MUD ACLs,
        operators would want to add all possible DNS names for each reverse
        DNS mapping, whether or not the DNS load balancing load-balancing in the forward DNS
        space lists that end-point endpoint at that moment.</t>
      </section>
      <section anchor="forward-dns-names-can-have-wildcards">
        <name>Forward DNS Names Can Have Wildcards</name>
        <t>In some large hosting providers providers, content is hosted through a domain
        name that is published as a DNS wildcard (and uses a wildcard
        certificate).

<!--[rfced] Please clarify "the Editors' copy of internet drafts".
What is this referring to? If this is referring to I-Ds created
using the i-d template build system, then perhaps "including the
Editors' copies of some Internet-Drafts that are stored on GitHub".

Original:
   For instance, github.io, which is used for hosted
   content, including the Editors' copy of internet drafts stored on
   github, does not actually publish any DNS names.

Current:
   For instance, github.io, which is used for hosted
   content, including the Editors' copy of Internet-Drafts stored on
   GitHub, does not actually publish any DNS names.
-->
For instance, github.io, which is used for hosting
        content, including the Editors' copy of Internet-Drafts stored on
        GitHub, does not actually publish any DNS names.  Instead, a wildcard
        exists to answer all potential DNS names: requests Requests are routed appropriate
        appropriately once they are received.</t>
        <t>This kind of system works well for self-managed hosted content.
        However, while it is possible to insert up to a few dozen PTR records,
        many thousand thousands of entries are not possible, nor is it possible to deal
        with the unlimited (infinite) number of possibilities that a wildcard
        supports.</t>
        <t>It
        <t>Therefore, it would be therefore impossible for the PTR reverse lookup to
        ever work with these wildcard DNS names.</t>
      </section>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> toc="include">
      <name>Contributors</name>
      <contact initials="T." surname="Reddy" surname="Reddy.K" fullname="Tirumaleswar Reddy"> Reddy.K">
        <organization>Nokia</organization>
        <address>
      </address>
      </contact>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA5V9WZfbRpLuO34FWn5w1bkktXqrlzvVKrutM7JarSqP7psP
CCRJjEAkB0uVaB399xtfLJkJkOWZ8TnToyKJXCIjI75YsVwus6EeGneV//Pg
umKofVs0+Wvf9nWlf/f5xnf5773L/Sa/eXeb123+xt/lN+6+Ll2fFet15+6v
8v1YLWs/LKu2zypftsWeRq26YjMsazdslv7QFw/bZfKzZTmZZ/n8pyyrD91V
PnRjP7x49uynZy+yonNFsro+e9jSn+9vrz/+I//ou091u83/0fnxkH16uMrf
tIPrWjcsbzBxVhbDVb4uD1l2qK9y+u+bvCzafKTNFF1XHPOLepMXTZMfXX+Z
0zZ3Rb/Ld65zWZ4PvrzCF/TP3ndD5zb9FQ9RuU0xNkNPv7Dvj3v5Wv8cirZa
Fo1vHW/GZVkxDjvfXWXZkuhHP/xtlX+oy13RVb1v6REh12/4yDXTr3xHO76l
EV2zp8Xf+s3wQFTh3WM2ty/qhuhfdv8HhP633n66Kosw38dV/r6IE310tf7N
o/86Fg/0yZ0rd61v/LZ2ycAPddPUxX51KFr60b/t+Ler0u+zrPXdno7l3l3R
zz/88vrH7148038+/+GnV1egFliGzqet6H/XxDv9eDgQOelXb5Y3K2YN4gV/
WHab8sdXP/20rnsd4qdnz3+inf/+5u76w+tfdYZnNCyxSbtJp77eF3/69vYl
/k0HJxz9RD7Nb18+kY+LbuuIH57shuHQXz196trVQ/2pPriqLlZEh6f466k8
9Yc9VRUDjfWCloJ5PhVEk9ks/Nn/bgp+5I+U3Gcmo5uyLz65bjrdb2OV/4aP
H5nRnsJsZwYt2qE+FANuSX91foSHh4dVsa0bV+Dc29LxwreN7/uiOz5NRngy
JQR98T79wiZ+8Xz57Ifl8xcZfbr2x4edL7vaVQ++2TyyhPNku9u5P/7uj398
3Pk/XmOEPz7SENNF0Pc5TZDz93n8Pqzl1fLZj8vn32EtxUPfv7yvu2Esmp3v
BxIlU1rf+IcWl3zY0W2rO/ro+uMtCb6mOPb5t7TX3fJ2ODbuW+Ix+vjQuZKF
VF4M+duiH+g+t+PgHjmpgY5/79t68N2qqPlPz+xwfFo2fqye0vqW/cvlAfNU
cfTHiEvSdOjq9Th4Zhm56Hd1N+6LxvUkMvIPrqqOduff+U81yYfs3rUjXyK5
7SKm/w33EpSnz7f1sBvXLGCeQnJDgp9Kb5I0y2VerPuhK8ohy+52dZ+THhj3
rh1IZA40ep9Pn6Gf+3HId/4hCG4oGXq03fb5BWmZS3qS1QzL7Dfvs6KqOtf3
9AFJOZYt2Ge/ovkc/YLGL8Ha+dqRgCIpXxL986LPaegHkpe0PUzuO/xiS9KI
6Nr4I5QICZcc8otuVztuaA9j56D3iq2js+2JZQ98the//X6DZW1qOjreBXEI
0943ulqalpZMi8qum94viH9SWuB69nmHBdLflZKCRn7YuZa3BYLQoNhy2CHU
Ls2cb+hiYmRQe19XVUPK5RuQr/PVWGKsLPvyRWXx16/5ofP3RHGil6glUiv1
n3Q1Hkj70RwV72zteE76ycGV9aYu88PYHTzNrxuSNY8CAsJZ0Un4sSuxnmve
MZAD0+Ft3ZN+vLh+/Zb0KlTu2gnJaOYam/xfkhu7JjLSvaLz29cDLVVXRnsQ
ap9ZVr4+4u7WXUJGUvJv3ueBjYiSCm2K8KOcOIQwAObjpcbf69ppW0AKRJX2
SF/dk0ikZZOWbT0xcNsc6bBpKogNEhU0Eg1ftxVJED4g2wO+3xeHA7iPF8CT
04bihBfAJfQJkY8QQbsl8vl7LK3eu0UOOhCD5VvXElc3dK50zHT/oRhLkt5H
Gez+FXMV/eP7uPEFbsWDI+xD/18WBAFIq7gvSHYORyyp8UWVr4uGtAC+w90e
HNQVzd2WzVjh0z1hoXr5+uadXiYweQ9m7hyRazYEeIHOi/DAwLhy6/y2Kw67
Iy8RP6YT+dU/ONrlgik0RuQpJwjK1/tDU5fx6oB7cSrARe6zw62vIIUxAG7N
wdPPj7kDbCgdX8ODr+l/L4bjQWhFBCE269wD/XG5yoiTy84NDl9gFPuKp1eO
46NW/fCWD/olgceC5FuPJePjQ1F+csNKxKHQTDlDeJS3TR8R7UV1xLNf8HcE
UMFVjlZzPGBXxNNv3veulGWlj/5+8x7sfff6fQ6Elbfjfk1rIsXRY8N0GHiC
zrDt+XtZKovOyPu0TMynD/0ty249nvRdBbbzTHkh4MASlx9aFz2tDLedV0WH
sCcED64tAoevSQI7J2sIEg1/4DFl0Mm9fGOzgk/2iZRgiUuAkv41JOKSZPCm
3tIPeDNF3/uyLkCxB1Jgp+uklXnCyTgoHkCJAOHRjExPAF8WXITjQXYwkgr6
BqsAqRwYgWDRioSu7pSELo/c0xHTnFvvq+TmiBQDnxJjg9mZM2QpTPt2GVF1
Tto8j4xD43h5HgZYEM0pZdi8mZFGd2bbwbygF+/03iUHQv864mteFU4Ry+RN
PADxEKXGHkeJ0XgZPKTxF2maNbGG2IszWi1IHpBNk+dfvgA6AEMuD0Qo9/nQ
FGSgrKC0iKmXh66+XxIooO8MM2AP5dh1zHP0vxVzzuys+pFGhyQb13TT+dve
dfc8Nf5gqXn39ja/uAGq+PLl/5IC+uHH7378+jX5wa93d+/5J7/aT3589eMr
/MR38Vf/+v3Na/zoX/ajn158B1UL2pcF5FUgBbMe3/bIAG4PKalnD8jSOZEW
CUhY4NSFIgAKWIEQUBRxgc1hLHpuDiQunqxJJgSKHQDHgKCeXJ65SCo6E7Ax
v4iyBRynGm5ggMh+05MryiMOru7LUTAarZMhnX5Ju+pHuwNRpGFenAudhP91
wct0nwsImktmwU3n/mukzTTHwLwVWSe8tBW0hcqigP7oIqryiwsl5VIGcQA9
DvYhZESP4HQd0AMts2cRWOSf6CroeGGL9H9jVw/YI+vdEuyg11zlfeu2fHVz
4mEgUPp258emAgWfBh1Ch0CAoVOxR2ucXeKdB/aCHGa5JqAV1/IbstFJVYuZ
kIf/vnyTfPx1Dr4n4I12SXyZYLEULGI5X748apd//ao8i0HyJ3KL1eLLZbeb
zu9zth6JLOqoIB1VbwkJ1AO2QVtcKOaguVJ7lIcHjujcRqU88CS2cEN4km0b
3PV3guXpZtutNxTL2lHu5Pc/PPthkd8q4nq+es6jf5Nfq6w9FVIpFotoA/gy
3IUv35iMVxr3Or7JqsIu+lHl/HyOkplhoBNZZR+FERkm1oS/ept5ZOCNEe2I
UkHAgoIkDEMQyBwQQ7T43g07X/Wzhzf0b1hUujI65/+EdmbhDR6T53mAntU7
fUmUxfibsYk7AskYPTTFYGpAiIRvTrYKYET7xHXChfWKsBvvP40HSB5TPPlF
gRGIVyr99lKwzwCDCMTAL+kIADQhfVLxREMf/GGkJcnPcIlINEDHRzVmUAiS
yPd9TcI5B1WIF/swFWnqogmS2E5WVq96ioUlX3fIXPpWjwvon9jnyIOCzb4h
87pd3riBryUxL+mk34R1eqH03hOVidokUekO5IAYtQrGmV0w7NyUHyf7x6xr
x7ihSqdbqRkIPxwrU7khgj1JbB1tC3sHy6Lu9zI5Yd4RIhQzXucXdLCdK3rf
FmuSqNf03yVrnE60cMGmA6NtxmoGdPv8UwvnCd3ND+z7+8C+PxpUUe3AOHrt
5IArU01kObmSUKkY9DmNRbY68DlNxoIgpRFrBfxAWJm+r0yTKWInEifGGz9Y
97pFKOBr0sYFiRAahwgiHCb7CvTlTVb1hiQS5udd0sEI+nb0cTkoj/RkksjC
2OYpiLhb2ZMiEQN7fU0sKmIDZiKuoEyNyYwtQboGI8DcAMoyvr1+ilMIhwAB
Gzd0p/ZOcg2NuxUubt3AoHwod2zSuSFeAEbiAZ9CddNFZSWXLIFkyVC7foIR
0wtW1h3pHcDPUsgnwEWkXD+YgeE+7wgqQVWuppKn7sURwicM3lmK3zihFXbL
K0rMBeM7eoSEhGMbXGC7mZjMRiKBplbtsR8Iq12pObdziZMp8Nr858Ry/U6u
o0Hq6UlkbwYxdgEUdnSbaUv1Rq0j/HQP3DeZSS0OOrt719aCdzY1uGIw4dmR
hX0UgvE/A6jfF90nrKFHvKFloLPKLt6wPrn9+fVjZs1CZCzzMmliWtGHD8F2
o80QyLw3nwPsSsgDsQGKvIFDs8t/phkunl3SAf5JcG3tNtjX2uE390VTw09Z
XSY2PV+o/9mZLJKLR2rngRETjb4lrmnVmBsPqkkA74g1jyYy9ZyKHiGilTIr
pCWfCG1vM3bs5mEXjUDphN0Sfw38eECKAm4CIyv2xiWU7ZKV5sHEg5BVfoUZ
d8V99N+kdjDcOJHHZhe3qivdGCtMu6TTZxJDcPp7u9V1rzMzN0Y5U5ikEbUu
tx/szKJhlb3ZnBsf98/ka8+uMkDiHoBXhRyz4MlmhM8yoBJijyrwci2O3KeM
LJRvJ8dgMllwk139yBeyTWg/8GijWlOtjrPeBEbUe7qOPSCDbL4Wv8X8BEi3
IcwEjbElhNEl+KWfOEVasLYcMwk+EtLE9YX5pO2BcK0wLwM+MWWKe0+UdZ+B
t0BIvgrK1Kkdm6niNI1vroc4Bl+B5EjUwofmuT5BZ6wMiWM7giC0ItoQAOhD
mzxfFqIksIqygUQKwqOAKqKJ/ZqXx4u9u3tr63YIRRi2IvAEyUKf72GZdZ7M
rAKeNZXamIbtMhq6QdiE4eSQNw5/MNyK6mXPIRUama4ElO702wp+igva9wFX
l5au67pk+7mRdbJ/pDnaznBWYrvLPWHYvqu3kA1qeZbHhTrS8dCpUAK+DR8C
TNDe/5Y9RnRiebaLaL2iGyPF43nPbx9TB1cPK61bkm3EJYJbeFR9yismq31F
kJNEZE2Hf+P5UvgYDBh2nXOp6zrLnq/y6zbVlnOZLEdf6O0nnFb3UCd64vQc
G9j80Ubx2em2ItiI37INoOtXjxIvM0oZobO5WucAp7cvIrnowr9Y5XcTs+HU
ux5Qtlphf7GktVM2lQ3wZx0C5G1cpQlS1aREXdcNNZTUHcns5Z1fvpVbCdAv
xpndcQOgEG8rxPf4YrCmIpzjH87J1HjvKz7fsY0iQXmQyPByBdghgQrDGiyo
GHt7uP01JjORu1iU2pgiGnn3sm9+POx6LmvVM+imaIghniGQ4EgMg5ikOZVd
pk8kfGq3gYjDNoygxggYZxSqo9cn9fgMNZJc3v8cmOUu4uManpKRgydMfnbi
PxY9SFSnyroi2YpugEbMQ5QhrMcnjGPLeMOGB0cV1aEtQLB05lZn11S/K6BD
N9Aj4QpfmaEgVxsqjvAdIjGMS4k52Jw8mXWhqDTZf+fW3g9g9ZJEcGcHxRyg
gPHsRMwcbGDQ3um82NlmJ5MOr18SW3zkXQ0pc7A3vJOBG/eZqQopD9yjX206
8TClpsLjJ++a3j0I9Th693Pw9LFbl26xhzISDuHIe/ArSUQ2ptzcqNtMPVD5
xe3Nu0thGdHl4tgLPBFjK4aOxFNyoP3XJUOK4MU/MrgiOSOW81lZt6DfdOe2
S485YGIN5NliPqUyTWWCjBw1Bh1/PQSLnZlQUGMBAhk/sgUObNOIiA+B4uA+
EEaD55tdBa1zlauywTNDsHQllTrk97V7SLwawNZ52dUcsAyQFDrOl7TwE/4x
/3dLowiIZB8AuCSjrTraqH2tgin1liw4oHJKv28BMA9mOmSppBSb88hMLThF
IsoCwz0BuXunRCsGJdqZAyJLV2OH+NITlk0jvCGoxoIqiyLFlpsAAY4/8gZN
i2m87r72Y98cg9RVFsqmKwmYa2oM0A9aQKZ7WFB6DOwvTWICSPBZaoaPcHLM
A5yE8eEoTcI8DL7VucOe4E3tmiqECtmiQ5DM/MDKnuI3B2fv2b2nqpfuorCE
Pnr2Kb1K9qTcw4Z/yQ9BFsNcTjzY/V95pWfOXvOlpX6PQbJWBNGd+vQTnSuQ
uVKvqKIApslC3FEBGGporWd0CYEBz0twXZ/oo15cj5rQgBNTDnnLrvcG51K3
dEUHX/rmK189cQLqZlU8JXhaYyfi4YIlwz/Z1N2eBeJ4qMR2AA+RTFwSLj0Y
cCCrA1C1ZnUrCAfCvSBkdyGnGINui0TGc8SpyN//8/Yu3gBxbXMwdE8mKomy
ouHUiIKQQFvRotTgZzaALGPxzRY+YqK8UFE//zUSPAvhN42ThS2FqPBUa8Xl
KTqtootaXKpYxLecgLHzJNAkDKRCNsnCMS+tyNF6o5cZ2kHVn60QE7B6Rg7R
A7alP2J5I9CnY5HD4EOjl7QOASc0koj8KnBTQP+KcLGD3z+8td2yTxpSNKGH
kmm6q/FANkLlElOFpQkBgSocn45bRMquG7+OngslrV7YinSPuE1h5IqmWWV/
h2i3CGbw/YYB6QNX8wlDrLDsBBczzrr48mVpqaNfv16GyHk9WD4SrZw0GMQK
Mz2n/ioheKV1PGpoqfb8ye5Zq60RE9sfVPGa/TLNHZL4F+tRM27sKvJNIYAr
8TrcMIH0gzo1beUOboOWb9w0xHxyIfmJsDaOSnNwrCnKTxpm4n2Lz4p2ZH5d
GY818y/8vXhyiUDrcWtKbhTPOO2HQ5P8bAju8gBsl586hx5UpnNy3tge4Gti
VwLvWYVNNCBYviVOfY5PnFgIBK7Bpn8fh1Sl9PDJFM2ZWPwY5OPsaPoA6Oem
7Ow2SGghjUWofME+mauVOeDygaVcuSCMJvyRcXaW74RV7r+3lUAX9eNeeKDQ
pDL4s3GrlH8jc17H9B32Y5Cyh2G69rThTzXuZGqgiRoNvmn7NRR0Fr0YkyAT
Pc6KCYMxrybbTe5AA2+xMqvQzWAF3M4FpxtgwwsNMuj2NTDsAndwftVhAGOI
AqhGxlrvru++f2Xx3eevvkfEOvpHaLNMJtAxm+AZNkxE4ySuK8ZzSvhX8xtk
W1sfMwlRkrXjxy3fjHQNP5BskTUq5JiN3q3roYNFLml4QtGVuYY4rTGmkgZv
pCWYCUEApScJO2IaBHw7j1eEax+QoORBTreWAEHLcWIanrsWdbSxsGTTyqzN
j5nqK+akuh3ZF2FiyE8eNLaIC1afW8zwmHBzndp24gA+R4JJfGyS7zgnTeAw
yMNFkHWJc6/IG2LiZp6yiaczv76vVbq6cCpK1Ok2h941Gz5molJXmRCiIe+x
/j6VQ6y2V4gX1b1yKVu5AfPlakQhfamES2mD1EcLu5+mDPY+E4uukUP85Jpj
lFSB0YPKNQcXtBFtV/iFJuObflaBiVuVlnPLrPSOzuoNEatEZrXdjWfff49s
BWFGuhyZST3X8kUCt7jP6uwlcb8OaALOVM7GH2tSyYJdOHI/iOumOWZsTdCf
BNTNP2X+aQvL8QVUJmeAUnX1jPJT/UyabClDChnZwAEzXdDRsy/6chE0cus5
Ogtwmfck5UmC8s0/0S3shPulbiXFVM5FQTeKYaAH/zLJJb94ffNOkoAxNifb
wuUVo1bg39fvrn/7eRqTqOmmGGOWMsOSTpyNXbpcSSiTw1pyEXkISxqs0vVY
Aj14tNuSxf+nOXBay1zGQVqedIyyh3yroDUM9TCF5Xg5eSTrxoY1mIrShw6u
jDaJUZ46ecbWBK6isz95x1lUPKtpIulMK0n8NjxbLVK5IhkXtpHsIebrzHcC
YWDBYM18QHYtwwdO1QZDWQAI9M6Ai0nqh7lmwfVb9kBNFxLp64LcPhCgE+A7
k7TwEkimet1m7CUsXXS+Rwr0yeYn5uO7eUYJM9o7y9y1rfcQcmQZE/QPVmRt
fi4riwh0Eq8mphbTTWgFCRjslhjKpytXN8ckuUtKIFbZB8cgpVSwWZvzZT4b
m3OwUySJyxxZehsQ6PEMyQhUqavuvmhGp8nbSMHDNzDSwZEIxUPsnCzLts1n
XBzVN8xZFKb9k0IVmsdPCjskFASxr5thocB6YwlH4TFHTpxFxDlPhgOAZ0ZP
fJhLFbdwPfkOTkm97RdutV0tSEpb0Zymt9IHXJZGgIbYL01pLPYTN69Orx7A
iC5U04UV2wJoy8zNcZU6AuF/snLrcmCHYQmytDYYDWCh3Ym5mDpVTNtxGpVq
fwi+lhRJyJqwC0FiwJxsE2QfaRuTA1RLC19iiZ3dFXbZPJBNRNplnzyLc/35
PqR4TPb/bW97m5759HINyL3GCtIoJKPiPYi3IfVjJSmhDMiEgEij6jS/CHmw
6vKdW4iC4STCFH/FelUuRTAc9Lpc5diNtz+RyLHcCmvoB24oGfIEV76es6qu
Ij8VJ6DGIk8Eq93hqf8lPfVJtCb9goMj/Sc1weUOimI0uMhMxVwhscAIltmz
BaSUP9n+sCpWmn78ZBGtRvcZMeUioMFwzuL56WOOfeU1PuLScDenWQqUk0ip
qGZOqNzM4TjCDElWpYDuRzIr6k0a5ArhnaSypp/5kBc8zcYjsijbAJWiXVhi
5HJIVeH57Et6hHPUApGQAsDp24q9TlQ2hhd1juAEqpy3TsYnE6DfBYPXIrOc
pEBccw8zhBFcEBE0l+R1SEKmusFyy8GxlaepRhDbBmpQTaFeCeVTVkbZRHFz
wlPwGylEksgj0a45xkTVsxyJ3XIWkPCD5xrGaXKhRYANmwSJa7M2XEo3s8A4
ddHSA5nRSnVKzYKx5vcxZq01R5mkLuHWtf6e58JECdYKbFpFz4KluiVAijVp
MCWC4RNxRJHfeZ//AyVqCYbIRMUA20qcChQqCSDRp13U0PdF3TDAY3GImHEj
PpALC9E96V/abUVN+pPLlTnr4fMRRFZztYCkpms5GKQDLQ7RqKuEaYhBok7i
mdTjEww4S5DkR2hEju/r2WtyNyiYoJyEUOKIIRG7HlEWtsgSm4a2OBTlJ4u2
clYKL1nEsdGGNc1nOm4k/4VM2LpnZF65A9fHcFJc+HY2gCgf+BevmKvNJE5S
kti3fGRHn9jE6a2pXEsLXvrN0rxdsvJERsCIqNnG6wd1AoD3wxIYcMgJtva0
rCMliFY9sR3AtYNCROgYqexHKAwpeFu2RsyjKt6+ef2XZs2LK1lj9bVwiGrc
WjGpVoTnWhIuAYE0OHRaNh4KI8BcnEVrxi57pHBdkhJL5ClLvCa/wAAKCfjT
bujVnxRQZzMoRM0vEP0VOsnHUldngaBgarFH4TKE795r8Q1m+Oc4cOEhp2fS
SYw9r/l1Utb25ZtJIZbmkUutlFaIaCOGWF7MW7whBcNV2f5XlMP9RRlJqJdg
iYeKlJW4bzmIHR217axGqFh9IuVME3z38tKM6RT6ed2diNQ04i13QKvDlG+T
AhLhT62zYYH5D++3ULqvAaZ/aQpUrfwHDYdIg0EdOMhZ+ZBQ1GKesinMY6ru
7AWx6D3JH7vYlu4TQvE8My1cfCODeOEZCRLipD+5gj1UUIWaJEwuu5LZp34N
gOASoXTLCVRf+X8/LjRLtG2Ktb93UkYSyxvPmOLBAOY4p7ovzUsniaKygov+
8hSQnE03tXxvyzdN0yhCDA54H0kFRX7z62suf/1AtKQFXVv2FZcjP+5DkCoY
9eUxWG0sXhaCFvgJp+aXg6lAVsBHNySJOa2f2LmVzyWxFJd5MwIQCARUQRdy
3Bi24szcZxJvvXol2NDNfid+aIRLGY7QD4Vl41TuMwCC+C3W83iZKeqErpBx
Dddz/iVh6Qr8JUVZunyY1R7e+cdTArwYLta2QSr9RdZwZROgHMn7Xm2zCHzV
LZ1U8sEHFdsVNUh3Y08KR0TZk6ouaS3RJkWKfJA9YwwFccqbvEf1HZZeXAWE
9LVeRJInGAVoOj8LqNRfjgYW/GBAh8SL6V3M//VBflBsNvXnkJbBleHFFlLh
grBKqCR9SVL2UpRJdADDqBb9rgYUMDerd+K5cTjj/jEgdhfiYRro5rpI3yiM
2bnmEOVtEolg/UjEPfbslI425yKX1VqfGag+LFaSIS09lpd9lFvxYAAVStUy
58WaImqknqiwmznWbU8SKsSZhsF7QB71mdQsaADqTNqa2xJ8OrahZUBoDBHS
RWf9SpIS1qS0ZYe0EWEfjspxilLntB4O0s9P0pL66IICQVUGVv+jkjPL3pp3
CdF6XUIl9ebIdFEXBD7lvXJXByvbFSzOHb36IdTQYpGivxg+coVXb1VuVjeY
pIp8FfkyK1qbrk7XLSmpAhwfiSUBAcfQd/SKaC6Aiqcgac2YIByzN3eX+CED
bKnyvx853TeVOZp1Kr7J82tt1BLHeUzbrSiUIpjp+qgvgi114pGYPGzOWS1M
VAjKEdeaRLhe+L8CSMYLLy6F1RQvmuwIzV708Ek+wcaRLhYxiGsdHYLRxkFJ
dJzibLux5TEWkmOMA+MwfHgc/vgT01P1pGPHu+Rr0G3hPzgeINInZEQi+4C4
RsqxBRxI5VByr5gq5r1MIkFJsOtc5IUNq6LnStqmKlE+OgmPcWWahLgRb4Ei
CPakhh3YA6JhtLpVj/yZYtHUf6vcqFGb5bmojZz3rRiRgV0tWqK7FSOUTQ52
TB247BkFJJMZk/PnH6cFFGmKPsjNOdK0Rjarpciemw2Iy4K9PchEH/wSaYv5
BSojzOe90RYHLHe4PnMSMznNPbe8zjRDP0F2NypZr9nvIEazXGwrMQ0Pqxfi
mpkprW4U8KQlpvzAPs2fCJAHylhyMpJEKw6iknCuxYHAC5Tju/H5OwKWOMU7
q0j6wOlLWlGsu4mC5ss3VrrEZ8JGkXSQ+OE5mzNw2MmOHPfGYkSx7Mc1GhJd
/Pz69pIL5Z4RcNErJ4Ux3P0i4+ZLZ7KL0rQzXZOZDuGWEhdMK+GyROqqG5U1
pDm5g4tBldQq+52s9n0Re92E2g66bsnYomP9wZsAIXSuaK1s4ODm1AaL3khI
w8RAODKjd5fSW8jVp0U2OOtMU8lmLryQ8+7HPp7rx0cAvmQMo7gpFFqEOKzl
HZuvTTOIM+77xOQWOTGlQ+DblBaBZkWSlE73IJskLmMZvIRJ+WxImubrMSmZ
Pds+QIF7dobVhL0CfijSEiFJfphcW8QxBiCebLbs/JFl5/kbRSuQc069XbUN
bgT8C7kQENebNjFVEj+UgPkIfusT03AUYBauQBZaf0U0OVWE1nlDc/0SFZfW
KGUxM2Z2j2e5fvW2ZSaGCU5fdHVViV+awyexZJ9USleQehgZKKzU6XnmDsjI
rKM6t9QY/s6FGknLXjQQlomy4CTRGHJnERhjx1qofJpUZSSdMdcO6ZfWGA7O
8CzMybAdGVzmKLV8O83MYoTPrgJzwC3Ez+ylqOcvYWJ2hiDwtsHoOel/cGIc
QKC/F9WJX92q4Hzrio7O9xd4UGHkPT1rxQpEPGs2Jz1u1ZyXAI/aSmw4Bmt5
0m9IFamJ8EZWwr7cs4uwVkPPn30fHInXNzf5x3+wh1PTIMxCfPX9y+CH0w9e
wCcTZWxojiqCwLVVsJyj/UAKSwtG2edNT0J6cVAEfqOn7BcaJs6B2CtP/Wih
vjQUJOpxTcY1+tivFyEVEn489Pz514J9h0Q3+A7Z0CX7y48IW1d2a6bp9MLV
HLGLuHJDk67hS+aIo3iuZ0tlyUhSf8uofwvtO6iPbI85pYVYIYkjd2cbHJi1
FJhY3DzTnitTuKA28nwtITfKCpujXLYbkUDAc84rk+jSb6BO2kqyaC4Gc0Og
QnrqChQl3VqjhCD8T84uPmAM1hpCUrAU6g05TAMpy1YBqnMhwRxMIGtbQPB2
GAMwsXac52ZLc2pIKDrgVCudO61xTXKsNmlWKJnCXJyNHI39YYjB6DMUSbyE
EwBVDPHM0lVBKsaoa5p6k7TlSzpqyFOhRkuxUhjR4h1s4cUGfmQv1iu3WuS4
LD9+99J87Yv81Sv741c1Eyc93rTB40obhDoWcFgQC7G9VfagQ8QNXI2EY+gy
nLgvLAODeUW1w744nO9HQ4Zo4qgTBmcbjJPXMLa1Z4LUWkiOstCF7zyRWIxs
cW0HHzr7o7ge04cfTn9D29ynbQWMmuesCq2k51S8FohFksj0lvVR71pydNIO
TQxHpYswkCrApm4/SR9XRW/H4P6x6L7pYtHtXH7F/vp0J/q8To1QQCOp58i7
bvsx1LYniCgG8QRu88OlFs/Dr4yqCI5osa9Z515l7yXlk0WlCkNxNksxE0uI
kAi0JoS/0TZV4ll6o9lwrSaZlkUfyTibN/T70VvD62jcthbbY9LJkh0BMfFB
I6qJBy90SkHCMd84cyiyY56d6RwTNucaF8ikuDamfWjNE8SuZIBIhsyKz/bJ
JKeSlWZhrTtp6HlWjfiJTw/DYsFnzkPuLbr9BLrYCiwL5RT0SIhb3GXscOCE
kTpJ2DoZI+mfI+nakNtI8mESRQTGDWZwsmmxdGvZqBLt4DrGUNIs6ZqWtswp
SuAac71eFA3c5NtdcOGwq1yMPEmq598x8Uk6BLdY3xblUpz6Icveo8Xi/jD2
s559begJR1hAorbn1qLNh8aWa7yljgr8Hh9nGVJbSxeQo7DIKkTj8vbG4NqP
P7IEk4IlC8uE3KvFxLMdWELK4TTMrkFJwrlBIepCFMSnQwjHDl0BTRXzzR/v
bMsuLfo9eofTFPvUDtK8FVkWO4fYacya9j81B9xJL8szsMM6wcBG0B7e2k4k
KBluP/Y3kEl6Y4bWt5NebAY7BXHbDJJBoHdk6rhP+g5nViA+c+0zGzGImsQL
tBzbc+P0hYXdIDMsvBEE1CTx3kKhq3mEwK6TtTR/bMmWg0IsUvqDFNVaRH72
oo0YeUcjTTEETvBbalqQ0PO9+p0sshJNJQs3iI8xSc9MuzcfCuk644iv+qrz
h4N1Koutl2NcP61A49j9Dg4EsW1OR+I+abi1Uv18slrVmwEEmrEntgCmSwxy
Q+Ixj9e6HcIAQByLq2U7tkGZgn/ZH/KnFy+fBWtLN5rmG1xwkkFEQkzD+Qmc
3RLkauCFs+SN9QWsD4LMsPodTbCtty37spFbGTsGIDFmutSP9fKX2tz80Uj7
eZI7Mc15T7dypqJOSiby6GQod16dNgm6U2DMFctjOM3JreMfSO+kmMbHKTeu
fKSUmAs72YJ9lD2DW/Mzx7RKDbTGngTJEr7tTeWLRLduxZYb1dVb7lJeqs2H
QArpvM3RvKRp6Px4QE35wT9YwoXkLgk4aIqxBXRiJzy3H8d3fXbSnMZSsK/t
YU6KZHedeTYtT0zy4+/Hpo1llj5tiHAZYi6IVaCDlIXP33KQ5eLf64GI3V7m
18jylVLOYdL8NmRj8wm53mKZ8DMtZsPSTwSt4Rj4Ehoz6J6e9CSRB39Eu2HL
U9emyBx/2q/x4p2+30si16N9rLmRe2s+gIC92EHKd8y3x70We9Sd1WOEtjdp
6epCFEshMNePk4JNuLA3Biotn20uL4XTEWAL1c0Swkpa5RsdHibZHUk1WUV3
qe2j0+GsuFxl/5SUHlld0lwjtkOo23sc0lZaIkRJHhvlo+GfVkTf/b+70KWO
l2717qHePDqLVMXpDuQdBYksHrQjzfFR+klDUHUcbYp+Fwet+6kI4zuE7rJs
rc8bl2FWa0/SW62eWVWpKcAZrtzIC+sMbbPUHbyyVqtJOxk2UYhM0/A22Hzg
WG3ibDESKWBJLf80/0hwFsGnesuCZSvN8QtJGNHqX45V+g6FBNyi0qlPUSvp
eyTMJfXqaRzrAc8nnBbuQMl7Qo1c9Bvtak3H5herCBRmk5lkiDammXOAbI9x
ya02uD4PTEL769O3u4SbAQ8aAVK+amE0tTjY2SmdxsJtEWu6jRjgodA4t7bS
keNNmlRzZ690xBCirKK3lruchiQ0Q//xxSB8PCagYhjIqzgxw7Iiqm5cTDY6
yRMZODzCzIK+NoF1aL7pGjWbM0k0q9tALAFJon1DtyX9LqYylSQTcWPIIgnN
nNL+/pp0gBU3kuwp7WnpQjXHzBLB5y8xsA7k0YsiQep22nxO0hcI+SHlBdc7
Zhr1+t4PK0MrAr3NAck5ptMWVhHbJJVvSZVq6r8T9QH9TuyEmJ8xIjdNDAEv
bq1Y99rtRWZK53H3qvCkUQygYRgxDNTrbOmDkCtcFAAfO+u91ontGEXaIjg6
zw4KdWaFuD6PhpW2iov7sL7emowoFZR+s1nlOZ8Lp9DRwalvLv5AvSScn5Z4
VWZr0MBVFMps++3FdsW7sz7i3VlkIPb87iy6d7MXdiE1xeDqrKtmdIanVrAh
3WThsjdp4poWyMBF28pT2pHKKUc8/roLmB8c2ppypcWhccPN36FYO56reCUs
65gMY35B1Ian1ZyqRYi8FU3wgphkCX1aNCco9cfZK48Su6OY+2+SQnPoYE6G
C6ImLYpKBtZeN9KDUF/MMAl2p9QxErI8ZJGcbl9jDqy3gSjEQQBLTpx7v/03
gAxxqYTi0c3NzZykynsxeZcS+qmSQOJsX+7oPK4lgfYYfFmPjYnD44xHVuYM
TgQ+SfuypHV36+MNFIajvcj7shAbkncA/CIt8fNb622Pr6f9rb58M++bn2XX
EkTozQU+70Q/CVN2KDrhlERJhdhwxvu8w5JGk0QtanMarX/muAwK/4yYrPp4
t/escbnxfGyANamZ6xfc+1EsMmk8n1SaJq2Ks+zVKk9rF0NTzN6MpRDmnZVG
LKwdLRYMeljwLXghWevE9/yY/lQ3XHHuNQNXTKLTlMS1a/yDhHtRUHRLf4FH
dWuzmvvpYQQVOnkDgS6rbpd4bFV0h4I74hy+l3/3hwIm7y9aydyoHW1dEGtN
DI9+UBM0LzD7y1xMax9eaqAttELl36TXK3JxaYpelxQDuKFdVU72Yv7iGQZ5
/uxZvpdyFHmz5tDVB12TVifTlnprkZuKPLCj9ugedvZ6KkOrkqyzCy2nVYp1
Dt0PkvQ+Lhzjfh3z9N2Y0oV7fMH1ufHHMluI4UvTVDrHy/guijXnSYsHsrY2
snK3pW+b9GBl3cm/60PMi2DPIDFGVL2HxtGyB+0xrO0XOXYYavy2s6rCNOlA
h4l9yBIGin3SRfOTIllttcE5Es5JpHXsp0ZX4kUIsOpS0hcTeH09FTqOoECI
GyZrruEHvezvk2vOyfNZ9vdj6BOVLizJ5KE7BV+mZCpbfLMItmeReiCQlHqm
XadUFi5CdXvS4wavQkA3sIkYWqF5Lb88h/t6aca6s16aO3mdVM9LOtSSREMn
v9Ket6dhigDjoYJ9y+/D5PK4hbzHxDL507ilfrb2w0D6LCha+93QOc0cCQLk
mqb6J8vGN0E2Zmczz9UDoJ1C1WUQqu2lQ5kUN8WQLloxYKNJGHKW4lJ34R0o
zAuSK5AEu9j/EfCxNLg0C1nr9bRaRtsdJiUSxI6uYuG8sXpW0p/2dpZ6v8eL
Vgd7E0PyGji8vFjlsYQdJENUaHYlqpubdVpzpahYrLuY2Lz8fg/CKTsJ3ODC
HV3R9cFWRSAAbKWv1PBtXH+vjqJpae1Z8lvaIROrHqaufHVZzLZizQtJEqBU
T7wW8/5bYaMV1xsJHlwBIh11JZIfaKXvxMdHNFnRhMWe217OFVQsQ5NFa5Kc
7WnboYchi9BdV7efuJJMhpJ1nZQTh5CSjYxcuvKTpV4k/YbwQqT8P1Sb/2qF
jtz/AFnC07esqpFC0LAdljGVNMnNYMWR7thOVZF1umo3b44zqeBWI5Hj5qet
bqSaP32DgvhvEaG0foYs9qRZtFES380TUxXRFPMu5/LCzliYvdA6ecPwZ3+u
l5Ipy8JGPU9nbk0syTrJ0k2TubvQhToGmrjAiMHzjpR+56Q9g+XL83nz29LQ
CJxDzxpdPRl7kSZsipRNR3x/9yH4DDU1w9kr6xIPoSINWJgKG36/ef/Uskok
21nea7XQ6hcV6E2TFkCCK+9evzcHn4xt7+ZAlT1Xl/MGkhci6fqUzo7wtNlN
2g/MSPIUSMSqnUIP1kIxz5TkSbrKpEYy+BtCkeSdl63RobANJWG3hHC25Wos
46umbPFWJbxIXkcs+34oJMsfrDFtazZ92RYHXc5wV8ytE62aIIMJ21rTWdU4
DEUBd7XbgL6fr1qGVjaiM7y67Ulx/pI8qsU4aEEKCls1Rh/vtrjLraI6Smsr
9K97/jJh2oKOndvrJ80Q9PWO/c7SR7TlhtR+XGgRj/hMTwtCLudhAXmx9ar2
i5jmHSpldDlJtxPzs4NwP1d4bXf/bWgbXVsGckWIiyiIpjuSqiazLOI9lko4
+MBlMxzoSQpM3kgu5SLdhhR5JqUJwhtaKx+fvpqmbrGnuZo4Wbx4wDQ3SfO1
Q+sYywcJucPI+eDUAI5WumazFL9sNSPQKr7g58FKgGbF2dqXR4wSQciV/5Mu
4+TaSGc3Uh69qh7JK9R8KxtPGqFDng+TOcJrIXPLS5KeBhdW3HN5Ut1jfU+1
rUMgub7uspfUyockc6sT+ynpOmQyXXYit1KNBCTg8lskQlmQZJiFedLSouz/
A5jtLxORgwAA [rfced] We see some inconsistencies with the following terms. Please
review and let us know if any updates are needed.

   edns-client-subnet (ECS) EDNS0 option
   edns-client-subnet option
   edns-client-server
   EDNS0
-->

<!-- [rfced] FYI - we added expansions to the following acronyms. Please
verify that these are correct.

   DNS-SD: DNS-based Service Discovery
   mDNS: Multicast DNS
   CPE: Customer Premises Equipment
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>