KSK Sentinel

DNSSEC, .PR - 2018-03 v0.3

Geoff Huston
Joao Silva Damas
Warren Kumari

What's the problem?

  • We need want to roll the DNSSEC trust-anchor (KSK)
  • Users with a validating resolver that doesn't have the new KSK  break; everything looks BOGUS
  • We have no way of measuring deployment, and so don't know who (and how many!) will break

Wait! RFC8145?!

  • Sadly, no.
  • This provides reporting from resolvers
  • I have a validating resolver in my basement...
  • it doesn't have the new key :-(
  • but no-one is using it :-)
  • If a resolver falls in the forest, but no-one is using it, does it matter?!

Pretty graphs!



  1. Requires a (simple) resolver update
  2. Allows anyone to set up a measurement service
  3. Exposes the result to the users

The change

Just before sending the response (after resolution, validation):

  • kskroll-sentinel-is-ta-[key].something?
    • If have the key, reply normally, else SERVFAIL
  • kskroll-sentinel-not-ta-[key].something?
    • If do NOT have the key, reply normally, else SERVFAIL


  • I'm a validating resolver. I support sentinel.
  • I have the new KSK (20326)
  • I get a query for invalid.example.com
    • It fails DNSSEC validation - SERVFAIL
  • I get a query for
    • I resolve it and get
    • I have (and am using) KeyID 20326
      • answer with 
  • I get a query for
    • I do have (and am using) KeyID 20326
      • send SERVFAIL

Yawn. So what?!

  • Fish? Not validating, key-roll doesn't affect you.
  • Kitten and Puppy? Legacy, we cannot tell.
  • Kitten? You have the new key, you'll be fine.
  • Puppy? DANGER! You only have the old key.

Do you see:

Srsly? Kittens?!

Sadly, no...

...but kittens!!!

Sorry, still no... :-(

Demo: http://www.ksk-test.net: