Transcript Security and Stability of Root Name Server System Jun Murai (From the panel on Nov.

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),
List of the Root Servers
name
a
b
c
d
e
f
g
h
i
j
k
l
m
org
InterNIC
ISI
PSInet
UMD
NASA
ISC
DISA
ARL
NORDUnet
(TBD)
RIPE
ICANN
WIDE
city
type
url
Herndon,VA, US
com http://www.internic.org
Marina del Rey,CA, US
e du http://www.isi.edu/
Herndon,VA, US
com http://www.psi.net/
College Park,MD, US edu http://www.umd.edu/
Mt View, CA, US
usg http://www.nasa.gov/
Palo Alto, CA, US com http://www.isc.org/
Vienna, VA, US
usg http://nic.mil/
Aberdeen, MD, US usg http://www.arl.mil/
Stockholm, SE
int http://www.nordu.net/
(colo w/ A)
() http://www.iana.org/
London, UK
int http://www.ripe.net/
Marina del Rey,CA, USorg http://www.icann.org/
Tokyo, JP
int http://www.wide.ad.jp/
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.rootservers.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!