1. Security and Stability of Root Name Server System Jun Murai (From the panel on Nov. 13 th by Paul Vixie, Mark Kosters, Lars-Johan Liman and Jun Murai) RSSAC

2. Root name servers: distributed system Diversed variants of the Unix operating system: –7 different hardware platforms –8 different operating systems (UNIX variants) –from 5 different vendors. geographically distributed operate on local time (including GMT),

3. List of the Root Servers

30. Root name servers: hardware Access to the machine –controlled physical access Environment –protection against power grid and cooling failures with UPS protected power Connections –diverse Internet connectivity in layers 1 through 3.

31. Administrative Services (1) Backup –Each root name server site keeps backup copies of zone files redundant hardware –All root name servers have redundant hardware Hot spare (manual) –In some cases, the hardware is in the form of a hot spare Live spare (automatic) –In other cases, the hardware is operated as a live spare

32. Administrative Services (2) BIND version –All root name servers run the recent-patched versions of BIND Contact information of operators –each root name server operator has contact information (digitally secured and hardcopy) for all other operators –Secure communication technologies Multi-level personnel –multi-level system administration personnel and support –internally defined escalation procedures.

33. Zone file: high-level process Additions/modifications/deletions to the root zone high-level process: –Fill out template found at http://www.iana.org/cctld/icp1.htm –Send completed template to root-mgmt@iana.org –IANA (and others) will check technical/political aspects –PGP-signed messages come from IANA with approval from DOC to VeriSign to make changes –Notification of to the root servers –Changes ready to be placed into zone file (and whois)

34. Zone File Distribution Definitions –Master – initial distribution point Information fed by a file File generated from a database –Slave – replicates the copy from master server How are changes detected –If fetched by protocol (called zone transfer) SOA Record –Serial Number –Refresh Interval –Notify Process may be protected by symmetric keys (TSIG) –If fetched by file Notified by pgp-signed email to small list

35. Zone File Distribution - Master Master File Generation –Generated by Provisioning Database –Replicated to disaster recovery site Database Distribution mechanism Backups stored at off-site locations –Humans look at differences –Look for key changes Serial number of SOA record Feedback from provisioning if changes made to Delegation –Security Elements Hash of zone file Gpg (pgp) signatures per file File that contains md5sum signed –Installed on staging machine Logs checked DNS queries

36. Zone File Distribution – Master (cont) Zone Files pushed to ftp servers –ftp://rs.internic.net/domains – ftp://ftp.crsnic.net/domains for those who have accounts for com/net/org Files pushed to distribution master and a.root- servers.net –Pushed to Trusted interface –Before loading -Security checks performed Authenticity Validity Multiple machines used while changing zones –Minimize downtime on a.root-servers.net or j.root-servers.net Message sent out to internal notification list

37. Zone File Distribution - Slave How changes are detected Using the DNS protocol –Notify message –Refresh interval check Out of band –Pgp-signed email –Cronjob Responsibility of each root operator to check validity

38. Operators Different personalities, different organizations, different types of organizations, different... Strong social network. Established encrypted communication channels.

39. Technical Guidelines The Internet Engineering Task Force (IETF) has well established procedures for developing technical recommendations. –Domain Name System Operations working group. –Domain Name System Extensions working group. Root operators use RFC 2870 as guidelines. –"Root Name Server Operational Requirements" –New ideas should go into the next version of that document.

40. Current Situation Physical access limitations in place. Placed reasonably well protected. Contingency plans.

41. ICANN’s role Complete the transition plan –Security and Stability on the new IANA roles MoU process –Btwn root server operators Backup of the IANA function TRUST Engineers and Operators!