Transcript DNSSEC An Update Olaf M. Kolkman [email protected] Olaf M. Kolkman . Apricot 2005, February 2005, Kyoto . http://www.ripe.net/disi.

DNSSEC
An Update
Olaf M. Kolkman
[email protected]
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
DNS: Data Flow
Registry/Registrar
Provisioning
1
Zone administrator
4
master
Zone file
Caching forwarder
2
3
Dynamic
updates
Olaf M. Kolkman
5
slaves
.
Apricot 2005, February 2005, Kyoto
resolver
.
http://www.ripe.net/disi
DNS Vulnerabilities
Registry/Registrar
Provisioning
Impersonating master
Zone administrator
1
Cache impersonation
4
Zone file
master
Corrupting data 2
Caching forwarder
3
Dynamic
updates
slaves
5
Cache pollution by
Data spoofing
resolver
Unauthorized updates
Altered zone data
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
DNSSEC Provides Data Security
example.com A 10.8.0.1
Registry/Registrar
Provisioning
example.com A 10.8.0.1
Zone administrator
master
Zone file
Dynamic
updates
Olaf M. Kolkman
Caching forwarder
example.com A 10.8.0.1
slaves
.
Apricot 2005, February 2005, Kyoto
resolver
.
http://www.ripe.net/disi
DEPLOYMENT NOW
DNS server infrastructure related
signing
APP
`
STUB
serving
validating
Olaf M. Kolkman
.
Protocol spec is clear on:
• Signing
• Serving
• Validating
Implemented in
• Signer
• Authoritative servers
• Security aware
recursive nameservers
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
DNSSEC Implementations
• BIND 9.3.
• NSD 2. ( authoritative only)
• Net::DNS::SEC for scripting tools
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
Main Improvement Areas
• “the last mile”
• Key management and key distribution
• NSEC walk
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
The last mile
APP
`
STUB
validating
Olaf M. Kolkman
.
• How to get validation results
back to the user
• The user may want to make
different decisions based on
the validation result
–
–
–
–
Not secured
Time out
Crypto failure
Query failure
• From the recursive resolver
to the stub resolver to the
Application
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
Problem Area
signing
APP
`
STUB
validating
Olaf M. Kolkman
.
Key Management
• Keys need to
propagate from the
signer to the validating
entity
• The validating entity
will need to “trust” the
key to “trust” the
signature.
• Possibly many islands
of security
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
Secure Islands and key
management
.
com.
net.
money.net.
corp
os.net.
kids.net.
geerthe
mac
unix
marnick
dev
nt
market dilbert
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
Secure Islands
• Server Side
– Different key management policies for all these
islands
– Different rollover mechanisms and frequencies
• Client Side
(Clients with a few to 10, 100 or more trust-anchors)
– How to keep the configured trust anchors in sync
with the rollover
– Bootstrapping the trust relation
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
NSEC walk
• The record for proving the non-existence of
data allows for zone enumeration
• Providing privacy was not a requirement for
DNSSEC
• Zone enumeration does provide a deployment
barrier
• Work starting to study possible solutions
– Requirements are gathered
– If and when a solution is developed it will be coexisting with DNSSEC-BIS !!!
– Until then on-line keys will do the trick.
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
Conclusion
• DNSSEC Deployment can be started now.
– .SE is preparing for deployment by end of this year
• Improvements will come, some work may take
one or more years
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi
References
• Some links
–
–
–
–
www.dnssec.net
www.dnssec-deployment.org
www.ripe.net/disi/dnssec_howto
Apster number 12
Olaf M. Kolkman
.
Apricot 2005, February 2005, Kyoto
.
http://www.ripe.net/disi