Quand utiliser .local?

Donc, j'ai mis en place quelques Win Servs dans mon temps et j'ai toujours fait la chose .local quand il y avait un routeur qui séparait mon interne des réseaux externes. Maintenant que j'installe une boîte * nix pour la première fois, ce concept s'applique-t-il toujours? Dois-je toujours que mes noms de domaine complets ( /etc/hostname) affichent .local ou .com pour toutes mes machines (mixtes: serveurs linux, stations de travail gagnantes) à l'intérieur de mon réseau.

Cette question s'inscrit dans le contexte où Active Directory me tient toujours la main à chaque étape du processus, où maintenant je configure manuellement une machine DNS.

Comme @Zoredache l'a souligné, l' .localespace de noms n'a pas de statut officiel (le plus proche que vous trouverez est .localhostdéfini et réservé dans la RFC 2606 ). En conséquence .local, ne devrait jamais être utilisé, car l'ICANN pourrait un jour attribuer ce TLD à quelqu'un.
La bonne chose à faire est d'enregistrer un domaine de votre choix example.comet de lui attribuer des noms d'hôte (peut-être sous internal.example.com) selon le cas.

Cela étant dit, si vous voulez utiliser .localou .lanque le domaine de premier niveau pour vos hôtes internes que vous ne serait certainement pas seul, et à ce moment la probabilité de toute personne essayant d'usurper .local, .lanou .privateest assez faible: Ils sont utilisés de façon pervasively que essayer de corriger les décennies de méchanceté ne valait pas la peine d'être combattu.
Notez cependant que ces machines et noms ne doivent pas être accessibles depuis (ou exposés de quelque manière que ce soit) à Internet public. C'est un moindre péché, similaire à l'émission d'adresses réseau RFC-1918 sur vos interfaces publiques, et des gens comme moi vous désapprouveront en public et se moqueront de vos fuites d'informations réseau en privé.

Notez également que les machines * nix n'ont pas vraiment de concept de "domaine" au sens Active Directory du terme - l'analogue le plus proche serait les domaines NIS, qui ne sont pas liés au DNS comme AD.
Un système nu * nix ne connaît vraiment que son propre nom d'hôte personnel, qui n'a pas besoin d'être un nom de domaine complet ( aliceest tout aussi valide que alice.wonder.lan), bien que par convention de nombreux administrateurs utilisent le nom DNS complet de la machine comme nom d'hôte.
Cela vous empêche d'utiliser des noms de domaine "non officiels" comme .local, mais à mon humble avis, c'est moins "correct" que d'avoir un nom de domaine valide, attribué et pleinement qualifié comme nom d'hôte de votre système.

Ce n'est pas encore officiel, mais il pourrait tout aussi bien être donné son ubiquité: .local est utilisé pour la résolution de nom de lien local dans le DNS multicast :

Ce document spécifie que le domaine DNS de niveau supérieur ".local". est un domaine spécial avec une sémantique spéciale, à savoir que tout nom complet se terminant par ".local". est link-local, et les noms dans ce domaine n'ont de sens que sur le lien d'où ils proviennent. Ceci est analogue aux adresses IPv4 dans le préfixe 169.254 / 16, ou aux adresses IPv6 dans le préfixe FE80 :: / 10, qui sont des liens locaux et qui n'ont de sens que sur le lien d'où elles proviennent.

Vous trouverez que les produits Apple et les distributions Linux modernes exécutant Avahi utiliseront .local de cette manière avec une configuration nulle. Sur mon propre réseau, j'en ai profité et j'ai arrêté de maintenir une zone DNS locale, car nous utilisons pratiquement exclusivement Linux et OS X - Bonjour pour Windows rempli dans le dernier espace vide pour les machines Windows.

Si vous devez réellement maintenir une zone DNS, je vous recommande de créer un sous-domaine d'un domaine que vous avez enregistré (par exemple, lan.example.com) et d'utiliser le DNS à horizon partagé pour résoudre le domaine local en interne. Sans même un brouillon Internet à citer, il est difficile de justifier la recommandation continue de Windows d'utiliser le domaine .local.