> On Aug 21, 2018, at 3:30 AM, Marek Vavruša > <mvavrusa=40cloudflare....@dmarc.ietf.org> wrote: > > On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <petr.spa...@nic.cz > <mailto:petr.spa...@nic.cz>> wrote: >> On 21.8.2018 04:38, Tom Pusateri wrote: >>> Come to think of it, DNSSEC validation in the stub resolver or browser >>> is really a place DoH could shine. Instead of all the round trips >>> required for validating up (down) the chain, the webserver could package >>> up all those validated records and push them so the client/stub could do >>> the validation quickly for all of the links in a page in an order that >>> the user is most likely to need based on previous statistics and >>> scrolling position. >> >> Could you elaborate how DOH helps here? I can't see it now. >> >> We already have RFC 7901 (Chain Query requests in DNS) which allows >> resolvers to get all RRs required for DNSSEC validation in one round >> trip even over "classic" DNS. >> >> This haven't been implemented because up to know browser vendors have >> not been interested in DNSSEC which consequently lead us (resolver >> vendors) to ignore complex RFC with no demand. >> >>> From my point of view DOH does not change anything in this regard, >> complexity on stub & resolver side is the same no matter what transport >> is used. >> >> What am I missing? How does DOH help with this complexity when compared >> to classical DNS? > > I think Tom is referring to the h/2 push semantics. The resolver can > push the trust chain records > ahead of time, so the forwarder will already have them in cache when > revalidating the final answer.
Yes, plus the fact that the web/DoH server already knows all of the questions you might ask because it just fed you a page of content with links. The Chain Query Requests in DNS (RFC 7901) are awesome for the stub resolver. But the web/DoH server has more knowledge that the stub doesn’t have yet and so it can benefit from this knowledge in a way that the stub resolver can’t. Tom
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
