1. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi DNSSEC Operational Practices draft-ietf-dnsop-dnssec-operational-practices-00.txt Olaf M. Kolkman (RIPE NCC) & Miek Gieben (NLnet Labs)

2. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi What ‘s this about Capturing first operational experience with DNSSEC Mainly workshops and experiments Identifying operational differences with “plain” DNS. Giving some basic recommendations; To be published as ‘Informational’

3. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi Content Document is about –TIME –DNSKEY –Parental Policies How do RR sets propagate through the system. New: Behavior depended on two RR sets propagating through the system.

4. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi TIME issues Time: DNSSEC introduces absolute times. Main problem: cached data expires at RRSIG expiry –The ‘Maximum zone TT’L of your zone data should be a fraction of SIG validity period –Push out new signatures at least 1 times TTL before RRSIGs expire. Problem related to authoritative servers: –SOA expiration doesn’t know about DNSSEC.

5. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi DNSKEY issues Key size recommendations. –Based on a “Journal of Cryptology’ publication by Lenstra and Verheul. Key Rollover Scenarios –Caches may have DNSKEYs and RRSIGs from different versions of a zone.

6. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi Key rollover scenarios About making sure that there is always a DNSKEY in the cache to verify the RRSIG that came directly from an authoritative server ZSK rollovers –Double signatures rollover (large zone files) –Pre-published key rollover (more steps hence more administration, cryptanalysis)

7. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi Key rollover scenarios (cntnd) KSK rollovers –Double signature rollover. Only one DS RR at the parent at all times. Loose coupling, most actions are done by the child. –Needs to wait for the parent to publish the new DS RR. –Different from Mike St Johns proposal Needs two DS RRs at the parent and multiple interactions Is automated (will need to be described in this doc too)

8. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi Other Issues covered Planning for emergency rollovers Some parental policy considerations –DNSKEY exchange and storage –Preventing “security lameness” –DS validity

9. Olaf M. Kolkman. IETF58, Minneapolis, November 2003. http://www.ripe.net/disi WG input. Yes please, the document is yours now. Test the described procedures Editorial nits to Kolkman or Gieben, content discussion on the list.