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

["Sebastian Nielsen" <[e-mail]>]

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] <mailto:[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 <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.

Think like OCSP stapling but for DNS responses instead.

 

 

Best regard, Sebastian Nielsen

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

-- 

Ulrich Wisser

[e-mail] <mailto:[e-mail]>