Noms d'hôtes - De quoi s'agit-il?

J'ai récemment été «forcé» de faire un travail d'administrateur système, alors que ce n'est pas quelque chose que j'aime absolument faire, j'ai lu, expérimenté et beaucoup appris.

Il y a un aspect fondamental de la configuration du serveur que je n'ai pas encore compris: les noms d'hôte .

Dans Ubuntu par exemple, définissez le nom d’hôte comme suit (selon la bibliothèque Linode ):

echo "plato" > /etc/hostname
hostname -F /etc/hostname

Fichier: / etc / hosts

127.0.0.1        localhost.localdomain        localhost
12.34.56.78      plato.example.com            plato

Je suppose que platoc'est un nom arbitraire et que plato.example.comc'est le nom de domaine complet.

Maintenant mes questions sont:

• Est-ce obligatoire?
• Dans quel but?
• Où est-il nécessaire / utilisé?
• Pourquoi ne puis-je pas définir "localhost" comme nom d'hôte pour chaque machine?
• Dois-je configurer une entrée DNS pour le plato.example.comnom de domaine complet?
• Devrait plato.example.comêtre utilisé comme entrée DNS inversée pour mon IP?

En outre, existe-t-il des "meilleures pratiques" pour choisir des noms d'hôte? J'ai vu des gens utiliser des lettres grecques, des noms de planètes et même des figures mythologiques ... Que se passe-t-il lorsque nous manquons de lettres / planètes?

Je suis désolé si cette question est idiote, mais je n’ai jamais été aussi enthousiasmée par les configurations réseau.

De nos jours, un système peut avoir plusieurs interfaces, chacune avec plusieurs adresses, et chaque adresse peut même être associée à plusieurs entrées DNS. Alors, que signifie même "nom d'hôte système"?

De nombreuses applications utilisent le nom d'hôte du système comme identifiant par défaut lorsqu'elles communiquent ailleurs. Par exemple, si vous collectez des messages Syslog sur un serveur central, tous les messages seront étiquetés avec le nom d'hôte du système d'origine. Dans un monde idéal, vous ignoreriez probablement cela (car vous ne voulez pas forcément faire confiance au client), mais le comportement par défaut - si vous appelez tous vos systèmes "localhost" - entraînerait une série de messages de journalisation ne serait pas en mesure de s'associer à un système spécifique.

Comme d'autres personnes l'ont souligné, le nom d'hôte du système est également un identifiant utile si vous vous trouvez en train d'accéder à distance à un certain nombre de systèmes. Si vous avez cinq fenêtres attachées à un système nommé "localhost", vous aurez du mal à les garder droites.

Dans le même ordre d'idées, nous essayons de faire en sorte que le nom d'hôte du système corresponde à celui que nous utilisons pour l'accès administratif à un système. Cela permet d'éviter toute confusion lors de la référence au système (courrier électronique, conversations, documentation, etc.).

Concernant le DNS:

Vous souhaitez disposer d'entrées DNS inverses et inverses appropriées pour vos applications afin d'éviter toute confusion. Vous avez besoin d' une entrée en aval (nom -> adresse IP) pour que les personnes puissent accéder facilement à votre application. La correspondance d’entrée inversée est utile pour un certain nombre de raisons - par exemple, elle vous aide à identifier correctement l’application si vous trouvez l’adresse IP correspondante dans un journal.

Notez que je parle ici d '"applications" et non de "systèmes" car, en particulier avec les serveurs Web, il est courant de posséder plusieurs adresses IP sur un système, associées à des noms d'hôtes et à des services différents.

Essayer de gérer les mappages de nom sur ip dans votre /etc/hostsfichier devient rapidement difficile car vous gérez un nombre croissant de systèmes. Il est très facile de désynchroniser le fichier des hôtes locaux par rapport au DNS, ce qui peut entraîner une confusion et, dans certains cas, un dysfonctionnement (par exemple, quelque chose tente de se lier à une adresse ip qui n'existe plus sur le système).

Vous pouvez définir chaque nom d’hôte sur "localhost", mais il est très pratique d’avoir alix@plato ~ $dans votre invite de commande lorsque vous gérez des machines sur ssh. La gestion des serveurs à distance peut devenir très déroutante si vous ne le faites pas.

Avoir un nom de domaine complet correct est important lorsque vous hébergez un serveur Web ou un serveur de messagerie. Ces types d’applications serveur aiment savoir "sur qui" elles tournent.

Pour choisir un bon schéma de nommage, je vous renvoie à cette question très populaire .

Un nom de domaine complet ne devient utile que lorsqu'il a un sens pour un autre ordinateur. Il y a trois niveaux à ceci:

• Un ordinateur de votre réseau local a une entrée dans son fichier hosts qui pointe vers cette machine.
• Vous avez un serveur DNS fonctionnant sur votre réseau local et chaque ordinateur local qui l'utilise comme serveur DNS connaît désormais plato par son nom.
• Vous enregistrez un nom de domaine et le monde entier sait maintenant sur quelle machine se trouve le nom plato.alixaxel.com.

Lorsque vous envoyez un courrier électronique ou que vous envoyez des pages Web au monde extérieur, le troisième est celui que vous souhaitez. Dans la plupart des autres cas, vous pouvez vous contenter d'un DNS local ou même éditer des fichiers hôtes.

Dans ce cas, vous pouvez simplement créer un nom de domaine (plato.alixnetwork peut convenir en tant que nom de domaine complet) à utiliser au sein de votre réseau local. La seule valeur ajoutée de la partie "alixnetwork" (le nom de domaine) est la commodité lorsque vous souhaitez distinguer un autre réseau local.

Un aperçu de base. Le nom d'hôte ne sont que des pointeurs. vous pouvez en affecter un spécifique au nom d’hôte référencé par la machine, mais il peut en avoir plusieurs. Certains services, notamment le courrier et HTTP, s'appuient sur des noms de domaine pour savoir où les services doivent être situés et comment y accéder.

Il y a longtemps, tous ces noms (qui, encore une fois, ne sont que des pointeurs vers des adresses IP) ont été conservés dans un fichier appelé hosts. Au fur et à mesure que le système se développait, ils ne pouvaient pas maintenir le fichier synchronisé sur tous les ordinateurs pertinents participant aux différents réseaux interconnectés. Le système DNS a donc été inventé. Lorsque vous effectuez une recherche de nom, il vérifie tout d’abord le fichier hosts, puis le système DNS. Windows peut également vérifier d'autres systèmes tels que WINS ou NetBIOS.

Lorsque vous mettez une entrée dans un hostsfichier, vous ne l'attribuez pas à l'ordinateur. L'affectation d'un nom d'hôte à celui utilisé par l'ordinateur est effectuée dans les fichiers de configuration (sur les systèmes * nix) et les propriétés système dans les systèmes Windows (le système Windows peut également comporter des suffixes spécifiques à la carte réseau).

Les entrées dans le hostsfichier, comme le système DNS, ne sont qu'un mappage d'un nom d'hôte à une adresse IP. Pour utiliser le nom d’hôte 'localhost' (il n’a rien de spécial, c’est un nom d’hôte comme tout le reste), il doit être mappé sur l’interface de bouclage (afin qu’il pointe toujours vers l’ordinateur local). Pour que cela fonctionne, tous les ordinateurs sont livrés avec ce mappage par défaut dans leur hostsfichier, mais celui-ci pourrait éventuellement être supprimé si vous ne souhaitiez pas pouvoir utiliser ce nom d'hôte.

De plus, comme d’autres l’ont noté, il est très utile d’attribuer un nom d’hôte à un ordinateur. Une fois connecté à l'ordinateur, vous pouvez lui demander d'afficher son nom d'hôte lorsque vous vous connectez ou sous forme d'invite, ou à un nombre quelconque d'autres emplacements. Cela facilite l'identification de l'ordinateur auquel vous êtes connecté. Si vous configurez ce nom d’hôte dans DNS ou si vous le placez dans tous les hostsfichiers, vous pourrez vous connecter à l’ordinateur en référençant son nom d’hôte au lieu de devoir connaître son adresse IP à tout moment. (Encore plus utile si l'ordinateur utilise DHCP, car l'adresse pourrait changer. Si l'ordinateur met à jour le DNS, l'enregistrement DNS pointera vers la nouvelle adresse IP; vous pourrez toujours vous connecter sans connaître la nouvelle adresse IP car vous connaissez le nom DNS. )

hostsSi vous lisez tout cela, il y a beaucoup d'autres utilisations des deux et du DNS, mais je suppose que vous avez plus de questions que de réponses.

Chaque hôte devrait recevoir un nom significatif. Le nom d'hôte peut servir à plusieurs fins:

1- Cela vous aide à reconnaître sur quoi vous travaillez actuellement.

2- Il /etc/hostsest plus facile d' utiliser des noms configurés dans et / ou des enregistrements DNS que de mémoriser de nombreuses adresses IP.

3- Localhost est un nom réservé pour faire référence à la machine actuelle (adresse 127.0.0.1).

4- Les enregistrements DNS sont utiles pour rendre vos serveurs accessibles au public.

Choisir un nom approprié pour chaque serveur vous aide beaucoup dans votre administration. En outre, cela aide vos clients à accéder à vos serveurs.

Remarque: une résolution DNS correcte et inversée est la pierre angulaire de toute installation informatique sur cette planète. Ne sous-estimez jamais la nécessité d'un DNS bien entretenu et d'une résolution correcte du nom d'hôte!

Avertissement: la question principale concerne les systèmes Linux, alors n'hésitez pas à ignorer cette réponse si le côté Windows du problème ne vous intéresse pas.

Quoi qu'il en soit, dans les systèmes Windows, mis à part tous les points mentionnés dans d'autres réponses, le nom d'hôte est réellement utilisé par le système d'exploitation lui-même, à des fins de mise en réseau et d'authentification; Plus précisément:

• Chaque système, membre ou non du domaine, doit avoir un nom unique sur le même réseau (c'est-à-dire dans le même sous-réseau IP), sinon un conflit de dénomination s'ensuivra et divers services réseau (principalement le partage de fichiers et d'impression) ne travail.
• Tous les systèmes membres du même domaine Active Directory doivent avoir un nom unique, quelles que soient les limites du réseau.
• Dans un environnement de domaine, le nom d'hôte d'un système agit comme une entité de sécurité et peut être utilisé pour l'authentification à distance (il suffit de le considérer comme un compte d'utilisateur pour la machine). des autorisations et des droits d'accès peuvent lui être attribués et placés dans des groupes à des fins de sécurité. Cela concerne tous les processus exécutés sur le système à l'aide des comptes utilisateur LocalSystemet intégré NetworkService, qui peuvent s'authentifier auprès d'autres systèmes à l'aide des informations d'identification du système sur lequel ils s'exécutent. Cela permet, par exemple, à un processus exécuté sous NetworkServiceSystemA d'accéder à un dossier partagé sur SystemB en accordant des autorisations sur le dossier au compte d'utilisateur de SystemA.

De nombreux sites et / ou supposés "administrateurs" déclarent maintenant que l'attribut "hostname" contient le nom de domaine complet de l'instance de système d'exploitation, ce qui "casse" toute résolution qui y ajoute le "domainname":

nomhôte
system1.domain1.org

ping hostname
- ne peut pas résoudre system1.domain1.org.domain1.org