Security and Stability of Root Name Server System

1
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

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
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15

16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
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/cct
  ld/icp1.htm
• Send completed template to root-mgmt_at_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
ICANNs 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!