From: Paul Hoffman

Date: 2021-04-09 00:24

To: Z.W. Yan

CC: RSSAC Caucus

Subject: Re: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators

I'd like to respond as an individual contributor.

 

 

On Apr 7, 2021, at 7:49 PM, YAN Zhiwei <yanzhiwei@cnnic.cn> wrote:

>

> 1)   In Section 1, “The purpose of the root server system (RSS) is to give authoritative answers to queries about the DNS root”. This may be described as “The purpose of the root server system (RSS) is to give authoritative answers to queries about the DNS Top-Level Domains (TLDs) (or root zone)”. Because “DNS root” may lead people to understand it as “root servers” as “Root Hind File” acts.

 

I agree with the others who have replied that this is not technically correct and should not be subsitited

 

> 2)  “RSS” is defined in the first paragraph of Section 1, it can be used directly in the following contents as the abbreviation of “root server system”, for example in the 4th paragraph of Section 1.

 

Good catch.

 

> 3)  This document mainly defines the rogue activities of RSO. As emphasized in Subsection 2.2, it cannot or is difficult to be used to judge or determine the intent of these behaviors or even mitigate these behaviors. So, in 4th paragraph of Section 1, the description “Future RSS governance bodies may use this document for developing a more complete definition of rogue RSO actions and will ultimately be the authority in determining subjective factors, such as intent, when judging the actions of an RSO.” should be weakened or without pointing out its application in “determining subjective factors, such as intent, when judging the actions of an RSO”.

 

This proposal sounds OK, but it is indeed weakening the curretn text.

 

> 4)  “Incorrect additional answers” part in Section 3: “extra NS records that are not the root zone” should be “extra NS records that are not in the root zone”.

 

Good catch.

 

> 5)  The currently listed cases are mainly the resolution service, should we consider the behavior of root zone management? for example, the RSO does not actively or timely update the root zone file.

 

That situation is not considered "rogue", it is considered bad RSO operations, and is thus part of RSSAC047.

 

> 6)   As in the “Intentionally degraded service” part, should we consider the behavior of link quality manipulation such as shut down the IPv4 or IPv6 connection, UDP or TCP connection and so on, except the dropping or delaying packets for degrading responses?

 

That feels too specific to me. Unfortunately, creative people can think of many ways to degrade service, and we shouldn't try to predict them all now.

 

--Paul Hoffman