IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Fri, 24 August 2018 14:45 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6478A128CB7 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 07:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 INhfN7-Kft4u for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 07:45:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 427511286E3 for <dnsop@ietf.org>; Fri, 24 Aug 2018 07:45:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1ftDKw-0000FDC; Fri, 24 Aug 2018 16:45:18 +0200
Message-Id: <m1ftDKw-0000FDC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Paul Hoffman <paul.hoffman@icann.org>
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <3D4A9165-6EE8-4997-A9F7-DB19632C25F3@icann.org> <5220d889-e587-d6dc-db45-0d76370eabae@nic.cz> <61FF26F6-F2E2-48C8-A4B6-94FC6652D55E@icann.org>
In-reply-to: Your message of "Fri, 24 Aug 2018 14:25:30 +0000 ." <61FF26F6-F2E2-48C8-A4B6-94FC6652D55E@icann.org>
Date: Fri, 24 Aug 2018 16:45:12 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5w5_2N0nNMVWqQjIITLS3arOGlc>
Subject: Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2018 14:45:46 -0000

> > Well, if the OS resolver is validating, it will SERVFAIL with such a
> > query.
> 
> The protocol requires special handling of those specific queries,
> so a resolver that understands the protocol will give the desired
> answer. A resolver that doesn't understand the answer will give
> NXDOMAIN even if it is validating because that RRtype is not in
> the root zone.

It seems to go wrong when you have one validating resolver that forwards to a
resolver that supports this mechanism.

It don't really see the point of what you propose. For resolvers obtained by
DHCP it makes more sense to include the URL in the DHCP reply than to have
yet another DNSSEC-violating discovery hack.

For manually configured resolvers, it is likely more convenient for the user
to just enter the URL and let the system figure out the addresses of the
resolvers.

Figuring out what SNI to use using insecure DNS sort of negates any advantage
TLS authentication offers.

v2.23.0 | Report a Bug | By Email