Tuto intéressant mais j'apporte les précisions suivantes :
  - Avec ce tuto, les clés crypto se trouvent sur le serveur DNS qui fait autorité sur la zone (sur le master quoi). Attention en cas de compromission de ce frontal, tout ça.

  - NSEC suffit amplement pour les zones au contenu banal et/ou public (comme . ) : un RRset NS, un RR A, un MX, un RR "www", ... Ce type de contenu se devine facilement sans avoir recours au zone walking permis par NSEC. Du coup l'overhead crypto ne se justifie pas. NSEC3 est utile quand le contenu d'une zone ne doit pas être public (exemple : la zone fr.) et/ou n'est pas trivial.

  - Le roulement des clés peut s'automatiser facilement avec OpenDNSSEC. Les timings sont calculés automatiquement en fonction des données des zones (TTL, TTL cache négatif, ...), par exemple. ça diminue drastiquement les prises de tête, les oublis de roulement et les erreurs humaines. Je *recommande vivement* l'usage d'OpenDNSSEC.

  - Je ne comprends pas l'intérêt de révoquer uniquement la KSK. De plus, la révocation des clés n'existe pas vraiment dans DNSSEC. Comme je l'ai écrit dans ce pavé https://www.guiguishow.info/2012/08/21/domain-name-system-attaques-et-securisation/#toc-2827-dlgation-et-chane-de-confiance : « Attention : ce bit permet la révocation uniquement dans le cas d'une clé utilisée comme première trust-anchor par un résolveur. Autrement dit : il ne sert à rien dans le cadre d'une délégation avec un enregistrement DS. ».

(via http://shaarli.cafai.fr/?9wJc_A)