Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Marek Vavruša <[e-mail]>]

On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <[e-mail]> 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 <[e-mail]
>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>>
>>>>     > On Aug 20, 2018, at 10:21 PM, Paul Vixie <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop