O arquivo / etc / hosts do OS X 10.10.1 e / private / etc / hosts estão sendo ignorados e não estão sendo resolvidos

Como o título diz, executando o x 10.10.1. se eu tiver uma entrada no meu arquivo hosts e fizer um digou nslookupainda mostrar um IP diferente do que está no meu arquivo hosts, mesmo depois de tentar liberar vários caches.

Eu tentei o seguinte ..

1. limpe os caches de mdns e udns executando:
   1. sudo discoveryutil mdnsflushcache;
   2. sudo discoveryutil udnsflushcaches;
2. liberar cache usando dscacheutil -flushcache
3. recarregar o discoveryd.plistarquivo
   1. sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
   2. sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist

meu arquivo hosts fica assim ..

% cat /private/etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##

127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0 localhost
166.78.60.102   admin.devsite1.com

/ private / etc / hosts parece estar funcionando normalmente para mim no Yosemite (versão 10.10.1). Não é necessário liberar o cache ou redefinir discoveryd(o resolvedor DNS no Yosemite); sudo fs_usage | grep private/etc/hostsmostra a discoverydleitura do arquivo imediatamente após salvar as alterações.

[Atualização: discoverydfoi usada apenas no OS X versões 10.10.0 - 10.10.3. Nas versões anteriores e posteriores, mDNSResponderfornece a mesma função ... e também nota imediatamente alterações no / etc / hosts.]

No entanto, dig, nslookup, e hostnão verá entradas nele porque desvio resolvedor do sistema e fazer pesquisas de DNS matérias. Eles sempre fizeram isso, então isso não é novidade em Yosemite. A maneira "oficial" de fazer uma pesquisa através do resolvedor do sistema no OS X é usar dscacheutil:

dscacheutil -q host -a name www.example.com

... mas como isso é dolorosamente detalhado, costumo usar apenas ping(e depois olhar para a primeira linha, onde ele lista qual IP está executando o ping). A partir do 10.9, você também pode usar a guia Pesquisa do Network Utility (antes disso dig, e, portanto, ignorou a política de pesquisa do sistema).

BTW, por favor, não preste atenção ao thread de macrumores que Tetsujin vinculou; está cheio de pessoas que não sabem o que estão fazendo e estão entendendo mal os resultados de seus próprios erros.

Eu descobri outra ruga com esse problema.

Para corrigir o problema que eu estava tendo, tive que adicionar entradas de arquivo de hosts no estilo IPv6.

Parece que o Safari ignorará as entradas IPv4 SE você tiver uma configuração de rede IPv6.

Você deve adicionar entradas duplicadas que resolvam para o endereço de host local IPv6 em / etc / hosts.

Entrada IPv4 127.68.56.101 facebook.com

por exemplo, entrada IPv6 fe80::1%lo0 facebook.com

etc.

Meu arquivo de hosts continuou sendo ignorado depois que eu editei na edição de texto. Tentei várias maneiras de corrigir as terminações de linha, adicionei entradas IPv6 às entradas existentes IPv4 sem êxito, seguindo a resposta de JB Smiths acima . Eu suspeito que a resposta dele funcionaria se minha empresa oferecer suporte ao IPv6, que eu descobri após minhas tentativas.

A única solução que funcionou para mim é usar este plug-in gratuito da GUI para editar o arquivo hosts.

https://github.com/specialunderwear/Hosts.prefpane/blob/master/README.mdown

Encontrei este artigo porque o Yosemite 10.10.5 não estava captando as alterações no arquivo hosts e nada que eu pudesse fazer foi corrigi-lo. (Reinicializei, tentei liberar caches, segui todos os conselhos que pude encontrar na internet etc etc).

A resposta foi tão simples que é constrangedora, na verdade, mas pensei em compartilhar. Eu usei o textedit para editar o arquivo hosts, e ele teve a liberdade de salvar o arquivo como hosts.txt. Normalmente, eu notaria algo assim, mas estou usando uma nova instalação do Yosemite e ainda não havia ativado "mostrar todas as extensões de arquivo", para que não parecesse que o nome do arquivo havia mudado quando o vi na área de trabalho.

Portanto, é meio óbvio, e a maioria das pessoas que está lendo esta postagem provavelmente já fez isso, mas verifique se o seu arquivo hosts está realmente lá e não foi substituído pelo hosts.txt .

Para ativar a exibição de extensões de nome de arquivo, vá para Finder> Preferências> Mostrar todas as extensões de nome de arquivo

Para impedir que o TextEdit adicione extensão .txt aos arquivos, abra um arquivo na edição de texto e escolha Arquivo> Salvar como (se você não vir o item de menu Salvar como , mantenha pressionada a tecla de opção depois de clicar em Arquivo e Salvar como deve aparecer no menu). Procure a opção Se nenhuma extensão for fornecida, use ".txt" e desmarque-a.

Acredito que a Apple reconhecerá isso como um bug (enviei um hoje). Notei que novas entradas /etc/hostssão selecionadas, mas as alterações nas entradas existentes são ignoradas. Então .... alterar o nome do host de uma entrada (por exemplo, web1 para web1a) forneceu uma solução alternativa para mim.

Entrada OLD / etc / hosts: 54.173.164.18 web1

Entrada NOVA / etc / hosts: 54.174.161.12 web1a

No meu caso, eu configuraria um arquivo .ssh / config

#Host *.ourdemo.ca
  User jumpy
  ProxyCommand ssh ourjumpbox.ca -W %h:%p

Eu tive um problema muito semelhante no qual recebi por correio duas linhas a serem adicionadas ao meu /etc/hosts

O domínio continha um -likemy-domain.com

O problema acabou sendo o cliente de email do remetente - não importa dizer, o MS Outlook - que converteu os ascii -no longo -caractere que a Microsoft adora tanto usar sua correção automática incorporada para substituí-los pelos -deles -.

O arquivo hosts parecia perfeito e era difícil encontrar esse problema. Quando apaguei as linhas e as escrevi manualmente, elas começaram a funcionar.

Era tão difícil entender isso, que eu expliquei profundamente por que o cliente MacOS deveria ignorar o arquivo hosts e pular diretamente para a resolução de nomes.

Só tive esse problema. Isso foi causado por copiar / colar do hipchat em vez de escrever o endereço.

O processo de cópia adicionou caracteres incorretos em vez de espaços e causou o problema.

Reescrever a linha resolveu o problema.

Estou usando o aplicativo SelfControl (na verdade no macOS mojave 10.14.4) há algum tempo e descobri como o SelfControl faz suas entradas ... elas se parecem com isso:

0.0.0.0 xyz.com
:: xyz.com
0.0.0.0 www.xyz.com
:: www.xyz.com

com base nisso, mudei tudo para meu host local, então

127.0.0.1
::1

trabalho.