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)

Slides:

Advertisements

Similar presentations

ICANN Security and Stability Advisory Committee ICANN Meetings Shanghai October 30, 2002.

Advertisements

Steve Lewis J.D. Edwards & Company

State of DNS Security Extensions Edward Lewis February 26, 2001 APRICOT 2001 Panel.

Cryptography and Network Security

Certification Authority. Overview  Identifying CA Hierarchy Design Requirements  Common CA Hierarchy Designs  Documenting Legal Requirements  Analyzing.

Cross Platform Single Sign On using client certificates Emmanuel Ormancey, Alberto Pace Internet Services group CERN, Information Technology department.

2.1 Installing the DNS Server Role Overview of the Domain Name System Role Overview of the DNS Namespace DNS Improvements for Windows Server 2008 Considerations.

Environmental Council of States Network Authentication and Authorization Services The Shared Security Component February 28, 2005.

Public Key Infrastructure (PKI) Providing secure communications and authentication over an open network.

DESIGNING A PUBLIC KEY INFRASTRUCTURE

Chapter 1 – Introduction

Information Security Policies and Standards

16.1 © 2004 Pearson Education, Inc. Exam Planning, Implementing, and Maintaining a Microsoft® Windows® Server 2003 Active Directory Infrastructure.

Lecture III : Communication Security, Services & Mechanisms Internet Security: Principles & Practices John K. Zao, PhD SMIEEE National Chiao-Tung University.

Chapter 7 HARDENING SERVERS.

Web Server Administration

Chapter 9 - Control in Computerized Environment ATG 383 – Spring 2002.

70-290: MCSE Guide to Managing a Microsoft Windows Server 2003 Environment Chapter 1: Introduction to Windows Server 2003.

SSH : The Secure Shell By Rachana Maheswari CS265 Spring 2003.

70-293: MCSE Guide to Planning a Microsoft Windows Server 2003 Network, Enhanced Chapter 8: Managing and Troubleshooting DNS.

Copyright, 1996 © Dale Carnegie & Associates, Inc. Digital Certificates Presented by Sunit Chauhan.

Managing Information Systems Information Systems Security and Control Part 2 Dr. Stephania Loizidou Himona ACSC 345.

70-293: MCSE Guide to Planning a Microsoft Windows Server 2003 Network, Enhanced Chapter 7: Planning a DNS Strategy.

1 System support & Management Protocols Lesson 13 NETS2150/2850 School of Information Technologies.

Disaster Recovery and Business Continuity Ensuring Member Service in Times of Crisis.

Beyond HIPAA, Protecting Data Key Points from the HIPAA Security Rule.

1 Disaster Recovery Planning & Cross-Border Backup of Data among AMEDA Members Vipin Mahabirsingh Managing Director, CDS Mauritius For Workgroup on Cross-Border.

Key Management in Cryptography

70-290: MCSE Guide to Managing a Microsoft Windows Server 2003 Environment, Enhanced Chapter 1: Introduction to Windows Server 2003.

Key Management Guidelines. 1. Introduction 2. Glossary of Terms and Acronyms 3. Cryptographic Algorithms, Keys and Other Keying Material 4. Key Management.

November 2009 Network Disaster Recovery October 2014.

Overview of Active Directory Domain Services Lesson 1.

1 DNSSEC at ESnet ESCC/Internet2 Joint Techs Workshop July 19, 2006 R. Kevin Oberman Network Engineer Lawrence Berkeley National Laboratory.

TELE 301 Lecture 11: DNS 1 Overview Last Lecture –Scheduled tasks and log management This Lecture –DNS Next Lecture –Address assignment (DHCP)

Overview Who is AusRegistry? Why use the existing infrastructure? What this means for you? Questions raised and Important points.

Wireless and Security CSCI 5857: Encoding and Encryption.

AM TLD Governance The role of ITC/AMNIC. AMNIC public services DNS Whois WWW Other services – , NTP, cDNS, RIPE Atlas Database - behind of scene.

Engineering Report Mark Kosters. Big changes with Engineering Lots of requests for development/operations support The Board heard you Engineering growing.

Figures – Chapter 14. Figure 14.1 System layers where security may be compromised.

Root Server System Advisory Committee Jun Murai, Chair of RSSAC/ICANN Director ICANN ｃｃ TLD meeting June 25, 2002 Bucharest, RO.

Root Server System Advisory Committee ICANN Open meeting May 26, 1999 Hotel Adlon, Berlin.

Module 9: Fundamentals of Securing Network Communication.

Planning a Microsoft Windows 2000 Administrative Structure Designing default administrative group membership Designing custom administrative groups local.

ICANN Root Name Server System Advisory Committee March 2, 1999 SUNTEC Convention Center Singapore.

Public Key Infrastructure (X509 PKI) Presented by : Ali Fanian

Prepared by Natalie Rose1 Managing Information Resources, Control and Security Lecture 9.

Chapter 2 Securing Network Server and User Workstations.

1 Chapter 1 – Background Computer Security T/ Tyseer Alsamany - Computer Security.

Topic 1 – Introduction Huiqun Yu Information Security Principles & Applications.

Security in DNS(DNSSEC) Yalda Edalat Pramodh Pallapothu.

1 Network Information System (NIS). 2 Module – Network Information System (NIS) ♦ Overview This module focuses on configuring and managing Network Information.

Security fundamentals Topic 2 Establishing and maintaining baseline security.

Need for Security Control access to servicesControl access to services Ensure confidentialityEnsure confidentiality Guard against attacksGuard against.

Creating and Managing Digital Certificates Chapter Eleven.

Registration Services Mark Kosters 10 November 1998.

Linux Operations and Administration

OVERVIEW OF ACTIVE DIRECTORY

1 CMPT 471 Networking II DNS © Janice Regan,

The Hierarchical Trust Model. PGP Certificate Server details Fast, efficient key repository –LDAP, HTTP interfaces Secure remote administration –“Pending”

Business Continuity Planning for OPEN OPEN Development Conference September 18, 2008 Ravi Rajaram IT Development Manager.

OPTION section It is the first section of the named.conf User can use only one option statement and many option-value pair under the section. Syntax is.

Cryptography and Network Security Chapter 1. Background  Information Security requirements have changed in recent times  traditionally provided by physical.

DNS Cache Poisoning (pretending to be the authoritative zone) ns.example.co m Webserver ( ) DNS Caching Server Client I want to access

Developing a DNSSEC Policy The Compulsory Zone Distribution Which DNSSEC Protocol Keys – and Managing them Managing the Children Using DNSSEC Mark Elkins.

Using Digital Signature with DNS. DNS structure Virtually every application uses the Domain Name System (DNS). DNS database maps: –Name to IP address.

Overview of Active Directory Domain Services

Chapter 17 Risks, Security and Disaster Recovery

THE STEPS TO MANAGE THE GRID

Presentation transcript:

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 –8 different operating systems (UNIX variants) –from 5 different vendors. geographically distributed operate on local time (including GMT),

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 –Send completed template to –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 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 –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!