DNS não resolvendo no Mac OS X

Alguns dos meus colegas de trabalho estão tendo problemas em seus Macs - a resolução do DNS não funciona no Mac OS X. Eles estão executando o Snow Leopard 10.6.8. Eles podem usar o DNS em uma máquina virtual Windows 7 (VMware Fusion 3.1.3) em execução no OS X. Os computadores são MacBook Pros de 15 ", modelo do início de 2011.

Coisas que eles tentaram que não funcionaram:

• ligar / desligar o aeroporto
• reiniciando
• usando conexão com fio em vez wifi
• excluir credenciais de conexão e adicioná-lo novamente
• desativando o firewall do Mac
• usando IP estático fixo
• configurando manualmente servidores DNS
• reiniciando o mDNSResponder
• as correções dessa outra pergunta

Resposta EDIT resposta de Martín:

• Você pode executar ping no DNS que deseja usar?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

• Quais são os endereços IP do (s) DNS (s) que você deseja usar?

Este é um servidor DNS da empresa fornecido com o DHCP, que funciona bem para outras pessoas. Eu também tentei o 8.8.4.4 e o 205.171.3.65 do Google (que achei do DNS Benchmark da GRC o mais rápido).

• Você já tentou usar o 8.8.8.8 (google) ou qualquer um dos OpenDNS 208.67.222.222 ou 208.67.220.220?

Não funciona, veja a saída do Google Chrome:

Não foi possível encontrar o servidor em www.apple.com porque a pesquisa de DNS falhou. DNS é o serviço de rede que traduz o nome de um site em seu endereço na Internet. Esse erro geralmente é causado por não haver conexão com a Internet ou uma rede mal configurada. Também pode ser causado por um servidor DNS que não responde ou por um firewall que impede o Google Chrome de acessar a rede.

• Você pode executar ping os anfitriões?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

• criando um usuário em branco

Uma conta de usuário convidado foi criada, o problema de DNS ainda estava lá ao usar a conta de convidado.

• nslookup e dig ambos funcionam bem

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

• também foi realizada a limpeza do cache DNS, mas não ajudou

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDIT 2 :

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222

Acontece que a solução foi devolver o mDNSResponder:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Isso foi obtido por um colega de trabalho diferente nesta pergunta sobre falha no servidor .

OS X 10.10.0 - 10.10.3, Yosemite

Aparentemente , o mDNSResponder não existe no Yosemite (OS X 10.10). Você pode reiniciar o descoveryd para corrigir esses problemas.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist

OS X 10.10.4+, Yosemite

No OSX 10.10.4, o mDNSResponder foi reintroduzido . Portanto, use o primeiro funcionará novamente.

Na verdade, acho que você pode querer usar

scutil --dns

scutil -r hostname

Esses comandos usam o armazenamento dinâmico em configd, em oposição aos arquivos simples em / etc, que geralmente são lidos apenas no modo de usuário único e para sistemas não em rede.

man scutil   # or

scutil --help  

Eu experimentei o mesmo problema ... E ao reiniciar o mDNSResponder parece "funcionar", reiniciá-lo algumas vezes a cada hora é uma merda.

Então, por enquanto, "resolvi" o problema executando o dnsmasq localmente. Fazer isso:

• Crie o dnsmasq (faça o download do tgz e makeou brew install dnsmasq)

• Coloque isso em um dnsmasq.confarquivo:

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

• Coloque isso em um resolv.confarquivo que esteja no mesmo diretório que o dnsmasq.confarquivo (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Corra dnsmasqcom sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. A saída deve ser algo como:

  ...
  dnsmasq: reading resolv.conf
  dnsmasq: using nameserver 4.2.2.1#53
  dnsmasq: using nameserver 4.2.2.2#53
  dnsmasq: using nameserver 8.8.8.8#53
  dnsmasq: read /etc/hosts - 6 addresses
  

• Abra Preferências de rede e verifique se esse 127.0.0.1é o único servidor DNS (preferências de rede -> avançadas -> DNS -> adicione 127.0.0.1)

As coisas devem começar a funcionar bem novamente.

Quando as coisas estiverem funcionando, você poderá executar dnsmasqsem as opções --no-daemone --log-queries, para que seja iniciado em segundo plano e não seja necessário manter uma janela do Terminal aberta.

A resolução de nomes no OSX (e no UNIX em geral) é obtida dos endereços IP dos DNSs no arquivo localizado em /etc/resolv.conf (que o OS X gera automaticamente até onde me lembro).

Como você tentou praticamente qualquer coisa que me vem à mente, gostaria de perguntar:

• Você pode executar ping no DNS que deseja usar?
• Qual é / são os endereços IP do (s) DNS (s) que você deseja usar?
• Você já tentou usar o 8.8.8.8 (google) ou qualquer um dos OpenDNS 208.67.222.222 ou 208.67.220.220?
• Você pode executar ping nesses hosts?

Por fim, um teste geralmente agradável consiste em criar um usuário em branco e verificar se esse novo usuário apresenta o mesmo problema. Caso contrário, você pode começar a pesquisar o que o usuário atual tem e que pode estar causando o problema; se também falhar, você sabe que isso é algo mais relacionado ao "sistema".

Dê uma olhada no console para ver se você consegue identificar algo que possa estar relacionado (e gostaria de colar aqui).

Por último, mas não menos importante, o seu Mac vem com dois comandos DNS importantes, nslookupe dig.

Então, para resolver www.apple.com usando o servidor do Google, digite:

nslookup "host para resolver" "servidor DNS para usar". Por exemplo:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

O NSLookup é um comando antigo (que deveria ser descontinuado há alguns anos e substituído pelo DIG, mas acho que a sintaxe fácil de usar era boa demais para matar). Sua "substituição" é digum comando muito mais poderoso, cuja sintaxe é mais louco.

Para executar a mesma consulta, digite:

dig @ 8.8.8.8 www.apple.com

E aqui está a saída:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.         IN  A

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Como você pode ver, o dig é muito mais "detalhado" (o que é bom para depurar o que diabos está acontecendo). O poder da escavação vem do fato de que você pode especificar que tipo de consulta deseja executar (entre outras coisas).

De qualquer forma, informe-nos as saídas exatas desses comandos.

Eu tinha exatamente os mesmos sintomas (e passava algum tempo solucionando problemas), mas consegui resolvê-lo quando percebi que estava mexendo /System/Library/LaunchDaemons/com.apple.mDNSResponder.pliste o que fiz foi de alguma forma interpretado como malformado. Eu restaurei a partir de um backup e a máquina conseguiu resolver os nomes de host novamente.

Antes de chegar à solução, também percebi que era capaz de navegar na Internet se usasse um proxy SOCKS5 ssh -De tentasse pesquisas de DNS através do túnel.

Eu tive um problema muito, muito parecido, exceto que os sintomas eram um pouco diferentes.

Meu usuário não conseguiu resolver nenhum nome (NAS local, Google etc.), mas um usuário convidado no mesmo iMac (OS X 10.7.4) funcionou bem.

Liberar e reiniciar o mDNSResponder conforme mencionado funcionou por um tempo. Embora permanecesse funcionando quando o iMac foi colocado no modo de suspensão, ele sempre falhava após a reinicialização.

Quando a liberação / reinicialização parou de funcionar, procurei outros motivos / soluções e descobri que estava relacionado ao meu firewall. Não sei o que estava causando minhas configurações de firewall (OS X), mas se eu restaurasse a configuração de firewall, funcionaria.

Para restaurar as configurações padrão que usei:

sudo cp /usr/libexec/ApplicationFirewall/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

Obviamente, qualquer regra personalizada será removida com esta restauração.

Eu queria compartilhar minha versão desse problema, pois ele me causa dor há meses e esse post é a melhor coleção de soluções possíveis na rede!

Eu atingi este problema em Yosemite (10.10). Acontece que um daemon de chave discoverydfoi morto porque consumia muita CPU.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Estranhamente, a reinicialização não fez com que ela fosse reiniciada.

Reiniciei manualmente o serviço com:

sudo launchctl kickstart -k system/com.apple.networking.discoveryd

e agora está tudo bem.

Estou tendo o mesmo problema com 10.6.8. A primeira viagem a uma Apple Store resultou na restauração do sistema. Mas, depois disso, o DNS quebrou novamente enquanto eu estava no exterior e não tinha um DVD do sistema comigo. Naquela época, encontrei esse tópico e excluído /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistpor @freezedpeanuts e @Tom Thorogood.

Ele resolveu o problema, mas, surpreendentemente, o DNS quebrou pela terceira vez alguns dias depois. Eu procurei uma imagem do sistema 10.6.3 e:

1. Copiado /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistda imagem do sistema.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Reinicializado

Isso resolveu o problema.

Ele é interrompido periodicamente para mim agora (aproximadamente uma vez por mês), e o procedimento de restauração se resume às etapas acima, exceto que, em vez de reiniciar, você pode:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Observe que para qualquer pessoa que ainda tenha problemas, talvez seja necessário remover todos os servidores DNS públicos até que o cache seja limpo.

Eu aparentemente tinha o mesmo problema que o OP. Usando a ferramenta networksetup, descobri que, para o nome de rede especificado, algum DNS errado foi configurado:

networksetup -getdnsservers <networkname>

listou 192.168.0.1 como DNS. Usando scutil --dns, obtive resultados comparáveis, listando que o resolvedor nº 2 usava o servidor de nomes [0]: 192.168.0.1.

Usando o comando

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Consegui reconfigurar o DNS para a rede especificada e resolver nomes de máquinas locais e globais quando conectado à VPN.

Isso provavelmente não ajudará ninguém, mas, acidentalmente, há algum tempo, criei um arquivo na pasta, quando um DNS estava inoperante para um domínio específico:

/ etc / resolvedor /

e isso estava impedindo que um nome específico fosse resolvido, dois anos depois.

No meu caso, tudo estava bem: o mDNSResponder estava funcionando e funcionando, host/ nslookupfuncionou, ambos /etc/resolv.confe networksetuprelatou os servidores DNS corretos, etc. Apesar de tudo, a resolução do DNS em geral (por exemplo, com ping) inevitavelmente parou de funcionar em algum momento algumas horas depois bota.

Esse problema específico pode ser um pouco improvável, mas vou documentá-lo aqui como resposta de qualquer maneira.

Eu só notei quando a máquina começou a ficar mais lenta, mas havia muitos processos idênticos em execução . sensu-clientespecificamente.

Nós o configuramos no launchd com este arquivo plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

A -bbandeira sensu-clientfaz com que ela fique em segundo plano, agindo como um daemon. No entanto, tudo o que launchdvemos é que o processo original foi encerrado e, de acordo com a KeepAlivebandeira, ele o reinicia. Isso deixa milhares de processos bifurcados em segundo plano e, mesmo assim, o launchd não será mais sábio para o fato de estar em execução.

Acredito que esses milhares de processos (todos sensu-clientos softwares para os quais criamos uma configuração launchd) possam ter solicitado simultaneamente ao mDNSResponder, resultando efetivamente em uma negação de serviço local do cache DNS . Matar esses processos e consertar a lista dada ao launchd acabou resolvendo o problema.

A correção plist foi apenas para remover o -bsinalizador (background / daemonise) da chamada sensu-client. Observe que isso não é culpa do sensu; esse pedido foi escrito por um ex-administrador de sistema dessa empresa.

Aqui estão alguns comandos avançados que podem ajudar a solucionar o problema do DNS:

• Execute digpara listar os servidores de nomes raiz.
• Execute dig example.compara executar a pesquisa de DNS para o example.comdomínio.
• Lista de suas portas de hardware por: networksetup -listallhardwareports.
• Verifique a saída do pacote DHCP / BOOTP que o cliente aceitou do servidor DHCP / BOOTP:: ipconfig getpacket en0.
• Verifique a configuração do DNS por: scutil --dns.
• Verifique se mDNSResponderprocesso está sendo executado por: ps wuax | grep mDNSResponder.
• Limpe as entradas de conversão do ARP por: arp -ad(execute man arppara obter ajuda). ^fonte

Para depurar o mDNSResponderprocesso, o seguinte comando pode ajudar:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

O comando acima enviará um SIGINFOsinal para o processo que irá despejar os detalhes da depuração na saída do log que pode ser lida e analisada.

Ligar e desligar o Wi-Fi novamente ajudou.

^{MacBook Pro com 10.9.1}

Especialmente se você desligar o wifi e depois reiniciar. O atraso extra e o início sem conexão IP / rede garantem que a solicitação para voltar à rede tenha melhores chances de êxito.

Infelizmente, nada disso me ajudou e acabou depois de uma hora tentando descobrir e batendo minha cabeça contra a mesa de café ... algo, de alguma forma, em algum lugar ... removeu o /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistarquivo e foi a razão pela qual tive esse problema.

Percebi isso quando vi esta mensagem de erro: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Aqui está uma cópia de uma versão do El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Aqui está o código dessa essência:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>

Como se vê, para resolver o problema, você precisa configurar um domínio de pesquisa e adicioná-lo ao campo de domínio de pesquisa em Configuração de DNS das Preferências do Sistema. Basicamente, o domínio de pesquisa funcionará da mesma maneira que .local, mas será.

Você precisa configurar seu domínio de pesquisa como uma zona principal no servidor DNS para que isso funcione.

Eu tenho um problema semelhante ao encontrar o servidor host. Temos 21 iMacs em execução no servidor (El Capitan, atualizado recentemente) e apenas um não será vinculado. A correção geralmente é bastante simples através de Usuários e Grupos no SysPref. Excluindo o servidor host e vinculando novamente, localizando o servidor disponível na opção suspensa, mas por algum motivo desconhecido, o servidor está listado como unkown-00-00-12-34-56-78.home, que eu descobri ser o endereço MAC do servidor. Eu executei isso no terminal:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

e

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

retornei para ligar ao servidor no SysPref e a opção correta do nome do servidor apareceu brevemente e depois voltou a "unkown-00-00-12-34-56-78.home" bem na minha frente!

Ao seguir os comandos da resposta aceita:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

você pode receber um aviso:

Operação não permitida enquanto o System Integrity Protection está ativado

Você precisa desligá-lo. Instruções completas aqui: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

No meu caso, eu tinha o OpenDNS instalado no passado e ele não foi removido corretamente. Havia vários processos relacionados ao DNS em execução, como DNSdnscrypt-proxy. Não pude forçá-los a sair no Activity Monitor, mas consegui impedi-los de iniciar a reinicialização removendo o arquivo .plist em Library / LaunchDaemons.

Vá para Configurações -> Rede -> Avançado -> DNS. Em seguida, faça literalmente quaisquer alterações no DNS (reordene suas entradas de DNS, por exemplo). Depois clique em "Ok" seguido de "Aplicar" na próxima tela. Não se iluda pensando que a mudança específica que você fez foi significativa; é a mágica do botão "Aplicar".

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s

O que funcionou para mim foi remover todas as entradas do servidor de servidores DNS e domínios de pesquisa de:

Preferências do Sistema → Rede → Avançado ... → DNS

Após a atualização do Snow Leopard em um Mac Book antigo para o Mountain Lion, o sistema não conseguiu resolver o DNS. Rubor, reinicie, nada ajudou. Alterar o WiFi para um ponto de acesso diferente (meu telefone) ajudou.

O Mountain Lion adiciona um novo campo de cliente às configurações de rede DHCP. O preenchimento desse campo pareceu fazer feliz o ponto de acesso wifi. Deixá-lo em branco significava que nada estava acontecendo, mesmo que a conexão wifi parecesse ter sucesso.