ICANN réserve ".INTERNAL" comme domaine dédié aux applications à usage privé

• Réservation de .INTERNAL comme domaine à « usage privé »
  • Le 18 septembre 2020, le SSAC a recommandé de réserver une chaîne pour les TLD à usage privé.
  • Le conseil d’administration a évalué la recommandation du SSAC et a décidé de réserver la chaîne .INTERNAL choisie par l’IANA.
  • Cette décision contribuera à renforcer la stabilité du DNS en fournissant une chaîne destinée aux applications privées.
• Motifs de la résolution 2024.07.29.06
  • La réservation de .INTERNAL offre aux administrateurs réseau un espace qu’ils peuvent utiliser en toute sécurité.
  • Cette décision relève de la mission de l’ICANN et est importante dans l’intérêt de la communauté mondiale de l’Internet.

[GN⁺]

Avis Hacker News

• Utiliser le domaine .internal nécessite une autorité de certification privée

  • De nombreuses organisations ont du mal à configurer une CA privée sur tous les systèmes internes
  • Ajouter des appareils BYOD ou des systèmes de prestataires crée de la confusion
  • Utiliser un domaine publiquement valide présente l’avantage de pouvoir utiliser des CA publiques gratuites comme Let’s Encrypt
  • Comme tous les appareils font confiance aux certificats internes, le travail est réduit au minimum
  • L’an dernier, création de getlocalcert pour proposer une méthode gratuite automatisant cette approche
  • Il est possible d’enregistrer un sous-domaine, de publier des enregistrements TXT pour la validation de certificats ACME DNS, et d’utiliser un serveur DNS interne pour tous les usages privés

• Question sur l’existence d’une raison d’utiliser un TLD comme .internal

  • Lors de la mise en place d’un nouveau système, il vaut mieux utiliser un nom de domaine classique comme racine
  • Cela offre la flexibilité de rendre les noms visibles sur Internet
  • Si l’on suit un modèle de sécurité zero trust, il est utile que des noms privés puissent être accessibles depuis Internet
  • Utiliser des noms qui ne peuvent pas être résolus sur Internet présente de nombreux inconvénients
  • Lorsqu’il dirigeait la stratégie d’usage cloud native AWS chez Amazon, tout utilisait un domaine .com comme racine
  • Même les services accessibles uniquement depuis un réseau privé utilisent des certificats TLS publics standards
  • S’il faut ensuite rendre l’accès possible depuis un nouveau réseau ou depuis Internet, il n’est pas nécessaire de changer les noms ou les certificats
  • Le fait que les noms apparaissent dans les journaux CT peut entraîner une fuite d’informations

• Mécontentement à propos du rachat du domaine .dev par Google

  • Il était autrefois beaucoup utilisé dans les environnements de développement

• L’idée d’utiliser le TLD .internal pour l’interne semble bonne

  • Il faudrait aussi créer un TLD .pseudo
  • Les systèmes d’exploitation ou les applications pourraient le gérer
  • Si nécessaire, l’administrateur système pourrait l’attribuer manuellement sur le système local

• Question sur la possibilité d’ajouter aussi les domaines .local ou .l pour un usage privé

• Le conseil d’administration de l’ICANN a réservé de manière permanente le domaine .INTERNAL dans la zone racine DNS

  • Il recommande de sensibiliser davantage via des actions de communication technique afin d’encourager son usage pour les applications privées

• Continuera à utiliser le domaine .lan

• La partie publique d’un domaine .com recevait un trafic privé étrange

  • Cela a été découvert grâce à une analyse de honeypot
  • Si une autre entreprise enregistre un .com utilisé ailleurs comme domaine AD, cela peut provoquer une fuite d’informations

• Continuera à utiliser le domaine .lan, mais il est appréciable que l’ICANN prenne ce cas d’usage en considération