L'ICANN veut un .internal pour les réseaux locaux (et les interfaces des Box)
Vous avez peut-être déjà eu le problème : est-ce que l'adresse du routeur fourni par votre FAI est 192.168.1.1 ou 192.168.1.254 ? Et est-ce qu'il faut taper http://livebox, mafreebox.freebox.fr, mabbox.bytel.fr ou http://monmodem pour les principaux fournisseurs français ? Un problème qui pourrait bien se résoudre avec une proposition de l'ICANN (Internet Corporation for Assigned Names and Numbers, une autorité de régulation d'Internet) : créer un .internal qui pourrait notamment renvoyer vers le routeur.
Ce n'est pas totalement nouveau : nous l'avons vu, les fournisseurs d'accès proposent des URL dédiées dans leurs produits, tout comme certains fabricants (D-Link) ou développeurs de logiciels de routeurs (OpenWRT emploie openwrt.lan). Et la technologie Bonjour d'Apple le permet aussi, mais elle a le défaut de ne pas être disponible directement avec tous les OS. La proposition de l'ICANN, elle, devrait simplifier les choses.
Plusieurs noms ont été évalués et le choix s'est fait entre .private et .internal, qui a finalement été sélectionné, notamment parce que le premier des deux pouvait faire croire à un respect plus élevé de la vie privée, ce qui n'est pas le but ici. La seule contrainte de cette solution, outre le fait que chaque FAI proposera probablement des adresses du type mafreebox.internal ou malivebox.internal, c'est que les adresses internes ne fonctionneront que si vous utilisez le résolveur DNS du routeur : le fait de passer par les DNS de Google (par exemple) empêchera donc les adresses en question de fonctionner.
Bien évidemment, le .internal ne devrait pas être réservé aux interfaces des routeurs dans l'absolu, mais c'est probablement l'usage grand public le plus évident. Mais le but est aussi de fournir une URL pour un usage interne dans d'autres cas, comme celui des entreprises : chaque service pourrait recevoir sa propre URL interne avec un domaine de premier niveau (top-level domain, TLD) standardisé.
En parlant box réseau et Mac, aujourd’hui comment obtenir les 8 gbps de la nouvelle Ultra (ou de l’ancienne delta)? La seule option que j’ai trouvé c’est un adaptateur SFP+ vers Thunderbolt 3…. Mais les prix piquent…
@winnipeg
Moi j’ai pris une borne wifi be85 avec port sfp+ et Ethernet 10g pour mon Mac Studio.
@cowboybebop95
1200€ le kit be85 ouch ça pique! Mais du coup ton Mac Studio lui est nativement équipé d’un port 10 G donc Freebox SFP+ vers ta borne Wifi port SFP+. Puis tu ressors de ta borne avec un câble ethernet 10G vers ton port 10G du Mac.
Mais ayant un MacBook Pro M1 Max, je n’ai pas de port 10G donc ça n’irait pas chez moi… :(
@winnipeg
Rien en dessous d’environ 250€ (pour du 10GBASE-T, si le port SFP+ de l’ultra accepte les transceivers) 🥲
Je pense que je vais me contenter d’un dock TB avec un port 2,5G…
@undidish
J’ai pensé la même chose mais c’est quand même dommage d’avoir 8gbps symétriques et se « contenter » de plus de 3 fois moins… même si en pratique on le ressentirait même pas, mais quand même…
@winnipeg
Depuis que j’ai troqué mon vieux PC muni d’une carte PCI-E SFP+ 10G pour un MacBook, ce sont surtout les accès au NAS qui me rendent triste 😢
Par contre, pour les tâches « internet », je pense que peu de sites saturent les 2,5G 🤓
@winnipeg
Un autre usage est d’avoir un peu plus d’1Gb par machine pour une dizaine d’appareils, au lieu de tout saturer avec un seul. Mais je voudrais aussi essayer d’avoir les 8Gb sur un seul appareil rien que pour voir (si cette connexion m’intéressait ^^)
Sinon je trouve aussi le .internal étrange, d’autant qu’en réalité on cherche cette info une fois puis ça ne bouge plus, sauf à jouer à changer de FAI tous les mois ou de changer le plan d’adressage local tous les 4 matins 😁
Il me semblait que le domaine .home.arpa est censé déjà servir à ça.
En quoi est ce différent des url.local de zeroconf / mdns ? Je ne suis pas sûr de bien comprendre. J’utilise régulièrement hostname.local sans me poser trop la question.
@Pierre Dandumont
Je puis me tromper mais Windows a bel et bien le .lan pour les anglophones et le .local pour nous autres francophones.
@Pierre Dandumont
En même temps, si on doit ce limité à ce que sait gérer Windows, on est pas arrivé… ils ne savent déjà pas gérer les caractères spéciaux dans les noms de fichier….
@Pierre Dandumont
C’est sans doute parce que j’installe iCloud pour Windows que je ne m’en suis pas rendu compte alors. Sous Linux ça fonctionne depuis longtemps.
İl y a aussi .local ! .internal ça fait bizarre
J'ai un gros doute car un domaine .XXXXXX est plutot lié avec les DNS pour faire le lien entre une IP et un nom de domaine mais si pas de liaison internet celui-ci ne fonctionne pas puisque pas acces au DNS.
et je vois pas trop la difference avec .local qui lui est un mDNS mais qui pourrait "potentiellement" service pour ca. Mais cela peut déjà engendrer des problèmes de nommages, conflits et compatibilités avec les .local actuellement (pour cela généralement l'utilisation des IP) alors automatiquement il y aura aussi des problèmes avec un .internal
J’aurais trouvé le .lan plus adapté mais bon.
Je me demande si le .local, ne serait pas pour la machine aussi ? Exemple : plusieurs serveurs web en local (ou pourquoi avec Docker ou OrbStack).
Bonsoir,
En fait, il y a bien un manque dans les RFC sur la résolution de nom.
Il est déconseillé d'utiliser le domaine `.local` dans un réseau interne en raison de son potentiel conflit avec mDNS / Zeroconf. Principalement utilisé dans un environnement Apple / UNIX. En effet, lorsque Zeroconf annonce les services disponibles d'une machine sur le réseau, elle indique ce domaine pour indiquer aux autres machines quel est le nom qu'elles doivent résoudre pour atteindre ce service. Par exemple, si la machine A cherche à partager sa bibliothèque iTunes sur le réseau, les autres machines vont recevoir comme message qu'elles peuvent se connecter sur `A.local` afin de se connecter sur la bibliothèque de la machine. Si ce domaine est utilisé comme domaine local pour le réseau interne, le serveur DNS risque de renvoyer A.local vers une autre machine que celle qui est annoncée par Zeroconf.
Les domaines `.home` et `.lan` n'ont jamais été réservés officiellement pour être utilisés pour un réseau local. Il y a eu une proposition - qui a été retenue si je ne me trompe pas -, pour que le domaine `.home.arpa`soit utilisé à la place pour un usage domestique.
Cependant, ce que ne dit pas l'article, c'est que la proposition de l'ICANN ne concerne pas uniquement les réseaux domestiques, mais bien l'utilisation d'un réseau local (RFC 1918) qui est également utilisé par les entreprises et, forcément, avoir `.home.arpa`pour le réseau local de son entreprise, ça peut prêter à sourire...
Je pense également que le domaine `.internal`a été choisi parce qu'une grande partie des entreprises ont choisi de créer le sous-domaine int.macompanie.fr pour désigner le domaine du réseau interne.
Peut-être que ce domaine permettra de corriger un comportement agaçant que je remarque dans l'utilisation des domaines exotiques `.home`et `.lan` : quand je note `livebox.home` dans Firefox ou Chromium, ces 2 navigateurs me renvoient dans une recherche Google. Je suis obligé d'écrire `livebox.home/`si je veux les forcer à se connecter sur ma Livebox...
Bref, tout ceci ne casse pas 3 pattes à un canard... Allez, à la bouffe !
Au taf on utilise un .lan, chez moi j’ai un un .local (avec volumio, c’est d’office). Certes, c’est pas normalisé.
Y’a déjà le .local, pourquoi ne pas l’utiliser ?
Après les extensions de domaine c’est pas un peu démodé ? Pourquoi ne pas les virer ? Ou créer le sien, genre ma.livebox, monnuméroclient.service ?
À ce qu’il paraît, on peut utiliser les accents aussi dans les domaines, mais force est de remarqué que personne n’a adhéré.
si si en 2018 ou 2019 une arnaque airfrance avec un domaine comme https://airfrạnce.fr/
*nottez le a de france avec un point juste en dessous qui correspond au charactère unicode (U+1EA1) (source: https://www.compart.com/en/unicode/U+1EA1)
Comme la plupart des navigateur et clients web ont tendances à souligner les liens web, beaucoups n'ont pas remarqué la supercherie et le site avait été copié en français et en anglais d'une façon très convaincante.
A mon avis c'est l'une des causes du pourquoi et du comment que les domaines avec charactères unicode ne sont pas très populaires... aussi certains ne savent pas ou ne sont pas capable d'écrire/taper les charactères spéciaux facilement.
source: https://professionvoyages.com/fraude-typosquattage-airfrance/
@gasova
D’accord, mais ça reste anecdotique, (l’utilisation, pas l’arnaque malheureusement…), surtout quand on voit que les gens ont tendance à préciser « tout en minuscule et sans accent » quand ils nous dictent leur adresse e-mail.