[ DNS et domaines ]

Noms de domaine internationalisés et punycode dans les contrôles DNS

Comparez les étiquettes de domaine internationalisés dans leurs formulaires Unicode et ASCII validés avant d'exécuter des contrôles DNS et d'authentification.

Par l’équipe de recherche EmailAuth

[ Points clés ]

  • Préservez l’entrée Unicode, la sortie validée de l’étiquette A et le profil IDNA exact.
  • Convertissez le domaine avant d'ajouter des étiquettes de soulignement de protocole.
  • Une authentification valide n'établit pas la propriété d'une marque similaire.
Sur cette page

Un domaine affiché en Unicode peut être interrogé via une représentation compatible ASCII. Conservez les formulaires et les règles de conversion afin qu'un résultat de vérificateur puisse être reproduit. La familiarité visuelle ne prouve pas que deux noms identifient le même domaine ou appartiennent à la même organisation.

Séparez le domaine de la boîte aux lettres

Références : RFC 5890 §2.3.2.1, RFC 5891 §5.

An internationalised domain label can have a U-label, its valid Unicode form, and an A-label, its validated ASCII-compatible form beginning xn--. IDNA processing operates on domain labels. Il ne convertit pas une partie locale de courrier électronique en boîte aux lettres ASCII et n'établit pas de support SMTPUTF8.

Les enregistrements d'authentification ajoutent des étiquettes de protocole autour du domaine. Convertissez la partie du domaine internationalisé avec l'implémentation IDNA appropriée, puis construisez le propriétaire, tel que _dmarc. plus le domaine de label A. N'exécutez pas un validateur IDNA de nom d'hôte uniquement sur les étiquettes de soulignement du protocole et concluez que le domaine sous-jacent n'est pas valide.

Valider plutôt que simplement encoder

Références : RFC 5890 §2.3.2.1, RFC 5891 §4, RFC 5895 §2.

Punycode fait partie de la représentation de l'étiquette A, mais toutes les chaînes commençant par xn- ne sont pas des étiquettes A valides. La validation inclut les règles IDNA applicables, les caractères autorisés et les restrictions contextuelles. RFC 5891 définit le traitement du protocole, tandis que les choix de mappage d'application peuvent affecter les entrées de l'utilisateur avant ce traitement.

Enregistrez la bibliothèque et la version, le profil IDNA, l'entrée Unicode et le formulaire ASCII résultant. Les valeurs par défaut des outils peuvent différer, en particulier pour les personnages affectés par le mappage ou un comportement IDNA plus ancien. Évitez de normaliser silencieusement une entrée utilisateur ambiguë et de présenter le résultat comme le seul domaine prévu possible.

Reproduire un luminaire aller-retour

À l’aide d’une bibliothèque Python idna installée qui implémente IDNA2008, exécutez idna.encode("si cher.example ", uts46=False).decode("ascii"). Le résultat attendu est xn--bcher-kva.example. Décodez-le avec la même bibliothèque et vérifiez l'aller-retour Unicode. L’exemple est illustratif et ne constitue pas une affirmation concernant le domaine actif d’une organisation.

Construction _dmarc.xn--bcher-kva.example et s1._domainkey.xn--bcher-kva.example as DNS owner strings. Dans un laboratoire ou un vérificateur contrôlé, indiquez si l'outil accepte l'entrée Unicode, la convertit, la rejette ou envoie une question différente. La capture historique conservée enregistre uniquement la conversion de bibliothèque, avec la version idna 3.18. La nouvelle vérification des conversions hors ligne présentée dans cette revue enregistre sa propre version installée séparément ; il ne s'agit pas non plus d'un test DNS ou SMTPUTF8.

Ajoutez un appareil négatif avec une étiquette xn-- invalide et conservez l'exception réelle de la bibliothèque. Traitez le rejet comme une preuve utile plutôt que de supprimer des caractères jusqu'à ce que l'entrée soit réussie. Pour les autres mappages destinés aux utilisateurs, documentez explicitement le profil alternatif au lieu de supposer qu'un résultat strict IDNA2008 correspond à chaque navigateur.

Comparez les identités réelles dans les preuves postales

Références : RFC 9989 §4.4, RFC 9989 §5.3.1.

Conserver l'original Depuis l'en-tête et les représentations de domaine utilisées par SPF, DKIM et DMARC analyse. Pour DMARC , RFC 9989 Le §5.3.1 nécessite qu'un domaine d'auteur d'étiquette U extrait soit converti en forme d'étiquette A pour un traitement ultérieur. Use the protocol's alignement règles plutôt qu’une comparaison visuelle des noms affichés. Where message syntax or internationalisation behavior is unsupported by a tool, report the limitation instead of silently picking a convenient identity.

Utilisez le contexte de propriété connu pour enquêter sur les sosies. Un domaine peut passer sa propre authentification tout en ressemblant visuellement au nom d'une autre organisation. IDNA conversion improves reproducibility; it does not certify brand ownership, remove hameçonnage risquer ou prouver qu'un message électronique a été autorisé par la partie attendue.

[ Emporter ]

Une authentification valide n'établit pas la propriété d'une marque similaire.

[ Par rôle ]

Qu'est-ce que cela signifie pour vous

Choisissez votre rôle pour les prochaines étapes pratiques.

Administrateur informatique/courrier

Enregistrer le comportement de normalisation

Un vérificateur doit révéler quel nom DNS il a réellement utilisé.

Prochaines étapes

  1. Capturez les formulaires Unicode et ASCII.
  2. Épinglez le profil et la version IDNA.
  3. Rejet des tests et allers-retours.

RSSI / SecOps

Examinez les sosies sans trop revendiquer

Une internationalisation valide n’est pas en soi suspecte ou digne de confiance.

Prochaines étapes

  1. Comparez les étiquettes réelles.
  2. Conservez les identités originales des messages.
  3. Gardez les résultats du phishing et du protocole distincts.

Fondateur / Non technique

Séparer l’identité de l’apparence

Un domaine d'apparence familière peut appartenir à quelqu'un d'autre.

Prochaines étapes

  1. Vérifiez le contexte réel de propriété du domaine.
  2. Évitez les allégations de marque basées uniquement sur l'authentification.
  3. Faites remonter les rapports clients ambigus.

[ FAQ ]

Questions fréquemment posées

Qu’est-ce qu’un label A ?

Une représentation valide compatible ASCII d'une étiquette de domaine internationalisée, en utilisant la forme xn--.

RFC 5890 §2.3.2.1

Chaque chaîne xn-- est-elle valide ?

Non. Il doit satisfaire à la validation IDNA, et pas seulement ressembler à Punycode.

RFC 5890 §2.3.2.1

IDNA convertit-il la partie locale de la boîte aux lettres ?

Non. La conversion de domaine est distincte de la prise en charge des adresses e-mail internationalisées.

Dois-je convertir _dmarc en tant qu'étiquette de nom d'hôte IDNA ?

Convertissez la partie domaine et construisez le propriétaire du protocole séparément ; underscore service labels have another role.

RFC 5891 §5

Pourquoi deux outils se normalisent-ils différemment ?

Ils peuvent utiliser différentes versions IDNA ou profils de mappage. Enregistrez les deux explicitement.

RFC 5895 §2

Que doit préserver un test aller-retour ?

L'étiquette Unicode valide prévue et son formulaire ASCII correspondant sous le profil indiqué.

RFC 5890 §2.3.2.1

Un sosie authentifié appartient-il à la marque ?

Non. L'authentification de ce domaine n'établit pas la propriété d'une autre marque.

L'exemple a-t-il été envoyé par courrier électronique ?

Non. Les preuves se limitent à la conversion de bibliothèque hors ligne et à la validation des entrées ; DNS , livraison de messages et SMTPUTF8 n'ont pas été testés.

[ Sources ]

Sources

  1. RFC 5890

    Sections §2.3.2.1

  2. RFC 5891

    Sections §4 · §5

  3. RFC 5895

    Sections §2

  4. RFC 9989

    Sections §4.4 · §5.3.1

[ Glossaire ]

Glossaire

Étiquette U
Une forme Unicode valide d'une étiquette de domaine internationalisée.

RFC 5890 §2.3.2.1

Étiquette A
Une étiquette IDNA validée et compatible ASCII.

RFC 5890 §2.3.2.1

Code Puny
Un encodage utilisé dans la représentation ASCII des étiquettes internationalisées.

RFC 5890 §2.3.2.1

Provenance de l'entreprise

Pourquoi les principales institutions financières et gouvernements ont retiré leurs tableaux de bord de sécurité de messagerie.

Les plateformes traditionnelles d'authentification de courrier électronique vous vendent un tableau de bord et demandent à vos ingénieurs de faire le travail. Dans les environnements à enjeux élevés, la surveillance manuelle entraîne des retards dans l’application, des dérives de configuration et des domaines fantômes non surveillés.

EmailAuth est la plateforme agent de provenance des e-mails. Nos agents appliquent p=reject, gardez les expéditeurs tiers alignés et déplacez vos domaines au maximum RFC 9989 conformité, la nouvelle norme DMARC , avec une auditabilité humaine dans la boucle.

Gouvernements Grandes entreprises Institutions financières de premier rang

SaaS · Location dédiée · Air-gappé sur site · Chiffrement BYOK

Base de connaissances