Re: [Doh] comments to DoH/RFC8484

StarBrilliant <> Thu, 01 July 2021 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF2C03A103F for <>; Thu, 1 Jul 2021 15:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=GlheoiAZ; dkim=pass (2048-bit key) header.b=K96t1q4l
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W8ehev4Wj9DK for <>; Thu, 1 Jul 2021 15:40:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79EB63A103E for <>; Thu, 1 Jul 2021 15:40:38 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 0E0185C0197 for <>; Thu, 1 Jul 2021 18:40:35 -0400 (EDT)
Received: from imap10 ([]) by compute3.internal (MEProxy); Thu, 01 Jul 2021 18:40:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=hqsRNorRcrhcYsrKGsbDhWPJdugcEDE /gKAKe9pwiKQ=; b=GlheoiAZtHxKfu1AE/vml4yXxh/No1KYa7k9vdZdk/q2CCb kvReWslzQEXSQuvDe1MHTi6nO4ZdlV/R+3iQDBsrS3LdSM2wwqr+YUD1q9oqPr1d CJ1tF2rMKfY+F6mx/xmcnikKpSAC588AT/qsop1uYhPOmpshsILJkx5mrmI6kU9g Nvi1f7IpDZWCGo7edISYPOZsnK+3+O18IVBy9HQJ2BeHebMNXaz9mz1UQrQgauSl oMJBIyEefcRVt/LivEtSSwTEcMvJL0reeWC6+o3c32TP/GVcKwIAW2J5YFVxER67 bocECrfGJjiXyjTUg6bzoqj/kYFciS6sYk4amzw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=fm3; bh=hqsRNo rRcrhcYsrKGsbDhWPJdugcEDE/gKAKe9pwiKQ=; b=K96t1q4lWntATssXFVkoqu Ky26ceiKgG7ZSv2nByeanQbF+AzBrCym6NkLERYQn5C0efdAN7NsEKuZtGh0gvHn MuRyO3z3EN9tsUSdkI0qHIBAyB3pHK2FlW1BEeBVPjv9/PLIOLVC8yKGYaGJbAyf F9c+QVi1Bd93bSSENT0kNXB7uQRIet4j7ZXJftJUgbMt5IEyKGdPawKnJFfv4rIM lCdBkCunudvXbwEQH596lfyedhsQcoReT96mekWpuMG68fPZU1APWLkfca9I7R+B cZuvYfpMP2FJboDBrSOAtYh3iTHFgVZTDJoXq2frB6ucfBVxoRWBAkgfuYkT9sRw ==
X-ME-Sender: <xms:YkTeYNtGphSzrBeAtAfojpJz5SQVM6A6aYtvzaodjYexAOkP8HvtiA> <xme:YkTeYGcJT7LCsDsfZiXffoytD2QuAKVmnyjYwCBUQujOKELGX8Zx_T2wpGrdy-UjW tB-5Whun4Wxw0JohAc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeijedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpefuthgrrheurhhilhhlihgrnhhtuceotghouggvrhesphho ohhrlhgrsgdrtghomheqnecuggftrfgrthhtvghrnheptdduffffuedtgfffgedvkeeffe ejheeghedugfffjeeitdeiieehheffudehkefgnecuffhomhgrihhnpeifihhkihhpvggu ihgrrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegtohguvghrsehpohhorhhlrggsrdgtohhm
X-ME-Proxy: <xmx:YkTeYAzjbeIzcwfWOftUSDwGNHbKgBml3gRo_x9HGfuXyzYG2GTKSw> <xmx:YkTeYEPguR6XbkUdqqWJsAny2o5ThezM-qc1DpTYmtgjU_uZwQi6TQ> <xmx:YkTeYN9yqChT4B_A9Ibv37-RnjjAfdSKoL0PsS7FH_6fI1oZgdpc1g> <xmx:Y0TeYAKSaL6pPeo_psq3D8z3e2tWI56XjmYe8juxvNAPGwH98Va4Bw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 950744E0091; Thu, 1 Jul 2021 18:40:34 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Thu, 01 Jul 2021 22:40:11 +0000
From: StarBrilliant <>
Content-Type: multipart/alternative; boundary=9366977445214baf902e49aff2df4389
Archived-At: <>
Subject: Re: [Doh] comments to DoH/RFC8484
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: Thu, 01 Jul 2021 22:40:44 -0000

Hi Stefan,

I am not an IETF person. But as the core maintainer of the project "m13253/dns-over-https", my short answer to your question is:
DoT is nation-widely blocked in China; while DoH is not (and can't be), unless it's a well-known DoH server on their human-maintained block-list.

Speaking of encrypted DNS, besides DoT, we also have DNSCrypt many years ago. They both work well in countries where you could sue your ISP if they forbid you from using them. DoH not only hides the content of your DNS communication, but also hides the fact itself that you are using an encrypted DNS service.

Any technology could potentially become a double-edged sword. You could gain Internet neutrality by hiding DNS from your ISP; but your home IoT products can also send encrypted DNS requests hiding from you. We can't stop the development of technology; instead, standardizing them would push the balance more towards the kind side than the evil side.

Also, DoH allows web applications written in JavaScript to submit DNS requests, where DoT can't.

Best regards,

On Mon, Jun 28, 2021, at 10:52, Stefan Kärst wrote:
> hi Team,
> I'd like to add some personal thoughts about RFC8484
> I'm working as an system administrator for quite a long time now. I 
> started working in IT in 1991.
> part of my daily work is to analyse problems regarding applications 
> running on GNU/Linux, either as VMs, bare metal or within clouds and/or 
> containers. based on my experience half of all problems are caused by 
> network issues including DNS.
> because of this it is important for me to be able to reproduce problems 
> and collect data to support customers. one of these tasks include 
> querying DNS. whether on the customers machines or on my own. as DNS is 
> an open globally distributed system, I can be sure to get the same 
> answers as applications/computers at the customers site are using.
> DoH not only breaks protocol layering. It makes our work useless in 
> terms of reproducing the data applications use. this is as bad as 
> caching of IP addresses within applications.
> both things do not belong into any application. IMHO
> there are dns resolvers and caching services like nscd available for 
> both purposes.
> as application use encrypted communication, we cannot check the (meta) 
> data and provide any kind of support if things do not work. even if DNS 
> would be encrypted .. it still is an open system so I can get the same 
> answers as any software would use.
> any software that works as a monolithic black box is a nightmare for 
> system administrators.
> I really hope you drop DoH in favour of DNS over TLS. with DNSSEC and 
> DANE there are standards available that make more sense in terms of 
> enhancing DNS rather than reinventing the wheel and put things into 
> application for what the operation system is meant to be responsible.
> I wish you could use your powers to promote DNS over TLS to keep DNS an 
> open distributed system for all! (except you are working for the Chinese 
> or Russian government and wish to make such services a secret to anybody ;)
> IMHO DoH has aspects of "security through obscurity" ;)  I cannot see 
> any advatage in DoH.
> Kind Regards!
> greetings from germany
> Stefan Kärst
> _______________________________________________
> Doh mailing list
> *Attachments:*
>  * OpenPGP_signature