Pedido de pesquisa de DNS do Mac OSX Lion [fechado]

Depois de atualizar para o Mac OSX Lion, descobri que / etc / hosts não é mais procurado em primeiro lugar para resolução de nomes. Isso leva a alguns efeitos colaterais como:

1. As entradas em / etc / hosts são resolvidas de forma dolorosamente lenta
2. Você não pode substituir os domínios existentes, por exemplo, 127.0.0.1 www.google.com
3. Se você obtiver entradas de domínio de pesquisa do DHCP, digamos .lan, e algum cara engraçado configurou localhost.lan para algo diferente de 127.0.0.1 no DNS local, você não pode mais acessar seu localhost.

Este comportamento é intencional? Isto faz algum sentido? E o mais importante, como posso voltar ao antigo comportamento.

Acho que importa se o Lion lida com o TLD .local de maneira diferente porque ele é reservado para alguns recursos DNS multicast (usados ​​por Bonjour). A única maneira que encontrei de resolver esse problema é usar um TLD diferente para hosts de desenvolvimento (ou seja: .dev). Funciona bem para mim, espero que seja útil para os outros!

Com relação à substituição de domínios no arquivo hosts, descobri que, em algumas circunstâncias, Lion consulta o endereço IPv6 de um domínio se sentir que um domínio não pode ser alcançado pela rede IPv4.

Descobri isso quando notei alguns anúncios que nunca tinha visto antes no Snow Leopard porque redirecionei os domínios de anúncios para 127.0.0.1. Eu ativei o wirehark e notei AAAA(registros DNS IPv6) consultas seguindo as Aconsultas IPv4 (IPv4). Os servidores de anúncios realmente têm endereços IPv6 e foram capazes de me servir seu conteúdo.

A solução para isso é ter um

::1 mydomain.com

entrada para cada

127.0.0.1 mydomain.com

entrada em seu arquivo hosts.

Curiosamente, se acontecer de você ter um servidor da web local em execução 127.0.0.1:80e seu navegador receber uma resposta do servidor da web (erro ou outro), nenhuma AAAAconsulta será emitida, pois parece que uma conexão TCP foi pelo menos possível.

Em uma observação relacionada, se você faz uso intenso do arquivo hosts (para adblocking, desenvolvimento local da web, etc), você pode querer executar seu próprio resolvedor DNS local. Há um impacto considerável no disco / CPU por ter que ler /etc/hostscada solicitação, portanto, é do seu interesse manter esse arquivo bem leve.

Uma vantagem de executar algo como dnsmasqlocalmente (além do aumento significativo de desempenho) é que você pode redirecionar domínios de nível superior inteiros de volta para sua máquina local. Isso permite que você tenha todo o namespace * .dev para desenvolvimento (por exemplo), sem ter que inserir individualmente cada domínio em que deseja resolver localmente/etc/hosts

O problema é que criei um link simbólico para o arquivo / etc / hosts. Se / etc / hosts for um arquivo simples, está tudo bem.

Atualização (2): OSX 10.10.5 traz o retorno de mDNSResponder.

Atualização: OSX 10.10 Yosemite substituiu mDNSResponder por "discoveryd". Não atualizei, então não tenho certeza do comportamento do discoveryd com pesquisas de DNS e /etc/hosts.

O resolvedor de DNS do sistema no Lion é o mDNSResponderprocesso.

Você pode estar pensando "mas mDNSResponder é o respondedor dns multicast". Você está certo; era para isso que servia originalmente e ainda cumpre essa função. No entanto, nas versões mais recentes do MacOS, ele também faz pesquisas de host padrão.

No Lion, não parece reler automaticamente /etc/hostsquando muda, pelo menos não sempre. Matar mDNSResponder(e permitir que seja reiniciado automaticamente) parece resolver o problema.

sudo killall mDNSResponder

deve fazer o truque.

abaixo está minha resposta original para a posteridade. Suponho que ainda possa ser um problema em alguns casos.

Certifique-se de que seu /etc/hostsarquivo seja um arquivo de texto no estilo Unix, com alimentações de linha no final ao invés de cr.

A edição com TextWrangler ou um editor de texto unix deve preservar o arquivo.

Se o seu arquivo já estiver bagunçado, tente isso para corrigir

tr '\015' '\012' < /etc/hosts > /tmp/hosts.$$
mv /etc/hosts /etc/hosts.bad
mv /tmp/hosts.$$ /etc/hosts
# fix up permissions while we are at it
chown root:wheel /etc/hosts
chmod 644 /etc/hosts

crédito para esta correção em:

http://techpatio.com/2011/guides-how-to/fixed-mac-osx-lion-etc-hosts-bugs-dns

Eu tive esse problema por um tempo, como estou trabalhando com uma equipe de desenvolvedores, tornou-se necessário usar .local em vez de .dev ou .localhost, achei este artigo muito útil.

iTand.me - Domínios locais do Leão e hosts etc.

Em suma;

Mas se você tiver que usar .local, a solução mais elegante que encontrei é o utilitário dscl. Usá-lo é muito simples. Para adicionar um host chamado mydev.local e apontar para o localhost, basta fazer o seguinte:

sudo dscl localhost -create /Local/Default/Hosts/mydev.local IPAddress 127.0.0.1

Para ver todos os hosts definidos atualmente e seus IPs

sudo dscl localhost -list /Local/Default/Hosts IPAddress

E para remover um host:

sudo dscl localhost -delete /Local/Default/Hosts/mydev.local

No geral, é bastante simples e funciona bem. Ainda preferiria poder editar / etc / hosts, mas essa é uma alternativa melhor do que renomear todos os nossos servidores .locais.

Antes de mudar do Snow Leopard para o Lion, eu tinha várias entradas específicas do aplicativo /etc/hosts, como esta:

127.0.0.1 foo.bar.local

Após a atualização, o carregamento dos meus aplicativos locais ficou MUITO lento. Percebi que o atraso aconteceu antes que a solicitação aparecesse no arquivo de log e que, depois que isso aconteceu, o próprio aplicativo ficou tão rápido como de costume.

Agora tenho duas linhas por aplicativo, assim:

127.0.0.1 foo.bar.local
::1       foo.bar.local

... e tudo é rápido novamente.

Aparentemente, isso adiciona endereços IPv6? Eu não entendo muito bem, realmente, mas funciona.

Minha situação era parecida, mas os atrasos, de exatamente 5 segundos, só aconteceram para URLs terminados em '.local'. Ao visualizar sites que terminavam em '.dev', não houve atraso.

Alguns dos outros desenvolvedores em meu escritório tiveram esse problema, enquanto alguns não. Eu esperava uma solução simples e não queria renomear o site para '.local' devido a outras dependências.

Executei o seguinte comando no Terminal e verifiquei minha saída com alguns outros usuários no escritório.

scutil --dns

Esta seção era a única diferença:

resolver #2
  domain   : 00000000.members.btmm.icloud.com
  options  : pdns
  timeout  : 5
  order    : 150000

Meu Mac estava vinculado à minha conta iCloud e eu tinha o Voltar ao Meu Mac ativado. Assim que desativei o Voltar ao Meu Mac, o resolvedor adicional foi embora e o atraso de 5 segundos desapareceu.

Uau, que pesadelo. Eu li absolutamente tudo sobre esse assunto e tudo o que foi sugerido até agora foi tentadoramente próximo ao que eu estava experimentando, mas nenhuma das soluções funcionou para mim.

E descobri o porquê.

Ao contrário de outros, eu não estava usando / etc / hosts para configurar domínios locais. Meu arquivo / etc / hosts estava em estoque, contendo apenas as entradas necessárias para a interface de loopback e o host de transmissão. Além disso, era um arquivo unix codificado corretamente, já que sou o tipo de pessoa que só edita isso na linha de comando usando emacs. E, graças a Deus, não precisei recorrer à execução de meu próprio servidor DNS, como o DNSmasq, para contornar o problema.

(Para ser claro, o sintoma que me trouxe aqui a este problema foi que o emacs demorou cerca de 10 segundos para iniciar, mas apenas quando eu estava em wi-fi. Se eu desligasse o wi-fi, o emacs iria iniciar instantaneamente como esperado.)

Minha solução: meu laptop tem um nome, "terminador". (Sim, seu exterior de alumínio brilhante me fez pensar no personagem Arnold Schwarzenegger.) Eu só precisava adicionar entradas em / etc / hosts para o nome da própria máquina:

127.0.0.1   terminator
::1         terminator

Encontrei o nome do meu host executando um comando simples no terminal:

hostname

... que voltou com a saída: "terminator". Depois de alterar / etc / hosts para conter essas duas entradas, o emacs agora pode resolver rapidamente o nome do meu laptop.

Espero que isso ajude alguém.

Tive problemas de velocidade ao usar o OSX Lion como caixa de desenvolvimento web ... Usando uma combinação de sugestões, recorri à desativação da rede ipv6 e ao roteamento do ipv6 para localhost6 ... as coisas ficaram um pouco mais rápidas ...

sudo networksetup -setv6off Ethernet

/ etc / hosts ...

127.0.0.1    localhost
127.0.0.1    dev.aliasdomain.com
... 
::1          localhost6 

Acho que houve algumas correções de bugs. Já vi muitos problemas serem mencionados e nenhum deles parece se aplicar atualmente (por exemplo, colocar vários aliases em uma única linha agora funciona bem para mim).

De qualquer forma, parece que com o Lion, a Apple fez algumas mudanças drásticas no mDNSResponder, que lida com todas as pesquisas de DNS e (pelo menos com o Lion) também lida com o cache de / etc / hosts. Para mim, as pesquisas futuras também funcionam agora. Mas as pesquisas reversas (por exemplo, pesquisar 1.2.3.4 em vez de google.com) não funcionam.

Depois de muita dor, parece que mDNSResponder converte esta pesquisa para 4.3.2.1.in-addr.arpa e faz uma pesquisa de nome. Pode muito bem ser assim que o DNS prefere operar, mas não funciona de forma alguma com / etc / hosts.

A menos, é claro, que você adicione um alias de 4.3.2.1.in-addr.arpa para cada host, onde 4.3.2.1 é o endereço IP na ordem oposta à qual você está acostumado a vê-lo. Isso resolve tudo para mim. Aqui está um exemplo de entrada / etc / hosts:

1.2.3.4 foo foo.example.com alias.example.com 4.3.2.1.in-addr.arpa