Re: [Doh] [Ext] DoH client-server interoperability vs. strict HTTP parameter checking

"Mark Delany" <> Sat, 01 June 2019 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6878B1201FA for <>; Sat, 1 Jun 2019 09:08:34 -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 kMrgDTUbikRr for <>; Sat, 1 Jun 2019 09:08:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ADE3E1200B4 for <>; Sat, 1 Jun 2019 09:08:32 -0700 (PDT)
Received: by (Postfix, from userid 1001) id C23363B05B; Sun, 2 Jun 2019 02:08:30 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;; s=2019; t=1559405310; bh=cvs6HapMJR9CLvX6+rnYfpgu2a8=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=bbSQkBaY+bX3wTcmVAFUq0BNS3Bw0GV8FL8cppev8DWvTpXA7xr/HvJRRdb6b97+U 7zt9leMSQNMYwJNMD92/qck6KuvgUC2RECc7yzPMoOQOaSHc8IW1y3iDyFrOXX5PA6 tTPHDVUhsJLS/etbYFsIpnVSmNg6xv84w6G9YKi0=9YKi0=
Comments: QMDA 0.3a
Received: (qmail 10634 invoked by uid 1001); 1 Jun 2019 16:08:30 -0000
Date: 1 Jun 2019 16:08:30 +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] [Ext] DoH client-server interoperability vs. strict HTTP parameter checking
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: Sat, 01 Jun 2019 16:08:35 -0000

> > should DoH servers be less strict and simply ignore additional HTTP
> > parameters and proceed with processing the relevant HTTP parameters
> > required to provide an answer?
> Yes.
> RFC 8484 makes it clear that a "DoH server" is just an HTTP server that understands the DoH semantics. Trying to limit it beyond that is just wrong (or maybe just lazy).

(I'm not sure about lazy since an HTTP server probably has to have
more code included to make such tests.)

As to the original question, the problem for a server that rejects
unrecognized HTTP parameters is, how does it differentiate between a
non-standard parameter and a parameter which was standardized in a
future version of RFC8484 written after the server was deployed?

Surely a server has to expect that it will eventually be talking to a
client from the future which will, by definition, be adding unknowable

Clearly a client is taking a small but non-zero risk that its
non-standard parameters may collide with the future as well, but the
namespace is kinda large so the risk is low.

Out of curiousity, what are these extraneous parameters and why is the
client sending them? Are they relevant to the DoH query?