19

Click here to load reader

ION Djibouti: KENIC DNSSEC Case Study

Embed Size (px)

DESCRIPTION

Presentation from ION Djibouti on 2 June 2014 by Toilem Poriot Godwin. This session will explore one potential technical solution for deploying DNSSEC support within a ccTLD registry. We’ll take a quick look at DNSSEC awareness strategy, the status/progress of signed domains, and lessons learned and challenges for increasing numbers of signed domain names.

Citation preview

Page 1: ION Djibouti: KENIC DNSSEC Case Study

KeNIC –DNSSec Case Study

2nd June 2014

BYTOILEM PORIOT GODWIN

Page 2: ION Djibouti: KENIC DNSSEC Case Study

2

KeNIC INTRODUCTION

KeNIC is the ccTLD manager of the .ke namespace.

KeNIC is a not-for-profit organization.

KeNIC isis in the final process of Implementing DNSSec

Full Implementation expected to be complete by 12th June 2014.

KeNIC has a total of 170 registrars and a total of 36000 domains.

Page 3: ION Djibouti: KENIC DNSSEC Case Study

.KE Registry Setup .ke Top level is not open for registration.

KE has a propagation server and a Registration server for SLD registartion.

Registry server generates zone files after domain registration and forwards domains every 30 mins to the Porpagation server

Domain details are stored in the registry server and only the zone file generated by the registry are sent to the propagation server

Domain registration has been automated to the registry via EPP and 50% of registrars are fully automated.

Page 4: ION Djibouti: KENIC DNSSEC Case Study

.ke DNSSec Delpoyment Roadmap

Interest on setting up of DNSSec in kenya started in 2010 .

DNSSec deployment was planned to start in May 2012.

Setup started in 2013 after the first DNSSec Roadshow by ICANN.

An upated DNSSec Test server was setup in June 2013.

The most challenging part was the development of .ke DNSSec Practice Statements( policy ) which determines how DNSSec will be deployed.

Page 5: ION Djibouti: KENIC DNSSEC Case Study

.ke DNSSec Delpoyment Roadmap

Phase after setting up the test server was to simulate the root servers. This would help use develop a real life chain of trust.

DNSsec Deployed on the propagation server and IANA database updated on 17th March 2014

April 17th 2014 the first ZSK key rollover fo .ke DNSSec deployed on registry test server for SLDs on 17th April

2014 DNSSec will be deployed on Registry System 12th June 2014

Page 6: ION Djibouti: KENIC DNSSEC Case Study

DNS and DNSSec Introduction The DNS is a critical piece of the Internet‟s infrastructure and makes a

natural target for people and organizations attempting to abuse the Internet. Threats to the DNS take many forms.

Some threats are attacks on the zone files and servers that make up the infrastructure of the DNS.

To understand DNSSEC – and what it can and cannot provide – a basic understanding of the threats to the DNS is important.

The DNS is subject to security problems in three key areas: confidentiality, integrity and availability. For the purposes of this work a loss of confidentiality is the unauthorized disclosure of or access to information. A loss of integrity is the unauthorized modification or destruction of information. And a loss of availability is the disruption of access to the underlying service.

DNSSEC is not an extension that provides tools for ensuring confidentiality or availability. Instead, its goal is to ensure integrity

Page 7: ION Djibouti: KENIC DNSSEC Case Study

Technical Solution on DNSSec Deployment

Some issues that affect the DNSSec deployment had to be looked at first: Update of Bind to a version that supports DNSSec Update of both Registry and Propagation Server OS to

OS versions that easily support applications that automate DNSSec

Key storage and management Module. Update of the registry System Ensure initial systems work well with the updated

systems

Page 8: ION Djibouti: KENIC DNSSEC Case Study

Technical Solution on DNSSec Deployment cont..

To solve the issues previosly listed, KeNIC had to: Run two DNSSec systems in parallel:

Run manual DNSSec on the propagation server Automate DNSSec on the registry system

This is because .ke zone does not change a lot. And frequent resign on the zone is not needed

The registry server updates the zone files every 30 mins and would require automation

The registry system updated to the current version that will allow regsitrars upload DS record of a domain to the registry system

Page 9: ION Djibouti: KENIC DNSSEC Case Study

Technical Solution on DNSSec Deployment cont..

To solve the issues previosly listed, KeNIC had to: Run two DNSSec systems in parallel:

Run manual DNSSec on the propagation server Automate DNSSec on the registry system

This is because .ke zone does not change a lot. And frequent resign on the zone is not needed

The registry server updates the zone files every 30 mins and would require automation

The registry system updated to the current version that will allow regsitrars upload DS record of a domain to the registry system

Use of softHSM for key storage and management(this will be used for a year before migrating to HS)

Use Opendnssec for DNSSec automation.

Page 10: ION Djibouti: KENIC DNSSEC Case Study

DNSSec Uptake Strategy Another major challenge of DNSSec after deployment is ensuring

registrars and registrants use the technology

This is attributed to the cost of managing and setting up a DNSSec environment.

The biggest challenge is making a Business case for DNSSec

As a registry KeNIC iwill help create a business case for DNSSec to increase uptake of DNSSec.

Page 11: ION Djibouti: KENIC DNSSEC Case Study

Creating DNSSEc business case

We can help create a business case by:

Reduce the effort(cost) for DNSSec implementation

Provide incentives to the registrars

Page 12: ION Djibouti: KENIC DNSSEC Case Study

Reduce the effort (cost)

This simply means brining down the cost of DNSSec implementation. This can be achieved by: Research and share Simplifying DNSSec implementation for

registrars Automation Reduce the risk of DNSSec implementation

Page 13: ION Djibouti: KENIC DNSSEC Case Study

Examples of reducing the effort

For regsitrars – Developing toolkits registrars can patch into their Domains managemnet system. We have a similar thing for registrar-registry automation

For registrants – Update the already automated registration process for most registrars to have a one click DNSSec.

ISPs – Help them create simple DNSSec resolvers

Users – Having an on/off DNSSec option enabled by default

Page 14: ION Djibouti: KENIC DNSSEC Case Study

Providing Incentives

There are two possible ways KeNIC would like to accomplish this:

Make DNSSec a RequirementGenerate User demand

Page 15: ION Djibouti: KENIC DNSSEC Case Study

Make DNSSec a requirement

By contractual agreement where all registrars all obligated to support DNSSec

Any new registrar must have DNSSec resolver and knowledge on DNSSec

Collaboration with the government in ensuring government institutions deploy DNSSec.

Page 16: ION Djibouti: KENIC DNSSEC Case Study

Generate user Demand

Need a reson to ”want” DNSSec.

The potential reson is “Security” “Security” “Security”.

Increase security:This will only work if visible to end usersThis requires education

Page 17: ION Djibouti: KENIC DNSSEC Case Study

Providing Incentives example

Target larger security conscious organisations

•  Lobby software developers to implement

•  Build DNSSEC as requirements into other applications (when it makes sense)

•  Find innovative uses for a secure DNS (e.g.. to supplement CAs)

Page 18: ION Djibouti: KENIC DNSSEC Case Study

Intergration of DNSSec to our current system

DNSSec automation.

Equipments needed to run DNSSec to be in line with DNSSec best practice

Uptake of DNSSec after registry has implemented DNSSec

Lack of easily tools for registrars to deploy DNSSec in their environment. Most registrars in Kenya use WHM and Cpanel.

Organization stracture makes management of DNSSec complex

Challenges on DNSSec Deployment

for .ke

Page 19: ION Djibouti: KENIC DNSSEC Case Study

DNSSec deploymenttechnically is not a hard task. The hard task is management of DNSSec and DNSSec policy developement

Registries can use softHSM if HSM is expensive. But this is not a best practice for DNSSec

There are free automation tools for DNSSec. Works well in the registry environment

Deployment of DNSSec for a registry ids not the last step. The last step is ensuring uptake of DNSSec by the end users

Lessons Learned