DNSSEC at ESnet
ESCC/Internet2 Joint Techs Workshop
July 19, 2006
R. Kevin Oberman
Network Engineer
Lawrence Berkeley National Laboratory
1
Overview
•
•
•
Why is ESnet implementing DNSSEC?
What is required?
How will DNSSEC be implemented in ESnet?
o
•
•
NIST SP800-81
Potential Problems and Solutions
Timeline for implementation?
2
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
o
o
•
It’s just a matter of time…
o
o
o
•
DNS has had many “fixes” to make it more secure but…
Fundamental parts of its design prevent real security
without source verification
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)
3
•
What is Required?
OMB mandate will likely be based on NIST
SP800-81 available at:
http://csrc.nist.gov/publications/nistpubs/80081/SP800-81.pdf
Provides general recommendations for securing DNS
o Not limited to DNSSEC
o BIND-centric—DHS is planning on a Windows version
o Everyone should have already implemented the
recommendations in the first seven chapters
o
•
Still no guidance on when and where transactional
signatures (TSIG) or signed data (DNSSEC) will be
required
o
o
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
4
•
•
•
•
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)
o
Not all gTLDs currently support DNSSEC
Advertising of public keys when not possible
o
o
Possibly using ISC’s DLV service
Other key publication systems will also be evaluated
5
Potential Problems and Solutions (1/4)
•
NIST SP800-81 requires that keys be stored off-line
in most cases.
o
o
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”.
6
Potential Problems and Solutions (2/4)
•
NSEC records can allow an effective “zone transfer”
that cannot be blocked
o
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
o
o
NSEC3 uses hashes for the “next secure” target
http://www1.ietf.org/internet-drafts/draft-ietf-dnsextnsec3-06.txt
7
Potential Problems and Solutions (3/4)
•
DNSSEC adds complexity, volume, and
computational intensity to DNS
Signatures need to be checked
o Signed zones are much larger
o More cached data in each server
o
•
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.
8
Potential Problems and Solutions (4/4)
•
No standard method of locating public keys for
DNSSEC “islands”
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?
•
One possible solution is DLV (DNS Lookaside
Validation) with an on-line database of public
keys
o
o
Provides a standard way to find public keys outside of
the DNS delegation chain
http://www1.ietf.org/internet-drafts/draft-weilerdnssec-dlv-01.txt
9
Timeline for Implementation
•
TSIG is currently being implemented
o
o
o
•
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
o
o
o
o
o
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
10
Summary
•
•
•
Careful implementation is ESSENTIAL!
•
•
Key management is and always and will be an issue
DNSSEC appears to be implemtnatble
TSIG is clearly implementable except for stub
resolvers
There is at least one significant vulnerability in the
current DNSSEC
o
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
11