define rules for cname (aka multi-cdn or multi-cloud)

[mcmanus]

traditional SNI is the origin name. You can use an HTTP connect tunnel, traverse a CNAME (or 3), or engage in some alt-svc load balancing and, while these things all change the DNS name you lookup and connect() to, they don't change the SNI.

what about eSNI? the keys are a property of the server, not really the origin. It seems really hard to coordinate this across administrative domains.

The case I'm particularly worried about is where more than one hosting provider is in the mix.. ISTM a typical way of doing this is LB'ing DNS responses with CNAMEs. (e.g. 50% of www.example.com gets CNAME www.cdnA.com and 50% gets www.cdnB.com).. We've got folks from 2 CDNs as active contributors here who know better than I, but this kind of level of indirection to get you CDN agility seems pretty common.. we would want cdnA and cdnB to be able to each use their own keys.

Even without agility, its a pretty common pattern for an origin to maintain control of their own DNS and only delegate to a CDN under load/whatnot and do that via cname...

that argues to me to allow _esni TXT records on the server lookup, not just the origin name. Perhaps they could override the _esni at the origin scope but that seems like a way to trigger the misconfiguration fallback path.

Also, what about connect tunnels where you do do SNI, but don't traditionally do DNS at all?

[mcmanus]

rfc 1034 (I cannot figure out if this provision has been udpated) says

The domain system provides such a feature using the canonical name
(CNAME) RR. A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR. If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.

[mcmanus]

I guess there is also the question of whether a txt query of _esni.www.example.com can return a CNAME even if www.exmaple.com returned A/AAAA (which would seem to be a good way to keep your keys straight.)

[kazuho]

I guess there is also the question of whether a txt query of _esni.www.example.com can return a CNAME even if www.exmaple.com returned A/AAAA (which would seem to be a good way to keep your keys straight.)

We need to allow this. As you said, certain CDNs do not provide DNS as a service and their customers use their own DNS. Please see my comment on #7 (comment).

Regarding the multi-CDN use-case, I do not think there is a easy solution.

One way of supporting that kind of configuration will be to do the following:

1. (instead of querying for A and _eni) client only queries for A. Let's consider example.com is queried for and 1.2.3.4 is returned.
2. client then connects to the return address via https to obtain the ESNIKeys (i.e. https://1.2.3.4/.well-known/esni-keys/example.com
3. client connects to 1.2.3.4 with ESNI specifying "example.com"

But this has more overhead, looks more like TLS tunneling...

Honestly, I'd prefer to not covering multi-CDN use-case. IIUC it's mostly for entertainment content. They need least protection, to the extent to which some believe that serving using plaintext HTTP is fine.

[mcmanus]

we need to document that when a.example.com -> cname b.example.com the TXT record that is looked up is _esni.b.example.com

We also need to document that when _esni.b.example.com is a CNAME to c.example.com the TXT record is recursively looked up from c.example.com not _esni.c.example.com. (If they want that behavior the CNAME should be from b.example.com to c.example.com).

[kazuho]

we need to document that when a.example.com -> cname b.example.com the TXT record that is looked up is _esni.b.example.com

I am not sure if using an intermediate result of address resolution as a key to obtain ESNI is a good approach. Rather, I would argue that _esni.a.example.com should be used in that case, due to the following reasons:

• some APIs used for querying a hostname (or a DNS record) might resolve CNAME's by itself
  • getaddrinfo is one of such APIs, though it does not provide you the ability to query TXT records
• we can fully parallelize the address resolution and the ESNI key resolution if we select _esni.original-host as the name

If we are not going to use the original hostname, I wonder if we could use the final result rather than the intermediate result (e.g., assuming that a.example.com results to 192.0.2.1, query _esni.1.2.0.192.in-addr.apa). That solves the API issue and the multi-CDN use-case, with the downside being that the queries cannot be parallelized.

[martinthomson]

I agree with @kazuho. You start with A/AAAA requests to example.com and TXT requests to _esni.example.com and see where each leads you. The point about _esni. using CNAME to point to a leaf that might not have the underscore is valuable.

[mcmanus]

the use case not being captured is when www.example.com is a cname to www.cdn-a.com (and at other times a cname to www.cdn-b.com). presumably the onus to manage their key records falls on cdn-a and cdn.b and should require example.com to be managing the _esni record. (example.com may not even be aware which cdn is currently doing esni)

…

On Tue, Jul 3, 2018 at 10:36 PM, Martin Thomson ***@***.***> wrote: I agree with @kazuho <https://github.com/kazuho>. You start with A/AAAA requests to example.com and TXT requests to _esni.example.com and see where each leads you. The point about _esni. using CNAME to point to a leaf that might not have the underscore is valuable. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP5s1q0uoHCz_HMIKovuOw4eQ1kRflNks5uDCoXgaJpZM4UADk5> .

[sludin]

I know this is three months old, but did the CDN case get landed? Entities using multiple CDNs, or even an entity flipping between using a CDN and not is a reality that needs to be fully thought through. Reading through the tickets and RFC I am concerned about:

• The apparent need to share the private key between entities
• The possibility of the TXT or RR record returning information for one CDN and then the A record returning information for another (in cases where there are multiple keys).

[chris-wood]

@mcmanus I think this issue is resolved. Can you please confirm and close if so?

[chris-wood]

Closing as resolved. Please re-open if something's still needed!