Por que não atribuir o nome do host ao endereço de loopback em / etc / hosts?

Question

Então eu entendo que o nome do host deve (pelo menos nos sistemas Debian) ser configurado em /etc/hostname . Para obter o FQDN (por meio de hostname -f ), o sistema localiza o IP do nome do host por meio de /etc/hosts e, em seguida, retorna a primeira entrada na linha.

Portanto, se o nome do host for server1 e isso estiver em /etc/hosts :

192.0.2.1    server1.example.com    server1

Ele retornará server1.example.com . Então é assim que é descrito em muitos sites. Mas eu estava pensando: por que não atribuir o nome do host ao endereço de loopback? Como você faz com localhost :

127.0.0.1    server1.example.com    server1    localhost

Com essa abordagem, você não precisa saber o endereço IP externo. Além disso, os aplicativos que podem usar o FQDN farão as solicitações diretamente no sistema, em vez de passarem pela rede.

Então, por que não fazer assim? Por que a maioria dos exemplos na internet usa o endereço IP externo?

    

Answer 1

poderia ser uma má ideia, por várias razões

• se você tiver um ip (e se comunicar com outros hosts), é altamente recomendado colocar o nome do host na frente do ip externo conhecido.

  • Alguns protocolos podem dizer "diga ao outro cara seu hostname e seu endereço ip" "ok. Outro cara, eu sou foo.localnetwork (127.0.0.1)". O outro indivíduo receberá este pacote com, no nível de IP, o IP externo, mas no nível do Protocolo, o IP 127.0.0.1, portanto, pode ser difícil trocar se esse protocolo precisar usar as informações anunciadas, em vez do IP nível ones (SIP, por exemplo, é provável que seja problemático com isso ...)

  • Além disso, alguns serviços ligam apenas na interface que contém o ip associado ao nome do host e, portanto, esses serviços só poderão falar com o host, via dispositivo de loopback, ninguém mais ...

Answer 2

Este é o padrão, pelo menos em novos lançamentos do Ubuntu.

Aqui está minha configuração /etc/hosts :

127.0.0.1   localhost.localdomain localhost
127.0.1.1   sprinkler.internal.lan sprinkler

Não é problemático de forma alguma e, de fato, tem o efeito bônus de não precisar de um DNS funcional para algumas operações.

Pessoalmente, tenho a tendência de adicionar mais algumas entradas, como o repositório de apt local, alguns construtores, etc.