Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DNSSEC An Update Olaf M. Kolkman

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DNS: Data Flow master Caching forwarder resolver Zone administrator Zone file Dynamic updates 12 slaves 345 Registry/Registrar Provisioning

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DNS Vulnerabilities master Caching forwarder resolver Zone administrator Zone file Dynamic updates 12 slaves 345 Corrupting data Impersonating master Unauthorized updates Cache impersonation Cache pollution by Data spoofing Altered zone data Registry/Registrar Provisioning

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DNSSEC Provides Data Security master Caching forwarder resolver Zone administrator Zone file Dynamic updates slaves Registry/Registrar Provisioning example.com A

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DEPLOYMENT NOW DNS server infrastructure related ` APP STUB Protocol spec is clear on: Signing Serving Validating Implemented in Signer Authoritative servers Security aware recursive nameservers signing serving validating

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. DNSSEC Implementations BIND 9.3. NSD 2. ( authoritative only) Net::DNS::SEC for scripting tools

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. Main Improvement Areas “the last mile” Key management and key distribution NSEC walk

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. The last mile ` APP STUB 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 validating

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. Problem Area ` APP STUB 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 signing validating

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. Secure Islands and key management net. money.net. kids.net. geerthe corp dev market dilbert unixmac marnick nt os.net. com..

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. 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. 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 co- existing with DNSSEC-BIS !!! –Until then on-line keys will do the trick.

Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. 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. References Some links – – – –Apster number 12