On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <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. > Petr Špaček @ CZ.NIC > > >> Tom >> >>> On Aug 20, 2018, at 10:31 PM, Tom Pusateri <pusat...@bangj.com >>> <mailto:pusat...@bangj.com>> wrote: >>> >>> Sure. My point was that there could be legitimate uses of DoH. >>> >>> You have to move DNSSEC validation from the resolver to the client in >>> order to really validate the answers if you can’t trust the resolver. >>> >>> Tom >>> >>> >>>> On Aug 20, 2018, at 10:28 PM, Ted Lemon <mel...@fugue.com >>>> <mailto:mel...@fugue.com>> wrote: >>>> >>>> Of course, the question is, how does the consumer of that data decide >>>> what is okay and what's not? We can't just say that the server has >>>> to behave correctly: someone has to enforce it. >>>> >>>> On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri <pusat...@bangj.com >>>> <mailto:pusat...@bangj.com>> wrote: >>>> >>>> >>>> >>>> > On Aug 20, 2018, at 10:21 PM, Paul Vixie <p...@redbarn.org >>>> <mailto:p...@redbarn.org>> wrote: >>>> > >>>> > >>>> > >>>> > Tom Pusateri wrote: >>>> >> ... I don’t know if it’s generally accepted that DoH will replace >>>> >> UDP/53 or DoT in the stub resolver or DoH will just end up in the >>>> >> browsers as a way to speed up web pages. But if DoH stays in the >>>> >> browser and DoT is tried and used on all DNS servers, there’s not a >>>> >> problem to solve. >>>> > >>>> > if DOH is widely used by criminals, botnets, and malware to >>>> bypass perimeter security policy, then there will be a big >>>> problem and we will be solving it for many years to come, even if >>>> the browser is the only thing using it. browsers are where most >>>> modern vulns have occurred, and i expect that trend to >>>> accelerate. "because that's where the money was.” >>>> >>>> I can see good use cases and bad ones. >>>> >>>> If web servers did DNSSEC validation and only served addresses >>>> for names that were validated, I wouldn’t have a problem with >>>> that at all. >>>> >>>> If web servers only served addresses for names within the domain >>>> of the web server, I wouldn’t have a problem with that either. >>>> >>>> if they start serving non DNSSEC validated addresses for names >>>> outside their domain, I think they’re overreaching. >>>> >>>> Tom > > _______________________________________________ > 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
