1 / 19

Internet Identity For All

Internet Identity For All. .my DNSSEC Experience Yong Yaw Eng Sr. Software & Application Engineer (DNSSEC Project Leader) 1 st November 2010 Amman, Jordan. Agenda. myDNSSEC Status Some implementation considerations What’s Next?. myDNSSEC Status. .my DNSSEC Implementation Stages.

teresacombs
Download Presentation

Internet Identity For All

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet Identity For All .my DNSSEC Experience Yong Yaw Eng Sr. Software & Application Engineer (DNSSEC Project Leader) 1st November 2010Amman, Jordan

  2. Agenda • myDNSSEC Status • Some implementation considerations • What’s Next?

  3. myDNSSEC Status

  4. .my DNSSEC Implementation Stages

  5. Deployment to Production Activities • Deployed Back-end DNSSEC Support on 9th Oct 2010 • Primary NS: Upgrade BIND to version 9.7 (to support RSASHA256 with NSEC3) • Configure servers to ensure that zone file can be retrieved and signed (in the hidden NS) before transferring to Primary name servers • Ensure keys generated from the Keygen server can generate and pass the key to the Hidden NS (signer)

  6. Deployment to Production Activities • Also complete TSIG implementation for secondary NS on 10-Oct 2010. • Other than locally hosted secondary NS, the secondary servers at cuhk.edu.hk, nic.fr and iij.ad.jp responded in a timely fashion. • Similarly, enabled DNSSEC when we requested so. • Only uu.net did not respond to the request for both TSIG and DNSSEC.

  7. Network Architecture before DNSSEC Database Plain zone Copied by script located on ns Hidden NS Plain zone Registry Web Application Sent via zone transfer dns1.mynic.net.my(Primary) dns.mynic.net.my(Primary) Secondary Name Servers

  8. Network Architecture with DNSSEC Database KSK / ZSK Secure connection Plain zone Dsset File Sent by script located on keygen Copied by script located on ns Hidden NS Key Generator & Signer Signed zone Registry Web Application Sent via zone transfer TSIG TSIG dns1.mynic.net.my(Primary) dns.mynic.net.my(Primary) Secondary Name Servers

  9. Deployment to Production Activities (cont’) • Deployed Front-end Application on 18th Oct 2010 • Deployed Registry System enhanced with DNSSEC: • Enable / Disable DNSSEC • Load / Update DS Records • Domain name DS Record properly generated from the database • Signed zone files contain the DS records and zones can be validated

  10. * This uses our own recursive server with .my as the trust anchor, since .my DS Records have yet to be submitted to IANA

  11. Some Implementation Considerations

  12. 1. If DNSSEC NOT being managed well • Some level of fear that DNSSEC would disrupt how current DNS works (includes loss of service due to expired signature) • Since the DNSSEC enhancement design is able to: • Get DS Record digest by converting DNSKEY RR • Get the signature expiry of the zone • The following flow chart attempt to address the issue of zone being bogus when DNSSEC is not manage well

  13. Flow chart of expiry checking mechanism Start Load / Update Keys Enable DNSSEC Keys in database to be included in zone files First Check Signature Expiring in: 7 days (first check) / 1 day (second check)? Second Check No Update new expiry No Yes Expiry extended (re-signing was done)? Key tags changed? Yes Yes No Send Email notice that signature expiring in 7 days (first check) /1 day (second check) After First Check Set all key status to Unpublished End After Second Check

  14. 2. Modification of Name Server • Disallow Name Server Modification when DNSSEC is enabled • To prevent the DS Record to be loaded IF new NS is without DNSSEC • At the very least, it is a reminder to the Technical Contact that DNSSEC is Enabled • DNSSEC need to be disabled before any change of NS can occur

  15. 3. No Transfer of DNSSEC • To transfer DNSSEC maybe tricky and very much dependent on the domain owner • A straight forward way is to “NOT transfer DNSSEC” • By default, New Registrant’s will start without DNSSEC (i.e. no DS Record will be included) • The “new” Technical Contact need to enable DNSSEC and load the DS Records again

  16. What’s Next?

  17. Tasks At Hand… • Pending submission of DS Records to IANA. Obstacle: • uu.net (secondary name server operator) have not responded to the request to enable DNSSEC, therefore, • Submitted a request to IANA to remove the secondary NS. Still pending removal of that NS from IANA records before a new form can be submitted • To replace uu.net as the secondary NS, we are now in progress in getting ISC to host our secondary NS

  18. Tasks Ahead… • Continue to engage with the public by organizing a DNSSEC training, and publicly announce that DNSSEC is ready by December • Further pursue ISPs to enable DNSSEC so that validation is done at the recursive server

  19. Thank You!

More Related