Re: [Doh] operational considerations

Patrick McManus <> Sun, 19 November 2017 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02BC4126B7F for <>; Sat, 18 Nov 2017 17:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P4i_ng3HqXNi for <>; Sat, 18 Nov 2017 17:48:09 -0800 (PST)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by (Postfix) with ESMTP id 7D2A3126557 for <>; Sat, 18 Nov 2017 17:48:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 6A3693A0A9 for <>; Sat, 18 Nov 2017 20:48:06 -0500 (EST)
Received: by with SMTP id i14so6492989lfc.1 for <>; Sat, 18 Nov 2017 17:48:06 -0800 (PST)
X-Gm-Message-State: AJaThX4pk6fBGevvdsAbHxBRI3xXvV3t6Kv38tzxixJWGQmoIIeHOip5 aXEQkgIHa8SMxs9mjxJNzIxR0oZJ5LLbXc9r1zg=
X-Google-Smtp-Source: AGs4zMaYCFNJoyaK8VoLjfUsNEpESvApbNQoAhczbs1qNQ4+fGdqLZsyqHBs2wJdziPuClUuxOy7/R+yJ5fCtKwLvh0=
X-Received: by with SMTP id 84mr2532728ljc.0.1511056085130; Sat, 18 Nov 2017 17:48:05 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 18 Nov 2017 17:48:03 -0800 (PST)
In-Reply-To: <>
References: <>
From: Patrick McManus <>
Date: Sun, 19 Nov 2017 09:48:03 +0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Eliot Lear <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="94eb2c1a168230a5b4055e4c2938"
Archived-At: <>
Subject: Re: [Doh] operational considerations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Nov 2017 01:48:11 -0000

Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it to
this scope I'm ok - but if the section begins to grow organically we should
really discuss moving to a different doc. I have a proposed  minor rework
of your text below which I believe to be more concise and a bit more
illuminating on the root issues. Let me know what you think.

Operational Considerations

Different DNS servers may provide different results to the same query. It
logically follows that which server is consulted influences the end result.
Split-horizon DNS [RFC6950] is a specific example of this approach where
the answers are derived from the (potentially natted) source of the query.
A client that chooses to query a non-default resolver for a name that is
using this style of algorithm may not obtain correct results.

The HTTPS channel used by this specification establishes secure two party
communication between the DNS API Client and the DNS API Server. Filtering
or inspection systems that rely on unsecured transport of DNS will not
function in a DNS over HTTPS environment.