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

From: "Sebastian Nielsen" <[email-masked]>
Date: Wed, 24 Oct 2018 11:37:53 +0200

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

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 24 Oct 2018 11:53:57 +0200

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=[email-masked]> schrieb am Mi., 24.
Okt. 2018 um 11:38 Uhr:

> 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.
>
>
>
> 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.
>
>
>
> would have the information about all its linked hosts permanently cached
> and updated regularly.
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
-- 
Ulrich Wisser
[email-masked]

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Wed, 24 Oct 2018 12:06:15 +0200

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 <[email-masked]> För Ulrich Wisser
Skickat: den 24 oktober 2018 11:54
Till: Sebastian Nielsen <sebastian=[email-masked]>
Kopia: [email-masked]
Ämne: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver

- 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=[email-masked] <mailto:[email-masked]> > schrieb am Mi., 24. Okt. 2018 um 11:38 Uhr:

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 <http://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 <http://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 <http://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.

 

_______________________________________________
Doh mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/doh

-- 

Ulrich Wisser

[email-masked] <mailto:[email-masked]>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Oct 2018 13:05:09 -0400

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=
[email-masked]> wrote:

> 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 <[email-masked]> *För *Ulrich Wisser
> *Skickat:* den 24 oktober 2018 11:54
> *Till:* Sebastian Nielsen <sebastian=[email-masked]>
> *Kopia:* [email-masked]
> *Ämne:* Re: [Doh] Suggestion: The final endpoint should be able to
> temporarly act as a recursive DoH resolver
>
>
>
> Sebastian Nielsen <sebastian=[email-masked]> schrieb am Mi.,
> 24. Okt. 2018 um 11:38 Uhr:
>

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 25 Oct 2018 15:42:15 -0400

Sebastian Nielsen writes:
> 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.

Do note that even if you're talking to www.example.org,
static.example.org can be in a different authoritative domain.  It
shouldn't be exempted from DNSSEC.