Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | len-higgins |
View: | 21 times |
Download: | 0 times |
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 [email protected]– 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!