L’ICANN propose le domaine de premier niveau ".internal" pour un usage privé

• L’IANA (Internet Assigned Numbers Authority) a décidé de réserver ".INTERNAL" pour les applications personnelles et les réseaux internes
• Avant que le conseil d’administration de l’ICANN n’examine et n’approuve cette réservation, l’organisation sollicite des retours pour vérifier si ce choix respecte la procédure définie dans le SAC113

Contexte

• Il peut exister des situations particulières où des opérateurs de réseaux privés, comme au sein d’une entreprise ou d’un domicile, souhaitent utiliser leur propre système de noms de domaine, inaccessible ou inutilisable sur le DNS public étendu
• L’IANA dispose déjà de blocs spéciaux distincts d’adresses IP privées pour ce type d’applications, mais il n’existe pas d’équivalent comparable dans le DNS sous la forme d’un espace de noms privé
• Cela a conduit à des pratiques comprenant l’usage informel de domaines de premier niveau, avec un risque de conflit avec la zone racine ou d’autres TLD désignés à d’autres fins
• Parmi 35 mots candidats, "INTERNAL" et "PRIVATE" ont été envisagés, mais c’est finalement "INTERNAL" qui a été retenu

[GN⁺]

Avis Hacker News

• L’une des meilleures pratiques concernant AD (Active Directory) consiste à ne pas utiliser de faux TLD (domaines de premier niveau) locaux comme .internal ou .local. Comme ils pourraient un jour exister réellement, il faut utiliser un gTLD (domaine générique de premier niveau) ou un ccTLD (domaine de premier niveau de code pays) légitime que l’on peut contrôler à la fois en externe et en interne.
• ICANN a décidé de reporter indéfiniment .corp, .home et .mail, ce qui signifie que ces TLD conviennent à un usage privé.
• Si le DNS se comporte de manière étrange, il faut vérifier s’il existe un domaine à étiquette unique pour Active Directory (par exemple host1.internal). Sous Windows, la résolution de noms pour les domaines à étiquette unique peut utiliser la résolution NetBIOS, ce qui peut empêcher l’ajout de nouveaux hôtes au domaine depuis d’autres sous-réseaux.
• .zz pourrait techniquement être un ccTLD, mais c’est un code ISO 3166-1 alpha-2 réservé à l’usage utilisateur, avec une probabilité très faible d’être réutilisé comme code valide. ICANN a envisagé ce choix, mais l’a rejeté au motif qu’il n’avait pas de sens.
• home.arpa est déjà réservé et a été spécialement conçu pour l’usage domestique, il n’entre donc en conflit avec rien.
• Il serait souhaitable que la prise en charge de l’extension TLS Name Constraints, qui permet de limiter une autorité de certification interne à l’émission de certificats uniquement pour le domaine .internal, soit plus largement répandue. Cela pourrait permettre des usages très intéressants pour simplifier HTTPS sur les réseaux locaux.
• Même après avoir lu tout le fil, je pense que .lan est un suffixe non réservé plus adapté à cet usage que .internal.
• Si .intra n’est pas déjà utilisé, il pourrait être préférable à .internal : moins pénible à taper tout en exprimant bien l’objectif avec seulement cinq lettres.
• Il existe déjà le TLD .home.arpa, mais .internal semble être une amélioration en termes de clarté. Personnellement, j’utilise cependant un sous-domaine d’un domaine que je possède afin d’utiliser HTTPS avec un certificat SSL approprié.
• .local a commencé de cette manière, mais a ensuite été utilisé par Apple pour le réseau. Un nouveau domaine privé sera bientôt absorbé par autre chose. Si vous avez besoin de DNS, il faut enregistrer et utiliser un vrai nom de domaine. J’aime l’idée de .internal, mais il deviendra vite inutilisable pour cet usage.