O arquivo Hosts no Mountain Lion parou de funcionar repentinamente

Eu usei meu arquivo de hosts (localizado em / private / etc / hosts) por vários meses para bloquear sites que causam distrações durante o dia de trabalho. Isso funcionou bem até agora. Hoje de repente parou de funcionar.

Algumas linhas de amostra do arquivo hosts:

127.0.0.1 facebook.com
127.0.0.1 www.facebook.com

Coloquei esse texto no arquivo hosts pelas seguintes etapas:

sudo nano / etc / hosts
escreveu as linhas acima, depois ^ O para gravar o arquivo, Enter para confirmar o nome do arquivo e ^ X para sair do editor.

Entre o IP do host local e o nome do domínio, tenho uma guia. As terminações de linha são do estilo Unix (LF), e a parte estranha é que, quando eu uso o pingcomando, ele parece fazer seu trabalho corretamente:

ping facebook.com
PING facebook.com (127.0.0.1): 56 bytes de dados
64 bytes de 127.0.0.1: icmp_seq = 0 ttl = 64 time = 0.137 ms
64 bytes de 127.0.0.1: icmp_seq = 1 ttl = 64 time = 0.122 ms
64 bytes de 127.0.0.1: icmp_seq = 2 ttl = 64 time = 0.118 ms
64 bytes de 127.0.0.1: icmp_seq = 3 ttl = 64 time = 0.110 ms
^ C
--- facebook.com ping statistics ---
4 pacotes transmitidos, 4 pacotes recebidos, perda de pacote de 0,0%
ida e volta min / avg / max / stddev = 0,110 / 0,122 / 0,137 / 0,010 ms

Mas quando tento acessar o facebook.com no Safari ou Firefox, ainda consigo acessar o site. Esse também é o caso de outro site bloqueado de maneira semelhante. Esvaziei o cache dos dois navegadores, mas isso não resolveu o problema.

O que posso fazer para resolver este problema?

Atualização 1: agora estou verificando todos os sites que bloqueei dessa maneira e descobri que o comportamento não é consistente em diferentes domínios. Estes são os "desperdiçadores de tempo" que estou bloqueando em / private / etc / hosts:

#Block time-killers
127.0.0.1 9gag.com
127.0.0.1 flabber.nl
127.0.0.1 geenstijl.nl
127.0.0.1 dumpert.nl
127.0.0.1 facebook.com
127.0.0.1 www.9gag.com
127.0.0.1 www.flabber. nl
127.0.0.1 www.geenstijl.nl
127.0.0.1 www.dumpert.nl
127.0.0.1 www.facebook.com
##

Todos os sites desta lista ping para 127.0.0.1, no entanto 9gag.come flabber.nlsão inacessíveis por qualquer navegador, mas geenstijl.nl, dumpert.nle facebook.com são acessíveis.

Eu tentei reiniciar, isso não resolveu o problema. Antes desse problema, não alterei a configuração do sistema por uma atualização de algum tipo.

Atualização 2: Três horas atrás, eu podia acessar facebook.compelo Safari e Firefox, agora não posso mais. geenstijl.nle dumpert.nlainda são acessíveis. Não mudei nada nas últimas três horas, apenas usei o Word e naveguei na web com o Safari.

Atualização 3: agora, quatro horas após a segunda atualização, o arquivo hosts volta a funcionar normalmente. No processo de me atrapalhar com o arquivo hosts, removi as entradas que não funcionavam e as adicionei uma a uma, testando cada uma depois que foram adicionadas. Não tenho idéia do que estava acontecendo e não consigo mais executar o wireshark no trânsito, pois não há comportamento defeituoso que possa observar.

Atualização 4: E o problema está de volta. Os mesmos sites da atualização 1 mostram o comportamento incorreto.

Atualização 5:
Tudo funciona novamente como deveria. Manterei as soluções postadas aqui em mente quando encontrar o erro novamente.

A resolução de DNS no OS X deu errado na atualização do Snow Leopard para o Lion. Após uma instalação limpa, tudo deve funcionar corretamente, mas se você seguiu a rota de atualização, as coisas podem ficar complicadas.

Opção 1: endereçamento IPv6

Muitos sites e provedores de Internet suportam IPv6 se o IPv4 estiver inacessível. Coloque as definições no início da /etc/hostsseguinte maneira:

# Block Facebook IPv4
127.0.0.1   www.facebook.com
127.0.0.1   facebook.com

# Block Facebook IPv6
fe80::1%lo0 www.facebook.com
fe80::1%lo0 facebook.com

Opção 2: Use DNSMasq

Se o conselho anterior falhar, você poderá instalar o DNSMasq .

Após qualquer alteração, /etc/hostsexecute dscacheutil -flushcachena linha de comando para limpar o cache DNS local. Isso funciona para mim todas as vezes, com uma exceção: o Firefox tem seu próprio cache DNS, então você terá que reiniciá-lo.

O sistema OSX não usa / etc / hosts para a maioria de suas operações de rede. Na maioria das vezes, os comandos terminal / linha de comando (material do Unixy) usam / etc / hosts, enquanto qualquer coisa Maccy (!) Usa as tabelas internas do tipo plist mantidas em outro local.

O uso não é consistente e problemático porque torna o OSX "unix" não determinístico. Como você descobriu.

Não tenho mais um mac para descobrir exatamente onde o Mac OSX armazena sua emulação do arquivo hosts, mas espero que essa informação o direcione na direção certa.

Eu sei que ele estará no diretório / Library (e / ou ~ / Library), e os arquivos plist estão compactados, então você não pode simplesmente esperar por coisas. Hum, o comando 'plutil' pode descompactar / exibir o conteúdo dos arquivos .plist (acho que esse é o nome). Talvez comece com um

find ~/Library /Library -iname "*host*" -ls

para ver o que está escondido naquele pântano de complexidade parecida com janelas.

Não é exatamente unix (netbsd) ... mas não é exatamente ... como quer que você possa chamar (GUI?). Até o Windows é consistente. Talvez errado ... mas consistente.

Apenas adicionando outro pedaço de vodu aqui. As entradas de meus hosts no 10.8.2 foram completamente ignoradas pelo sistema até .

1. Mudei minhas entradas para o topo do arquivo

2. Usei uma única guia para separar o endereço IP e o nome do host

3. Eu joguei um $ dnscacheutil -flushcachesó por segurança

Eu não me aprofundei no porquê disso acontecer, apenas transmitindo o ritual que o resolveu para mim.

Eu descobri que no OS X 10.9 o Safari e o Firefox continuavam acessando os domínios bloqueados até que eu implementasse os blocos IPv6 no arquivo etc / hosts. Somente o Chrome foi afetado pelos bloqueios do IPv4.