Avant d'approuver DKIM délégation, demandez le changement DNS exact et l’identité de signature qu’il permettra. « Ajouter nos enregistrements DNS » est une instruction trop large pour un examen de sécurité. UN sélecteur CNAME, une délégation NS et un accès à l'intégralité du compte DNS accordent différentes formes de contrôle.
Tracez la limite avant de l’approuver
Un CNAME au niveau d'un nom de propriétaire de sélecteur dirige la résolution via sa cible. Un fournisseur contrôlant cette cible peut modifier les données de vérification obtenues via l'alias. Il n'accorde pas, en soi, l'autorisation de modifier des noms arbitraires dans votre zone. Une délégation NS établit une limite de zone et donne aux serveurs faisant autorité délégués la responsabilité des noms en dessous, sous réserve de la hiérarchie DNS . L’accès administratif à l’ensemble du compte peut être encore beaucoup plus large. RFC 1034 §3.6.2 et RFC 1034 §4.2 décrire ces mécanismes DNS .
Écrivez le nom du propriétaire et le sous-arbre concerné dans l'approbation. Une demande de service1._domainkey.example.com est différent du contrôle de l’ensemble _domainkey.example.com sous-arbre. Ne remplacez pas un enregistrement restreint pris en charge par un fournisseur par une large délégation simplement parce qu’il semble plus simple à automatiser.
Distinguer la portée DNS de l'impact de la signature
La vérification DKIM obtient une clé à l'aide du sélecteur de signature et du domaine de signature. Le contrôle des données de vérification d'un sélecteur utilisable, ainsi que la clé de signature privée correspondante, peuvent permettre des signatures valides pour ce domaine de signature. L’étroitesse apparente d’un nom DNS ne signifie donc pas que la conséquence sur la confiance dans le courrier électronique est négligeable.
Un exemple synthétique illustre la distinction. Un fournisseur reçoit un CNAME à invoices._domainkey.example.com et exploite le signataire correspondant pour d=example.com. Son accès DNS est limité à l'alias cible, mais ce signataire peut produire des signatures revendiquant la responsabilité de example.com. Un sélecteur nommé factures ne limite pas lui-même les signatures aux factures, à des destinataires particuliers ou à une campagne approuvée. Les contrôles des applications et des comptes doivent imposer ces limites.
Si vous utilisez un sous-domaine d'envoi dédié, évaluez les DMARC alignement des règles aussi. La séparation des sous-domaines n'isole pas automatiquement l'alignement détendu. RFC 9989 §4.4 décrit comment les identifiants authentifiés sont comparés au domaine d'auteur ; la question de la détermination de la politique et du domaine organisationnel.
Recueillir des preuves qui répondent à la question d'approbation
Demandez les instructions actuelles du fournisseur, les noms générés, l'identifiant de compte, le domaine de signature pris en charge et le modèle de rotation. Vérifiez qui peut modifier ces valeurs dans le compte du fournisseur et si la séparation des rôles est disponible. Renseignez-vous sur la fermeture de compte et la gestion des DNS obsolètes, sans assumer de garanties contractuelles qui n'ont pas été fournies.
Créez un registre compact : propriétaire DNS , type d'enregistrement, destination ou serveurs de noms, propriétaire du service, destiné d= identité, utilisateurs prestataires privilégiés, date de renouvellement et procédure de retrait. Pour une délégation NS proposée, inspectez l’intégralité du sous-arbre affecté pour rechercher les sélecteurs existants avant de l’approuver. Pour une demande d'accès au compte, demandez-vous pourquoi les instructions par enregistrement ou un rôle pris en charge plus restreint sont insuffisants.
Test d'intégration et résiliation du plan
Après une modification approuvée, comparez les observations DNS faisant autorité et récursives et envoyez-les via le service prévu. Inspectez le résultat et l’alignement DKIM d’un récepteur fiable. Le test doit démontrer l'identité accordée, et non seulement montrer qu'une signature est réussie.
À la fin, arrêtez l'accès aux applications, supprimez les informations d'identification d'envoi obsolètes et coordonnez le retrait du sélecteur avec les files d'attente de livraison et le processus du fournisseur. Si le fournisseur est soupçonné de compromission, invoquez une réponse aux incidents plutôt que de préserver automatiquement un chevauchement de routine. Un service marqué comme inactif dans les dossiers d'approvisionnement peut toujours représenter une dépendance technique active.
Documentez explicitement la confiance résiduelle : ce que le fournisseur peut signer, qui peut l'administrer et à quelle vitesse l'organisation peut supprimer la dépendance. Cet enregistrement fait des renouvellements ultérieurs un examen de l'autorité réelle plutôt qu'une répétition du ticket DNS d'origine.
Comparez trois demandes d’approbation hypothétiques
Utilisez la portée et les conséquences ensemble :
- Un sélecteur CNAME : examine son propriétaire et sa cible exacts, destinés aux contrôles d'identité et de compte fournisseur. Il n'accorde pas d'accès arbitraire en modification de zone, mais son mappage de clé peut permettre la signature pour cette identité.
- Délégation NS ci-dessous _domainkey.example.com : inventoriez les sélecteurs sous cette zone déléguée et qui contrôle ses serveurs faisant autorité. Les sélecteurs existants ou futurs pourraient être concernés, sous réserve de nouvelles réductions de zone.
- Accès complet au compte DNS : exigez un besoin explicite et inspectez les autorisations réelles du compte. Il peut atteindre des enregistrements de courrier et Web sans rapport ; cela n'équivaut pas à publier un alias de sélecteur.
Il s'agit de scénarios de révision, et non d'autorisations ou de modifications apportées à une zone réelle. Si la portée ou la propriété exacte est inconnue, résolvez cette lacune avant l'approbation.
Lecture connexe
Publication DKIM TXT et CNAME : suivez le modèle de gestion des clés du fournisseur · Révoquer une clé DKIM et distinguer la révocation d'un enregistrement DNS manquant.