2. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi DNSSEC An Update Olaf M. Kolkman olaf@ripe.net

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

4. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi 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

5. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi DNSSEC Provides Data Security master Caching forwarder resolver Zone administrator Zone file Dynamic updates slaves Registry/Registrar Provisioning example.com A 10.8.0.1

6. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi 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

7. Olaf M. Kolkman. 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

8. 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

9. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi 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

10. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi 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

11. Olaf M. Kolkman. Apricot 2005, February 2005, Kyoto. http://www.ripe.net/disi Secure Islands and key management net. money.net. kids.net. geerthe corp dev market dilbert unixmac marnick nt os.net. com..

12. 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

13. 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 co- existing with DNSSEC-BIS !!! –Until then on-line keys will do the trick.

14. 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

15. 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