Re: [Doh] signalling client expectations and server capabilities

"Mark Delany" <> Sun, 02 June 2019 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6B491200F5 for <>; Sun, 2 Jun 2019 13:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wdmOjoFS5dp6 for <>; Sun, 2 Jun 2019 13:57:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DFD9012004E for <>; Sun, 2 Jun 2019 13:57:38 -0700 (PDT)
Received: by (Postfix, from userid 1001) id CD4933B05C; Mon, 3 Jun 2019 06:57:35 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;; s=2019; t=1559509055; bh=2hDS0esy/D1gSwvjc+2tyG3tJLM=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=M94hGQhNSzLZe/j5KXAOWRzWdo2GMa/R6Mxglrna5RK583l2OJfd2mfYflly5o7RX K/kSLK3DXfrEJq5qXyPWd+No6txt0SU22ya+vDOnvIl1+mc9bsNqUh18cW+RKixZxE eF+gmsIvw5PQfddDnU400XKU/JPAF5NtYWmo07Xo=o07Xo=
Comments: QMDA 0.3a
Received: (qmail 17700 invoked by uid 1001); 2 Jun 2019 20:57:35 -0000
Date: 2 Jun 2019 20:57:35 +0000
Message-ID: <>
From: "Mark Delany" <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Doh] signalling client expectations and server capabilities
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Jun 2019 20:57:41 -0000

On 02Jun19, Jim Reid allegedly wrote:
> > On 2 Jun 2019, at 16:54, Joe Abley <> wrote:
> > 
> > In the very general sense (ignoring protocol specifics relating to the DNS and HTTP) it feels like it might be handy to be able to specify a capabilities requirement with a query. Something like
> > 
> >  - I want an answer to the question PIR.ORG/IN/SOA with RD=1
> >  - I want query minimisation and secure transport for recursive queries
> >  - I want you to confirm explicitly that you understand the request for query minimisation

Yes, I had thought about mentioning capabilities but I doubted anyone would have
read below the fold of my email :-)

One thing I wondered about is how well capabilities work in a multi-hop and
multi-transport system that has DoH in the path. In the very general sense
should a stub resolver asking for capabilities have said query punch all the way
through to an auth server?

There is already a smattering of adhoc capability signals in DNS such as TC=1
and maximum response size which probably should have received some attention in
8484 so if nothing else maybe formalization will at least raise the question for
future protocol designers: "how do we deal with capabilities?".

> Hmmm. The add list might be a more appropriate place to discuss this. Or maybe dnsop. It???s not clear if these sorts of capabilities could/should be signalled in DoH or vanilla DNS.

It's certainly a big topic and probably risks the second-system syndrome.