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

"Sebastian Nielsen" <sebastian@sebbe.eu> Wed, 24 October 2018 10:06 UTC

Return-Path: <sebastian@sebbe.eu>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1311130EE2 for <doh@ietfa.amsl.com>; Wed, 24 Oct 2018 03:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEh5XVyeGqAO for <doh@ietfa.amsl.com>; Wed, 24 Oct 2018 03:06:18 -0700 (PDT)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB8A130E86 for <doh@ietf.org>; Wed, 24 Oct 2018 03:06:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:Cc:To:From; bh=yveUXWVc+lUk6Vu2IiXTN+4tLB1eTxkxODAZzzoVqHo=; b=AZpME09H4zMrswd0acy/rNB8tpoEIr/UoIoBFZ8FsTdowufmEUEmAldXcVpadmvg7xxbKYlldt q4G/y25p9OnmyMClEBXzTr5fjRWPItlqAFx8aT45Pdnrss0Nshgg+nn7PT0+vImTp8q6HtD50u1E8 j1QpihrXxi6Y9Fnf3EuQ=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebastian-desktop with esmtp (Exim 4.89) (envelope-from <sebastian@sebbe.eu>) id 1gFG3L-0001uU-Fn; Wed, 24 Oct 2018 12:06:15 +0200
Received: from [192.168.4.100] (helo=DESKTOPA8GMOTG) by sebastian-desktop with esmtpa (Exim 4.89) (envelope-from <sebastian@sebbe.eu>) id 1gFG3L-0001uQ-2o; Wed, 24 Oct 2018 12:06:15 +0200
From: "Sebastian Nielsen" <sebastian@sebbe.eu>
To: "'Ulrich Wisser'" <ulrich@wisser.se>, "'Sebastian Nielsen'" <sebastian=40sebbe.eu@dmarc.ietf.org>
Cc: <doh@ietf.org>
Message-ID: <003601d46b81$341b13d0$9c513b70$@sebbe.eu>
In-Reply-To: <CAJ9-zoUtsunVNuuMOdhJfsE9qqD9bNW_YA4z3Gr1_zormLku=Q@mail.gmail.com>
References: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu> <CAJ9-zoUtsunVNuuMOdhJfsE9qqD9bNW_YA4z3Gr1_zormLku=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_308_1124527970.1540375575445"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJsIUaNuBL0KKV8fbIZoMpu0AyRxwI3K8v2o+0EZHA=
Date: Wed, 24 Oct 2018 12:06:15 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/gCMVJJbuo3rBzAT7_TPEQnWpVsM>
Subject: Re: [Doh] Suggestion: The final endpoint should be able to temporarly act as a recursive DoH resolver
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 10:06:24 -0000

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 <doh-bounces@ietf.org> För Ulrich Wisser
Skickat: den 24 oktober 2018 11:54
Till: Sebastian Nielsen <sebastian=40sebbe.eu@dmarc.ietf.org>
Kopia: doh@ietf.org
Ä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=40sebbe.eu@dmarc.ietf.org <mailto:40sebbe.eu@dmarc.ietf.org> > 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
Doh@ietf.org <mailto:Doh@ietf.org> 
https://www.ietf.org/mailman/listinfo/doh

-- 

Ulrich Wisser

ulrich@wisser.se <mailto:ulrich@wisser.se>