Click here to load reader
View
392
Download
1
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
KeNIC –DNSSec Case Study
2nd June 2014
BYTOILEM PORIOT GODWIN
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.
.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.
.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.
.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
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
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
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
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.
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.
Creating DNSSEc business case
We can help create a business case by:
Reduce the effort(cost) for DNSSec implementation
Provide incentives to the registrars
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
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
Providing Incentives
There are two possible ways KeNIC would like to accomplish this:
Make DNSSec a RequirementGenerate User demand
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.
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
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)
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
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