- rssac-caucus - lists.icann.org

[rssac-caucus] FYI: Root Stability Study RFP
by Steve Sheng June 10, 2015

June 10, 2015

https://www.icann.org/news/announcement-2-2015-06-05-en The Internet Corporation for Assigned Names and Numbers (³ICANN²) is seeking one or more providers to conduct a technical study examining the impact of the New gTLD Program (the Program) on the DNS root system. Consistent with its mission supporting the security and stability of the Internet¹s system of unique identifiers, ICANN will undertake an examination of the Program¹s impact on the DNS root system. The selected provider(s) will design and execute one or more studies incorporating the collection and analysis of data from root server operators, historical performance data, data gathered from previous studies, and other tools and measures. ICANN is seeking one or more qualified providers to manage this complex exercise in a timely and efficient manner. A review of the Program for security and stability impact is a previous commitment based on advice from ICANN¹s Governmental Advisory Committee <https://archive.icann.org/en/topics/new-gtlds/board-notes-gac-scorecard-cle an-15apr11-en.pdf> and other discussions. Specifically, ICANN committed to review the effects of the New gTLD Program on the operations of the DNS root system, and to postpone delegations in a future round until it is determined that the delegations in the 2012 round have not jeopardized the root system's security or stability. The goals of this study include, at a minimum: * Executing a thorough review of the impact of the Program on the security and stability of the DNS. * Identifying what steps, if any, should be undertaken as a prerequisite to adding more TLDs to the root zone. * Identifying what steps, if any, should be undertaken by the community going forward to assess the state of the root zone on an ongoing basis. For additional information, complete timeline, and instructions for submitting responses please click <https://www.icann.org/en/system/files/files/root-stability-study-rfp-05jun1 5-en.zip> . [ZIP, 983 KB] Proposals should be submitted to RootStabilityStudy-RFP(a)icann.org by 23:59 UTC ON 2 July 2015.

4 3

[rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
by Steve Sheng June 8, 2015

June 8, 2015

Dear RSSAC Caucus, On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt. Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today¹s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review. One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone¹s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area. The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires. All the best, Steve

2 3

[rssac-caucus] possible new work item
by Joe Abley June 8, 2015

June 8, 2015

Hi all, I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party. A rough sketch of a charter follows. Comments would be most welcome! Thanks, Joe Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc. ftp://rs.internic.net/domain/named.cache The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past. ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners. In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone. The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others. SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response. Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that: 1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change; 2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation; 3. Considers the risks associated with any transition from the current naming scheme to a different one; 4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning. All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role.

17 18

[rssac-caucus] Fwd: The real story of how the Internet became so vulnerable | The Washington Post
by Barbara Roseman June 3, 2015

June 3, 2015

Many of you already know this history, but from the Washington Post, this is a good overview of how the Internet in the US was developed without security as a primary concern. Very nice overview of the beginnings of things. Looks as if it may be part of a series and we¹ll forward the rest as it becomes available. -Barb Begin forwarded message: > From: David Olive <david.olive(a)icann.org> > Date: May 31, 2015 at 5:40:05 PM GMT+3 > To: David Olive <david.olive(a)icann.org> > Subject: The real story of how the Internet became so vulnerable | The > Washington Post > > > http://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part… > ?wprss=rss_MobileTopStories > > > David A. Olive > Sent from my iPad

5 4

[rssac-caucus] Six New RSSAC Caucus Members
by Carlos Reyes May 1, 2015

May 1, 2015

Dear RSSAC Caucus, I hope you are well. Earlier this month, the RSSAC approved six new members of the RSSAC Caucus as recommended by the Membership Committee: * Adiel Akplogan * Bobby Cates * Wes Hardaker * Keith Mitchell * Gerry Sneeringer * William Sotomayor Their statements of interest can be found here <https://community.icann.org/x/orzhAg> . Please join me in welcoming them. Best, Carlos Carlos Reyes Senior Policy Analyst ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006 | www.icann.org <http://www.icann.org> carlos.reyes(a)icann.org | +1 (202) 802-8019

3 2

[rssac-caucus] Meeting Notes and Actions from 23 TTL WP Call
by Steve Sheng April 30, 2015

April 30, 2015

Dear all, My apologies for sending the notes and action items for this call late. Steve 23 April 2015 RSSAC Caucus TTL WP Call Participants: Duane Wessels (leader), Jaap Akkerhuis, John Bond, Joe Abley, Matt Thomas. Staff: Steve Sheng, Carlos Reyes, Barbara Roseman, Kathy Schnitt Apologies: Brian Dickson, Warren Kumari Action items: * Matt and Shumon to rerun the test measuring the DS and DNSKEY TTLS for TLDs with a more recent copy of the root zone file. Also perform the analysis to compare NS and DNSKEY on a per TLD basis to see if they are the same or different. * Jaap to continue the task of finding the recursive resolver application's TTL settings. Jaap to provide some text about measurements of TTL in relation to Warren¹s contribution. * Each of the streams of work to provide an ETA for their efforts. * Duane to send an email to the WP regarding 6 May meeting time, if no objections the next meeting will be 6 May. Decision: * For next meeting, the working group will create the report document and puttings things together. Notes: Kathy Schnitt:Apology: Brian Dickson jaap akkerhuis:No sound no mike Kathy Schnitt:Japp sound on AC is working now Matt: Shumon and I measured the TTL of DS and DNSKEY of delegated TLDs, these came from root zone file in March the DS key TTL is uniform. There were some DS keys that are absent. The DNSKEY, there is a non-uniform TTL distribution. Majority is 86400. A large portion of them have smaller values, varing from TTLs in ccTLDs. We plan to rerun the test, as quite a few TLDs have been delegated. Duane: The graph you send are specific to DNSKEY TTLs, right? Duane: have you done work on NS TTLs? Duane: Matt is having some connectivity issues. Duane: This is good. One thing is compare to compare NS and DNSKEY on a per TLD basis. Duane: To see if they are the same or they are different. Matt: Sure. ACTION ITEM: Matt to compare NS and DNSKEY TTL for the root zone. ACTION: With new zone file. Jaap: It is too early to draw conclusions. Duane: Yes, I agree. Since most of the TTL is one day. Matt: Duane and I are doing some analysis on the DITL data. Matt: As it stand, we are about half way done. Matt: We use the root zone file to determine delegated TLDs. Matt: We calculate, minimum, maximum, mean, median time delta of the queries. Kathy Schnitt:Warren is unable to make the call today. Matt: This graph shows the distribution of the queries by TLD. Matt: The number of requests measured by IP. Duane: As we are writing the report on TTL, we need to think about what group of users are most important. Duane: One thing is to profile the IP by query types. Duane: To identify recursive resolvers. Duane: The problem of identifying typical is that they are all over the map. Duane: It is difficult to define normal vs. abnormal. John: Looking at that, it seems there is no impact if changing TTL from 2 day to 1 day. Duane: That seems to be my understanding, but this affect clients, we need to see how many queries are affected. Duane: Jaap, do you have any news for us? Jaap: I looked at warren's measurements, but I think some of it may not be measuring the right thing. Jaap: [not captured] Duane: It would be good to document this behavior. ACTION: Jaap to continue the task on the recursive resolver application TTL. Jaap: Also Peter Koch did not respond to my requests for root zone's prior 1999. Duane: Let's look at SOA. John: I have put my contribution in the email, my recommendation is change some values. Duane: I tend to agree. Duane: One way is to lower the zone expiry time from 7 days to 3 days at least to solve this problem. Duane: The other to increase the validity period to 20 days. Duane: The other option is to generate more signatures more frequently. John: My gut feeling here is changing the expiray in SOA seem to make the most sense. That value seems a little bit too high, I woudl prefer root zone to expire their data earlier than 7 days. The root server operators should ensure their servers much earlier than expiry period. Joe: There is also a large part of the population not validating DNSSEC. Duane: I have some experience with this kind of thing, the tool is designed to tell whether you were using a validating recusive name server. The first time you query it, it responded with bad response, and expected you to try again. Duane: This works great for BIND. It works just ok for UNBOUND. It works terribly for Nominom's implementation. as they only tried once. Duane: I think there is nothing in the protocol that mandates retrial numbers. Duane: I suspect we will need RSSAC to choose. Duane: Are there any last minute things to talk about. Duane: I will send out a message to the list. For each item, let's get an update progress and ETA. I think maybe in about 2 weeks we should start creating the report document and puttings things together. That would give us three weeks before our deadline. John: My item is complete, but Joe raised a good point. How caching resolvers respond when they get an expired response. Duane: One administrivia in two weeks, I will be heading to OARC meeting. Can we reschedule that. to the day before? ACTION: Duane to send a note asking people's flexibility on Wed 6 May. jabley:thanks! jaap akkerhuis:Later!

1 0

[rssac-caucus] Commutator turning machine
by Mandy April 22, 2015

April 22, 2015

Dear Sir, We produce the full line machines for electric motors manufacturing, such as armature winding machine, slot paper inserting machine, commutator hotstacking machine, commutator turning machine, coil winding machine, stator winding machine, coil inserting machine, forming machine, lacing machine, etc. We directly and indirectly supply our machines to more than 40 countries, among China suppliers we rank No.1 in the international market . We sincerely wish there is a chance to be of service. Best Regards Mandy Tel: 86-574-87295639 Fax: 86-574-87295637 The email is for automatic marketing, if you don’t like to receive, please kindly inform us, we will not send again after notification, and sorry for disturbance if any.

1 0

[rssac-caucus] 22 March 2015 - RSSAC caucus kick off meeting draft notes
by Steve Sheng March 23, 2015

March 23, 2015

Dear RSSAC Caucus, Attached please find the draft notes from yesterday's Caucus kick off meeting. Please let us know if we have missed any important points or mischaracterized any discussions, so that we can correct them. In general, a lot of good points and suggestions were raised, but need to be followed up on the mailing list, to provide more substance to these points and suggestions so that conclusions can be reached. All the best, Steve

1 0

[rssac-caucus] Two brainstorm suggestions Re: Invitation to RSSAC Caucus meeting at IETF in Dallas.
by Wang Wei March 23, 2015

March 23, 2015

Dear Liman Thanks you for hosting Caucus meeting. I really enjoy the communication with every members this afternoon. Here I just want to send you formally the suggestions I raised in brainstorm session. 1) draft report on expectation and measurement of root servers from customers side RSSAC 001 and 002 focus on the expectation and measurement of root servers from root operators side. But considering DNS resolution mechanism, the one-way measurement from root operators would not be able to reflect root service seen on the stub-resolvers or recursive servers. During the root mirror instances deployment in China, we found the end user side measurement is vital for root service evaluation and planning. We suggest that expectation and measurement from customer side should be considered, like what ICANN test New gTLD. 2) involve more parties in root operation At least for emergency response and communication, local root mirror hosts should be informed and could provide assistance. Some recursive operators should also be considered if they load zonefile in cache as described in draft-ietf-dnsop-root-loopback-01. Hope these suggestion might help. Btw, I just quit from CNNIC, could you please replace wangwei(a)cnnic.cn into wesley(a)zdns.cn in the mailing list? thanks Regards Wang Wei

1 0

[rssac-caucus] 2015-03-22 meeting slides.
by Lars-Johan Liman March 22, 2015

March 22, 2015

These slides will be used during the meeting soon.

1 0