Security and Stability of Root Name Server System

Jun Murai(From the panel on Nov. 13th 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– 8 different operating systems (UNIX variants)– from 5 different vendors.

• geographically distributed

• operate on local time (including GMT),

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, US edu 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 ICANN Marina del Rey,CA, USorg http:/ / www.icann.org/m WIDE Tokyo, J P int http:/ / www.wide.ad.jp/

List of the Root Servers

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.

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

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.

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)

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

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

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

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

Operators

• Different personalities, different organizations, different types of organizations, different ...

• Strong social network.

• Established encrypted communication channels.

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.

Current Situation

• Physical access limitations in place.

• Placed reasonably well protected.

• Contingency plans.

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!