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
