Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver

[Ben Schwartz <[e-mail]>]

Hi Sebastian,

This is definitely a topic of interest, but it may be outside of the DoH
Working Group's charter.  Discussions on this topic have been moved to
their own special mailing list:
https://mailarchive.ietf.org/arch/browse/resolverless-dns/

I encourage you to read the messages there, and also to send your thoughts
to that list.

Thanks,
Ben Schwartz

On Wed, Oct 24, 2018 at 6:06 AM Sebastian Nielsen <sebastian=
[e-mail]> wrote:

> 1: Yes, but the server should supply the whole chain to the root, thus the
> client only need to do root validation.
>
> 2: yes.
>
> 3: The reason to require DNSSEC signature for third-party domains is so
> not a hostile WWW server can replace answers to third party domains, for
> example loading paypal.com in a frame and then pointing paypal.com to
> themselves.
>
>
>
> 4: The server should point this out to the administrator during
> configuration. The thing is that the client should refuse to accept
> non-DNSSEC signed responses for reason 3. The server could just refuse
> queries for domains not DNSSEC signed, like for domains not in the ACL, but
> the server should of course keep the domain in the ACL in case it selects
> to start DNSSEC signing in the future, but for such domains cache updating
> could be done less often, for example weekly.
>
>
>
> During configuration of the ACL, or startup of the server software, and if
> it doesn’t have any cache data written, the server could simply “prime” the
> cache by doing one request for all domains in the ACL, for all record types.
>
>
>
> *Från:* Doh <[e-mail]> *För *Ulrich Wisser
> *Skickat:* den 24 oktober 2018 11:54
> *Till:* Sebastian Nielsen <sebastian=[e-mail]>
> *Kopia:* [e-mail]
> *Ämne:* Re: [Doh] Suggestion: The final endpoint should be able to
> temporarly act as a recursive DoH resolver
>
>
>
> I can see the reason behind this but would like to point out a few details.
>
>
>
> - clients would have to do dnssec validation
>
> - servers would need to not only provide answers to queries, but also the
> dnssec chain for the validation
>
> - what should happen with not dnssec signed answers? Dropped? How will the
> client get an answer in that case?
>
>
>
> Additionally, I think it should be made clearer that an endpoint should
> only answer for a known list of domains, as to not get abused by clients.
>
> - what should a server do if a not dnssec signed domain is configured in
> it's list?
>
>
>
> /Ulrich
>
>
>
> Sebastian Nielsen <sebastian=[e-mail]> schrieb am Mi.,
> 24. Okt. 2018 um 11:38 Uhr:
>
> I have a suggestion for extending the DoH specification:
>
>
>
> The final endpoint, should be able to act as a authorative and sometimes
> recursive DoH resolver if it has support for the DoH protocol, during the
> normal HTTPS connection.
>
>
>
> This could mean that once you reach a WWW server, theres no need for
> looking up domains like static.example.org and such since the result of
> such domains could be returned by the original HTTPS server over the same
> connection as the website traffic goes over.
>
> If the HTTPS server has other domains for example
> ads.thirdparty-example.org as links it could return those aswell but only
> if they are DNSSEC signed, and for security, a DoH client should only
> accept results for a third-party domain if the result is DNSSEC signed.
>
>
>
> To avoid abuse, a WWW server supporting this extension should only allow
> queries for its own domain and subdomains, and also queries for any
> resources it has been configured to resolve (and this type of configuration
> could be done automatically by for example a script on the web server that
> adds all external links to its ACL)
>
>
>
> This would mean an WWW server serving content for itself and also have
> links to ads.thirdparty-example.org could have those 2 domains cached in
> its internal DoH resolver and resolve for those, thus once you reach a
> webpage’s server, you no longer need to talk to your recursive DoH serverl,
> which also increases privacy.
>
>
>
> This could lead to much faster response times aswell, as the WWW server
> would have the information about all its linked hosts permanently cached
> and updated regularly.
>
> Think like OCSP stapling but for DNS responses instead.
>
>
>
>
>
> Best regard, Sebastian Nielsen
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>
> --
>
> Ulrich Wisser
>
> [e-mail]
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>