On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <mbis...@evequefou.be> wrote: > > Stephen, there are a couple complicating factors here where I think we all > have varying knowledge gaps. > > There are two major ways of pointing to a CDN: Direct A/AAAA records and > CNAMEs. The easiest way to handle key update complexities on the part of the > CDN(s) is simply to CNAME the ESNI query for your domain to their ESNI > record, but you can certainly directly host your CDN’s keys in your domain if > you prefer. Nothing should preclude that. > The issue we’re trying to address is when the ESNI record and the A/AAAA > record follow different CNAME chains and you get the records from different > hosts. Of course, if we move to an ESNI RRType with the same hostname (see > #105), there’s hopefully a single CNAME chain that gets cached at the > resolver and used when looking up both queries. If they remain separate > hostnames, it seems like it gets much easier for them to diverge. > It’s my understanding that DNSsec doesn’t play well with returning a subset > of all extant RRs for a given name+type. However, some CDNs return DNS > results tailored to the user’s location; the load-balancing servers will (in > some cases) return CNAMEs to different targets based on the desired traffic > share. That’s not a behavior that maps well to DNSsec as I understand it. > You mention DNSsec signing your domain as part of why you have issues with > the proposal, but I think this is an open issue beyond ESNI or these PRs. > > Maybe someone better-steeped in DNS/DNSsec can help us figure out how all > that should work, and I agree with you that there are definitely bumps here > we need to iron out – maybe those are just questions to answer, or maybe > changes to the structure of the record are warranted. > > However, these PRs are primarily about what information should be in these > records and how clients make use of it. I disagree with you that we have to > resolve both questions at the same time. Let’s agree on content first, and > spent some time separately with DNS folks to see whether the content can be > more pleasantly arranged.
Thanks all for the discussion so far! Focusing strictly on the content of the records and not the formatting, as Mike suggests, we essentially have the following: - #137 gives clients a way to detect A/AAAA+ESNI mismatch and recover, at the cost of another sequential DNS query for ESNI. In this change, A/AAAA records still control where traffic goes. - #136 never requires clients to send a second DNS query for ESNI since clients ignore the A/AAAA results. In this change, ESNI records dictate routing. With #137, clients willing to send a second DNS query will get ESNI for all supporting providers. Clients unwilling to send a second DNS query will only get ESNI for those providers which ensure that their A/AAAA and ESNI records very rarely mismatch. With #136, clients only get ESNI for those providers capable of building ESNI records with correct addresses. In theory, these providers should be the same ones that could ensure A/AAAA and ESNI record matching. Given this, the discussion seems to hinge on the following question: Are operators comfortable with the risks of letting ESNI records control routing. If so, #136 is probably a better design for said operators. If not, then #137 is probably required. Note that this does not mean we must choose between #136 and #137 right now. We can do both (after possibly simplifying #137!), use them, and see what works best in practice. Anyway, I hope this summary accurately captures the differences and possible tradeoffs. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
