remove _esni prefix because it makes CNAME alias too hard

[mcmanus]

issue #7 briefly discussed the choice of a _esni DNS prefix for the TXT record. I think we should revisit that.

My primary concern is that using 2 different names for the addressing and key information makes DNS aliasing un-necessarily complicated.

Consider the case where www.example.com is a customer of bigHoster.com and bigHoster.com is deploying ESNI for all its customers.

A classic way to do this is to have www.example.com be a CNAME for host1.bighoster.com

unfortunately to use bighoster.com's new ESNI infrastructure www.example.com would need to add a CNAME record for _esni.www.example.com as well. So the ESNI deployment requires DNS changes outside of the org deploying ESNI, which is going to limit its deployment, which in turn is going to limit the breadth of its anonymity pool. :(

Additionally, I've been told that anecdotally putting names under a CNAME is legal but error prone. RFC 1912 seems to have some language that suggests its not even legal (though that is informational).

If the ESNI information were instead stored without a prefix then the alias would automatically apply as the CNAME applies to all the RR's of a hostname.

Part of the reason for choosing the prefix was to avoid collisions in the TXT space, so it makes sense to also reopen #40 and use a non TXT RR type if we drop the prefix. I think the consensus is moving towards that being fine.

This would also resolve #79 to harmonize esni with existing dns deployments.

[mcmanus]

I forgot to acknowledge the downside here is with apex records. You can't cname an apex record, so the normally annoying second cname with the prefix is actually the only thing the apex can use natively as an alias and this proposal gives that up.

otoh apex records inline someone's A records (usually a single provider's anycast) already so they can do the same thing with esni.. and/or we could allow some kind of delegation explicitly as part of the new rrtype (i.e. delegation within the new rrtype data, not via cname)

[mcmanus]

also see pr #73

[kazuho]

unfortunately to use bighoster.com's new ESNI infrastructure www.example.com would need to add a CNAME record for _esni.www.example.com as well. So the ESNI deployment requires DNS changes outside of the org deploying ESNI, which is going to limit its deployment, which in turn is going to limit the breadth of its anonymity pool. :(

I am not sure if I agree with the problem statement.

To me it seems that the argument is based on the assumption that bighoster.com is the one to decide if ESNI should be applied for www.example.com. I am not sure if all of us would be happy with that assumption.

The alternative approach here is to give the owner of each hostname the freedom of deciding whether the hostname should be covered by ESNI. Current design allows the hosting companies to adopt that model, by using the DNS configuration that the hostname owner controls as the switch.

[mcmanus]

ESNI is already a property of the server not the origin name.. in the same way the version of TLS or the cipher suite set is a property of the server.. or the level of http. All necessarily under the control of bighoster.com because it reflects whatever is available on their infrastructure.

bighoster may commonly allow their customers to configure this stuff on a per customer or service basis, but that's a bit of a different take and not incompatible with the approach here.

[kazuho]

@mcmanus While that might be true, I am not sure if removing the _esni prefix and introducing ESNIInclude (#110) is worth the additional complexity and overhead.

Assuming that we merge #109, #79 becomes a non-issue. Because a wildcard will much all names with the designated type, including the _esni prefix.

For example, the following configuration will support ESNI for all the hostnames under example.com, like a.example.com, b.c.example.com, because any query for _esni.*.example.com resolves to *.example.com.

*.example.com. IN A 192.0.2.1
*.example.com IN ESNI ...

So the only downside is that using prefix and a dedicated RR type at the same time might look strange. But it's practical.

I am not sure if we would prefer to require alias resolution for every ESNI client.

Implementation wise, it's about reimplementing what DNS recursor usually does in the stub resolver. You need to do things like detecting too many redirects and/or loops.

There would also be a performance degradation, because each client needs to do the recursive lookup, while with the prefix we can rely on the recursive resolvers to do it and cache it for other clients.

To reiterate, I wonder if there is any practical reason to reinvent the wheel.

[MikeBishop]

Stretching the bounds of my DNS knowledge here, but I think this makes divergence between the A/AAAA and ESNIKeys records much less likely. That is, when www.example.com is served by both CDN A and CDN B, the DNS will return www.example.com CNAME www.example.com.cdnalpha.com or www.example.com CNAME www.example.com.cdnbeta.com. If both things are record types on the same hostname, then the divergence only happens when the queries happen on opposite sides of a cached CNAME record expiring and getting the opposite answer the next time around.

But if they're separate hostnames, as in the current doc, it's entirely possible to get opposite CNAME records cached, and you've diverged for all clients of the caching resolver for the TTL of the shorter CNAME record. That's a far worse probability of divergence.

[chris-wood]

Fixed in #144. Closing.