Your SlideShare is downloading. ×

ION Djibouti: KENIC DNSSEC Case Study

393

Published on

Presentation from ION Djibouti on 2 June 2014 by Toilem Poriot Godwin. …

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
393
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×