Re: [DNSOP] extension of DoH to authoritative servers

Jim Reid <jim@rfc1035.com> Thu, 14 February 2019 09:49 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 7A4CF12D4E6 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 01:49:10 -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 DdsL56O0kMDg for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 01:49:09 -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 D43F112D4E9 for <dnsop@ietf.org>; Thu, 14 Feb 2019 01:49:08 -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 BB5EC242109D; Thu, 14 Feb 2019 09:49:05 +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: <2019021416583813239822@cnnic.cn>
Date: Thu, 14 Feb 2019 09:49:05 +0000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31284842-591A-491F-B42A-390D56CE7750@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> <20190214083311.2d6ncijynujoq6vc@nic.fr> <2019021416583813239822@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/diLtwhdlW9ioJU6qfLpJAXcEvZc>
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 09:49:10 -0000


> On 14 Feb 2019, at 08:58, zuopeng@cnnic.cn wrote:
> 
> the premise is the recursive server should completely trust an Authenticated server

You’ve already made that clear. The problem with that premise is it’s a false one. It represents a naive/unrealistic view of how the DNS is used.

Your proposal also needs all the authoritative servers for some zone to be under the same administrative/operational control. That’s also a false premise. And naive/unrealistic. It’s been explained to you that many organisations, TLDs in particular, don’t do that. They arrange service from multiple DNS providers to avoid single points of failure, improve redundancy, have extra capacity, etc, etc.

> if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil and modifies DNS records, it will succeed because it has private key and can fake anything

That premise is wrong too. Only the master server needs access to the private DNSSEC key. That master server isn’t necessarily in the zone's NS RRset and handling queries from resolving servers. Besides, if someone gives their private key to someone else -- in this case another authoritative DNS server -- by definition it isn’t a private key any more.