Connexion
Abonnez-vous

L’ICANN propose le domaine .internal pour votre réseau local

Bientôt le .External… #OhWait !

L’ICANN propose le domaine .internal pour votre réseau local

Home sweet home (1874) by Currier & Ives

La proposition vient de l’ICANN (Internet Corporation for Assigned Names and Numbers) qui souhaite définir un « domaine de premier niveau pouvant être utilisé pour des applications à usage interne ou privé ». Deux propositions étaient en lice sur la liste finale : Internal et Private. La première a été préférée à la seconde.

Le 01 février à 11h16

Un domaine pour les usages internes, en plus des IP privées

Pour les usages internes, il existe déjà trois plages d’adresses IP, utilisables par tout un chacun (particuliers comme professionnels). Bien évidemment, elles ne sont pas « routées » sur Internet et ne fonctionnent qu’en local.

L’IANA (Internet Assigned Numbers Authority) en a réservé trois (que vous connaissez surement), comme indiqué dans la RFC1918 de 1996 intitulée Address Allocation for Private Internets :

  • De 10.0.0.0 à 10.255.255.255 (10.0.0.0/8)
  • De 172.16.0.0 à 172.31.255.255 (172.16.0.0/12)
  • De 192.168.0.0 à 192.168.255.255 (192.168.0.0/16)

À l’heure actuelle, il n’existe par contre aucun domaine pour un usage interne, comme ce que proposent les trois plages d’adresses ci-dessus. Attention d’ailleurs à ne pas les confondre avec les 127.0.0.0/8 pour les adresses de bouclage (localhost) dont le 127.0.0.1 est la plus connue.

Il doit répondre à quatre critères

En septembre 2020, le SSAC (Security and Stability Advisory Committee) de l’ICANN lui recommandait de réserver un domaine de premier niveau avec la garantie qu’il « n'entre pas en conflit dans la zone racine du DNS ».

Le SSAC formulait quatre critères : cela doit être un nom de domaine valide, il ne doit bien sûr pas déjà être utilisé, il ne doit pas y avoir de risque de confusion avec un autre domaine et, enfin, il doit être « relativement court, facile à retenir et significatif » dans le message à faire passer.

L’IANA a identifié et analysé 35 candidats en fonction des critères définis par le SSAC. L’évaluation s’est déroulée dans les six langues officielles des Nations Unies, à savoir l’anglais, l’arabe, le chinois, l’espagnol, le français et le russe.

À la fin, il restait deux candidats : internal et private.

Le .private ne faisait pas passer le bon message

Dans les deux cas, des risques ont été identifiés : « Les deux ont été considérés comme pouvant laisser penser qu’il y avait des garanties sur le fait que leur utilisation resterait interne ou privée, même s’il est probable que ces noms soient divulgués dans la pratique, comme c’est le cas aujourd'hui avec les adresses IP à usage privé », explique l’ICANN.

Si on prend le cas des adresses IP, laisser fuiter qu’une machine se trouve en 192.168.1.10 ne représente pas un grand risque en soi (on ne peut pas la joindre directement depuis Internet). Par contre, cela peut devenir problématique si une personne parvient à infiltrer un réseau interne, en connaissant des adresses IP internes, il peut tenter d’attaquer d’autres machines.

« Il a été noté que "internal" pouvait être contracté en "int" » qui est utilisé par les organisations et les traités internationaux. C’est le cas de l’OTAN par exemple, accessible via nato.int (NATO pour North Atlantic Treaty Organization ou Organisation du Traité de l'Atlantique Nord en français). Mais « cela n'a pas été considéré comme représentant une similitude prêtant à confusion », indique l’ICANN.

Quant à private, le risque était évidemment de penser, à tort, que ce nom de domaine apportait une sécurité supplémentaire sur la « vie privée ». Ce n’est pas le cas et ce n’est pas non plus le message que voulait faire passer l’ICANN.

Bref, internal remporte donc la bataille.

L’ICANN demande votre avis

L'ICANN a lancé une consultation publique afin de recueillir l’avis de la communauté. Ce sera également l’occasion de vérifier si une utilisation imprévue ou un risque qui n’a pas encore été identifié ne remonte à la surface.

Les propositions sont ouvertes jusqu’au 21 mars. Celles déjà postées sont visibles par ici. La décision finale est attendue pour début avril avec la confirmation, ou pas, de .internal.

Commentaires (50)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Enfin ! Cela permettra d'accéder à ses équipements IPv6 plus facilement sans avoir à faire des configurations réseaux trop compliqués. On peut espérer une implémentation dans les routeurs permettant de facilement associer une adresse MAC/IP à un nom de domaine xxx.internal.
votre avatar
il n'y avait pas déjà le .local ?
votre avatar
en.wikipedia.org Wikipedia
C'est différent mais ça mérite de le préciser !
votre avatar
Merci pour la distinction et merci Fred42 pour les explications.

Concrètement, je suis censé avoir un serveur DNS local (LAN-facing) pour répondre à des requêtes de machines cherchant des noms en .internal ? (oui on est d'accord que pour le péquin moyen ça sera implémenté dans la box à terme)
votre avatar
Oui, mais la résolution de nom ne s'appuie pas sur le protocole DNS dans ce cas.
Il y a home aussi en seconde position.

Ils veulent juste traiter le cas du protocole DNS.
Je pense que c'est une erreur parce qu'il faudrait éviter que ces 2 (ou plus) noms de premier niveau ne partent pas vers les serveur DNS racine comme ils le font actuellement si le nom ne peut être résolu localement.
internal pour le protocole DNS, pourquoi pas, mais il faut aussi lister quelques nom de premier niveau qui ne pourront jamais être utilisé sur Internet (local et home en font partie à mon avis).

Édit : je lis dans le lien du commentaire ci-dessus que local est déjà réservé par l'IETF.
votre avatar
Et il me semble même qu'il y a .localdomain...
votre avatar
Je n'y connais pas grand chose en réseau, donc je vais sûrement poser une question bête, mais c'est différent du .local ?
Depuis mon PC j'ouvre un ssh sur mon serveur en tapant ssh serveur.local...

Edit : à ben le temps de lire la news et écrire mon commentaire, la même question a été posée...
votre avatar
Toujours lire les commentaires avant de poser une question, surtout quand il n'y en a pas beaucoup comme ici. :langue:
votre avatar
Oui mais pour le .local ça se passe comment ?

(je sors :D)
votre avatar
Lire les commentaires, j'avais fait, c'est rafraîchir la page que je n'avais pas fait :roll:
votre avatar
Le SSAC formulait quatre critères :
- cela doit être un nom de domaine valide : fuck
- il ne doit bien sûr pas déjà être utilisé : fuck
- il ne doit pas y avoir de risque de confusion avec un autre domaine : fuck
- et, enfin, il doit être « relativement court, facile à retenir et significatif » dans le message à faire passer : fuck

Déclinable dans d'autres langues en fonction des préférences nationales. .putain pour le français par exemple. Des expressions comme "c'est encore ce putain de réseau qui plante" prendraient alors pleinement leur sens :francais:

:nimp::humour::bouletdujour:
votre avatar
Quand je test un site en local c'est nomdedomaine.prout
votre avatar
C'est comme ça que tu sens si ça gaze ? :D
votre avatar
Autant standardiser le domaine .cestlafauteaureseau.

Parce que de toute façon, c'est toujours la faute au réseau.
votre avatar
Ça fait un bout de temps que j'implémente le .lan.
C'est un peu tard pour se poser la question non ?
votre avatar
Pareil, j'aime bien le .lan.
votre avatar
C'est vrai qu'on croise souvent du ".lan"
votre avatar
Toujours mieux que .internal non pas que j'ai la flemme de taper 8 lettres mais si en fait
votre avatar
Si on prend le cas des adresses IP, laisser fuiter qu’une machine se trouve en 192.168.1.10 ne représente pas un grand risque en soi (on ne peut pas la joindre directement depuis Internet). Par contre, cela peut devenir problématique si une personne parvient à infiltrer un réseau interne, en connaissant des adresses IP internes, il peut tenter d’attaquer d’autres machines.
Je comprends pas trop la différence ? Non parce que quelqu'un sur le réseau interne qui a l'adresse va trouver tout aussi facilement l'IP associée avec une simple résolution DNS... Le seul avantage que j'y vois sur ce point, c'est qu'une capture d'écran ou un code source ne permet pas de connaître l'IP de la machine en question, même si ça fuite quelque part.

En revanche, pousser les réseaux à passer sur du nom, c'est une bonne chose pour bascule vers l'IPv6 (et ses adresses impossibles à retenir) et c'est surtout beaucoup plus modulaire de pouvoir changer un domaine central sans devoir faire modifier tous les appels. Mais ça, j'espère pour eux que ceux que ça concerne n'ont pas attendus que l'ICANN décide de créer un TLD.
votre avatar
l'important c'est que le tld ne soit pas réservé par quelqu'un d'autre, pour du global, même si ça reste privé, ça poserait problème à un moment ou un autre.
votre avatar
C'est la question que je me posais. j'ai un domaine du type monnomdefamille.me car le .fr était déjà pris par une entreprise créée par un homonyme. Du coup comment ça ce passe pour le .internal si jamais il s'échappe sur internet?
votre avatar
Le .internal est juste un nom, il ne sera pas diffusé sur le DNS mondial, donc chacun met ce qu'il veut, le souci aurait existé si il avait été diffusé sur le dns mondial.
votre avatar
je trouve dommage en 2024 d'illustrer les plages réseau privé par "les trois" de la rfc 1918, sans même faire allusion à ce qui devrait devenir une règle: IPV6 et ses ULA.
C'est d'ailleurs une occasion de mettre en place un dns automatique qui manque tant en ipv6 avec effectivement des adresses impossibles à mémoriser, perso j'aurais préféré un .pz comme private zone ou .zp comme zone privée, mais peut-etre que les tld à 2 lettres sont réservés aux pays, je ne sais pas.
votre avatar
Rien sur IPv6 dans l'actualité. Il a été écrit avant 2000 ou bien?

Et en IPv4, il y a aussi les adresses de lien local 169.254.0.0/16
votre avatar
Non, car les adresses 169.254.0.0/16 ne permettent pas de créer et gérer les réseaux, ni de donner un accès à internet. Tu ne pourras communiquer qu'avec les machines directement accessible (pas de routeurs, mais le switch doit passer).

Après, l'IPv4 est encore très fortement répandue et majoritaire, notamment dans les réseaux d'entreprises (IPv4 ne pose aucun souci en interne à une entreprise). Le seul problème vrai d'IPv4, c'est la pénurie d'adresse au niveau mondial, ce qui est sans impact pour les réseaux locaux d'entreprise.
votre avatar
J'ai même observé l'usage d'IP non privé pour des accès internes (99.77.55.33,...). Ça gère parfois de très grandes flotte d'appareils et ils se fichent des accès internet.

Pareil pour les DNS d'ailleurs. Si vous souhaitez utiliser .gouv.fr en interne ça posera aucun problème. Faut pas avoir besoin a des services externes sur ces extensions là et puis c'est tout.
votre avatar
Ou un cas plutôt connu aussi, où les box d'Orange considérait que 1.1.1.1 c'était une adresse en interne. Sauf que c'est une adresse qui existe bel et bien et est à CloudFlare je crois (notamment pour leur DNS).

Après, on peut bien évidemment utiliser n'importe quel adressage en interne, d'autant plus si le réseau n'est pas connecté à Internet. Mais comme la plupart le sont...

Maintenant, la norme prévoit des usages spécifiques pour certaines plages, et si on respecte la norme, la plage 169.254.0.0/16 n'est pas utilisable (et c'était là-dessus que je réagissais ;) ).
votre avatar
Le problème de 1.1.1.1 sur les Livebox n'était pas volontaire, juste de l'incompétence.

Les concepteurs utilisaient 1.1.1.1 et 1.1.1.2 pour la communication interne entre le SOC et un chip WiFi de certaines Livebox.
votre avatar
tu peux même avoir un .gouv.fr tout en ayant des services externes tant qu'il n'y a pas de collision.
votre avatar
A la base, le système automatique apipa qui permet d'affecter une ipv4 169.254.0.0/16 ne fournit pas de passerelle par défaut à l'interface, mais un tyoe vicieux qui voudrait numéroter statiquement ou par un DHCP son réseau privé aussi, pourrait configurer des routes par défaut vers un routeur dans le même réseau, ça pourrait donc être une adresse privée tout pareil, genre extension rfc 1918, ce qui n'est pas le cas avec les adresses lien local (fe80::/10) de l'ipv6, déjà qu'on ne nate pas en principe.
votre avatar
Le même type pourrait aussi décider de router 127.0.0.0/16. La seule chose que mériterait un type faisant ça est le pilori, attaché et fouetté avec des câbles RJ45 !

Les adresses en 169.254.0.0/16 sont les liens locaux pour l'IPv4. C'est la norme. La différence avec l'IPv6, c'est que la norme IPv6 précise explicitement que les routeurs ne doivent pas transmettre le trafic des liens locaux.

Autrement dit, en IPv6, c'est techniquement impossible. En IPv4, c'est techniquement possible mais interdit par la norme. Si jamais je vois un réseau comme ça, je préfère encore demander à Numérobis de le refaire. Ce sera toujours mieux !
votre avatar
Non, car les adresses 169.254.0.0/16 ne permettent pas de créer et gérer les réseaux, ni de donner un accès à internet. Tu ne pourras communiquer qu'avec les machines directement accessible (pas de routeurs, mais le switch doit passer).
Désolé mais ta réponse est à côté du sujet. Rappel du sujet: les noms dns et en sujet secondaire les plages d'adresses IP réservées pour les réseaux locaux.
La plage 169.254.0.0/16 est bien réservée pour cet usage et c'est celle qui est associée à l'extension .local . a aucun moment je n'ai dis que cette plage était routable.

Avec les adresses de lien local 169.254.0.0/16 et fe80::/64 tu peut tout à fait créer et gérer un réseau même si effectivement ce réseau ne donnera aucun accès à Internet. Et si cela n'avait aucune utilité, les protocole bonjour et mdns n'existeraient pas.
Après, l'IPv4 est encore très fortement répandue et majoritaire, notamment dans les réseaux d'entreprises (IPv4 ne pose aucun souci en interne à une entreprise). Le seul problème vrai d'IPv4, c'est la pénurie d'adresse au niveau mondial, ce qui est sans impact pour les réseaux locaux d'entreprise.
IPv4 pose des soucis en entreprise mais les IT on l'habitude de faire avec. De la à dire qu'ils n'ont pas besoin d'IPv6, c'est juste de la résistance au changement et on sais tous que cela n'a rien de rationnel. IPv4 pose bien plus de problème que l'adressage et réduire le passage à IPv6 à une augmentation du nombre d'adresses est passer à côté de 99% des ajouts d'IPv6. C'est limite insultant pour ceux qui y ont travaillé.
votre avatar
Désolé mais ta réponse est à côté du sujet. Rappel du sujet: les noms dns et en sujet secondaire les plages d'adresses IP réservées pour les réseaux locaux.
Ben non, ce n'est pas à côté de la plaque. Une fois encore, tu sembles confondre réseau et lien local. Les adresses 169.254.0.0/16, c'est pour du lien local. Rien d'autre. C'est la norme (RFC 5735 section 4)
10.0.0.0/8 Private-Use Networks RFC 1918
169.254.0.0/16 Link Local RFC 3927
172.16.0.0/12 Private-Use Networks RFC 1918
192.168.0.0/16 Private-Use Networks RFC 1918
La plage 169.254.0.0/16 est bien réservée pour cet usage et c'est celle qui est associée à l'extension .local . a aucun moment je n'ai dis que cette plage était routable.
L'extension .local, bien que d'usage répandue, n'est, à ma connaissance, pas normalisé. Donc non, le 169.254 n'est pas associé à .local. Ca ne veut rien dire (d'autant plus que la norme précise bien que c'est un link-local et non un private-use network
Avec les adresses de lien local 169.254.0.0/16 et fe80::/64 tu peut tout à fait créer et gérer un réseau même si effectivement ce réseau ne donnera aucun accès à Internet. Et si cela n'avait aucune utilité, les protocole bonjour et mdns n'existeraient pas.
Encore une fois, non. Avec le 169.254 tu pourrais certes gérer un réseau (comme déjà dit dans un autre commentaire, même si je clouerais volontier le type qui ferait ça).

Par contre, c'est techniquement impossible en IPv6, puisque les routeurs ne doivent pas transmettre les paquets qui s'échangent sur un lien-local. Ci-dessous un extrait de la RFC 4291 section 2.5.6
Routers must not forward any packets with Link-Local source or destination addresses to other links.
IPv4 pose des soucis en entreprise mais les IT on l'habitude de faire avec. De la à dire qu'ils n'ont pas besoin d'IPv6, c'est juste de la résistance au changement et on sais tous que cela n'a rien de rationnel. IPv4 pose bien plus de problème que l'adressage et réduire le passage à IPv6 à une augmentation du nombre d'adresses est passer à côté de 99% des ajouts d'IPv6. C'est limite insultant pour ceux qui y ont travaillé.
Je te trouve bien agressif dans tes propos. L'IPv6 dispose effectivement d'avantage par rapport à l'IPv4, mais réduire le manque de déploiement à une simple résistance au changement c'est ne pas avoir compris les problématiques des entreprises. Les avantages de l'IPv6 sur l'IPv4 sur la QoS ou le routage par exemple ne sont que très rarement utile pour un réseau interne d'entreprise.
votre avatar
L'extension .local, bien que d'usage répandue, n'est, à ma connaissance, pas normalisé. Donc non, le 169.254 n'est pas associé à .local. Ca ne veut rien dire (d'autant plus que la norme précise bien que c'est un link-local et non un private-use network
Comme on peut le voir dans le lien de ce commentaire .local a été réservé par l'IETF afin qu'il ne soit pas un TLD. Il a fini par entériner le passage en force d'Apple.

Stéphane Bortzmeyer en parle sur son blog et voilà la RFC 6762 où il est défini.
votre avatar
Ah ben si, c'est normalisé. Lecture intéressante. Merci :chinois: Le coup d'Apple est pas mal non plus et instructif.

En tout cas, ne pas utiliser .local pour un réseau local donc.
votre avatar
Par définition, dès lors que des machines reliées sur le même lien peuvent communiquer, c'est un réseau. Peut-être pas assez noble à ton goût mais un réseau tout de même.
Et quand on a pas le besoin ou la volonté de relier ce réseau à d'autres réseaux, cela est bien suffisant. C'est exactement l'esprit du protocole bonjour.

Donc, dans ces cas, l'utilisation des adresses 169.254.0.0/16 ou fe80::/64, qui sont effectivement toutes les deux des adresses link local, pour communiquer entre machines, est valable.

Et il est tout à fait possible d'ajouter les adresses link-local dans le fichier hosts à la condition de préciser le port réseau concerné vu qu'aucune route ne peut y mener.

Alors, oui, ce n'est pas la solution que je favoriserait pour mes besoins ou que je conseilllerai mais cela fonctionne et c'est bien un réseau.
votre avatar
Et pourquoi ne pas utiliser .home.arpa ?
votre avatar
Je pense que le dotArpa est, de nos jours, plutôt lié à de l'infra pure. Et surtout, ne valide pas la case "nom significatif".
votre avatar
Ah oui effectivement je ne l’avais pas vu comme ça !
votre avatar
je préfère .intergouvernementalisations
votre avatar
Ils en ont pas marre de changer ?

J'étais sur .intra puis maintenant sur .home.arpa, laisse mes DNS "maison" tranquille :transpi:
votre avatar
Intéressant le point sur les certificats et la sécurité associée si on veut s'appuyer sur des entités de certifications comme Let's Encrypt et assimilé. Comme tout le monde pourra enregistrer bigcorp.internal, l'intérêt du certificat tombe et on peut usurper les utilisateurs assz facilement au final... En l'état, cela impose d'avoir une PKI privée et le fait de déployer les certificats de la CA en question sur votre parc...

https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024/submissions/alexander-robert-27-01-2024
votre avatar
Let's Encrypt ne fonctionnera pas sur du .internal puisque ce TLD n'est pas accessible depuis Internet.
Ça m'étonnerait que les autres autorités de certifications émettent des certificats sur ce TLD puisqu'il n'appartient à personne ou à tout le monde ce qui revient au même.

À partir de là, il n'y a que les certificats locaux qui fonctionnent ou utiliser son propre nom de domaine en ayant une partie publique et une partie privée, mais c'est ce que veut éviter ce .internal.

J'ai l'impression que le monsieur qui a posté ce commentaire en profite pour faire de la pub à son service.
votre avatar
J'ai l'impression que le monsieur qui a posté ce commentaire en profite pour faire de la pub à son service.
Tout à fait. Surtout que s'il y a besoin d'établir des certificats pour du .internal, alors il suffit simplement de déployer son propre CA en interne.

Internal, c'est du "localhost" au niveau d'une entité (par exemple une entreprise). La même problématique se pose avec les certificats localhost. Soit du autosigné que l'on accepte, soit une CA maison.
votre avatar
@fred42 @fdorin : oui mais il était possible sur du dns interne avec un tld public de produire des certificats via LE par ex même si ces (sous-)domaines n'étaient pas accessible en tant que tel sur internet. Donc même pour des ressources internes, on pouvait utiliser des certificats LE & co.

Avec le .internal, cela ne sera plus possible pour les raisons évoquées.

Certes, on peut déployer une PKI en interne (même si c'est un peu fastidieux) mais le confort apporté par LE & co va disparaitre avec le .internal. Pas un inconvénient insurmontable mais un inconvénient quand même :-)

Et la réponse "on est en interne, on peut se passer de certificats" n'est pas la bonne réponse ;-)

Je sais pas s'il fait de la pub pour lui ou un proche ou jusque parce qu'il connait le service ou qu'il cherche à partager une réponse au problème, mais il reste que le point qu'il soulève est juste...
votre avatar
C'est un truc à lui et il ne s'en cache pas :
I operate three public suffixes that offer free registration and are compatible with the public CAs.
J'ai coupé pour pas donner l'URL ici.
votre avatar
oui mais il était possible sur du dns interne avec un tld public de produire des certificats via LE par ex même si ces (sous-)domaines n'étaient pas accessible en tant que tel sur internet.
Si il est effectivement possible via Let's encrypt de générer des certificats pour des domaines pas accessibles sur internet (mais des domaines existants et enregistrés), il faut malgré tout que le domaine t'appartienne. C'est pour ça que Let's encrypt ne pourra pas générer des certificats pour .internal, car .internal n'appartient à personne et qu'il ne sera pas possible de répondre aux challenges permettant de valider un certificat (ni challenge DNS, ni challenge HTTP)
votre avatar
On va donc faire fuiter à l'extérieur les noms de machines du réseau local.
Excellent vecteur d'analyse d'un attaquant qui n'aura plus qu'à écouter le trafic DNS sortant pour énumérer des cibles de sa (future) victime.

Quelle bêtise de vouloir résoudre des adresses d'un réseau non-routable sur un système hiérarchique de domaines…
.local ne peut par construction pas sortir du réseau, tout comme les adresses IP associée : qu'il y a-t-il donc là-dedans qui n'est pas compréhensible ?!
votre avatar
On va donc faire fuiter à l'extérieur les noms de machines du réseau local.
Et pourquoi donc ?
Si tu es capable de mettre le .internal en place, tu es capable de mettre ton serveur DNS en interne et ne l'interroger qu'en interne en passant par exemple par unbound à qui tu indiques que pour .internal, il doit interroger ton serveur DNS interne et que pour le reste, il interroge le serveur DNS habituel.

Le .local ne répond pas au besoin d'une entreprise avec un réseau avec plusieurs routeurs qui ne laissent pas passer le mDNS.
Chez toi, le .local suffit généralement, oui.
votre avatar
Après, tu peux faire tout ça avec n'importe quel autre nom de domaine que tu possèdes déjà.
Si j'ai le "example.com", je peux ne rediriger le "git.example.com" que depuis le réseau interne (depuis le VPN par exemple) vers le bon serveur.
C'est le serveur DNS du réseau interne qui connaitrait cette adresse et l'extérieur n'en saurait rien.

Du coup, ça serait plus pour les particuliers ou petites boîtes qui n'ont pas de nom de domaine j'imagine.

L’ICANN propose le domaine .internal pour votre réseau local

  • Un domaine pour les usages internes, en plus des IP privées

  • Il doit répondre à quatre critères

  • Le .private ne faisait pas passer le bon message

  • L’ICANN demande votre avis

Fermer