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

Joe Abley <> Sun, 02 June 2019 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 528281200E6 for <>; Sun, 2 Jun 2019 08:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 tP-5MiBBfL3j for <>; Sun, 2 Jun 2019 08:54:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B468D120026 for <>; Sun, 2 Jun 2019 08:54:23 -0700 (PDT)
Received: by with SMTP id a186so23610181itg.0 for <>; Sun, 02 Jun 2019 08:54:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cWMPAVZ3FnrVrqKljNOCqj4v2uqzIQBU2L5h5zOdoHk=; b=J3FdB5+Y06nYmfKS8OdMDYrJHoFbAe2nzRyUGQgVtPa/rbAxmjynYcftkUPZ4DU8ZX fE7uFlY8bKP+5Go0SFcN4SeoWk/6uLl0gbEM/75HrI4TL/oikJ7aXlj+s/EM/1LaXr7n kn5qEeByBIuuXehW6/JzSafY5tpP9KMZwE3Ho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cWMPAVZ3FnrVrqKljNOCqj4v2uqzIQBU2L5h5zOdoHk=; b=UhwrvNKo0gJKtlKj/j9Afi3uB5EuLOuDeXAnhr8jcIrTtaX6iXxLoGri79qK/J3OrV NYL4aJg9+yjaeOVO8IX0k37Nkb1y28xQDPzG/L1ehti5om3tBU9S+ju5cZd/Ybs9uhBe YkDdYB+Ry/o1gc3Qyq8o8de1VciolNkCwmwqR18oe56sxOolVzptqAwES2AiYytxMVXg +IzhVF1jkkVQEfdLfVN4LpBgjHBw6UfhkMA0Ss9M0Grx/j9wXfTauPOg3OF4T8D+74Zf 19Wmn/N/zEUMDw2JAf7so4m/fhZ05L5uqTQvnn4G50dxSzJrJOKsDr8RWtBhi3327AgT TyrA==
X-Gm-Message-State: APjAAAVHckhwTep7t2WKVKSfPkzYkyvLENN8VuiVYwXTpacrXLQzUZy0 D/Ccvp5B+u1NyGI8uVJ0XovVczWMH3X3TZAk
X-Google-Smtp-Source: APXvYqxDP7QAIHZphbIkPAtdJ9oMwLYrhKMahSMwV4lW0ZeNZxXlY4CXQPUxkvqR13wVIw4ZalG9Sw==
X-Received: by 2002:a05:660c:a59:: with SMTP id j25mr14005357itl.111.1559490862919; Sun, 02 Jun 2019 08:54:22 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t22sm2294987ioc.75.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jun 2019 08:54:21 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_C408DF3A-FB08-404E-BE8E-C888A50900FA"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 2 Jun 2019 11:54:20 -0400
In-Reply-To: <>
To: Mark Delany <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
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: Sun, 02 Jun 2019 15:54:25 -0000

Hi Mark,

On 2 Jun 2019, at 08:17, Mark Delany < <>> wrote:

>> And in the DNS world we've often let clients know we don't get their
>> newfangled speak (FORMERR).  Silently ignoring unexpected parameters is a
>> great way to proliferate half-working configurations.  "Did
>> parentalcontrol=0&malwarefilter=1 get accepted or not?  I have no idea".
> There are certainly pros and cons to this as well as many counter-examples.
> Haven't we just spent the last decade trying to encourage things like caches,
> forwarders and firewalls to accept and pass thru DNS RR types they don't
> recognize?

I'm not sure that's actually a particularly good example. New RRTYPEs are not new parameters or new protocol elements; they're existing ones with different code-points. The distinction is important. To the kinds of intermediate actors you mention, wire-format RRSets ought to be passed through as opaque structures.

> After all, how would we ever extend DNS if every component rejected
> every RR type and OPT sub-type it didn't understand?

EDNS is a better example, since RFC 6891 makes it clear that unknown options MUST be ignored.

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

A receiving server could ignore the request for secure transport if it didn't understand it, but would refuse to process the query if it didn't understand query minimisation (and hence would otherwise silently discard the request).