1. Olaf M. Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/ris DNSSEC and in-addr an update Olaf M. Kolkman olaf@ripe.net

2. Olaf Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/disi DNSSEC on 1 page Data authenticity and integrity by SIGning the resource records Public KEYs can be used to verify the SIGs Children sign their zones with their private key. The authenticity of their KEY is established by a SIGnature over that key by the parent In the ideal case, only one public KEY needs to be distributed off-band

3. Olaf Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/disi Why DNSSEC on in-addr Delegations follow topology –Allocation/assignment can be used to verify childs key authority –First (proposed) applications use reverse tree (IP- SEC) RIPE NCC is authoritative for top nodes of the tree. –We can gain experience and may make a difference

4. Olaf Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/disi Why not yet RFC 2535 has been around for a few years We started working on DNSSEC about 1.5 years ago, at the same time other groups started deployment Operation to troublesome –Mainly key-rollover Fixes needed in the protocol

5. Olaf Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/disi Fixes, what fixes? DS RR –Delegation from parent to child –Solves key rollover problems –Backward incompatible NXT OPT-IN –Scaling problems for large zones –Opt-In allows for slowly introducing DNSSEC –Loss of authenticated denial

6. Olaf Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/disi Whats next Waiting for protocol to settle –Depends on IETF process –Implementation needs to be available –This may all happen in about 1-2 months Test code and work towards implementation –Deployment on reverse tree expected around Q4