¿Debe / etc / hosts contener una entrada como '127.0.0.1 localhost myhost.example.org myhost'?


16

Al observar una variedad de sistemas Linux y FreeBSD, noté que en algunos sistemas /etc/hostscontiene una entrada para el nombre de host público del host, pero no en otros sistemas.

¿Cuál es la mejor práctica aquí? ¿Mi archivo / etc / hosts debe contener una entrada para el FQDN de los hosts (por ejemplo, myhost.example.org) y para el nombre de host corto (por ejemplo, myhost)? ¿Debería el registro del FQDN apuntar al localhost o debería apuntar a la IP externa de la caja?

Por ejemplo, la configuración predeterminada en muchos cuadros RHEL / EL no pone el nombre de host público en /etc/hosts:

myhost # cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
myhost #

La otra variante es que el nombre de host corto del host y el FQDN también apuntan a 127.0.0.1. Me han dicho que esta es una práctica más antigua que está mal vista en estos días, pero muchos administradores aún hacen esto.

myhost # cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 myhost myhost.example.org
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
myhost #    

La tercera variante es que el FQDN de los hosts y el nombre de host corto reciben la dirección IP externa del host. Esta tercera variante me parece óptima porque reduce las búsquedas en los servidores DNS.

myhost # cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
74.125.239.xxx myhost myhost.example.org
myhost #  

¿Cuál es la mejor práctica aquí?


2
se reduce a qué alias están usando los programas (para ex gustos / necesidades de Mysql para tener un alias 'localhost'), 127.0.0.1 localhost myhostdebería ser suficiente y, 74.125.239.xxx myhost myhost.example.orgcomo dijiste, guarda las búsquedas de DNS. La "mejor práctica", a menos que haya un estándar, es "lo que usan las personas con conocimientos".
LinuxDevOps

Respuestas:


12

¿Está dispuesto a aceptar el DNS en funcionamiento como un punto de falla en su entorno o no? Algunos servicios / aplicaciones fallarán en ciertas configuraciones si un sistema no puede resolver el nombre de la máquina local.

Si tiene un servicio absolutamente crítico que debe estar ejecutándose en todas las situaciones, no es inusual agregar una entrada en el archivo de hosts para que el servicio pueda continuar operando en la situación donde falla la resolución de DNS.

Si puede aceptar su DNS como un punto de falla, o si sus servicios no fallan en el caso de una resolución rota, se pueden evitar las entradas de configuración en el archivo de hosts.

Le sugiero encarecidamente que haga que sus servidores DNS sean lo más sólidos posible, y si debe configurar su archivo de hosts, use un sistema de administración de configuración para hacerlo. Realmente debe evitar manualmente evitar tocar un archivo de hosts.


13
Solo para agregar a esto, en la mayoría de los casos /etc/hostsreemplazará a DNS, no se utilizará como reserva en caso de una falla de DNS. Esta es una distinción que creo que debería hacerse. (No tratando de molestar). Todo depende del orden definido en /etc/nsswitch.conf.
Aaron Copley

44
El otro problema es que consultar los servidores DNS es mucho más lento que consultar el /etc/hostsarchivo. Muchas aplicaciones consultan su nombre de host una y otra vez, varias veces por segundo. Agregar el nombre de host a /etc/hostsreducirá la latencia y debería acelerar la aplicación.
Stefan Lasiewski
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.