Erik, In that case you should take a hard look at caching. The ESNI lookup needs to retrieve the name and the SNI key of the published server. It will remain valid as long as the key or the relationship between published and private does not change. If it is cached, the only required real time lookup is for the current address of the published server, which arguably may change more often than the ESNI data. So with proper caching, all that can be optimized.
-- Christian Huitema > On Jul 26, 2019, at 2:58 PM, Erik Nygren <erik+i...@nygren.org> wrote: > > The need to bootstrap ESNI (encrypted SNI) keys via DNS is the forcing > function here for clients. They need to do something new here to address > that, and if that requires an additional lookup then there is opportunity if > other problems can be solved at the same time as long as we don't slow down > ESNI deployment or hurt performance over an ESNI-specific solution. > > Erik > > >> On Fri, Jul 26, 2019 at 2:52 PM 神明達哉 <jin...@wide.ad.jp> wrote: >> At Tue, 23 Jul 2019 17:04:43 +0200, >> Matthijs Mekking <matth...@pletterpet.nl> wrote: >> >> > But as soon as clients start querying for ANAME (and not address >> > records) meaning it will chase the target itself, the DNS server >> > actually does not have to do a target lookup anymore. >> >> True, but my understanding is that the key difference is that the web >> browser community (at least some big players of it) is willing to >> support HTTPSSVC, thereby already overcoming the most difficult part >> of the chicken-and-egg problem: how to deploy it in the client side. >> I actually don't fully understand how HTTPSSVC has got the support >> while ANAME hasn't though (perhaps because of the incentive of other >> HTTPSSVC features like the alternative service form?). >> >> Once a sufficient number of clients support it, the authoritative side >> will have the incentive of deploying HTTPSSVC, and if it's >> sufficiently deployed in the authoritative side, too, then we can >> eventually hope to deprecate the practice of CNAME at apex. >> >> Right now, I'm not sure how we can expect this to happen for ANAME >> (except by waiting for perhaps several decades, until almost all >> recursive servers natively support ANAME). >> >> -- >> JINMEI, Tatuya >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
