Presentation on theme: "Olaf M. Kolkman. APNIC, 6 February 2014, Bangkok. DNSSEC and in-addr an update Olaf M. Kolkman"— Presentation transcript:
Olaf M. Kolkman. APNIC, 6 February 2014, Bangkok. http://www.ripe.net/ris DNSSEC and in-addr an update Olaf M. Kolkman firstname.lastname@example.org
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
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
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
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
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
Your consent to our cookies if you continue to use this website.