Re: [Doh] panel discussion on DoH/DoC

Martin Thomson <> Sun, 10 February 2019 23:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 892871295D8 for <>; Sun, 10 Feb 2019 15:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=qb/zr04W; dkim=pass (2048-bit key) header.b=TSEd29HB
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ov1pJ4UUc0J2 for <>; Sun, 10 Feb 2019 15:51:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5278F12958B for <>; Sun, 10 Feb 2019 15:51:29 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 5A58D21A90 for <>; Sun, 10 Feb 2019 18:51:28 -0500 (EST)
Received: from web3 ([]) by compute1.internal (MEProxy); Sun, 10 Feb 2019 18:51:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=2Sv k+RDkcxyGtOrauqR9mVlKDiHJW1+mMmOBBJ5czSE=; b=qb/zr04WOkigDCy0GxH QPMLrMuPAobNbIVDYShq7ZQkScLB4E2emSWkQrPcW8SaRdETDomPmeILTSw7G5JY rr+e1LWP5yAx8JHtCKSlU0iUTWrGHnpWii9QXnoMb5oeOOGSEKyUUEKYjVmFnQbc tSACQnne1jZ2mSNehEc+osn1IU4X4oaMk6gUgsBZJl9W4Z5Lh5grLG9ZQN6fCice /I8ojLHkc9ky1sBRTTHylK+m4Gpkd8csVn45Z59g2lR0KAOJRZPt322sBEuobgUy zyMvdgRV3LUP+q8ZKJuEwGef3pRXLLAEH2gTVe0S2/8bTvOJuNfB+2FLBPCCx66n PxQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=2Svk+RDkcxyGtOrauqR9mVlKDiHJW1+mMmOBBJ5cz SE=; b=TSEd29HBybkPUwbiuxEFUiu/G99xYZJaqpgw6y6athAPCY2vTHgBH3ffm js34F26WUy0u93kl5ZRiudjOUOvITU5Yfg/nfua1+M3WMvt645zXfUeHbu/JiSC/ 4pdy5CEYqRdORvX0FU3JW/1RN6gP1oAlaKLczYNZQ6WuOMsZt/iNdNvk9stRLnwX nY8NySjKV30hcrPF+7kq2ZtgqzsPwUb6oDmtehxs4vZygy2k91/6MZl70PJaalKJ nMPIdUbKsAVaN2vDl9X/rugmMClSo/9Ov5y7xG2QpWOFnwrXbottRXFAKFo+5csH sXBa8MPNT1Z8zOkIXuqONxeTWJsXQ==
X-ME-Sender: <xms:_7hgXCPNi2ruaaWP1vRyJDj2kQQ-HEEmly90JoOdOhFKpRaR3pylcg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleejgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhfujgffsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:_7hgXL_a89-EcekNE9IR69ouAyyY7GxPbZIWGJhMU8uLoObtVc4e-A> <xmx:_7hgXP4POIomrSfm_J76pVLOdszEfT9BpPDwzLYuI_O-Al_z1p9IaA> <xmx:_7hgXAUVrjmLUkjtUHoVqoKGrz8_tL_KRBflzqIo_cc52HmXkk287Q> <xmx:ALlgXPu5_LCMPw4Pop-MbrSNQXXIUnYCNfTve6ZcYHDNk9j9FXY_dQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id BF2EA9E567; Sun, 10 Feb 2019 18:51:27 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-e6290ad1
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 11 Feb 2019 10:51:27 +1100
Archived-At: <>
Subject: Re: [Doh] panel discussion on DoH/DoC
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, 10 Feb 2019 23:51:31 -0000

On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:
> Those are great points and I may have taken some liberty with the the
> "multiplexing across many DOH providers" statement as I'm not really sure
> what browsers want to do, it just seems like having one or a few options is
> not ideal. Anyway, I recognize that the work I'm interested in is not
> protocol work (as far as I can tell), so I'll stop bugging folks here!

I don't think that this is entirely crazy.  I agree with Shane that trying to load balance between servers or randomly route to servers is likely to be worse than just picking one, but one option we've considered is picking one server randomly and using that consistently thereafter.  (Cue all the second-order questions regarding how to use that for tracking, etc...)

There is also talk of finding ways to route requests to servers that might own the same name, but that's far more risky.  In other words, this is not a decided matter because it is so clearly not simple.