IETF Logo Mail Archive

[Doh] signalling client expectations and server capabilities

Jim Reid <jim@rfc1035.com> Sun, 02 June 2019 16:22 UTC

Return-Path: <jim@rfc1035.com>
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 485981200DB for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 09:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 JwzA6NNh71x3 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 09:22:12 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7771120094 for <doh@ietf.org>; Sun, 2 Jun 2019 09:22:11 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 2DDD324205E6; Sun, 2 Jun 2019 16:21:53 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <D857B391-A414-4681-9AC2-72D82301ACE6@hopcount.ca>
Date: Sun, 02 Jun 2019 17:21:52 +0100
Cc: Mark Delany <d5e@xray.emu.st>, doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C954F5BA-0B74-4D6F-9395-B537EFCC7CF8@rfc1035.com>
References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl> <20190602121754.15405.qmail@f3-external.bushwire.net> <D857B391-A414-4681-9AC2-72D82301ACE6@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/ymxq3CSSrwczb9CXhQNHBB8qWc0>
Subject: [Doh] signalling client expectations and server capabilities
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: Sun, 02 Jun 2019 16:22:13 -0000


> On 2 Jun 2019, at 16:54, Joe Abley <jabley@hopcount.ca> 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

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.

v2.23.0 | Report a Bug | By Email