1 / 11

DNSSEC at ESnet ESCC/Internet2 Joint Techs Workshop July 19, 2006

R. Kevin Oberman Network Engineer Lawrence Berkeley National Laboratory. DNSSEC at ESnet ESCC/Internet2 Joint Techs Workshop July 19, 2006. Overview. Why is ESnet implementing DNSSEC? What is required? How will DNSSEC be implemented in ESnet? NIST SP800-81

cyndi
Download Presentation

DNSSEC at ESnet ESCC/Internet2 Joint Techs Workshop July 19, 2006

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. R. Kevin Oberman Network Engineer Lawrence Berkeley National Laboratory DNSSEC at ESnetESCC/Internet2 Joint Techs WorkshopJuly 19, 2006

  2. Overview Why is ESnet implementing DNSSEC? What is required? How will DNSSEC be implemented in ESnet? NIST SP800-81 Potential Problems and Solutions Timeline for implementation?

  3. Why is ESnet implementing DNSSEC? DNS has long been an ‘Achilles Heel’ of the Internet DNS was designed in pre-commercial days with no concern for security DNS has had many “fixes” to make it more secure but… Fundamental parts of its design prevent real security without source verification It’s just a matter of time… Crackers already use holes in DNS for phishing attacks Even more severe attacks are likely in the future It is possible that a massive attack on the overall Internet could be based on breaking or subverting DNS OMB says we have to! (OK, this is the REAL reason)

  4. What is Required? OMB mandate will likely be based on NIST SP800-81 available at: http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf Provides general recommendations for securing DNS Not limited to DNSSEC BIND-centric—DHS is planning on a Windows version Everyone should have already implemented the recommendations in the first seven chapters Still no guidance on when and where transactional signatures (TSIG) or signed data (DNSSEC) will be required TSIG for zone transfers is a good idea, in any case Signed data will almost certainly be required in .gov and probably will be required for federally funded systems in other gTLDs

  5. How will DNSSEC be implemented in ESnet? TSIG authentication of all zone transfers Signing of all forward zones Addition of public keys to delegation points (when possible) Not all gTLDs currently support DNSSEC Advertising of public keys when not possible Possibly using ISC’s DLV service Other key publication systems will also be evaluated

  6. Potential Problems and Solutions (1/4) NIST SP800-81 requires that keys be stored off-line in most cases. Operationally difficult Not compatible with may commercial and locally written DNS management tools May be worked around using the dynamic update rule. Even if DNS-DYNUPD is not used, the wording in SP800-81 should allow keys kept on line if used “dynamically”.

  7. Potential Problems and Solutions (2/4) NSEC records can allow an effective “zone transfer” that cannot be blocked NSEC records allow the verifiable testing for the existence or non-existence of a name in DNS by pointing to the next record in the zone This allows trivial “walking” of the zone data to get the same data that would otherwise be controled by refusing zone transfers Many places consider this to be “sensitive” data The use of RFC4470 or, better, NSEC3 in place of NSEC NSEC3 uses hashes for the “next secure” target http://www1.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-06.txt

  8. Potential Problems and Solutions (3/4) DNSSEC adds complexity, volume, and computational intensity to DNS Signatures need to be checked Signed zones are much larger More cached data in each server May require hardware upgrades. May even require hardware crypto processors. Memory appears not to be an issue for all but the largest servers and disks are cheap.

  9. No standard method of locating public keys for DNSSEC “islands” One possible solution is DLV (DNS Lookaside Validation) with an on-line database of public keys Provides a standard way to find public keys outside of the DNS delegation chain http://www1.ietf.org/internet-drafts/draft-weiler-dnssec-dlv-01.txt Potential Problems and Solutions (4/4) • No standard method of locating public keys for DNSSEC “islands” • One possible solution is DLV (DNS Lookaside Validation) with an on-line database of public keys • Provides a standard way to find public keys outside of the DNS delegation chain • http://www1.ietf.org/internet-drafts/draft-weiler-dnssec-dlv-01.txt root Blue zones are unsigned Green zones are signed .gov ..edu .com .them .us “.us” is signed—but how do we find a trusted public key?

  10. Timeline for Implementation TSIG is currently being implemented Trusted, encrypted distribution is needed PGP seems reasonable Does not always scale well, but ESnet does backup DNS for only about 20 organizations—may not work for larger cases Signed data can be done independently Currently not running on production servers Our DNS management software does not support DNSSEC today Fairly easy to implement Once implemented, key distribution and roll-over will be the primary issued Targeting full production by mid-2008

  11. Summary Careful implementation is ESSENTIAL! DNSSEC appears to be implemtnatble TSIG is clearly implementable except for stub resolvers Key management is and always and will be an issue There is at least one significant vulnerability in the current DNSSEC NSEC3 looks like a solution We (ESnet and other government funded projects) MUST implement DNSSEC ‘soon’ NIST SP800-81 is a very good starting point

More Related