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