rfc9848.original.xml   rfc9848.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. -ietf-tls-svcb-ech-08" number="9848" updates="" obsoletes="" submissionType="IET
4) --> F" xml:lang="en" category="std" consensus="true" tocInclude="true" sortRefs="tru
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft e" symRefs="true" version="3">
-ietf-tls-svcb-ech-08" category="std" consensus="true" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.1 -->
<front> <front>
<title abbrev="ECH in SVCB">Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title> <title abbrev="ECH in SVCB">Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-svcb-ech-08"/> <seriesInfo name="RFC" value="9848"/>
<author initials="B." surname="Schwartz" fullname="Ben Schwartz"> <author initials="B." surname="Schwartz" fullname="Ben Schwartz">
<organization>Meta Platforms, Inc.</organization> <organization>Meta Platforms, Inc.</organization>
<address> <address>
<email>ietf@bemasc.net</email> <email>ietf@bemasc.net</email>
</address> </address>
</author> </author>
<author initials="M." surname="Bishop" fullname="Mike Bishop"> <author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>mbishop@evequefou.be</email> <email>mbishop@evequefou.be</email>
</address> </address>
</author> </author>
<author initials="E." surname="Nygren" fullname="Erik Nygren"> <author initials="E." surname="Nygren" fullname="Erik Nygren">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>erik+ietf@nygren.org</email> <email>erik+ietf@nygren.org</email>
</address> </address>
</author> </author>
<date/> <date month="December" year="2025"/>
<area>Security</area> <area>SEC</area>
<workgroup>TLS Working Group</workgroup> <workgroup>tls</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 36?>
<t>To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH conf <!-- [rfced] Please insert any keywords (beyond those that appear in
iguration for a server before it attempts a connection to the server. This spec the title) for use on https://www.rfc-editor.org/search. -->
ification provides a mechanism for conveying the ECH configuration information v
ia DNS, using a SVCB or HTTPS resource record (RR).</t> <keyword>example</keyword>
<abstract>
<t>To use TLS Encrypted ClientHello (ECH), the client needs to learn the ECH con
figuration for a server before it attempts a connection to the server. This spe
cification provides a mechanism for conveying the ECH configuration information
via DNS, using a SVCB or HTTPS resource record (RR).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 40?>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>The Service Bindings framework <xref target="SVCB"/> allows server oper <t>The Service Bindings framework <xref target="RFC9460"/> allows server o
ators to publish a detailed description of their service in the Domain Name Syst perators to publish a detailed description of their service in the Domain Name S
em (see <xref target="RFC1034"/>, <xref target="BCP219"/>) using SVCB or HTTPS r ystem (DNS) (see <xref target="RFC1034"/> and <xref target="BCP219"/>) using SVC
ecords. Each SVCB record describes a single "alternative endpoint", and contain B or HTTPS records. Each SVCB record describes a single "alternative endpoint"
s a collection of "SvcParams" that can be extended with new kinds of information and contains a collection of "SvcParams" that can be extended with new kinds of
that may be of interest to a client. Clients can use the SvcParams to improve information that may be of interest to a client. Clients can use the SvcParams
the privacy, security, and performance of their connection to this endpoint.</t> to improve the privacy, security, and performance of their connection to this en
<t>This specification defines a new SvcParam to enable the use of TLS Encr dpoint.</t>
ypted ClientHello <xref target="ECH"/> in TLS-based protocols. This SvcParam ca <t>This specification defines a new SvcParam to enable the use of TLS Encr
n be used in SVCB, HTTPS or any future SVCB-compatible DNS records, and is inten ypted ClientHello <xref target="RFC9849"/> in TLS-based protocols. This SvcPara
ded to serve as the primary bootstrap mechanism for ECH.</t> m can be used in SVCB, HTTPS, or any future SVCB-compatible DNS records and is i
ntended to serve as the primary bootstrap mechanism for ECH.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
only when, they <xref target="RFC8174"/> when, and only when, they appear in all capitals,
appear in all capitals, as shown here.</t> as shown here.
<?line -18?> </t>
</section>
</section>
<section anchor="ech-param"> <section anchor="ech-param">
<name>SvcParam for ECH configuration</name> <name>SvcParam for ECH Configuration</name>
<t>The "ech" SvcParamKey conveys the ECH configuration of an alternative e ndpoint. It is applicable to all schemes that use TLS-based protocols (includin g DTLS <xref target="RFC9147"/> and QUIC version 1 <xref target="RFC9001"/>) unl ess otherwise specified.</t> <t>The "ech" SvcParamKey conveys the ECH configuration of an alternative e ndpoint. It is applicable to all schemes that use TLS-based protocols (includin g DTLS <xref target="RFC9147"/> and QUIC version 1 <xref target="RFC9001"/>) unl ess otherwise specified.</t>
<t>In wire format, the value of the parameter is an ECHConfigList (<xref s <t>In wire format, the value of the parameter is an ECHConfigList (<xref s
ection="4" sectionFormat="of" target="ECH"/>), including the redundant length pr ection="4" sectionFormat="of" target="RFC9849"/>), including the redundant lengt
efix. In presentation format, the value is the ECHConfigList in Base 64 Encodin h prefix. In presentation format, the value is the ECHConfigList in Base 64 enc
g (<xref section="4" sectionFormat="of" target="RFC4648"/>). Base 64 is used he oding (<xref section="4" sectionFormat="of" target="RFC4648"/>). Base 64 is use
re to simplify integration with TLS server software. To enable simpler parsing, d here to simplify integration with TLS server software. To enable simpler pars
this SvcParam <bcp14>MUST NOT</bcp14> contain escape sequences.</t> ing, this SvcParam <bcp14>MUST NOT</bcp14> contain escape sequences.</t>
<figure> <figure>
<name>ECH SvcParam with a public_name of "ech-sites.example.net".</name> <name>ECH SvcParam with a public_name of "ech-sites.example.net"</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ
VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA=" VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="requirements-for-server-deployments"> <section anchor="requirements-for-server-deployments">
<name>Requirements for server deployments</name> <name>Requirements for Server Deployments</name>
<t>When publishing a record containing an "ech" parameter, the publisher < <t>When publishing a record containing an "ech" parameter, the publisher <
bcp14>MUST</bcp14> ensure that all IP addresses of TargetName correspond to serv bcp14>MUST</bcp14> ensure that all IP addresses of TargetName correspond to serv
ers that have access to the corresponding private key or are authoritative for t ers that have access to the corresponding private key or are authoritative for t
he public name. (See Sections <xref target="ECH" section="6.1.7" sectionFormat=" he public name. (See Sections <xref target="RFC9849" section="6.1.7" sectionForm
bare"/> and <xref target="ECH" section="8.1.1" sectionFormat="bare"/> of <xref t at="bare"/> and <xref target="RFC9849" section="8.1.1" sectionFormat="bare"/> of
arget="ECH"/> for requirements related to the public name.) Otherwise, connecti <xref target="RFC9849"/> for requirements related to the public name.) Otherwi
ons will fail entirely.</t> se, connections will fail entirely.</t>
<t>These servers <bcp14>SHOULD</bcp14> support a protocol version that is compatible with ECH. At the time of writing, the compatible versions are TLS 1. 3, DTLS 1.3, and QUIC version 1. If the server does not support a compatible ve rsion, each connection attempt will have to be retried, delaying the connection and wasting resources.</t> <t>These servers <bcp14>SHOULD</bcp14> support a protocol version that is compatible with ECH. At the time of writing, the compatible versions are TLS 1. 3, DTLS 1.3, and QUIC version 1. If the server does not support a compatible ve rsion, each connection attempt will have to be retried, delaying the connection and wasting resources.</t>
</section> </section>
<section anchor="ech-client-behavior"> <section anchor="ech-client-behavior">
<name>Requirements for client implementations</name> <name>Requirements for Client Implementations</name>
<t>This section describes client behavior in using ECH configurations prov ided in SVCB or HTTPS records.</t> <t>This section describes client behavior in using ECH configurations prov ided in SVCB or HTTPS records.</t>
<section anchor="disabling-fallback"> <section anchor="disabling-fallback">
<name>Disabling fallback</name> <name>Disabling Fallback</name>
<t>The SVCB-optional client behavior specified in (<xref section="3" sec <t>The SVCB-optional client behavior specified in <xref section="3" sect
tionFormat="of" target="SVCB"/>) permits clients to fall back to a direct connec ionFormat="of" target="RFC9460"/> permits clients to fall back to a direct conne
tion if all SVCB options fail. This behavior is not suitable for ECH, because f ction if all SVCB options fail. This behavior is not suitable for ECH, because
allback would negate the privacy benefits of ECH. Accordingly, ECH-capable SVCB fallback would negate the privacy benefits of ECH. Accordingly, ECH-capable, SV
-optional clients <bcp14>MUST</bcp14> switch to SVCB-reliant connection establis CB-optional clients <bcp14>MUST</bcp14> switch to SVCB-reliant connection establ
hment if SVCB resolution succeeded (as defined in <xref section="3" sectionForma ishment if SVCB resolution succeeded (as defined in <xref section="3" sectionFor
t="of" target="SVCB"/>) and all alternative endpoints have an "ech" SvcParam.</t mat="of" target="RFC9460"/>) and all alternative endpoints have an "ech" SvcPara
> m.</t>
</section> </section>
<section anchor="clienthello-construction"> <section anchor="clienthello-construction">
<name>ClientHello construction</name> <name>ClientHello Construction</name>
<t>When ECH is in use, the TLS ClientHello is divided into an unencrypte <t>When ECH is in use, the TLS ClientHello is divided into an unencrypte
d "outer" and an encrypted "inner" ClientHello. The outer ClientHello is an imp d "outer" and an encrypted "inner" ClientHello. The outer ClientHello is an imp
lementation detail of ECH, and its contents are controlled by the ECHConfig in a lementation detail of ECH, and its contents are controlled by the ECHConfig in a
ccordance with <xref target="ECH"/>. The inner ClientHello is used for establis ccordance with <xref target="RFC9849"/>. The inner ClientHello is used for esta
hing a connection to the service, so its contents may be influenced by other SVC blishing a connection to the service, so its contents may be influenced by other
B parameters. For example, the requirements related to ALPN protocol identifier SVCB parameters. For example, the requirements related to Application-Layer Pr
s in <xref section="7.1.2" sectionFormat="of" target="SVCB"/> apply only to the otocol Negotiation (ALPN) protocol identifiers in <xref section="7.1.2" sectionF
inner ClientHello. Similarly, it is the inner ClientHello whose Server Name Ind ormat="of" target="RFC9460"/> apply only to the inner ClientHello. Similarly, i
ication (SNI) identifies the desired service.</t> t is the inner ClientHello whose Server Name Indication (SNI) identifies the des
ired service.</t>
</section> </section>
<section anchor="performance-optimizations"> <section anchor="performance-optimizations">
<name>Performance optimizations</name> <name>Performance Optimizations</name>
<t>Prior to retrieving the SVCB records, the client does not know whethe <t>Prior to retrieving the SVCB records, the client does not know whethe
r they contain an "ech" parameter. As a latency optimization, clients <bcp14>MA r they contain an "ech" parameter. As a latency optimization, clients <bcp14>MA
Y</bcp14> prefetch DNS records that will only be used if this parameter is not p Y</bcp14> prefetch DNS records that will only be used if this parameter is not p
resent (i.e. only in SVCB-optional mode).</t> resent (i.e., only in SVCB-optional mode).</t>
<t>The "ech" SvcParam alters the contents of the TLS ClientHello if it i <t>The "ech" SvcParam alters the contents of the TLS ClientHello if it i
s present. Therefore, clients that support ECH <bcp14>MUST NOT</bcp14> issue an s present. Therefore, clients that support ECH <bcp14>MUST NOT</bcp14> issue an
y TLS ClientHello until after SVCB resolution has completed. (See <xref section y TLS ClientHello until after SVCB resolution has completed. (See <xref section
="5.1" sectionFormat="of" target="SVCB"/>).</t> ="5.1" sectionFormat="of" target="RFC9460"/>.)</t>
</section> </section>
</section> </section>
<section anchor="interaction-with-http-alt-svc"> <section anchor="interaction-with-http-alt-svc">
<name>Interaction with HTTP Alt-Svc</name> <name>Interaction with HTTP Alt-Svc</name>
<t>HTTP clients that implement both HTTP Alt-Svc <xref target="RFC7838"/> <t>HTTP clients that implement both HTTP Alt-Svc <xref target="RFC7838"/>
and the HTTPS record type <xref target="SVCB"/> can use them together, provided and the HTTPS record type <xref target="RFC9460"/> can use them together, provid
that they only perform connection attempts that are "consistent" with both sets ed that they only perform connection attempts that are "consistent" with both se
of parameters (<xref section="9.3" sectionFormat="of" target="SVCB"/>). At the ts of parameters (<xref section="9.3" sectionFormat="of" target="RFC9460"/>). A
time of writing, there is no defined parameter related to ECH for Alt-Svc. Acco t the time of writing, there is no defined parameter related to ECH for Alt-Svc.
rdingly, a connection attempt that uses ECH is considered "consistent" with an A Accordingly, a connection attempt that uses ECH is considered "consistent" wit
lt-Svc Field Value that does not mention ECH.</t> h an Alt-Svc field value that does not mention ECH.</t>
<t>Origins that publish an "ech" SvcParam in their HTTPS record <bcp14>SHO <t>Origins that publish an "ech" SvcParam in their HTTPS record <bcp14>SHO
ULD</bcp14> also publish an HTTPS record with the "ech" SvcParam for every alt-a ULD</bcp14> also publish an HTTPS record with the "ech" SvcParam for every alt-a
uthority offered in its Alt-Svc Field Values. Otherwise, clients might reveal t uthority offered in its Alt-Svc field values. Otherwise, clients might reveal t
he name of the server in an unencrypted ClientHello to an alt-authority.</t> he name of the server in an unencrypted ClientHello to an alt-authority.</t>
<t>If all HTTPS records for an alt-authority contain "ech" SvcParams, the <t>If all HTTPS records for an alt-authority contain "ech" SvcParams, the
client <bcp14>MUST</bcp14> adopt SVCB-reliant behavior (as in <xref target="disa client <bcp14>MUST</bcp14> adopt SVCB-reliant behavior (as in <xref target="disa
bling-fallback"/>) for that RRSet. This precludes the use of certain connection bling-fallback"/>) for that resource record set (RRSet). This precludes the use
s that Alt-Svc would otherwise allow, as discussed in <xref section="9.3" sectio of certain connections that Alt-Svc would otherwise allow, as discussed in <xre
nFormat="of" target="SVCB"/>.</t> f section="9.3" sectionFormat="of" target="RFC9460"/>.</t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<!--[rfced] FYI - We moved the second sentence in the title of Figure 2 out of
the title. It now directly follows the figure. Please review and let us
know of any objections.
Original:
Figure 2: Simple example zone with the same configuration on the
apex and web domain. It is compatible with clients that do or do
not support HTTPS records.
Current:
Figure 2: Simple Example Zone with the Same Configuration on the
Apex and Web Domain
The example above is compatible with clients that do or do not support
HTTPS records.
-->
<figure> <figure>
<name>Simple example zone with the same configuration on the apex and we <name>Simple Example Zone with the Same Configuration on the Apex and We
b domain. It is compatible with clients that do or do not support HTTPS records b Domain</name>
.</name> <sourcecode type=""><![CDATA[
<artwork><![CDATA[
$ORIGIN simple.example. ; Simple example zone $ORIGIN simple.example. ; Simple example zone
@ 300 IN A 192.0.2.1 @ 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
HTTPS 1 . ech=ABC... HTTPS 1 . ech=ABC...
www 300 IN A 192.0.2.1 www 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
HTTPS 1 . ech=ABC... HTTPS 1 . ech=ABC...]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>The example above is compatible with clients that do or do not support HTTPS records.</t>
<figure> <figure>
<name>Service that allows clients to choose between two server pools wit <name>Service That Allows Clients to Choose Between Two Server Pools wit
h different ECH configurations.</name> h Different ECH Configurations</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
$ORIGIN heterogeneous.example. ; Example zone with two pools of servers $ORIGIN heterogeneous.example. ; Example zone with two pools of servers
pool1 300 IN A 192.0.2.1 pool1 300 IN A 192.0.2.1
AAAA 2001:db8:1::a AAAA 2001:db8:1::a
pool2 300 IN A 192.0.2.2 pool2 300 IN A 192.0.2.2
AAAA 2001:db8:2::a AAAA 2001:db8:2::a
service 300 IN SVCB 1 pool1 ech=ABC... service 300 IN SVCB 1 pool1 ech=ABC...
SVCB 1 pool2 ech=DEF... SVCB 1 pool2 ech=DEF...
A 192.0.2.1 A 192.0.2.1
A 192.0.2.2 A 192.0.2.2
AAAA 2001:db8:1::a AAAA 2001:db8:1::a
AAAA 2001:db8:2::a AAAA 2001:db8:2::a]]></sourcecode>
]]></artwork>
</figure> </figure>
<figure> <figure>
<name>ECH usage pattern for an aliasing-based CDN.</name> <name>ECH Usage Pattern for an Aliasing-Based CDN</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
$ORIGIN cdn.example. ; CDN operator zone $ORIGIN cdn.example. ; CDN operator zone
pool 300 IN A 192.0.2.1 pool 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
HTTPS 1 . ech=ABC... HTTPS 1 . ech=ABC...
$ORIGIN customer.example. ; CDN customer's zone $ORIGIN customer.example. ; CDN customer's zone
@ 3600 IN HTTPS 0 pool.cdn.example. @ 3600 IN HTTPS 0 pool.cdn.example.
; Apex IP records for compatibility with clients that do not support ; Apex IP records for compatibility with clients that do not support
; HTTPS records. ; HTTPS records.
@ 300 IN A 192.0.2.1 @ 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
www 300 IN CNAME pool.cdn.example. www 300 IN CNAME pool.cdn.example.]]></sourcecode>
]]></artwork>
</figure> </figure>
<figure> <figure>
<name>A domain that is only reachable using ECH.</name> <name>A Domain That is Only Reachable Using ECH</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
$ORIGIN secret.example. ; High confidentiality zone $ORIGIN secret.example. ; High confidentiality zone
www 3600 IN HTTPS 1 backend ech=ABC... mandatory=ech www 3600 IN HTTPS 1 backend ech=ABC... mandatory=ech
backend 300 IN A 192.0.2.1 backend 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1]]></sourcecode>
]]></artwork>
</figure> </figure>
<figure> <figure>
<name>Multi-CDN configuration using server-side selection.</name> <name>Multi-CDN Configuration Using Server-Side Selection</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
$ORIGIN cdn1.example. ; First CDN operator zone $ORIGIN cdn1.example. ; First CDN operator zone
pool 300 IN A 192.0.2.1 pool 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
HTTPS 1 . ech=ABC... HTTPS 1 . ech=ABC...
$ORIGIN cdn2.example. ; Second CDN operator zone $ORIGIN cdn2.example. ; Second CDN operator zone
pool 300 IN A 192.0.2.2 pool 300 IN A 192.0.2.2
AAAA 2001:db8::2 AAAA 2001:db8::2
HTTPS 1 . ech=DEF... HTTPS 1 . ech=DEF...
skipping to change at line 184 skipping to change at line 206
; Apex IP records for compatibility with clients that do not support ; Apex IP records for compatibility with clients that do not support
; HTTPS records. ; HTTPS records.
@ 300 IN A 192.0.2.1 @ 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
www 3600 IN CNAME pool.cdn1.example. www 3600 IN CNAME pool.cdn1.example.
;; Multi-CDN customer zone (version 2) ;; Multi-CDN customer zone (version 2)
@ 3600 IN HTTPS 0 pool.cdn2.example. @ 3600 IN HTTPS 0 pool.cdn2.example.
@ 300 IN A 192.0.2.2 @ 300 IN A 192.0.2.2
AAAA 2001:db8::2 AAAA 2001:db8::2
www 3600 IN CNAME pool.cdn2.example. www 3600 IN CNAME pool.cdn2.example.]]></sourcecode>
]]></artwork>
</figure> </figure>
<figure> <figure>
<name>Example of a DNS server that supports ECH.</name> <name>Example of a DNS Server That Supports ECH</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
$ORIGIN dns.example. ; DNS server example. $ORIGIN dns.example. ; DNS server example.
@ 3600 IN A 192.0.2.1 @ 3600 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
HTTPS 1 . ech=ABC... alpn=h3 dohpath=/q{?dns} HTTPS 1 . ech=ABC... alpn=h3 dohpath=/q{?dns}
_dns 3600 IN SVCB 1 @ ech=ABC... alpn=dot,doq,h3 dohpath=/q{?dns} _dns 3600 IN SVCB 1 @ ech=ABC... alpn=dot,doq,h3 dohpath=/q{?dns}]]></sourcecod
]]></artwork> e>
</figure> </figure>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>A SVCB RRSet containing some RRs with "ech" and some without is vulnera <t>A SVCB RRSet containing some RRs with "ech" and some without is vulnera
ble to a downgrade attack: a network intermediary can block connections to the e ble to a downgrade attack: A network intermediary can block connections to the e
ndpoints that support ECH, causing the client to fall back to a non-ECH endpoint ndpoints that support ECH, causing the client to fall back to a non-ECH endpoint
. This configuration is <bcp14>NOT RECOMMENDED</bcp14>, but it may be unavoidab . This configuration is <bcp14>NOT RECOMMENDED</bcp14>, but it may be unavoidab
le when combining endpoints from different providers or conducting a staged roll le when combining endpoints from different providers or conducting a staged roll
out. Zone owners who do use such a mixed configuration <bcp14>SHOULD</bcp14> mar out. Zone owners who do use such a mixed configuration <bcp14>SHOULD</bcp14> mar
k the RRs with "ech" as more preferred (i.e. lower SvcPriority value) than those k the RRs with "ech" as more preferred (i.e., lower SvcPriority value) than thos
without, in order to maximize the likelihood that ECH will be used in the absen e without, in order to maximize the likelihood that ECH will be used in the abse
ce of an active adversary.</t> nce of an active adversary.</t>
<t>When Encrypted ClientHello is deployed, the inner TLS SNI is protected
from disclosure to attackers. However, there are still many ways that an attacke <t>When Encrypted ClientHello is deployed, the inner TLS SNI is protected
r might infer the SNI. Even in an idealized deployment, ECH's protection is limi from disclosure to attackers. However, there are still many ways that an attacke
ted to an anonymity set consisting of all the ECH-enabled server domains support r might infer the SNI. Even in an idealized deployment, ECH's protection is limi
ed by a given client-facing server that share an ECH configuration. An attacker ted to an anonymity set consisting of all the ECH-enabled server domains support
who can enumerate this set can always guess the encrypted SNI with probability a ed by a given client-facing server that share an ECH configuration. An attacker
t least 1/K, where K is the number of domains in the set. Some attackers may ach who can enumerate this set can always guess the encrypted SNI with a probability
ieve much greater accuracy using traffic analysis, popularity weighting, and oth of at least 1/K, where K is the number of domains in the set. Some attackers ma
er mechanisms (see e.g., <xref target="CLINIC"/>).</t> y achieve much greater accuracy using traffic analysis, popularity weighting, an
d other mechanisms (e.g., see <xref target="CLINIC"/>).</t>
<t>ECH ensures that TLS does not disclose the SNI, but the same informatio n is also present in the DNS queries used to resolve the server's hostname. Thi s specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and resolver without authenticated encrypti on, an attacker on this path can also learn the destination server name. A simi lar attack applies if the client can be linked to a request from the resolver to a DNS authority.</t> <t>ECH ensures that TLS does not disclose the SNI, but the same informatio n is also present in the DNS queries used to resolve the server's hostname. Thi s specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and resolver without authenticated encrypti on, an attacker on this path can also learn the destination server name. A simi lar attack applies if the client can be linked to a request from the resolver to a DNS authority.</t>
<t>An attacker who can prevent SVCB resolution can deny clients any associ ated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, e ven when the client and recursive resolver validate DNSSEC <xref target="RFC9364 "/> and use a secure transport. These downgrade attacks can prevent a client fro m being aware that "ech" is configured which could result in the client sending the ClientHello in cleartext. To prevent downgrades, <xref section="3.1" section Format="of" target="SVCB"/> recommends that clients abandon the connection attem pt when such an attack is detected.</t> <t>An attacker who can prevent SVCB resolution can deny clients any associ ated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, e ven when the client and recursive resolver validate DNSSEC <xref target="RFC9364 "/> and use a secure transport. These downgrade attacks can prevent a client fro m being aware that "ech" is configured, which could result in the client sending the ClientHello in cleartext. To prevent downgrades, <xref section="3.1" sectio nFormat="of" target="RFC9460"/> recommends that clients abandon the connection a ttempt when such an attack is detected.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>In the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry on the "DNS Service Bindings (SVCB)" page, IANA is instructed to modify the entry for "ech" as follows:</t> <t>IANA has modified the entry for "ech" in the "DNS SVCB Service Paramete r Keys (SvcParamKeys)" registry in the "DNS Service Bindings (SVCB)" registry gr oup as follows:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Number</th> <th align="left">Number</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Meaning</th> <th align="left">Meaning</th>
<th align="left">Format Reference</th>
<th align="left">Change Controller</th> <th align="left">Change Controller</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">ech</td> <td align="left">ech</td>
<td align="left">TLS Encrypted ClientHello Config</td> <td align="left">TLS Encrypted ClientHello Config</td>
<td align="left">(This document)</td>
<td align="left">IETF</td> <td align="left">IETF</td>
<td align="left">RFC 9848</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9460" to="SVCB"/>
<displayreference target="RFC9849" to="ECH"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="SVCB"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 460.xml"/>
<title>Service Binding and Parameter Specification via the DNS (SVCB <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
and HTTPS Resource Records)</title> 034.xml"/>
<author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
<author fullname="M. Bishop" initials="M." surname="Bishop"/> <!-- [ECH] (RFC9849)
<author fullname="E. Nygren" initials="E." surname="Nygren"/> draft-ietf-tls-esni-25
<date month="November" year="2023"/> companion doc RFC 9849
<abstract> RFC Ed Queue as of 08/08/25
<t>This document specifies the "SVCB" ("Service Binding") and "HTT -->
PS" DNS resource record (RR) types to facilitate the lookup of information neede <reference anchor="RFC9849" target="https://www.rfc-editor.org/info/rfc9
d to make connections to network services, such as for HTTP origins. SVCB record 849">
s allow a service to be provided from multiple alternative endpoints, each with
associated parameters (such as transport protocol configuration), and are extens
ible to support future uses (such as keys for encrypting the TLS ClientHello). T
hey also enable aliasing of apex domains, which is not possible with CNAME. The
HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics
"). By providing more information to the client before it attempts to establish
a connection, these records offer potential benefits to both performance and pri
vacy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9460"/>
<seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>
<reference anchor="RFC1034">
<front>
<title>Domain names - concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name Sys
tem. It obsoletes RFC-882. This memo describes the domain style names and their
used for host address look up and electronic mail forwarding. It discusses the c
lients and servers in the domain name system and the protocol used between them.
</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="ECH">
<front> <front>
<title>TLS Encrypted Client Hello</title> <title>TLS Encrypted Client Hello</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<author fullname="Kazuho Oku" initials="K." surname="Oku"> <author initials="K." surname="Oku" fullname="Kazuho Oku">
<organization>Fastly</organization> <organization>Fastly</organization>
</author> </author>
<author fullname="Nick Sullivan" initials="N." surname="Sullivan"> <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
<organization>Cryptography Consulting LLC</organization> <organization>Cryptography Consulting LLC</organization>
</author> </author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo d"> <author initials="C. A." surname="Wood" fullname="Christopher A. Woo d">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
</author> </author>
<date day="14" month="June" year="2025"/> <date month="December" year="2025"/>
<abstract>
<t> This document describes a mechanism in Transport Layer Secur
ity (TLS)
for encrypting a ClientHello message under a server public key.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/draft-ietf-tls-esni
(https://github.com/tlswg/draft-ietf-tls-esni).
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-25"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC9364">
<front>
<title>DNS Security Extensions (DNSSEC)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="February" year="2023"/>
<abstract>
<t>This document describes the DNS Security Extensions (commonly c
alled "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a ha
ndful of others. One purpose is to introduce all of the RFCs in one place so tha
t the reader can understand the many aspects of DNSSEC. This document does not u
pdate any of those RFCs. A second purpose is to state that using DNSSEC for orig
in authentication of DNS data is the best current practice. A third purpose is t
o provide a single reference for other documents that want to refer to DNSSEC.</
t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="237"/> <seriesInfo name="RFC" value="9849"/>
<seriesInfo name="RFC" value="9364"/> <seriesInfo name="DOI" value="10.17487/RFC9849"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
364.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="CLINIC"> <reference anchor="CLINIC">
<front> <front>
<title>I Know Why You Went to the Clinic: Risks and Realization of H TTPS Traffic Analysis</title> <title>I Know Why You Went to the Clinic: Risks and Realization of H TTPS Traffic Analysis</title>
<author fullname="Brad Miller" initials="B." surname="Miller"> <author fullname="Brad Miller" initials="B." surname="Miller">
<organization/> <organization/>
</author> </author>
<author fullname="Ling Huang" initials="L." surname="Huang"> <author fullname="Ling Huang" initials="L." surname="Huang">
<organization/> <organization/>
</author> </author>
<author fullname="A. D. Joseph" initials="A." surname="Joseph"> <author fullname="A. D. Joseph" initials="A." surname="Joseph">
<organization/> <organization/>
</author> </author>
<author fullname="J. D. Tygar" initials="J." surname="Tygar"> <author fullname="J. D. Tygar" initials="J." surname="Tygar">
<organization/> <organization/>
</author> </author>
<date year="2014"/> <date year="2014"/>
</front> </front>
<seriesInfo name="Lecture Notes in Computer Science" value="pp. 143-16 3"/>
<seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_8"/> <seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_8"/>
<seriesInfo name="ISBN" value="[&quot;9783319085050&quot;, &quot;97833 <refcontent>Lecture Notes in Computer Science, vol. 8555, pp. 143-163<
19085067&quot;]"/> /refcontent>
<refcontent>Springer International Publishing</refcontent>
</reference>
<referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/
bcp219">
<reference anchor="RFC9499" target="https://www.rfc-editor.org/info/rf
c9499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="March" year="2024"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens o
f different RFCs. The terminology used by implementers and developers of DNS pro
tocols, and by operators of DNS systems, has changed in the decades since the DN
S was first defined. This document gives current definitions for many of the ter
ms used in the DNS in a single document.</t>
<t>This document updates RFC 2308 by clarifying the definitions
of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and c
larifications. Comprehensive lists of changed and new definitions can be found i
n Appendices A and B.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="9499"/>
<seriesInfo name="DOI" value="10.17487/RFC9499"/>
</reference>
</referencegroup>
<reference anchor="RFC9147">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC9001">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu
rner"/>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="RFC7838">
<front>
<title>HTTP Alternative Services</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="P. McManus" initials="P." surname="McManus"/>
<author fullname="J. Reschke" initials="J." surname="Reschke"/>
<date month="April" year="2016"/>
<abstract>
<t>This document specifies "Alternative Services" for HTTP, which
allow an origin's resources to be authoritatively available at a separate networ
k location, possibly accessed with a different protocol configuration.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
0219.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
001.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
838.xml"/>
</references> </references>
</references> </references>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81a6XLbRrb+j6foYW7VSDckI1KKLTPjSWhJtlnWFku2x5ma
SjWBJtlXWBg0IJqWlWeZZ5knm++cboANkpIz99ewvJBAL2f9ztLd6XSCQhex
GogXWVaYIpfzuU6n4vr0SpykYb6cFyoSR7FWafFaxXEmFrqYiePzK3Gl8lsd
KvFCpxGmmECOx7m6HYiTo9dCp+Lq/dGLIMrCVCZYPsrlpOhoVUw6RWw65jYc
d1Q46+wdBpEsMODueHh9ch+E+DHN8uVAmCIKAj3PB6LIS1P09/ae7fUDmSs5
wN5hmetiGSyy/GaaZ+V8wCR/wE8i/xU9Cm7UEu+jgRilhcpTVXSOiYogMIVM
o19lnKXYeKlMMNcD8fciC9vCZHmRq4nBt2VCX/4RBLIsZlk+CEQnEPjo1EBc
XXEVzhYyLz7zQ8vlC5U2H2f5VKb6syx0lg7EmSqkuIxlMcnyBFuM0rDLw1Qi
dTwQJJ6fxvhhwi7IbWx41oWkzSybe9ud6RvlP8VuAzG8kVhNXEO6aRZnUw3+
vD2SMY//Sd2q30o1ycruWDU2OumK8+U0V6m30Umub/ynf2QjhTnfMkcpT+xi
EhSaEu+Qx60a0Oij09H56Gggji9G3d4e/uw9/e7Z08POfme/9wzW8f3ek87T
Xw+DoNPpCDkmCw2hwetMlEY9YqY7sMJdUcyUCPmpSJWKjCgyESuZp/yGDDXM
0omeljlrSIA2IYWBZatcjCGdXAldCFkUKpkXBu8wPlUhD8ZatIod3RXieqaN
MHMV6okO7XrzPLvVkaKJCcQEUzAJb4JlbtWSTHU7IbWY8P1WS3K4NjimCZI9
CyoQr6+vL69ErkxW5nDEXIWwdrHz9u1u18or0VEUqyD4RlzckreqBSSH/dZd
V0xyqJl8Sdzd/YmWf/725dGzgyd79/dCQpwLUwklmyuQmOUsynk5jmFNICmC
ZesYOgCzYa7nTHg2Ie50znNpP23lfpzBQlJxjj3F1dJAtmLHKEV7Y9ve3v7B
/X0bv358cXTZ7z27v991rK8zTvwaSP5EhjP70snAUjFmwdPMWImWjAkE2PKE
SqN5ptOi1RZAApI9yE+tfuPY6Rfkt65uw0sJ4ZgWKJeFCGUKuxDqU4ElwC6j
YaoWArAD88IUX3M8JZFLmsKvQIEyBYlOOrsE9dZsDa9NRk0iqvelsTohO7Iv
5rm+leES8OQg0HIArfC2aahWYl+3VZhnxXiXDGHDXCM10SkLjViqaKDJKpXj
2FJAJGKLh10PaoRBPx91jrs13iuTatgStI55nbE0mAOmALlZbCrfqTd0Ui5p
lIskbad0ctB0KSZlUcI36U0nzJI56Cf6KC45s7BywaokddYV2GAjFtJUokxk
DuVUkW/NR8FEl3znWuWJZoRbWvdBXBEUWIxonb27uoYR8f/i/IK/vz35+d3o
7ckxfb96PTw9rb8EbsTV64t3p8erb6uZRxdnZyfnx3YynorGo6B1NvzobLZ1
cXk9ujgfnrasW4FTBNsyIaxDkCRux8qa3DxXpCNpgsovWKzwrn/9s3fg3K7f
I09zPw57T+GDYjFTqd0tS+Ol+wnRLQOkCYBRWgXwAH3NdSFjkjlMapYtUjGD
pUN6//t3ksw/BuIv43DeO/ire0AMNx5WMms8ZJltPtmYbIW45dGWbWppNp6v
SbpJ7/Bj43cld+/hX36M4Tei0zv88a8BmUxtyc6O1tD97htKfeY04t6aVAsP
WvW0NzAwGyHMA/EBDihJ9puQBmcaFWT3UFEMx2a3zVhNJpypRBkLSy58rvui
2NFpGJcUFsQx+ThgmGJB7+ApxQKYAhR1JBAKDNHRq97v7fUYp9NYGeAgqM4X
Gls4gFERjGGUAi9hmhYg2ZLErYzLCrIESwS2mjP9KfF9xGyfaqDmzt3dlYOz
A5pBKIM922JFMS2Sq6hMIwk3iFU6BTzD/Cf6E8mFArIy8JA62q/RoWt5e/uS
q0BI4skBAV7GG23QAhkcPDk4BD3YqBqO5RjDyBkYfoDksZ4s2S2nTpUcQkjS
LsKabFIggVSEijXw8ky8hIQonrWtw9dmVvlUFckE/FzOKTdBjoeYYCD933//
PYCVPW8NT/7v2+OfX5wMfx5Oh0fDKPrWhO/03ujjS/O39N3o3dObrH8ePfv2
5eFZ/8l8+OqX9/PP373JP1xOhydD+vPh5+D9Lx/Os9O/nc+jV+8/nybvDz5+
6C3Gr96V4+T93nA4fN7i/e6QvFN58bxFJlyTyyxLmz6Ev1KKycGWnMLoAtSq
T5L4pSS41W3dk0u9BSswnoRDJbmVE1ek5nG25MdB8AEIVWUlNldyCYGTCz9L
nbfV1mYtwE3DkixNlRqKMOwr5DyjSyGjCOZjFMf5a5lPVcE5DHbA83mWrmJM
7rxsJinehCE5hcsXV6OJGo7nhY0pFNuwpS03dGH9mlityQs5H++KnStOl5wJ
GvGk2+s+Ze88xLfeyjt4eu6LLleoP2w0XF92V4iLynHbXvZgoDBIYIIMD2Ip
sFS85ARCGVWz6xDXlPM5SijSroOUGitYILBaL16zIVCcFWJYMD2FtsawgACc
oSt/hlvMsKTIa3rd/bZFKv62iVDk+BMvU0eYhAbTrPBo3dygLRQllV4K5YoA
KwvWqw2xCK458K0NS4xlndL7E0HSQhpip07WTXerTbtahZ09qXDKuHhhX3bG
CpvrLL+vUji3zSrndatUAwnAbP68EUdMVaHUedZmeg1CvxHH2gCHaI0JnGEs
wxtXSVAClnG6L+ONjWvwp9U9yNxnA6W5FDPmlF8VFdnsJ7SJoF1sqhxBSGHh
y1RP2CktxXPLCtlnlUqueK9UDX8i9bqA3MaIUFIMrPhBRlfGERLfKbmjl2pj
ZIoAUrDXO1sNSTRUVyD9xqMOwJZX3yYOY/HEwNZhUOCHB8GHNMUojydUBpIh
iHM4cOgqGpPFJQ8wJYBEkbJ2kGfZZJ1F+5BkyfJITNvyBOOwKV3LPay+/Xwe
JCI9LnkDB7Hc4jHWsJT1UfJAfxblo7oyLdIixqaqLhhaWQmaWpZE8L56oSEQ
vPDWYqUCFWjG+h6Y2/QWV4o6ZbkqgKwrozqgsMBBP3Kq9CIxXjZDPue0rF8u
phih7u4YTB0dTOA6HRznybhqLdr4s71fgGKYWk1NwlyhiAIy5qDNtHEmZS2h
jldUML2krWyUbLu0ZzvID08vz1dYDH0AwOGSuWkazlPEjT4JzdoOZ49Lm/Y7
ujfYBhVXOtGxzMkNdFFlT5vyWcwyY7sOeMEhc4To54rOnavz0e6KMLsGwAzM
RJWwrFFe+kUunCxxjTUE/sucnB2UWjS+rWDYawqYtt8OqoPATZotqLJhOVNt
U+dQm4kCuT5VxyTcFMjgE9FeufvwI+ecivzdq0htAOTwwXKtK9yJzeYa2S+R
5pJVpORdxHye41B6hTFJFqnd7rYiwnq9qaKRtTGXaG8468Tpz21pLT3nBtiK
Maa/CpoEAXXaqY0pFRfm6yuX0CoAaFJUVuzh2UzaZCCm8hRbNrMa8b1LZBya
ccTkTq4MV4kzxSoxjIsO2A4C/tUgtwYHlPlrw13p8vRw/9CVNiQaP/iJYjlX
VUsMY7wODXVFpmw07VUM5R3ZhlhZrimzJYlwxBEUtQheUWaAxJZliQk1ympr
5fR+AH3WbQD94+lTrqxB1RFjZWgeTpA+Cb+ccNajnNyWClWFpKkCAvMSKfLc
Tb4gvEryL7VCrH3PNRcvUrsjqYq2sM2Xi1xPqS/HY+pu43rIcn1F3cxcqoxU
xibz5zbGMGHFpu8wkgOtluRFnSojh14nE+YOOxJ2b+GHwNnPop0xJno6K7Dr
rYLT0oZV1eMlphZz/Cjpe5KNoQ1yqKa2iVAjZbNt7LWxNaw1OW2iIju0jIAu
zSylTqco8eC4EVUJYadKoCjhsMUKdPX27ZUqqmQMoEIFuoN21z8MVc7k+GUG
T61kavOxVSeB+9DcYcLeYWnMeu7TdAqGixMbIY2tfv/n4u3o1ejcFdN1kSl+
oDiGb1VAFZ+zVAU/if29PYHhQzrUEL1n/e5et9/t8RkHf1Dn4l1/b683iMaH
g4H3yuqjJ7qCSu7hi6NutxssFovVmlvWcytuXfCBJZtF9hY2VhZubKna6CLZ
frycq0+2SlFjeCI15+su0nqx1gDXKKNyAf/61VSzeqDi3Zf9jHAHyJmqrDS+
Ck42iV7AbzPqSUGrrswM6EGvkiJJ7AHdbBVobzCQvEL/oRX6X1mhTytUxxlu
DQ5rPWEp83SztpA3rM/Djk9ebhn2gGU0X22QuYXPr/OxZjyOq6rjQYc+XkkW
zjJK4saqWChUAKQcB1tWR6yySDM+psWWUnPDFMIo9Q3g6Pi8Pl2yHkgLf8Vh
HvWY7S6z2r80RZYgq1sjonr+Z1MBgRD7TywZdsU95rnrMxD8IIbkRqPLBgpX
7qNjguCtHuT5DhZZq715b2xd49AflEKNNTTx6Hx4drKF5M0OXWnklNqwBdWL
qzCiJbUPXKsYItpQpVEhEm9fkK8R76wBcGIvmX8WJ1EmNkTa43IfxamnKlRE
aUTmsHyOh0E1oCGPr/l+QypNhocO6+rGFCdtOfV9uJiveybbLLfnM/tS56b4
qgF/RX3/XyuO0n4jlMF00ug/Iqb/KDH9R4hxEBb88IM4K+NCd3z/sVC+Uzfi
dh/2vEd9rPff6mTsY0+2OplH8x8STn/3URH01yS1jdgtWvSV+Aix/YcgwSO7
kTdYz7Dw36GEH9/dqfmGr0RpI8xTPeziRoOlmvVHvfpxR9nqKYCvefp8tg8r
mMFKZs+/++3uRxAFMn/Ff/W+HJ4x96eNuVFWtKPst/a2NdYg1OUwdDrnc+oX
zqZGlG/qa0ziyNVNVTtjaMnhLNo/uzAwHTx10dZm8pS48XN6lpWMZLdlnGK1
6uwPdC/SaS6hKEA7YHTAR/wF3/jgI+JERZrOwvnkPc7Cm2ZebjtAq9bheicA
dY60RuEVE5t93DRLOxRmvLNKLhDW7r4YsXYe2xZj4qu+S1Gm8jbTEfNHh9KE
AGMroRWNkzxLvITEFemoo+31m4gamtyiMwWCXiSoHwjxdcUv5JkQGI1dzDKC
D6pZTBnSoVWiP6lojWJXaSYS4iQBrGsI5R/dJOKmUE7lo+3oIMWirggqMepe
kR3wKSRdW5IUlSjfckqlQ04QHiluciXyE/WdbJs61jeo0pCduf4DCZibTN4N
Cs7yx0a56yEU1EPuBsuIEAia71ad3a21JzVz+ZyNzjlWPT5q9lydj2zjKCtg
LtQEtXI3YZzZE7TMGR03Ll+D51t35EZnXfhrCqI2oe7RQi6r1khaz3K1s04n
tkNHW3bFya1KXcUMtSK/+My3j6rDQO7L/7mmy9lVDLG5fgdtAHtcJiR3Y92M
+hVkE5ktql1fuGPPYKPV+VHCl4Wc/ds+rRRTTRS5Q5qJDFcQ6dxlxod76WZq
3BVDj1syuZBb4mVCiKBsd5BJ5GyMhTQt+UiRvbLSGKmCzQ5Mj6ULh5LOwSXS
k953b9rkLSDiTdWqxRZjutQ1qZlyxmKoer8iVKl1x86H3EhDfyIhZ5giV6Iu
kgwBY3RS4iAgl5OJDsGqjJcQaRuBZl7Gki18oUiZ3JrieyXcdq3v3Rh7EUx1
p126AGYvB9ren8UNsihnIWR8ddvI2Zuq7MMiRl32+pey6NCAW0Kuu1pdSgNc
/1aqnDrQ7DbcTDZZ7C5eWVXCouCWhT2F3Xbjr6YIGg6rXo8zA275sHtUG7oN
cntGSU8SqBVwZI8pjD1NcxXXCllJctXUGvap00OpdsgdPWcV3Jj2fSlLq2Yz
ZUlsT8a/ExkpcgHLi0c2tQOpb0LdfreYvWACSvXEp83d3Yp1euMcjY8m6Npb
zXpNO78mtv2W1jZnmFPnLC02Wsj0DgXGsk74CEWkMVmoWQzVLbn6EA++xhrU
MV+YLJF+3XoEeR7Gy1alvju2qyzEmteWCEryoDWySaFWVHsEIxYsAKlt6i6m
NnhtKHaDKoQFTbekSVRXJ0fuktaz/ScHrnFN8UlaZhX5X2oImbrCHtGvR3/T
EGl1E9GqZ6w4KC5kdffBhjAvSNOtx5nms3Fq0IFIZImVF7mlYLj1fZxGHCGA
hK0V6hNRl9VE1CSatn+a2TgB4IQ9AbhXRym1zseQgetlbTuwJyHb6F1Zlg1o
NmDZc4Xh+XAjCxvZJVt82520X7VILusG+hu6orXj3dsyuy3QOUUgyZdVf621
7bo8ZmHJXTpdmqq2JYCPVO1Zq/WdJIvoupCFeVqRyp06qZhk3KUZBMEXcW6R
nD9f7Bmb9/kizpTk/Oixzxc6VUyoe6s4aQrVI0OPgNhTRTKzJ6m5+AIyOquP
qH75szpbP+trbx+1Zd6WoUzG943lIK+1DR6+vOoOgXnUzrV/q3L3McGNTq5f
rj0L/g2gB8hpXTEAAA==
<!-- [rfced] Figures 1 and 3 are too long for the line limit of the text
output (72 characters in the text, which means 69 characters within the
sourcecode element in the XML file). Please let us know how these figures
should be updated.
a) Figure 1 - perhaps break at the "/"
Original:
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ
VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="
Perhaps:
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/
KrWPgAEAAEAAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="
b) Figure 3 - perhaps change "two" to "2"
Original:
$ORIGIN heterogeneous.example. ; Example zone with two pools of servers
Perhaps:
$ORIGIN heterogeneous.example. ; Example zone with 2 pools of servers
-->
<!-- [rfced] We updated <artwork> to <sourcecode> in the figures in this
document. Currently, the "type" attribute is not set. Please review the
types at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types,
and let us know if one is applicable. If the list does not contain an applicable
type, then feel free to let us know. Also, it is acceptable to leave the
"type" attribute not set.
Note: RFC 9460 used type="dns-rr" for sourcecode similar to Figures 2-7 in
this document.
-->
<!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Application-Layer Protocol Negotiation (ALPN)
resource record set (RRSet)
-->
<!-- [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.
Note that our script did not flag any words in particular, but this should still
be reviewed as a best practice.
--> -->
</back>
</rfc> </rfc>
 End of changes. 58 change blocks. 
488 lines changed or deleted 266 lines changed or added

This html diff was produced by rfcdiff 1.48.