October 2016 - rssac-caucus

[rssac-caucus] FOR REVIEW: Technical Analysis of the Naming Scheme used for Individual Root Servers
by Steve Sheng Jan. 4, 2017

Jan. 4, 2017

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-stateme…<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…>. 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

5 7

Re: [rssac-caucus] FOR REVIEW: Technical Analysis of the Naming Scheme used for Individual Root Servers
by George Michaelson Oct. 26, 2016

Oct. 26, 2016

UDP MSS? Its analogous to the TCP MSS proffered in the connection, and influenced end-to-end by the same mechanisms of EDNS0 proffer and server configuration. But that said, its a neologism, and would require a definition somewhere. It is the product of the EDNS0 activity in the DNS protocol exchange, right? On 27 October 2016 at 05:27, Paul Hoffman <paul.hoffman(a)icann.org> wrote: > 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 > _______________________________________________ > rssac-caucus mailing list > rssac-caucus(a)icann.org > https://mm.icann.org/mailman/listinfo/rssac-caucus >

1 0

[rssac-caucus] Anycast Work Party
by Kathy Schnitt Oct. 26, 2016

Oct. 26, 2016

Dear RSSAC Caucus, We wanted to notify you that a Work Party has been created for RSSAC-Caucus Anycast. I have listed its members below. It was too difficult for us to schedule a meeting before ICANN 57 therefore we will try after Hyderabad. If anyone has any questions please feel free to contact me at any time. Ray Bellis Marc Blanchet John Bond Shane Kerr Suresh Krishnaswamy Russ Mundy Abby Pan Rao Naveed Bin Rais Kaveh Ranjbar David Song William Sotomayor Ryan Stephenson Ondrej Sury Best regards, Kathy Kathy Schnitt, Secretariat Services Coordinator for RSSAC and SSAC

1 0

[rssac-caucus] A DNSSEC issue during KSK rollover
by Davey Song Oct. 26, 2016

Oct. 26, 2016

Hi folks, For your information, there is a article I put down to describe the issue we found during Yeti KSK rollover. Hope it help. http://yeti-dns.org/yeti/blog/2016/10/26/A-DNSSEC-issue-during-Yeti-KSK-rol… Best regards, Davey

1 0

[rssac-caucus] RSSAC Caucus Meeting at ICANN 57
by Andrew Mcconachie Oct. 20, 2016

Oct. 20, 2016

Dear RSSAC Caucus Members, Attached please find the draft agenda for the RSSAC Caucus meeting at ICANN 57. The meeting will be held on November 6, in Hall 5 at 15:15 - 16:45 IST(local time), 9:45 - 21:15 UTC. Please send in any agenda items you would like to see discussed. A separate meeting invite email will be sent closer to the date. Thanks, Andrew

1 0

[rssac-caucus] NSID support on the root-servers
by Ondřej Surý Oct. 18, 2016

Oct. 18, 2016

Hi, I just did a quick test (after seeing yet another "we are using CH TXT") for NSID support at root level and only 6 out of 13 of letters did support NSID. Is this something worth enough for RSSAC to look into? Ideally it would be great to have NSID support at all root-server instances. Cheers, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ --------------------------------------------

7 15

[rssac-caucus] REMINDER: CALL FOR VOLUNTEERS: new Caucus Work Party on anycast
by Kathy Schnitt Oct. 17, 2016

Oct. 17, 2016

Dear RSSAC Caucus, REMINDER: The RSSAC wishes to investigate best practices to optimize the distribution of root server instances in order to maximize root service resiliency, and to reduce the Round-Trip Time (RTT) between recursive servers and root servers. It requests Kaveh Ranjbar to lead a Caucus work party to produce a report, with adherence to RSSAC Caucus procedures. The work party is asked to consider a number of issues related to the distribution of anycast instances of the root name service, including: * Given the state of current internet technology, what is the maximum latency a relying party should experience when transacting with the DNS root service as opposed to with a single "root server?" * Will adding more instances in more topologically diverse locations make the system more resilient to Denial Of Service (DOS) attacks? * If root operators were to coordinate their deployments of anycast instances, what considerations should be contemplated? * Are there any regional or global technological risks (or benefits) if only a subset of operators (versus all or the majority of root operators) deploy anycast instances? REMINDER: If you are interested in this topic and would like to join this work party, please email Kathy Schnitt kathy.schnitt(a)icann.org<mailto:kathy.schnitt@icann.org> by close of business 19 October 2016. A list of interested parties I have so far are Marc Blanchet, Ondrej Sury, Suresh Krishnaswamy, Shane Kerr, Abby Pan and Ray Bellis. Best regards, Kathy and Steve

1 0

[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators v3
by Andrew Mcconachie Oct. 14, 2016

Oct. 14, 2016

Dear RSSAC Caucus, Please find Key Technical Elements of Potential Root Operators version 3. Redline and clean versions are attached. Duane and I worked to include the feedback we've received on this mailing list into this version. Changes since version 2.2: - Incorporated Warren’s suggestions on wording in the Introduction, and the change of 3.4.8’s Title to Access Segregation. - Lowercased all instances of RFC 2119 language and removed the paragraph on RFC 2119 in the Introduction. - Deleted paragragh in section 3.3.7 on RPKI. Thanks, Andrew

1 0

[rssac-caucus] CALL FOR VOLUNTEERS: new Caucus Work Party on anycast
by Steve Sheng Oct. 12, 2016

Oct. 12, 2016

Dear RSSAC Caucus, The RSSAC wishes to investigate best practices to optimize the distribution of root server instances in order to maximize root service resiliency, and to reduce the Round-Trip Time (RTT) between recursive servers and root servers. It requests Kaveh Ranjbar to lead a Caucus work party to produce a report, with adherence to RSSAC Caucus procedures. The work party is asked to consider a number of issues related to the distribution of anycast instances of the root name service, including: * Given the state of current internet technology, what is the maximum latency a relying party should experience when transacting with the DNS root service as opposed to with a single “root server?” * Will adding more instances in more topologically diverse locations make the system more resilient to Denial Of Service (DOS) attacks? * If root operators were to coordinate their deployments of anycast instances, what considerations should be contemplated? * Are there any regional or global technological risks (or benefits) if only a subset of operators (versus all or the majority of root operators) deploy anycast instances? If you are interested in this topic and would like to join this work party, please email Kathy Schnitt kathy.schnitt(a)icann.org<mailto:kathy.schnitt@icann.org> by close of business 19 October 2016. Best Steve

1 0

[rssac-caucus] Reminders
by Carlos Reyes Oct. 12, 2016

Oct. 12, 2016

Dear RSSAC Caucus, The minutes from the 1 September RSSAC meeting have been published: Webpage | File The RSSAC Caucus will meet on Sunday, 6 November, 15:15-16:45 India Standard Time, in Hall 5 at the Hyderabad International Convention Center during ICANN57. The agenda will be similar to the recent meeting at IETF96 in Berlin, Germany, but agenda items are certainly welcome. Please propose agenda items on the list. In addition to ICANN Annual General Meetings (“C” meetings in the new rotation, the third/last meeting of every year), the RSSAC Caucus will continue to meet at every other IETF meeting. The next RSSAC Caucus meeting will be in March 2017 at IETF98 in Chicago, USA. Thank you, Carlos Carlos Reyes | Policy and Community Engagement Manager carlos.reyes(a)icann.org | +1 (202) 802-8019 ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006

1 0