[rssac-caucus] FOR REVIEW: Technical Analysis of the Naming Scheme used for Individual Root Servers
Dear RSSAC Caucus, On behalf of the Caucus work party on root server naming schemes, attached please find the draft Technical Analysis of the Naming Scheme used for Individual Root Servers for your review. The work was charted by the RSSAC on 19 July 2015 (see https://www.icann.org/en/system/files/files/rssac-root-servers-work-statement-09jul15-en.pdf)[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_rssac-2Droot-2Dservers-2Dwork-2Dstatement-2D09jul15-2Den.pdf-29&d=DQMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=O16Ko7V_SvDE5jZHxFQsUEzduEwmIp0AxPl2Gzy-KTc&m=--el4CfBGSsHJlQCsjYBe1IWmeFpJMiih1v6EkKTzJ8&s=e023V4sMiP0QDUK5o6nFVeOfad1PZDEHYmerqVM1zTA&e=>. The work party was led by Joe Abley, and subsequently by John Bond. It was tasked to: 1. Document the technical history of the names assigned to individual root servers since the creation of the Root Server System; 2. Consider changes to the current naming scheme, in particular whether the names assigned to individual root servers should be moved into the root zone from the ROOT-SERVERS.NET zone; 3. Consider the impact on the priming response of including DNSSEC signatures over root server address records; 4. Perform a risk analysis, and 5. Make a recommendation to root server operators, root zone management partners, and ICANN on whether changes should be made, and what those changes should be. The review period for this draft report is 30 days. Please provide your feedback / comments / concerns to the list no later than 13 November 2016. Best Steve
It feels weird to be the first one to comment here; I hope folks in the RSSAC Caucus who were not on this work party are reading the document and will comment soon. Having said that, an issue has been raised about the use of "MTU" in this document. MTU is a term of art for layer 2 and layer 3, but we are using it here to mean something like "maximum UDP message size I can receive". It is used twice in the body of the document: - Page 12, second bullet - Page 18, first bullet of Section 7.3 It's also used in the tables at the back. I propose changing the use on page 12 and page 18 to "maximum UDP message size", but don't know what to put in the tables that won't get too long. Thoughts? --Paul Hoffman
Hi Steve, I've reviewed the document and made a bunch of comments in the attached copy. I'm really concerned about one thing however. It seems to be a foregone conclusion that the priming response data must be fully DNSSEC-validatable. Every proposed naming scheme other than "current" talks about fully signed data. The document makes vague references to DNSSEC protecting resolvers from "various name-based attacks" but does not say what these attacks are. There might be legitimate attacks but I don't think they are data integrity attacks. I'd like to see more discussion on the tradeoffs of a validatable vs unvalidatable priming response. For some naming schemes adding DNSSEC increases complexity. I think it would be useful to know how current recursive name server implementations behave with respect to setting DO=1 in their priming queries, if they do any validation of the response, and if so, how they handle a bogus response. The document devotes a lot to concerns about the size of a priming response. Perhaps RSSAC should recommend a specific upper limit on priming response size, which could then be used to evaluate the various naming schemes.
Thanks Duane, noted! At the close of the review period, the work party will meet and go over each comment and provide an account to the caucus on how they are addressed. We will invite commentators to join the work party call to discuss the feedback. Caucus, this a reminder for you to review, discuss and provide feedback to this document. Best Steve On 10/27/16, 1:04 PM, "Wessels, Duane" <dwessels@verisign.com> wrote: Hi Steve, I've reviewed the document and made a bunch of comments in the attached copy. I'm really concerned about one thing however. It seems to be a foregone conclusion that the priming response data must be fully DNSSEC-validatable. Every proposed naming scheme other than "current" talks about fully signed data. The document makes vague references to DNSSEC protecting resolvers from "various name-based attacks" but does not say what these attacks are. There might be legitimate attacks but I don't think they are data integrity attacks. I'd like to see more discussion on the tradeoffs of a validatable vs unvalidatable priming response. For some naming schemes adding DNSSEC increases complexity. I think it would be useful to know how current recursive name server implementations behave with respect to setting DO=1 in their priming queries, if they do any validation of the response, and if so, how they handle a bogus response. The document devotes a lot to concerns about the size of a priming response. Perhaps RSSAC should recommend a specific upper limit on priming response size, which could then be used to evaluate the various naming schemes.
Dear RSSAC Caucus, On behalf of the Caucus Work Party on Root Server Naming Schemes, please find the draft Technical Analysis of the Naming Scheme used for Individual Root Servers for your review. The Work Party has considered the comments of the RSSAC Caucus and considers them resolved in the current document. Specifically, the Work Party would like to draw the reviewers’ attention to the 3rd paragraph of the Introduction that describes the motivation for this study. This review will last until January 4th, 2017(2 weeks). Please send any comments you have to this list. Thanks, Andrew On Oct 14, 2016, at 14:41, Steve Sheng <steve.sheng@icann.org<mailto:steve.sheng@icann.org>> wrote: Dear RSSAC Caucus, On behalf of the Caucus work party on root server naming schemes, attached please find the draft Technical Analysis of the Naming Scheme used for Individual Root Servers for your review. The work was charted by the RSSAC on 19 July 2015 (see https://www.icann.org/en/system/files/files/rssac-root-servers-work-statement-09jul15-en.pdf)[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_rssac-2Droot-2Dservers-2Dwork-2Dstatement-2D09jul15-2Den.pdf-29&d=DQMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=O16Ko7V_SvDE5jZHxFQsUEzduEwmIp0AxPl2Gzy-KTc&m=--el4CfBGSsHJlQCsjYBe1IWmeFpJMiih1v6EkKTzJ8&s=e023V4sMiP0QDUK5o6nFVeOfad1PZDEHYmerqVM1zTA&e=>. The work party was led by Joe Abley, and subsequently by John Bond. It was tasked to: 1. Document the technical history of the names assigned to individual root servers since the creation of the Root Server System; 2. Consider changes to the current naming scheme, in particular whether the names assigned to individual root servers should be moved into the root zone from the ROOT-SERVERS.NET<http://root-servers.net/> zone; 3. Consider the impact on the priming response of including DNSSEC signatures over root server address records; 4. Perform a risk analysis, and 5. Make a recommendation to root server operators, root zone management partners, and ICANN on whether changes should be made, and what those changes should be. The review period for this draft report is 30 days. Please provide your feedback / comments / concerns to the list no later than 13 November 2016. Best Steve <13 October Root Servers Naming Scheme.docx><13 October Root Servers Naming Scheme.pdf>_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
Andrew, At 2016-12-21 18:09:40 +0000 Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
On behalf of the Caucus Work Party on Root Server Naming Schemes, please find the draft Technical Analysis of the Naming Scheme used for Individual Root Servers for your review.
The Work Party has considered the comments of the RSSAC Caucus and considers them resolved in the current document. Specifically, the Work Party would like to draw the reviewers’ attention to the 3rd paragraph of the Introduction that describes the motivation for this study.
This review will last until January 4th, 2017(2 weeks). Please send any comments you have to this list.
I have a few comments, and then I'd like to respond to some others that people have sent separately. In particular, I haven't reviewed all of Duane's comments yet. * First, I think it makes sense to make an "executive summary" at the top of the document. I passed out a few times since I was holding my breath to know the actual recommendations, which I didn't find until near the bottom of page 17, and even then not really highlighted in any way. ;) * In this paragraph: "However, given today’s Internet environment, the RSSAC would like to study the naming scheme used for individual root servers and consider whether changes need to be made." We should change "would like to study" to "has studied" and "consider" to "considered". The work is done, not pending. * Minor nit... some of the RFC references are a lovely shade of blue, but not all. Probably these should all be made into clickable links and all presumably blue, or all left as formal black. * I think that this paragraph needs some tweaking: "In order to maintain compatibility with current resolvers, this list does not include any proposal that would cause the response to a priming query that includes all 13 of the current root servers’ IPv4 addresses to be larger than 512 bytes." I just did a quick check, and at least I, J, and L currently sometimes return answers that do not include 13 root server IPv4 addresses in their response to 512-byte queries. On example is where the name servers are returned sorted, with A followed by AAAA records. Actually some root servers return only IPv6 glue if queried without EDNS using IPv6. I guess the assumption is that "current resolvers" don't run IPv6 so are not included in this description? I guess what is really meant is something like, "to be conservative, we want to return a response that fits all 13 of the current root servers' IPv4 addresses in 512 bytes for resolvers that do not use EDNS or IPv6"? * "scheme.." should be "scheme.", or possibly "scheme...." ;) * I'm not sure how to take this paragraph: "However, different name server implementations differ on whether or not they return RRSIG information for the name server names within the shared TLD." It reads like a limitation, whereas since there are only 13 root server operators they could co-ordinate and make sure that the software they run is consistent if this is important (or varies in behavior if that is important). Cheers, -- Shane
Andrew & all, At 2016-12-23 16:14:38 +0100 Shane Kerr <shane@time-travellers.org> wrote:
I have a few comments, and then I'd like to respond to some others that people have sent separately. In particular, I haven't reviewed all of Duane's comments yet.
...and now I see those were sent 2 months ago, so presumably have been incorporated into the document. Sorry! :) Cheers, -- Shane
I'll take a stab at responding to these since it's the end of the call for comments. On Dec 23, 2016, at 7:14 AM, Shane Kerr <shane@time-travellers.org> wrote:
* First, I think it makes sense to make an "executive summary" at the top of the document. I passed out a few times since I was holding my breath to know the actual recommendations, which I didn't find until near the bottom of page 17, and even then not really highlighted in any way. ;)
RSSAC and SSAC documents don't seem to put the recommendations at the top, always at the end. I guess the folks reading them have mostly gotten used to that.
* In this paragraph:
"However, given today’s Internet environment, the RSSAC would like to study the naming scheme used for individual root servers and consider whether changes need to be made."
We should change "would like to study" to "has studied" and "consider" to "considered". The work is done, not pending.
Agree, now that this is ready for publication.
* Minor nit... some of the RFC references are a lovely shade of blue, but not all. Probably these should all be made into clickable links and all presumably blue, or all left as formal black.
Agree.
* I think that this paragraph needs some tweaking:
"In order to maintain compatibility with current resolvers, this list does not include any proposal that would cause the response to a priming query that includes all 13 of the current root servers’ IPv4 addresses to be larger than 512 bytes."
I just did a quick check, and at least I, J, and L currently sometimes return answers that do not include 13 root server IPv4 addresses in their response to 512-byte queries. On example is where the name servers are returned sorted, with A followed by AAAA records.
Actually some root servers return only IPv6 glue if queried without EDNS using IPv6. I guess the assumption is that "current resolvers" don't run IPv6 so are not included in this description?
I guess what is really meant is something like, "to be conservative, we want to return a response that fits all 13 of the current root servers' IPv4 addresses in 512 bytes for resolvers that do not use EDNS or IPv6"?
Disagree. The sentence as it stands is correct: we want a root server operator that wants to send all 13 of the current root servers’ IPv4 addresses to be able to do so in less than 512 bytes. If a root server operator wants to send a different set of addresses, they can.
* "scheme.." should be "scheme.", or possibly "scheme...." ;)
Sure.
* I'm not sure how to take this paragraph:
"However, different name server implementations differ on whether or not they return RRSIG information for the name server names within the shared TLD."
It reads like a limitation, whereas since there are only 13 root server operators they could co-ordinate and make sure that the software they run is consistent if this is important (or varies in behavior if that is important).
We are not claiming that the behavior is important, so it is not a limitation that we know of. --Paul Hoffman
participants (5)
-
Andrew Mcconachie -
Paul Hoffman -
Shane Kerr -
Steve Sheng -
Wessels, Duane