Étape 05 · Déléguer
Pointez-le vers la machine. Puis lisez ce que vous venez de publier.
La délégation elle-même se résume à deux enregistrements et cinq minutes. Réglez les serveurs de noms chez le bureau d'enregistrement, créez un enregistrement d'adresse pour l'hôte, attendez que la modification se propage jusqu'au registre, et vérifiez-la depuis l'extérieur de votre propre réseau plutôt que depuis la machine qui connaît déjà la réponse. Ce qui mérite les quarante minutes restantes, c'est tout ce que la délégation rend visible par la suite.
dig +short NS example.com @1.1.1.1 # the delegation as the world sees it, not your cache
dig +short A app.example.com # must return the VPS address before you deploy anything
dig +short CAA example.com # empty today; step 05 fills it in
dig +short DS example.com # non-empty only if DNSSEC is actually signed
Sur la question de qui exploite les serveurs faisant autorité, la réponse honnête n'est pas celle que donne d'habitude le reste de cette série. Le DNS faisant autorité auto-hébergé est le seul composant où le faire soi-même est généralement pire : il exige deux serveurs ou plus sur des réseaux distincts, il doit continuer à fonctionner pendant précisément la panne qui a mis votre machine principale hors service, il nécessite une vigilance permanente pour éviter d'être exploité à des fins d'amplification, et quand il tombe, tout tombe avec lui — y compris le renouvellement de certificat qui vous aurait permis de réparer la situation. Il crée aussi une corrélation que vous cherchiez précisément à éviter, car un serveur de noms auto-hébergé partagé entre deux projets les relie publiquement dans des jeux de données que n'importe qui peut interroger. Utilisez un opérateur DNS doté d'un réseau anycast, choisi selon qu'il exige une pièce d'identité plutôt que selon sa liste de fonctionnalités, et conservez un fichier de zone exporté afin qu'un déménagement soit un simple copier-coller plutôt qu'une fouille archéologique. C'est un travail différent du résolveur récursif privé de la série, qui déplace vers votre propre machine le journal de ce que vous recherchez, et qui vaut la peine d'être fait.
Voici maintenant la fuite qui défait plus d'installations soigneuses que tout autre élément de cette page, car elle agit silencieusement et après que vous avez cessé d'y prêter attention. Tout certificat émis par une autorité reconnue publiquement est soumis à des journaux publics en ajout seul, et les navigateurs rejettent les certificats qui ne le sont pas. Ces journaux existent pour qu'une émission erronée soit détectable, ce qui est réellement une bonne chose, et ils sont indexés par des interfaces de recherche gratuites. La conséquence est que chaque nom d'hôte pour lequel vous avez jamais demandé un certificat n'est qu'à une recherche par mot-clé, pour n'importe qui, de façon permanente — y compris staging., vpn., backup. et le nom administratif que vous pensiez indevinable.
# every certificate ever issued under the zone, and every hostname inside each one
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -u
La parade consiste en un unique certificat wildcard pour la zone, servi pour chaque nom d'hôte interne qui s'y trouve. L'entrée du journal enregistre alors qu'un certificat existe pour la zone, et rien sur ce qui vit à l'intérieur. Le coût est qu'un wildcard exige le défi basé sur le DNS plutôt que le plus simple défi basé sur un fichier, ce qui implique un jeton API pour votre opérateur DNS sur la machine — dix minutes de configuration, à mettre en balance avec une liste publique permanente de votre schéma de nommage interne. Émettez un seul wildcard, conservez-le sur le proxy inverse, et arrêtez de demander des certificats par nom d'hôte.
Deux enregistrements achèvent le travail. Un enregistrement CAA indique quelles autorités de certification sont autorisées à émettre pour le nom, de sorte qu'une émission erronée par toute autre autorité est refusée à la source plutôt que détectée après coup. Et DNSSEC, si votre registre et votre opérateur DNS le prennent tous deux en charge, signe la délégation afin qu'un résolveur puisse distinguer une réponse falsifiée d'une réponse authentique — c'est un simple interrupteur chez la plupart des opérateurs et un enregistrement chez le bureau d'enregistrement, et le seul point de vigilance est qu'une zone signée dont les clés sont mal gérées échoue de façon fermée, c'est-à-dire complètement.
; in the zone — only this authority may issue, and tell us if anyone tries
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:abuse@example.com"
Enfin, la couche de corrélation, celle où deux compartiments n'en deviennent qu'un sans que personne ne commette d'erreur. Les jeux de données DNS passif enregistrent quels noms ont résolu vers quelles adresses et quand ; une adresse partagée, un même jeu de serveurs de noms ou un même serveur de messagerie suffisent à réunir deux projets qui n'ont rien d'autre en commun. Si deux noms doivent rester non liés, il leur faut des serveurs séparés, des jeux de serveurs de noms séparés et un routage de courrier séparé — et il en va de même pour les petites choses que personne ne compte, comme un identifiant analytique réutilisé sur les deux sites ou un favicon identique, tous deux recherchables à l'échelle d'internet par quiconque s'en donne la peine.