L’ICANN propose le domaine .internal pour votre réseau local
Bientôt le .External… #OhWait !
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
4 min
Internet
Internet
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.
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
Commentaires (50)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousModifié le 01/02/2024 à 11h29
Le 01/02/2024 à 11h53
Le 01/02/2024 à 11h55
C'est différent mais ça mérite de le préciser !
Le 01/02/2024 à 12h36
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)
Modifié le 01/02/2024 à 12h03
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.
Le 04/02/2024 à 20h56
Modifié le 01/02/2024 à 12h04
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...
Le 01/02/2024 à 12h19
Le 01/02/2024 à 14h00
(je sors )
Le 02/02/2024 à 09h07
Modifié le 01/02/2024 à 14h08
- 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
Le 01/02/2024 à 14h35
Le 01/02/2024 à 15h23
Le 02/02/2024 à 12h49
.cestlafauteaureseau
.Parce que de toute façon, c'est toujours la faute au réseau.
Le 01/02/2024 à 14h27
C'est un peu tard pour se poser la question non ?
Le 01/02/2024 à 16h29
Le 02/02/2024 à 08h20
Le 02/02/2024 à 09h54
Le 01/02/2024 à 16h16
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.
Le 02/02/2024 à 00h09
Le 02/02/2024 à 13h14
Le 02/02/2024 à 23h45
Le 02/02/2024 à 00h40
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.
Le 02/02/2024 à 08h16
Et en IPv4, il y a aussi les adresses de lien local 169.254.0.0/16
Le 02/02/2024 à 08h40
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.
Le 02/02/2024 à 08h56
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.
Le 02/02/2024 à 09h08
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 ;) ).
Le 02/02/2024 à 09h35
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.
Le 02/02/2024 à 09h58
Le 02/02/2024 à 23h54
Le 03/02/2024 à 00h17
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 !
Le 03/02/2024 à 17h20
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.
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é.
Le 03/02/2024 à 18h43
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
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
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.
Le 03/02/2024 à 19h12
Stéphane Bortzmeyer en parle sur son blog et voilà la RFC 6762 où il est défini.
Le 03/02/2024 à 19h41
En tout cas, ne pas utiliser .local pour un réseau local donc.
Le 03/02/2024 à 20h57
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.
Le 02/02/2024 à 08h25
Le 02/02/2024 à 09h38
Le 02/02/2024 à 10h24
Le 02/02/2024 à 10h00
Le 02/02/2024 à 15h06
J'étais sur .intra puis maintenant sur .home.arpa, laisse mes DNS "maison" tranquille
Le 03/02/2024 à 10h11
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
Le 03/02/2024 à 10h35
Ç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.
Le 03/02/2024 à 12h49
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.
Modifié le 03/02/2024 à 19h44
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...
Le 03/02/2024 à 19h51
Le 03/02/2024 à 20h29
Le 04/02/2024 à 17h24
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 ?!Le 04/02/2024 à 17h44
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.
Le 06/02/2024 à 07h54
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.