DNSSEC Operational Practices draft-ietf-dnsop-dnssec-operational-practices-00 txt Olaf M Kolkman

DNSSEC Operational Practices draft-ietf-dnsop-dnssec-operational-practices-00. txt Olaf M. Kolkman (RIPE NCC) & Miek Gieben (NLnet Labs) Olaf M. Kolkman . IETF 58, 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’ Olaf M. Kolkman . IETF 58, 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. Olaf M. Kolkman . IETF 58, 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. Olaf M. Kolkman . IETF 58, 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. Olaf M. Kolkman . IETF 58, 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) Olaf M. Kolkman . IETF 58, 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) Olaf M. Kolkman . IETF 58, 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 Olaf M. Kolkman . IETF 58, 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. Olaf M. Kolkman . IETF 58, Minneapolis, November 2003 . http: //www. ripe. net/disi