The "keys to the Internet" is a misnomer. He is a "recovery key shareholder", which means he holds a smart card in an m-of-n configuration that allows ICANN to decrypt a backup of the Root Zone Key Signing Key in a disaster recovery scenario should the KSK need to be rebuilt.

The primary roles are the cryptographic officers, these are Internet community members who attend key signing ceremonies to observe use of the KSK.

Here are a list of the trusted community representatives: https://www.iana.org/dnssec/tcrs

> The primary roles are the cryptographic officers, these are Internet community members who attend key signing ceremonies to observe use of the KSK.

While I realize those key signing ceremonies are probably just a bunch of people sitting around playing games on their phones, waiting around for their turn to give their keys to someone who's typing in all of the appropriate commands, I want to believe they're in some sort of dungeon, wearing black, hooded robes and chanting Gregorian chants while doing it.

I dunno, maybe I'm just weird.

It's a little more interesting than your guess, but not quite as cloak and dagger as it could be.

Here's a good article about the ceremony itself: http://www.theguardian.com/technology/2014/feb/28/seven-peop...

For those of us not up to date with the wheelings and dealings of organizations such as ICANN, what are these 7 "keys to the Internet?"

DNSSEC root key shares.

DNSSEC root keys (or a portion thereof)

So, this mistake might cost him the rights?

What's the mistake?

The reason there are multiple DNS servers is in case one/some of them have problems. There are two other root servers for the .io. zone that are apparently functioning just fine. That means the overall system is working as intended, no?

Also, I don't think we know (yet) why five of the seven are down. If it turns out to be some "amateur hour" mistake then, sure, I could see it being used against ICB. If, however, the underlying issue is/was out of their control, then why should they be penalized?

ETA: It appears that the name servers are actually "up". They respond to ICMP echo requests but aren't answering queries:

  $ ping -q -c 5 a.nic.io
  PING a.nic.io (64.251.31.179): 56 data bytes

  --- a.nic.io ping statistics ---
  5 packets transmitted, 5 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 45.123/45.283/45.453/0.106 ms

  $ dig ns docker.io @a.nic.io

  ; <<>> DiG 9.10.2 <<>> ns docker.io @a.nic.io
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

To be fair, even if it was "amateur hour", it was apparently mitigated by practices which kept two of the seven up.

I've watched other companies do far worse.

Try using +norec in dig and you'll get a response.

Interesting, it works locally for me when using +norec (i.e. Recursion Desired = false)... but is there a valid reason for an authoritative to to respond anything if RD is set to true? FYI Pulse always sets RD=true

Interesting. I was using "+trace" earlier (which implies "+norec", IIRC) and still wasn't getting a response from most of them.