[DNSOP] Dnsdir last call review of draft-ietf-dnsop-rfc8109bis-05

Di Ma via Datatracker <noreply@ietf.org> Tue, 16 July 2024 07:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from [10.244.2.27] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 30584C14F6B5; Tue, 16 Jul 2024 00:06:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Di Ma via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172111361280.73300.11259378316735467523@dt-datatracker-6fbcf4599b-975km>
Date: Tue, 16 Jul 2024 00:06:52 -0700
Message-ID-Hash: L24XFZGR62WOX7CF2RKHBZHNPFDKJRG5
X-Message-ID-Hash: L24XFZGR62WOX7CF2RKHBZHNPFDKJRG5
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, draft-ietf-dnsop-rfc8109bis.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Di Ma <madi@juicybun.cn>
Subject: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-rfc8109bis-05
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TO4_8KhyD4_BqBjPhW9PeWDg9-k>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Reviewer: Di Ma
Review result: Ready with Issues

This version adds more discussions about DNSSEC to priming exchange, which I
think need clearer statements.

In this document, the authors say “With such resolvers, an attacker that
controls a rogue root server effectively controls the entire domain name space
and can view all queries and alter all unsigned data undetected.”

However, this is not true when a DNSSEC-aware resolver has been configured with
one or more Trust Anchors from some TLDs. In such case, it is not safe to say
"an attacker that controls a rogue root server effectively controls the entire
domain name space".