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.

1. KeNIC –DNSSec Case Study
2nd June 2014
BY
TOILEM PORIOT GODWIN

2. 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.

3. .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.

4. .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.

5. .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

6. 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

7. 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

8. 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

9. 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.

10. 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.

11. Creating DNSSEc business case
We can help create a business case by:

Reduce the effort(cost) for DNSSec
implementation

Provide incentives to the registrars

12. 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

13. 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

14. Providing Incentives
There are two possible ways KeNIC would
like to accomplish this:

Make DNSSec a Requirement

Generate User demand

15. 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.

16. 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 users

This requires education

17. 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)

18. 
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

19. 
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