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

Philip Homburg <> Fri, 24 August 2018 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6478A128CB7 for <>; Fri, 24 Aug 2018 07:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id INhfN7-Kft4u for <>; Fri, 24 Aug 2018 07:45:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 427511286E3 for <>; Fri, 24 Aug 2018 07:45:43 -0700 (PDT)
Received: from (localhost [::ffff:]) by 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: <>
Cc: Paul Hoffman <>
From: Philip Homburg <>
References: <> <> <>
In-reply-to: Your message of "Fri, 24 Aug 2018 14:25:30 +0000 ." <>
Date: Fri, 24 Aug 2018 16:45:12 +0200
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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