DNS não resolvendo no Mac OS X


102

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

Também acontece comigo no leão.
dkagedal

Acontecendo para mim no Mavericks, 10.9.4
greg7gkb

Isso parece um problema histórico que apodreceu a vida dos usuários e administradores de rede, do Leopard a Yosemite. Se alguém ainda vir esse problema, informe claramente se você possui mais de uma interface ativa e, além disso, obtém sua conf. de um servidor DHCP (de lados diferentes). Por quê? Eu nunca vi esse problema em nenhum outro Unix e em nenhum dos meus Macs (eu tenho muito), mas nenhum deles tem mais de uma interface falando sobre uma fonte de informações de DNS.
dan

Tente mudar sua configuração de DNS (pedido de alteração ou remover entradas), que resolver o mesmo problema para mim
MEMS

Respostas:


91

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.


5
Mas essa não é realmente uma resposta satisfatória. Eu preciso saber como impedir que isso aconteça em primeiro lugar.
precisa saber é o seguinte

1
@dkagedal Essa é realmente a resposta mais adequada que conseguiremos - isso acontece porque o seu mac armazena em cache as entradas DNS para evitar atingir o servidor DNS (provavelmente o roteador) para todas as pesquisas de DNS - o que acontece muito. Esse cache é necessário e bom, mas seria bom se houvesse um comportamento melhor quando uma entrada não fosse encontrada (considero isso um bug). De qualquer forma, há algum tempo limite no cache; quando esperei 10 minutos ou mais na minha máquina, essa situação se resolveu. Para a maioria dos usuários, o comportamento existente é bom, portanto não é provável que seja alterado pela Apple tão cedo.
Matt

2
Claro que isso não é tão bom quanto ele ganha. Nenhum outro sistema operacional tem esse problema. Não há nada errado com o DNS, o registro para www.google.com não desapareceu, é apenas o cache do MacOS que, de alguma forma, o perdeu e não o busca novamente. E isso é um bug que precisa ser corrigido.
dkagedal

1
Consegui esse problema no 10.9 e a solução funcionou perfeitamente. No meu caso, o DNS estava resolvendo nomes completos, mas não curtos.
29513

1
@ Matteo Talvez o arquivo não precise existir ou talvez a resposta precise ser atualizada para o Yosemite. Você tem esse problema? A execução desses comandos corrige isso?
precisa saber é o seguinte

10

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  

3
Você não explica por que esses comandos ajudariam com esse problema. Eles até? Ou isso significa um comentário para uma das outras respostas ou algo assim?
dkagedal

Uma possível vantagem do scutil é que ele pode funcionar independentemente de o computador ter discoveryd ou mDNSResponder. Data de antes de sua introdução.
DA Vincent

1
esses comandos não resolvem o problema #
Radu Simionescu

8

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.


Gostaria apenas de salientar que, depois de 16 horas seguidas vasculhando a Internet, esta é a única solução que encontrei que permite resolver nomes de empresas internos E permitir que redes divididas funcionem corretamente. Muito obrigado por fazer este comentário.
Ron Thompson

Eu também apontaria que no OS X El Capitan, para criar um script para isso, envolvi meu openconnectcomando em um script python, junto com comandos como networksetup -setdnsservers 127.0.0.1e networksetup -setsearchdomains "$COMPANY_NAME".com. Adicione seu dnsmasqcomando e está tudo pronto! Finalmente, tenho uma solução VPN estável, graças a este comentário.
Ron Thompson

Para futuros leitores, achei mais fácil simplesmente colocar ssh em minha caixa no trabalho, determinar quais IPs possuíam para servidores de nomes e depois codificá-los no meu resolv.conf abaixo de 8.8.8.8 (servidor DNS do Google). Isso permite que todos os nomes de empresas que não sejam da empresa sejam resolvidos corretamente sem ter que passar pelos servidores da empresa, o que acho útil para privacidade e velocidade. No que diz respeito à codificação, esses IPs não mudarão tão cedo, e se o fizerem, eu não serei o único afetado e deve ser trivial editar duas linhas.
Ron Thompson

Ele diz que o endereço 127.0.0.1 já está em uso quando tento iniciar o dnsmasq. O que eu tenho que fazer? High Sierra
IceFire

@ IceFire Eu sei que isso é antigo, mas isso significa que já existe um serviço vinculado a essa porta (53). Tecnicamente, isso significa que está recebendo o erro EADDRINUSE, mas não irei lá :) Quanto a esta resposta, acho isso intrigante. Eu tenho um problema semelhante, mas acho que (espero) para mim que a outra resposta o resolva apenas que não preciso habilitá-lo pelo menos para minha rede doméstica, pois tenho meus próprios servidores DNS autoritativos (e um deles é o local e o que eu uso). Otoh, como usuário Unix de longa data, o fato de eu poder usar o /etc/resolv.conf é atraente, mas tentarei o outro primeiro.
Pryftan

7

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.


Veja minha edição da pergunta.
CajunLuke #

@CajunLuke hmmmm interessante… Eu me importo de adicionar a saída de: cat /etc/resolv.conf à sua pergunta?
Martin Marconcini

Editado. (Preenchimento para fazer comentário ajuste.)
CajunLuke

@CajunLuke, estou intrigado. Vamos voltar às raízes ... isso só acontece nesta máquina e somente no OSX, as VMs estão ok. Estou começando a suspeitar que o Parallels ou o VMware podem estar causando alguns problemas. Que tipo de rede essas VMs estão usando? Ponte? Compartilhado?
Martin Marconcini

1
Ou, se você quiser realmente curto, você sempre pode ... cavar + curto um apple.com ...
Pryftan 15/03

6

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.


1
Minha empresa tem esse problema há meses e meses, sempre levando os Macs para a "barra Genius", cuja única solução era limpar os discos rígidos e começar de novo. Vi sua postagem e apaguei o arquivo com.apple.mDNSResponder.plist, reiniciei e o problema foi resolvido. Eu gostaria de poder te votar um bilhão de vezes.
9788 Thomas Thomogood #

1
Observe excluir com.apple.mDNSResponder.plist! Fiz como o @TomThorogood sugeriu. Tenho dificuldade em voltar. Mesmo colocando o arquivo de volta e reiniciando, não consegui obter nenhuma resposta da Internet. O sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistque ajudou.
Pavel Binar

5

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!


4

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.


1
Esta foi a solução para mim também em Yosemite. Alguns detalhes: host, escavação e Chrome funcionaram bem, mas ping, telnet, ssh, firefox e safari não conseguiram resolver os nomes de host. Esta solução corrigiu meu problema.
precisa saber é o seguinte

Irritante isso acontece o tempo todo para mim. Tem que reiniciar o serviço.
Callum Rogers

2

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


2

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.


1
Talvez devêssemos mencionar support.apple.com/pt-br/HT203244 .
DA Vincent

@ DAVincent Alguns anos atrasado, mas esse link é decepcionante. É claramente um bug da Apple, mas eles o atribuem ao erro do usuário.
weberc2 11/06

2

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.


2

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.


Muito obrigado, este foi o meu problema. Estou depurando há horas, e quando procurei no / etc / resolvedor, é claro que encontrei um arquivo chamado "test", com os IPs errôneos ...
keyser

Exatamente o meu problema. Só percebi isso depois que corri scutil --dnse notei que o resolvedor nº 8 adicionou servidores de nomes personalizados para o meu domínio problemático. Tentei removê-los pela scutilinterface da linha de comandos, mas sem sorte. E então, de alguma forma, me deparei com /etc/resolver... aleluia! Essa resposta foi muito útil para explicar a idéia de DNS no macOS.
llude

2

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.


2

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.


1

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.


1
Embora a pergunta possa precisar de alguma edição, ela ainda diz (no momento em que escrevemos esse comentário) que os funcionários já tentaram ligar e desligar o Wi-Fi. Talvez possamos retirar esta resposta?
DA Vincent

Não tenho reputação suficiente para adicionar um comentário a uma postagem sobre como desativar e ativar o wifi, mas isso funcionou para mim. Recolher a resposta seria bobagem.

+1 na sugestão para tentar novamente. Várias respostas ajudam muitas pessoas, e cada roteador tem diferentes tempos limite e comportamentos.
Bmike

1

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>

0

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.


0

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!


0

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/


0

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.


0

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

0

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


-1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.