[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 09:37 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 BC334130DDB for <doh@ietfa.amsl.com>; Wed, 24 Oct 2018 02:37:58 -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=ham 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 JvY0HgbzWSwd for <doh@ietfa.amsl.com>; Wed, 24 Oct 2018 02:37:56 -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 C329E12958B for <doh@ietf.org>; Wed, 24 Oct 2018 02:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:To:From:cc; bh=SRe0FswqNkK4l+Dn/OKZ1MRYXB7qVyIjRcH/4RZjykY=; b=H4CTv5prOpAhlIcgtODreVe0zpHIm2NtjCaNnHCJGmgIgOOswEBHotEZdVGyjXoFFkQkM6owUu BgDJXEqV7r+cCLcV1DuCVEntCf7lmovhtkujYCcy2+fjDWJFwlugsq2iB5uWe2LuDHUzsFaAGa2d7 uGEW4w8z0uhrERD90dUs=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebastian-desktop with esmtp (Exim 4.89) (envelope-from <sebastian@sebbe.eu>) id 1gFFbt-0001r4-Rk for doh@ietf.org; Wed, 24 Oct 2018 11:37:53 +0200
Received: from [192.168.4.100] (helo=DESKTOPA8GMOTG) by sebastian-desktop with esmtpa (Exim 4.89) (envelope-from <sebastian@sebbe.eu>) id 1gFFbt-0001r0-HN for doh@ietf.org; Wed, 24 Oct 2018 11:37:53 +0200
From: "Sebastian Nielsen" <sebastian@sebbe.eu>
To: <doh@ietf.org>
Message-ID: <001801d46b7d$3de32f50$b9a98df0$@sebbe.eu>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_302_1260088417.1540373873826"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdRreubztp4DjNfDSaWzm+WB9IGnuw==
Date: Wed, 24 Oct 2018 11:37:53 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/fxWVaXaC1I91udjid4iHWVdoDT0>
Subject: [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 09:37:59 -0000

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