draft-dlr-doh-deploy.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: deploy-doh,v 1.2 2020/10/22 10:29:52 jim Exp $ -->
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2137 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2137.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC2845 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2845.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">
<!ENTITY RFC3645 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3645.xml">
<!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!ENTITY RFC6895 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
<!ENTITY RFC6950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6950.xml">
<!ENTITY RFC7816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7816.xml">
<!ENTITY RFC7858 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7858.xml">
<!ENTITY RFC7871 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7871.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY RFC8484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8484.xml">
<!ENTITY RFC8499 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml">

<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?><!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-dlr-doh-deploy-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->
<front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="draft-dlr-doh-deploy">
	   DNS over HTTPS (DoH) Deployment Considerations 
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->


    <author fullname="John Dickinson" initials="J" surname="Dickinson">
      <organization>Sinodun Internet Technologies Ltd</organization>
       <address>
        <postal>
          <street>Oxford Science Park</street>
          <city>Oxford</city>
           <code>OX4 4GA</code>
          <country>UK</country>
        </postal>
        <email>jad@sinodun.com</email>
      </address>
    </author>

    <author fullname="Jason Livingood" initials="J" surname="Livingood">
      <organization>Comcast</organization>
        <address>
        <postal>
          <street>1800 Arch Street</street>
          <city>Philadelphia</city>
          <code>PA 19118</code>
          <country>USA</country>
        </postal>
        <email>jason_livingood@comcast.com</email>
      </address>
    </author>

    <author fullname="Jim Reid" initials="J" surname="Reid">
      <organization>RTFM llp</organization>
      <address>
        <postal>
          <street>St Andrews House</street>
          <city>382 Hillington Road</city>
          <region>Glasgow</region>
          <code>G51 4BL</code>
          <country>Scotland</country>
        </postal>
        <email>jim@rfc1035.com</email>
      </address>
    </author>

    <date month="October" year="2020" />

    <!-- Meta-data Declarations -->

     <area>Applications and Real-Time</area>

    <workgroup>TBD</workgroup>

    <keyword>template</keyword>

    <abstract>
      <t>
	Deployment of DNS over HTTPS (DoH) <xref target="RFC8484"></xref>
	introduces a major change to the way in which devices and
	applications are able to use the Domain Name System. DoH traffic
	uses HTTP over a TLS session. DoH clients and servers can use
	HTTP primitives to request and supply DNS data instead of
	conventional DNS queries and responses using port 53. This
	presents a number of challenges, including new risks and
	security concerns.
      </t>
      <t>
	The objective of this document is to describe these challenges
	and provide advice on how to minimise their impact.
      </t>
      <t>
	It is also likely that DoH servers could be operated and controlled by
	website administrators and developers who are not familiar with the
	DNS. They may need guidance on how to provide DoH services that are
	aligned with best DNS practices. This document is intended to bridge the
	gap between the HTTP and DNS communities.
      </t>
    </abstract>

</front>

<middle>

  
<section title="Introduction">
  <t>
    Traditional DNS traffic is not encrypted. This poses an obvious privacy
    challenge for Internet users, because their access to named network
    resources could potentially be tracked through their DNS queries. Measures
    like Query Minimisation <xref target="RFC7816"></xref> can reduce but
    not eliminate this exposure. In principle, any network element in the
    path between the user and resolver could observe this unencrypted traffic.
  </t>
  <t>
    DoH partially eliminates this problem by using TLS to encrypt the queries
    and responses that are made. These use HTTPS rather than the conventional DNS
    protocol. Furthermore DoH traffic is intermingled with other HTTPS traffic,
    making it difficult for an eavesdropper to monitor DNS traffic or even be
    aware that it is taking place. It should be noted however that a user's DNS
    queries could still be observed by the DoH server(s) which receive them.
  </t>
  <t>
    The conventional model for DNS transactions involves a stub resolver,
    recursive servers and authoritative DNS servers. The stub resolver is
    usually part of the operating system software and is used by applications to make
    DNS queries and receive responses from recursive servers which are typically
    provided by an ISP or the local network administrator. Recursive servers
    answer queries from stub resolvers by traversing a hierarchy of
    authoritative DNS servers, querying them for data about some domain name and
    ultimately returning that response to the stub resolver that initiated the
    orginal query.
  </t>
  <t>
    New models of DNS usage are created with DoH. A DoH server typically occupies
    the role of the recursive resolving server in conventional DNS. DoH clients
    send DNS queries to DoH servers over DoH instead of using a stub resolver to
    send plaintext DNS queries to a conventional recursive resolving
    server. This DoH server will sometimes be operated and controlled by a third
    party - i.e. not whoever operates and controls the existing recursive
    resolver DNS servers in some network. That in turn disrupts the long
    standing and well understood (if sometimes poorly documented) trust
    relationships in traditional DNS.
  </t>
  <t>
    HTTP servers would be able to offer DoH resolution service without the need for
    conventional DNS query-response transactions (e.g. Do53). For instance, HTTP servers
    could just return application/dns-message elements for the URIs in some web
    page, saving the web client from issuing DoH (or plaintext DNS) queries to
    lookup the hostnames in those URIs. On one hand there may be performance benefits to 
    doing so in some cases, balanced against some risk arising from tighter coupling between 
    layers and applications. 
    </t>
</section>


<section title="Terminology">
  <t>
    DoH Server: A server supporting the DNS over HTTPS is called a "DoH server" to differentiate it
    from a "DNS server" (one that only provides DNS service over one or more of the other transport
    protocols standardised for DNS).  Similarly, a client that supports the DNS over HTTPS is called
    a "DoH client".
  </t>
  <t>
    A detailed glossary of DNS terms can  be found in <xref target="RFC8499">RFC
    8499</xref>.
  </t>
  <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
    <xref target="RFC2119">RFC 2119</xref>.
  </t>
</section>


<section title="Contrasting DoH and Conventional DNS">
  <t>
    With conventional DNS today, using UDP or TCP port 53 (DNS over port 53 - Do53), most users are
    assigned the IP addresses of several recursive resolvers via Dynamic Host Configuration Protocol (DHCP) or similar
    network bootstrapping mechanism. These are usually the IP addresses of
    recursive resolvers that are administered by the network operator.
  </t>
  <t>
    When DoH is used, client and server DNS traffic is encrypted using a TLS
    channel, typically via port 443. DoH clients may have little need for
    conventional DNS apart from an initial bootstrap query to find the IP
    addresses of a suitable DoH server. The bulk of their DNS resolver traffic
    could bypass the current network's DNS resolver infrastructure because that
    traffic will make use of the resolver service provided by the DoH server.
  </t>
  <t>
    At present there is no standard for DoH server discovery, which is 
    being worked on in the Adaptive DNS Discovery (ADD) working group. Browser vendors,
    who have been first to use DoH, have so far adopted ad-hoc solutions until 
    suitable standard(s) are available. One potential 
    approach is to embed the names or URIs for public DoH resolvers in the
    browser's configuration. Another is to try DoH opportunistically: if there
    is a DoH service at the IP address(es) found in the device's stub resolver
    configuration, the browser uses that.
  </t>
</section>


<section title="DoH Impact on Existing DNS Behaviour">
  <section title="DNS servers using Access Control Lists">
    <t>
       When a DoH server performs the role of a recursive resolving DNS server, it queries
       other DNS or DoH servers to resolve the queries received from DoH clients. In some
       settings, a DOH server will forward these queries to a recursive resolver or some
       proxy. In either scenario, these outbound queries will use a source IP address of
       the DoH server, not that of the originating DoH client. This may sometimes cause
       operational or security problems, for instance when the DoH server queries another
       DoH or DNS server that uses access control lists based on source IP address. In this
       case, the ACL applies to the source address of the DoH server (or an intermediary)
       and not the original DoH client. That can mean the DoH client eventually gets a
       different response than if it had made the query itself. In particular, this may be
       a problem for IXFR or AXFR queries because authoritative DNS servers commonly use
       ACLs to restrict these queries.

    </t>
    <t>
       This problem becomes more acute for dynamic updates <xref
       target="RFC2137"></xref>. If an ACL based on source IP address is used to
       accept or reject these requests, it will be the address of the DoH server
       rather than the DoH client which determines the outcome. However
       Transaction Signatures (TSIG) <xref target="RFC2845"></xref> and GSS-TSIG
       <xref target="RFC3645"></xref> are commonly used for authenticating
       dynamic update requests. It is therefore essential that DoH servers do not
       interfere with any TSIG resource records in queries or responses. DoH
       servers MUST ensure TSIG resource records included in any requests
       received from DoH clients are included whenever the DoH server has to
       contact another DoH or DNS server to satisfy that request. Similarly, DoH
       servers MUST return to DoH clients any TSIG resource records that are
       received from DNS or DoH servers.
       </t>
  </section>
  <section title="Split DNS">
    <t>
      Split DNS configurations <xref target="RFC8499"></xref> are widely
      used, particularly in enterprise networks. These have an internal name
      space which is not visible to the public Internet. Resolving DNS servers
      in such networks are usually configured to only provide answers for this
      name internal space to requests from clients on the enterprise network.
    </t>
    <t>
      Applications and devices making DoH requests on networks which use split
      DNS will not be able to access these internal names unless their requests
      are sent to a suitably configured DoH server. This probably means that
      networks using split DNS SHOULD provide DoH servers which are able to
      provide answers for their internal name space. It therefore follows that
      networks using split DNS SHOULD ensure that DoH clients query local DoH
      servers which have been configured for that network's internal name space.
    </t>
    <t>
       Use of third-party DoH servers is not recommended in networks which have split
       DNS. These servers are unlikely to know about the configuration of the local network
       and will therefore be unable to resolve or otherwise properly handle requests for
       the internal name space. When third-party DoH servers are used in these networks, it
       also presents security and privacy risks. Requests from DoH clients for internal
       names will leak, disclosing this potentially sensitive information to an external
       DNS server or proxy which is operated and controlled by a third party.
    </t>
  </section>
  <section title="Secure DNS (DNSSEC)">
    <t>
      RFC 8484 explains that interactions between a DoH server and client
      benefit from the transport security provided by HTTPS and that DoH does
      not provide message integrity. Although a DoH client can be sure it
      received exactly the data sent by a DoH server, it does not know if that
      server is telling the truth. That can only be determined by DNSSEC
      validation, assuming that the DNS data are properly signed. Therefore a
      security-conscious DoH client SHOULD support DNSSEC and perform DNSSEC
      validation by itself. DoH clients MAY trust a DoH server to validate
      signed responses on their behalf but MUST take full account of the
      consequences of doing so.
    </t>
  </section>
  <section title="DNS Headers, OP Codes and EDNS Options">
    <t>
       DoH servers MUST check the headers and opcodes on inbound DoH requests and act
       accordingly. In particular, DoH servers MUST NOT assume that those requests are
       queries unless both the QR bit and Opcode header are set to zero. Relevant header
       and EDNS bits (DO, CD, etc) on incoming queries MUST be reflected in the outgoing
       DNS or DoH queries needed to resolve the original request. Similarly, the header and
       EDNS bits returned in responses MUST be reflected in the responses transmitted to a
       DoH client by the DoH server.
    </t>
    <t>
      To do: add clarifications on behaviour around EDNS goop - buffer sizes, padding, ECN,
      keepalive, extended error code, DNS cookies, etc
    </t>
  </section>
  <section title="Multicast DNS">
    <t>
      Need to say something about this and .local? Should DoH services need
      to know or care about it?
    </t>
  </section>
</section>


<section title="DoH Impact on Browser Behaviour">
  <section title="Browser Caches">
    <t>
      A web browser maintains a cache of recent DNS data. Responses from DoH
      servers will affect the contents of that cache. This presents a security
      risk because DoH servers could arbitrarily manipulate the content of a
      browser's cache in a way that would not be possible with conventional
      DNS. DoH servers may be able to populate a browser's cache without the
      browser making DNS (or DoH) queries by sending arbitrary
      application/dns-message elements in the HTML needed to render a web page.
    </t>
    <t>
      DoH servers SHOULD NOT send DoH data (i.e. application/dns-message
      elements) unrelated to the request made by a DoH Client. Similarly, a web
      server SHOULD NOT send DoH data that does not correspond to any of the
      URIs in the HTML which is returned. i.e. If all the URIs on some web page
      are for foo.example.com, the web server SHOULD NOT send
      application/dns-message elements for bar.example.com or example.net. DoH
      clients SHOULD ignore such unrelated DoH data sent by a DoH or web
      server. DoH clients MUST NOT cache such data.
    </t>
  </section>
  <section title="What else?">
    <t>
     There have to be some server PUSH horrors here
    </t>
    <t>
      Say something about the evils of web cookies and related spyware
      (trackers, beacons, etc)?
    </t>
  </section>
</section>

<section title="Use Cases">
   <section title="DoH server resolving incoming queries">
      <t>
       A DoH server is unlikely to be able to answer all the incoming queries it
       receives. This means it will need to interact with other DNS servers in order to
       resolve those queries. There are two scenarios. The DoH server could send these queries
       to a suitable proxy or forwarding server for resolution. It could function as a
       validating recursive DNS server and resolve the queries for itself.
     </t>
     <t>
       There are potential privacy and security implications for both scenarios. If the DoH
       server's outbound queries use Do53, the query name (or parts of the query name) will
       be transmitted in plaintext - possibly disclosing sensitive information. The
       corresponding plaintext responses to those queries could also include sensitive information.
       Operators of DoH will need to decide what transport(s) are used for outgoing queries
       and what policy applies and consider the technical and privacy trade-offs of those
       choices . This would presumably be some combination of DoH, DoT and Do53. A DoH server
       will probably need to have configuration controls to apply local policy for those
       outgoing queries: for instance, try DoH first then fall back to Do53 if DoH is not
       available.
     </t>
     <t>
       A DoH server cannot assume in the general case that it can use DoH (or DoT) to resolve
       queries. Though this may be possible when the server sends its queries to a proxy or
       resolving DNS server that's under the same administrative control. It therefore
       follows that a DoH server SHOULD support Do53 unless it is operating in an
       environment where the DoH server is configured with the answers for all possible
       queries that the local DoH clients will generate.
      </t>
   </section>

  <section title="DoH server forwarding to a traditional validating resolver:">
    <t>
      Recursive DNS operators will likely choose to deploy DoH support in a variety 
      of ways, depending upon their internal technical requirements and platform 
	    capabilities. One mode of deployment is to support DoH via a special 
	    HTTPS server (or network element such as a load balancer) that then 
	    forwards (proxies) the DNS query to a Do53 resolver on the backend. 
	    This would typically occur within a datacenter or trusted private 
	    network and represents a simple internal function separation 
	    between two different protocols. It may also have the advantage of 
	    off-loading TLS-session management and encryption onto hardware 
	    and/or software optimized to performing those tasks.
    </t>
 </section>
  <section title="Combined DoH server and DNS resolver:">
    <t>
      In contrast to the deployment design above, an alternative is to run the 
	    DoH resolver on a server that is also running a recursive DNS resolver. 
	    This combines the protocols offered for DNS resolution into a unified 
	    service - potentially also supporting other protocols such as DoT. 
	    However, at least based on current CPU capabilities, the result 
	    seems likely to be that each server can handle fewer queries per 
	    second than a Do53 server, necessitating a greater number of servers 
	    to be deployed for a given peak query load. On the other hand, 
	    server costs continue to decline and virtualization can in some 
	    cases mitigate those concerns. 
    </t>
 </section>
  <section title="DoH server using private DNS RRs">
    <t>
      Some DoH environments could use "private" DNS Resource Records for internal
      purposes. These private use resource records SHOULD NOT leak to the public
      Internet.
    </t>
    <t>
      Care is needed when choosing the type codes for these sorts of resource
      records. The guidance in <xref target="RFC6895"></xref> RFC 6895 should be followed.
      If these private-use Resource Records are used in a closed setting that is isolated
      from the public Internet, type codes SHOULD be assigned from the Reserved from
      Private Use Range, ie 0xF00-0xFFFE (65280-65535). However care should be taken when
      two or more of these private networks are connected to ensure there are no type code
      collisions: ie situations where network A and network B have both used type code
      65000 (say) for discrete internal purposes.
    </t>
    <t>
      For DoH settings on the Internet, type codes for new resource record types MUST be
      registered with IANA. This will ensure the type code assignment is unique and reduce
      the potential for type code collisions. The Expert Review process described in
      Section 3.1.1 of RFC 6895 MUST be used for these assignments.
    </t>
     <t>
      Both these forms of type code assignment imply that DoH clients and servers support
      RFC 3597.
     </t>
   </section>
   <section title="DoH server to HTTP server forwarding to a traditional validating resolver:">
     <t>
      Covered by "DoH server resolving incoming queries" above?
     </t>
   </section>
   <section title="DoH server to HTTP server using private dns RRs known only to the DoH server">
     <t>
      Covered by "DoH server using private DNS RRs" above?
     </t>
   </section>

</section>



<section title="Privacy Concerns">
    <t>
      If a resolver operator has functionally separated the DoH service and Do53 service and is using a logically 
	    separate DoH service to proxy DNS queries, then the network connection between the DoH service and 
	    Do53 server should be trusted. If this is not the case, then it defeats the privacy objectives inherent 
	    in the rationale for DoH. [JL: this is also in requirements below - and maybe it belongs in one or
	    the other and not both]
    </t>
</section>


<section anchor="Security" title="Security Considerations">
  <t>
    This document contains no security concerns that have not already been addressed by 
	    RFC 8484. 
  </t>
</section>


<section title="Recommendations">
    <t>
	If a resolver operator has functionally separated the DoH service and Do53 service and is using a logically 
	    separate DoH service to proxy DNS queries, then the network connection between the DoH service and 
	    Do53 server should be trusted. If this is not the case, then it defeats the privacy objectives inherent 
	    in the rationale for DoH.
    </t>
    <t>    
      DoH servers on the public Internet MUST NOT create an alternate root or
      publish data for TLDs that have not been created through ICANN or IETF
      processes. DoH servers on private networks MAY use alternate roots and/or
      ad-hoc TLDs provided these name spaces do not leak to the public Internet.
    </t>
    <t>
      The responses received over DoH MUST be available in the traditional DNS.
    </t>
    <t>
      A DoH server MAY make choices about which RRs to return if it knows more
      about the network or client locality, provided that does not compromise DNSSEC
      validation.
    </t>
    <t>
      The DoH server MAY push useful additional RRs to DoH Client if the server
      knows the client is likely to need those RRs soon. Again, these RRs MUST be
      available in the traditional DNS.
    </t>
    <t>
      DoH servers and clients MUST handle unknown RRtypes correctly: ie support
      <xref target="RFC3597">RFC 3597</xref>.
    </t>
    <t>
      DoH servers MUST support DNSSEC validation.
    </t>
    <t>
      DoH clients SHOULD support DNSSEC validation.
    </t>
    <t>
      DoH servers and clients SHOULD support Transaction Signatures (TSIG). Although
      the message integrity checking offered by TSIG is redundant when DNS
      transactions are carried over a TLS channel, TSIG offers protection
      against replay attacks. This may be useful for some types of DNS
      transactions.
    </t>
    <t>
      DoH servers MUST honour DNS error codes and extended error codes
      [draft-ietf-dnsop-extended-error-16]. These MUST be returned to DoH
      clients. Use of HTTP error codes SHOULD complement these DNS error codes
      and MUST NOT replace them. DNS error codes have specific meaning and these
      semantics may not always be readily conveyed in an HTTP error code. It is also
      possible that DoH clients could strip any HTTP information before returning the DNS
      response to the application that had initiated the DoH query.
    </t>
      
</section>


<section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
</section>


<section anchor="Acknowledgements" title="Acknowledgements">
      <t>
	Fill this in later
      </t>
</section>
    
</middle>

  <!--  *****BACK MATTER ***** -->

<back>

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;
      



    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC2137;
      &RFC2845;
      &RFC3597;
      &RFC3645;
      &RFC6895;
      &RFC7816;
      &RFC8484;
      &RFC8499;

    </references>

    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>

 </back>
</rfc>