1 / 41

Security and Stability of Root Name Server System

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. Root name servers: distributed system. Diversed variants of the Unix operating system: 7 different hardware platforms

len-higgins
Download Presentation

Security and Stability of Root Name Server System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security and Stability ofRoot Name Server System Jun Murai (From the panel on Nov. 13th 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

  4. 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.

  5. 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

  6. 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.

  7. 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)

  8. 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

  9. 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

  10. 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

  11. 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

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

  13. 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.

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

  15. 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!

More Related