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.
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)
#1
#2
#2.1
C'est différent mais ça mérite de le préciser !
#2.3
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)
#2.2
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.
#2.4
#3
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...
#3.1
#3.2
(je sors
#3.3
#4
- 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
#4.1
#4.2
#4.3
.cestlafauteaureseau.Parce que de toute façon, c'est toujours la faute au réseau.
#5
C'est un peu tard pour se poser la question non ?
#5.1
#5.2
#5.3
#6
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.
#6.1
#6.2
#6.3
#7
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.
#8
Et en IPv4, il y a aussi les adresses de lien local 169.254.0.0/16
#8.1
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.
#8.2
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.
#8.3
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 ;) ).
#8.4
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.
#8.5
#8.6
#8.7
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 !
#8.8
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.
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é.
#8.9
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)
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.
#8.10
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.
#8.11
En tout cas, ne pas utiliser .local pour un réseau local donc.
#8.12
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.
#9
#9.1
#9.2
#10
#11
J'étais sur .intra puis maintenant sur .home.arpa, laisse mes DNS "maison" tranquille
#12
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
#12.1
Ç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.
#12.2
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.
#12.3
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...
#12.4
J'ai coupé pour pas donner l'URL ici.
#12.5
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)
#13
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…
.localne 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 ?!#13.1
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.
#13.2
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.