IETF Logo Mail Archive

Re: [DNSOP] extension of DoH to authoritative servers

Jim Reid <jim@rfc1035.com> Thu, 14 February 2019 07:50 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141AB12D7F8 for <dnsop@ietfa.amsl.com>; Wed, 13 Feb 2019 23:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3O0Z_JE8fa8 for <dnsop@ietfa.amsl.com>; Wed, 13 Feb 2019 23:50:19 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B0D12D4EF for <dnsop@ietf.org>; Wed, 13 Feb 2019 23:50:19 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 9B51B242109D; Thu, 14 Feb 2019 07:50:16 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
X-Priority: 3
In-Reply-To: <201902141436144299614@cnnic.cn>
Date: Thu, 14 Feb 2019 07:50:15 +0000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <212516D2-110D-45DD-B77B-46FD2BA6FECA@rfc1035.com>
References: <2019021215560470371417@cnnic.cn> <alpine.LRH.2.21.1902120846480.18026@bofh.nohats.ca> <201902131403257357123@cnnic.cn> <20190213134408.ri5iy42q7u7h37ui@sources.org> <201902141436144299614@cnnic.cn>
To: "zuopeng@cnnic.cn" <zuopeng@cnnic.cn>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/t2DY7RP7dxp2zsLRM9oCBMQqFk0>
Subject: Re: [DNSOP] extension of DoH to authoritative servers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 07:50:22 -0000

On 14 Feb 2019, at 06:36, zuopeng@cnnic.cn wrote:
> 
> i think both DNSSEC and DoH(or DoT) can protect DNS data

It depends on your definition of “protect”. For some threats/attacks, DoH or DoT by themselves can’t protect DNS data - for instance a DoH or DoT server that intentionally or accidentally returns false data. DNSSEC can counter that. Provided the client can perform validation and the DoH or DoT server returns DNSSEC material in its responses. It might not always be wise to make these assumptions, especially client-side validation.

> Transiting trust is hard but may be accomplished in the future.

That simply won’t be possible until every DNS client does DNSSEC validation. Good luck with that.

> The deployment of DNSSEC also takes a long time and is still in progress.

Indeed. That’s yet another reason why transiting trust is hard.

v2.31.3 | Report a Bug | By Email | System Status