Root Server System Advisory Committee ICANN Open meeting May 26, 1999 Hotel Adlon, Berlin.

Root Server System Advisory Committee

ICANN Open meeting

May 26, 1999

Hotel Adlon, Berlin

The Past Meetings

• March 2, 1999 in Singapore (Apricot)

• March 16, 1999 in Minneapolis (IETF)

• Scheduled working meeting in May, postponed to be planned INET99 in San Jose

Who is on the meeting?

• Lars-Johan Liman, KTH (server I) [email protected]

• Daniel Karrenberg, RIPE (server K) [email protected]

• Mirjam Kuehne, RIPE (server K) [email protected]• Bill Manning (server B, L) [email protected]• Paul Wilson, APNIC [email protected]• Mark Bohannon, US Dept. of Commerce Mark_

[email protected]• Akira Kato, WIDE (server M) [email protected]• Ray Plzak, DDN NIC (server G) [email protected]• Mark Kosters, NSI (server A, J) markk@netsol.

com• Suzanne Woolf, IANA [email protected]• David Conrad, Internet Software Consortium (s

erver F) [email protected]• Piet Barber, DDN NIC (server G) [email protected]

l

• Doug Engebretson, DISA (server G) [email protected]

• Maurizio Binello, LINX (server K?) [email protected]• James Fielding, ARL (server H) [email protected]• Shane Kerr, ARIN• Kim Hubbard, ARIN ([email protected])• Gerry Sneeringer, University of Maryland (server D) sne

[email protected]• Josh Elliott, IANA [email protected]• Mike Roberts, ICANN [email protected]• Paul Vixie, Internet Software Consortium (server F) paul

@vix.com• Randy Bush, IESG [email protected]• Evi Nemeth, CAIDA [email protected]• Goeff Huston, IEPG, [email protected]• Jun Murai, WIDE, [email protected]• Esther Dyson, ICANN, [email protected]

Extracts from ICANN Bylaws

• To advise the Board about the operation of the root name servers of the domain name system.

• To advise the Board on the operational requirements of root name servers, including host hardware capacities, operating systems and name server software versions, network connectivity and physical environment.

• To examine and to advise on the security aspects of the root name server system.

• To review the　 number, location, and distribution of root name servers considering the total system performance, robustness, and reliability.

name org city type urla InterNIC Herndon,VA, US comhttp:/ / www.internic.orgb ISI Marina del Rey,CA, USedu http:/ / www.isi.edu/c PSInet Herndon,VA, US comhttp:/ / www.psi.net/d UMD College Park,MD, USedu http:/ / www.umd.edu/e NASA Mt View, CA, US usg http:/ / www.nasa.gov/f ISC Palo Alto, CA, US comhttp:/ / www.isc.org/g DISA Vienna, VA, US usg http:/ / nic.mil/h ARL Aberdeen, MD, US usg http:/ / www.arl.mil/i NORDUnet Stockholm, SE int http:/ / www.nordu.net/j (TBD) (colo w/ A) () http:/ / www.iana.org/k RIPE London, UK int http:/ / www.ripe.net/l (TBD) (colo w/ B) () http:/ / www.iana.org/m WIDE Tokyo, J P int http:/ / www.wide.ad.jp/

List of the Root Servers

Major updates after the last meeting

• Technical specs/procedure to operate and change the root servers/zones.– Almost done. Plan to be generated in June

• Additional issues re: root server operations– Y2K issues. Plan to be generated in June

• ‘Formal’ procedure for the operational roles– For safe and stable operation– Work in progress

Important IETF efforts

• RFC2010– “Operational Criteria for Root Name Server

s” by Bill Manning and Paul Vixie

• IETF BOF (to WG?) – From March 1999 – Root Server Operation, – co-chaired by Lars-Johan Liman and Randy Bu

sh

Internet Root Server System and its relationship to the Y2K event

Super, Super Draft!

RSS components

• The Zone

• The Servers

• Administrative Services

• Testing

• Open Issues

The zone

• File currently maintained by NSI– automatically generated via backend DB– Integrated into the larger TLD zone

administrative thrust– Complex backend, automated DB, multiple

inputs– This subsystem is still being checked for Y2K

compliance

The zone - as distributed

• No need to tie to a complex backend

• Fairly static – ISO 3166 codes– Generic TLDs– Infrastructure Zones

• No specific Y2K issues

Servers

• Broadly distributed– US Government (MIL)– Industry (NSI, ISC, PSI)– Academic (ISI, UMD)– International (RIPE/Linx, WIDE, Nordunet)

Servers - continued

• “Hardened” against environmental contingencies– Power Grid failure– Cooling failure– Server hardware failure– Single ISP failure

• The system can handle the existing load with 40% of the servers offline

Administrative Services

• each site keeps backup copies of the zone• each site has redundant hardware• each site has controlled access facilities• each site uses BIND• each site has multi-level sys-admin support• each site has full contact data for each other

site

Testing - Subsystems

• UNIX & variants

• Applications– BIND– NTP– SYSLOG– SSH

• contact verification

Open Issues

• UNIX 32bit counter (not Y2K)

• UNIX system calls (affects syslog)

• BIND is Y2K compliant

• Stability of telecoms infrastructure

DRAFT:　 Summary

• The Root Server System will be able to answer all queries received through the Y2K event.

• Testing for clock rollover, leap year, and GSM failure have been done with no operational impact noted.

Fin

• This data was collected in Y2K seminars and RSSAC meetings : Singapore - Apricot’99, IETF44, Online discussion from July 1998 through May 1999.

• Inaccuracies and omissions may be present

• This may not reflect the view of all root server operators 　 yet.

Schedules

• The third meeting of RSSAC is planned– During INET99/San Jose (June 15-19)

• Expected initial output draft after the second meeting– Before the third meeting

• Mailing list:– [email protected]

Charter

• Changes in the root server system have been discussed inside and outside of the government for over two years. As part of the Green Paper and White Paper process, it was agreed that the entire system would be reviewed and revised as part of the formation of ICANN.

• Consequently, a specific provision for a Root Server System Advisory Committee （ RSSAC ） was included in the bylaws from the beginning.

Extract from ICANN Bylaws• "(b) There shall be a DNS Root Server System Advisory Committee. The initial c

hairman of the DNS Root Server System Advisory Committee shall be appointed by the Board; subsequent chairs shall be elected by the members of the DNS Root Server System Advisory Committee pursuant to procedures adopted by the members. The responsibility of the Root Server System Advisory Committee shall be to advise the Board about the operation of the root name servers of the domain name system. The Root Server System Advisory Committee should consider and provide advice on the operational requirements of root name servers, including host hardware capacities, operating systems and name server software versions, network connectivity and physical environment. The Root Server System Advisory Committee should examine and advise on the security aspects of the root name server system. Further, the Root Server System Advisory Committee should review the 　 number, location, and distribution of root name servers considering the total system performance, robustness, and reliability."

Membership

• The ICANN Board is responsible for appointing the initial chairman of the RSSAC, which it did at its meeting of 1/17/99 by appointing Jun Murai.

• It is anticipated that the chairman will nominate an initial slate of members for the RSSAC.

• It is not required that the committee have a specific number of members, nor that the full complement of members be appointed immediately.

Extracts from the Dept of Commerce - ICANN MOU/JPA related to the root servers and system(1)

• "In the DNS Project, the Parties will jointly design, develop, and test the mechanisms, methods, and procedures to carry out the following DNS management functions:

– Establishment of policy for and direction of the allocation of IP number blocks;

– Oversight of the operation of the authoritative root server system;– Oversight of the policy for coordination of the DNS, including

determining the circumstances under which new top level domains would be added to the root system; and

– Coordination of the assignment of other Internet technical parameters as needed to maintain universal connectivity on the Internet.

Extracts from the Dept of Commerce - ICANN MOU/JPA

related to the root servers and system(2)

• Collaborate on a study on the design, development, and testing of a process for making the management of the root server system more robust and secure. This aspect of the DNS Project will address:– Operational requirements of root name servers, including host

hardware capacities, operating system and name server software versions, network connectivity, and physical environment.

– Examination of the security aspects of the root name server system and review of the number, location, and distribution of root name servers considering the total system performance, robustness, and reliability.

– Development of operational procedures for the root server system, including formalization of contractual relationships under which root servers throughout the world are operated.

Extracts from the Dept of Commerce - ICANN MOU/JPA

related to the root servers and system(3)• Collaborate on written technical procedures for operation of the primary root server inc

luding procedures that permit modifications, additions or deletions to the root zone file.

• Collaborate on a study and process for making the management of the root server system more robust and secure. This aspect of the plan will address:– Operational requirements of root name servers, including host hardware capacities, operating

system and name server software versions, network connectivity, and physical environment.– Examination of the security aspects of the root name server system and review of the numbe

r, location, and distribution of root name servers considering the total system performance, robustness, and reliability.

– Development of operational procedures for the root server system, including formalization of contractual relationships under which root servers throughout the world are operated.

• Collaborate on the design, development, and testing of a plan for creating a process that will consider the possible expansion of the number of gTLDs. The designed process should consider and take into account the following:– The potential impact of new gTLDs on the Internet root server system and Internet stability."