FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators
Dear RSSAC Caucus, On behalf of Ken Renard, please see included (and attached) for your review the draft RSSAC Advisory on Rogue DNS Root Server Operators. Given the evolution of root server system (RSS) governance, this document aims to inform future RSS governance bodies on the types of root server operator (RSO) activity that might be considered rogue and the risks that these activities may pose to the Internet community. The PDF version is attached to this email. The google doc link for the document is at: https://docs.google.com/document/d/1XS2dIl_Sv1f7e4pA19QHnHEmLgRSkgEI2-zD7Tp0... Please kindly review and provide your feedback by Monday 19 April. Best Steve Sheng
Hi Steve, I reviewed the document and left a couple of comments in the google doc. DW
On Apr 7, 2021, at 8:04 AM, Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
On behalf of Ken Renard, please see included (and attached) for your review the draft RSSAC Advisory on Rogue DNS Root Server Operators.
Given the evolution of root server system (RSS) governance, this document aims to inform future RSS governance bodies on the types of root server operator (RSO) activity that might be considered rogue and the risks that these activities may pose to the Internet community.
The PDF version is attached to this email. The google doc link for the document is at: https://docs.google.com/document/d/1XS2dIl_Sv1f7e4pA19QHnHEmLgRSkgEI2-zD7Tp0...
Please kindly review and provide your feedback by Monday 19 April.
Best Steve Sheng
<DRAFT_ RSSAC Advisory on Rogue DNS Root Server Operator (1).pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://secure-web.cisco.com/1gzPaSbEeu7pNb7Cq7TjuQ64yHFwsujx-iKy0BoAVJRqn5v...
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1PHUsrxFAPkm2FKQtiWaVdafusf0iXwUQfg2cGnJ6X-q304...) and the website Terms of Service (https://secure-web.cisco.com/1YbVnslT71kIBDvCnAOo40LcCl_8up8fzvVSjEI1mQWGLl0...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi, Steve and all, The followings are some of my comments on this draft: 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. 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. 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”. 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”. 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. 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? BR, Zhiwei Yan From: Steve Sheng Date: 2021-04-07 23:04 To: rssac-caucus@icann.org Subject: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators Dear RSSAC Caucus, On behalf of Ken Renard, please see included (and attached) for your review the draft RSSAC Advisory on Rogue DNS Root Server Operators. Given the evolution of root server system (RSS) governance, this document aims to inform future RSS governance bodies on the types of root server operator (RSO) activity that might be considered rogue and the risks that these activities may pose to the Internet community. The PDF version is attached to this email. The google doc link for the document is at: https://docs.google.com/document/d/1XS2dIl_Sv1f7e4pA19QHnHEmLgRSkgEI2-zD7Tp0... Please kindly review and provide your feedback by Monday 19 April. Best Steve Sheng
On 08/04/2021 03:49, YAN Zhiwei 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.
The NS records for the TLDs in the root zone are _not_ authoritative (in the strict DNS usage of that term). cheers, Ray
On Thu, 8 Apr 2021 08:04:53 +0100 Ray Bellis <ray@isc.org> wrote:
On 08/04/2021 03:49, YAN Zhiwei 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.
The NS records for the TLDs in the root zone are _not_ authoritative (in the strict DNS usage of that term).
I share Ray's concern. It is bit confusing in this sentence for the person who know the DNS protocol. Better not to use "authoritative answer" here. Alternate text would be... ? Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd.
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
Thanks, Paul, for the clarification, especially the last two points. YAN Zhiwei 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
Thank you, Zhiwei for the comments, The WP had a call and considered each of them and here is how they are addressed (see below). Let me know if you have any questions regarding them, or have further feedback. Thank you very much again. Best Steve From: YAN Zhiwei <yanzhiwei@cnnic.cn> Date: Wednesday, April 7, 2021 at 10:50 PM To: Steve Sheng <steve.sheng@icann.org>, "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [Ext] Re: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators Hi, Steve and all, The followings are some of my comments on this draft: 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.
editor: Thank you. This sentence is changed to “The purpose of the root server system (RSS) is to provide responses to queries for data in the root zone.”
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.
editor: Thank you. This is fixed.
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”.
editor: The WP had a discussion, and this is changed to “Future RSS governance bodies may use this document for developing a more complete definition of rogue RSO actions.”
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”.
Editor: Thank you, this is corrected.
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.
Editor: The WP discussed this on the call. Regarding the behavior of root zone management such as not timely serve the root zone file, these are captured as 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?
Editor: The WP discussed this and decided not go into specifics on how the service can be degraded. Reasons are (1) the term “degrade service” covers a range of scenarios. It is good to describe in general terms, (1) creative people can think of many ways to degrade the service, over-specifying may limit the applicability of this scenario.
BR, Zhiwei Yan From: Steve Sheng<mailto:steve.sheng@icann.org> Date: 2021-04-07 23:04 To: rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> Subject: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators Dear RSSAC Caucus, On behalf of Ken Renard, please see included (and attached) for your review the draft RSSAC Advisory on Rogue DNS Root Server Operators. Given the evolution of root server system (RSS) governance, this document aims to inform future RSS governance bodies on the types of root server operator (RSO) activity that might be considered rogue and the risks that these activities may pose to the Internet community. The PDF version is attached to this email. The google doc link for the document is at: https://docs.google.com/document/d/1XS2dIl_Sv1f7e4pA19QHnHEmLgRSkgEI2-zD7Tp0... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1XS2dIl_Sv1f7e...> Please kindly review and provide your feedback by Monday 19 April. Best Steve Sheng
Hello, Steve, Thank you for your effort. I am OK with those points. BR, YAN Zhiwei From: Steve Sheng Date: 2021-05-18 19:26 To: YAN Zhiwei; rssac-caucus@icann.org Subject: Re: [Ext] Re: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators Thank you, Zhiwei for the comments, The WP had a call and considered each of them and here is how they are addressed (see below). Let me know if you have any questions regarding them, or have further feedback. Thank you very much again. Best Steve From: YAN Zhiwei <yanzhiwei@cnnic.cn> Date: Wednesday, April 7, 2021 at 10:50 PM To: Steve Sheng <steve.sheng@icann.org>, "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [Ext] Re: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators Hi, Steve and all, The followings are some of my comments on this draft: 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.
editor: Thank you. This sentence is changed to “The purpose of the root server system (RSS) is to provide responses to queries for data in the root zone.”
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.
editor: Thank you. This is fixed.
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”.
editor: The WP had a discussion, and this is changed to “Future RSS governance bodies may use this document for developing a more complete definition of rogue RSO actions.”
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”.
Editor: Thank you, this is corrected.
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.
Editor: The WP discussed this on the call. Regarding the behavior of root zone management such as not timely serve the root zone file, these are captured as 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?
Editor: The WP discussed this and decided not go into specifics on how the service can be degraded. Reasons are (1) the term “degrade service” covers a range of scenarios. It is good to describe in general terms, (1) creative people can think of many ways to degrade the service, over-specifying may limit the applicability of this scenario.
BR, Zhiwei Yan From: Steve Sheng Date: 2021-04-07 23:04 To: rssac-caucus@icann.org Subject: [RSSAC Caucus] FOR REVIEW: DRAFT RSSAC Advisory on Rogue DNS Root Server Operators Dear RSSAC Caucus, On behalf of Ken Renard, please see included (and attached) for your review the draft RSSAC Advisory on Rogue DNS Root Server Operators. Given the evolution of root server system (RSS) governance, this document aims to inform future RSS governance bodies on the types of root server operator (RSO) activity that might be considered rogue and the risks that these activities may pose to the Internet community. The PDF version is attached to this email. The google doc link for the document is at: https://docs.google.com/document/d/1XS2dIl_Sv1f7e4pA19QHnHEmLgRSkgEI2-zD7Tp0... [docs.google.com] Please kindly review and provide your feedback by Monday 19 April. Best Steve Sheng
participants (6)
-
Paul Hoffman -
Ray Bellis -
Shinta Sato -
Steve Sheng -
Wessels, Duane -
YAN Zhiwei