Puisque j’oublie souvent, voilà une méthode simple pour générer un champ SSHFP :
ssh-keygen -r <fqdn> -f <file>

en remplaçant "<fqdn>" par votre nom de domaine avec le nom de votre machine, comme "foo.example.com", et "<file>" par le chemin vers le fichier.

Pour recréer à partir d’OpenSSL https://unix.stackexchange.com/questions/121880/how-do-i-generate-sshfp-records#133957

Ce petit billet me sert principalement de garde-mémoire, je ne vais donc pas détailler ce qu'est le champ TLSA et son but ; ceci est détaillé dans la RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” (https://tools.ietf.org/html/rfc6698)

Principalement, ce qui nous intéresse, c’est de fournir soit l’empreinte de la clef, soit l’empreinte du certificat ; c’est ce que définit le champ "Selector" (section 2.1.2).
Remarque : j’ai considéré par défaut que nous sommes dans le cas d’un "DANE-EE: Domain Issued Certificate", valeur "3" du champ "Certificate Usage" (section 2.1.1).
 * Si vous souhaitez uniquement donner l’empreinte de votre clef (valeur "1" dans le "Selector Field"), utilisez les valeurs "3 1 1" et "3 1 2" respectivement pour les hashs SHA256 et SHA512 ;
Ensuite, vous pouvez au choix déterminer les hashs (SHA256 et SHA512) à partir de la clef privée (n’oubliez pas l’option -pubout, voir openssl pkey(1))
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha256
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha512
OU, en alternative, déterminer les hashs (SHA256 et SHA512) à partir d'un certificat (c’est ainsi de cette façon qu’un tiers peut vérifier)
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha256
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha512

 * Par contre, si vous souhaitez fournir l’empreinte complète du certificat, utilisez les valeurs "3 0 1" et "3 0 2" respectivement, et exécutez :
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha256
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha512

Ensuite, créer une entrée DNS dans votre zone, en suivant la sémantique suivante :
_<port>._<protocole>.<nomdedomaine> IN TLSA <X Y Z> <hash>

Par exemple, pour avoir le hash du certificat pour le service HTTPS, donc le protocole TCP qui répond au port 443, sur la machine foo.example.com, le résultat est "_443._tcp.foo.example.com." (ne pas oublier le dernier point à la fin).
Et pour les valeurs <X Y Z> :
X → https://tools.ietf.org/html/rfc6698#section-2.1.1 : la valeur "3" indique que ce sont des informations avec le certificat le plus proche.
Y → https://tools.ietf.org/html/rfc6698#section-2.1.2 : exporter la clef est plus simple, de ce que j’ai compris.
Z → https://tools.ietf.org/html/rfc6698#section-2.1.3 : "1" pour le hash SHA256, "2" pour le hash SHA512.
Concernant le hash, n'oubliez pas de supprimer les doubles-points (par exemple : echo $hash | tr -d ':')

Sources :
- https://www.ietf.org/mail-archive/web/dane/current/msg07210.html
- https://tools.ietf.org/html/rfc6698

Un outil du site web de l'AFNIC (registar français pour les TLD en .fr) pour analyser les erreurs possibles contenu dans une zone. Très pratique, car il permet aussi de vérifier les plages de temps de l'entrée SOA.

Pour info concernant le SOA, voici les règles de l'AFNIC :
- Le numéro de série suit la forme AAAAMMJJnn.
- Le champ 'refresh' du SOA est entre 1H et 2D.
- Le champ 'retry' du SOA est entre 15M et 1D.
- Le champ 'expire' du SOA est entre 1W et 100W.
- Le champ 'minimum' du SOA est entre 3M et 1W.
tout en vérifiant :
- Le champ 'retry' du SOA inférieur à celui du 'refresh'.
- Le champ 'expire' est au moins 7 fois celui du 'refresh'.