Como inspecionar os resolvedores DNS que o seu Mac usa numa VPN

scutil --dns imprime a configuração do resolvedor que o macOS realmente consulta, não o único servidor DNS que você digitou num painel de ajustes. A saída é mais longa do que a maioria imagina, porque o sistema mantém blocos de resolvedor separados para o caminho padrão, para interfaces com escopo e para encaminhamento específico de domínio. O bloco no topo da saída não é necessariamente o que responde à consulta. Se um nome privado resolve no escritório e falha no momento em que a VPN sobe, o descompasso está nas regras de correspondência e nas rotas, não no endereço do servidor. Leia primeiro a ordem e depois prove a resposta com uma busca real.

Leia a ordem dos blocos antes dos endereços

Cada entrada abre com resolver #N e lista nameserver[0], às vezes if_index, uma linha flags, reach e, quando o bloco não é um padrão simples, um domain e uma lista search domain. O resolvedor número 1 sem domínio é o padrão que trata nomes públicos. Tudo o que traz Scoped nos seus flags está ligado à interface nomeada por if_index, e tudo o que está marcado como Supplemental se aplica apenas aos domínios listados abaixo dele.

A seleção é correspondência de sufixo. Para um nome como intranet.corp.example, o macOS prefere o resolvedor cuja entrada domain é o sufixo correspondente mais longo, então um bloco com domain : corp.example vence o padrão mesmo quando está bem abaixo na saída. order desempata domínios do mesmo comprimento. Uma primeira olhada raramente precisa de mais: a saída inteira quando você quer ler um bloco do começo ao fim, as primeiras linhas para aprender a ordem dos blocos e uma passagem filtrada que imprime os cabeçalhos dos blocos ao lado das linhas de campo. Os blocos com escopo aparecem sob o próprio cabeçalho e são lidos como uma continuação da lista acima deles, então mantenha um cabeçalho à vista sempre que citar a saída.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Combine if_index com a interface do túnel

Um índice só é útil se você puder nomear a interface por trás dele. scutil --nwi lista as informações de rede que o sistema mantém, incluindo a interface primária e a alcançabilidade, enquanto ifconfig -l dá os nomes, onde utun0 até utun9 são os candidatos a túnel que um cliente costuma criar. A Apple usa o scutil --dns como seu próprio exemplo de inspeção no guia de implantação, e documenta como o Network Extension pode encaminhar domínios escolhidos para resolvedores escolhidos, que é o mecanismo que esses blocos com escopo expõem.

A verificação que resolve a questão é se o resolvedor está no caminho que o túnel instalou:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Se o route -n get devolve um gateway e uma interface que não batem com a entrada do resolvedor, o endereço pode estar perfeitamente correto e ainda assim inalcançável. Um túnel dividido que carrega apenas as sub-redes corporativas descarta as consultas dirigidas a um servidor DNS fora delas, e a falha aparece como tempo esgotado, e é por isso que a saída de configuração continua parecendo limpa.

Consulte o resolvedor do sistema, depois o servidor

Três ferramentas respondem a três perguntas diferentes, e confundi-las produz a maioria das conclusões erradas nesta área. O dscacheutil -q host -a name passa pelo mesmo resolvedor do sistema que as aplicações comuns usam, então valem os blocos com escopo e os suplementares. O dig sem argumento de servidor lê /etc/resolv.conf, que não é a fonte da verdade para resolução com escopo no macOS, e ignora por completo as regras por domínio. O dig @address alcança exatamente um servidor e não diz nada sobre a seleção.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Quando o primeiro comando responde e o segundo devolve NXDOMAIN, você encontrou a separação que procurava e nada está quebrado. Quando o primeiro esgota o tempo enquanto o dig @10.20.0.53 responde, o resolvedor funciona mas não é alcançável no caminho que o túnel escolheu, então o próximo passo é o route -n get e não uma edição nos ajustes de DNS. Mantenha nomes privados fora de tudo o que você cola num ticket ou numa nota compartilhada.

O que a saída não pode lhe mostrar

Várias camadas ficam acima ou ao lado da lista de resolvedores, e cada uma pode enviar uma consulta a um lugar que a saída nunca menciona. Um navegador com DNS seguro ativado pode resolver pelo próprio canal cifrado, então uma página que carrega enquanto o dscacheutil esgota o tempo não é contradição. Um proxy DNS instalado por software de segurança roda como provedor de Network Extension e encaminha as consultas por conta própria, e o scutil --dns mostra o que foi configurado, não o endereço de origem que o proxy acabou usando. Os domínios de busca acrescentam uma terceira dobra: a um nome não qualificado acrescenta-se cada sufixo listado em ordem, então o bloco que respondeu pode ser um que você nunca suspeitou.

As respostas desatualizadas são o mais barato de descartar e o que mais frequentemente se esquece:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Se a saída muda após a limpeza, o estado estava em cache e a saída anterior descrevia um túnel que já não existia. Se não muda, a configuração é o que é, e a questão passa para as rotas e para a política de aplicações.

Um guia curto para antes e depois

Capture uma linha de base apenas onde a política permite, e mantenha os arquivos fora de qualquer pasta sincronizada. A sequência abaixo é a que executo em máquinas de clientes: capture a linha de base, conecte, capture de novo, depois compare e pesquise.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Leia a diferença por blocos em vez de por linhas. Um novo resolvedor com escopo que traga o índice da interface do túnel e uma entrada domain para o sufixo privado é a forma esperada. Um novo resolvedor padrão apontando para um endereço público é um achado que vale a pena levantar com quem possui o perfil do cliente. Depois repita a consulta dentro da aplicação que realmente falhou, não apenas no shell, e anote a interface do route -n get ao lado do resultado.

Para desfazer uma alteração, desconecte e repita a captura da linha de base. Se o bloco com escopo sumiu, o cliente limpou depois de si. Se o bloco continua listado contra uma interface que já não existe, o estado está desatualizado, e uma limpeza mais uma reconexão é o conserto mais suave antes de alguém tocar no perfil.

Quatro verificações, nesta ordem: algum bloco de resolvedor corresponde ao sufixo mais longo do nome; esse bloco está ligado à interface que o túnel instalou; a rota até o servidor de nomes dele usa o túnel; e o resolvedor do sistema, e não o dig, devolve a resposta. A primeira verificação que falha diz se você deve mudar a política de DNS, as rotas do túnel ou a aplicação. Se as quatro passarem e o nome ainda falhar, o problema está acima do DNS, e a próxima coisa a inspecionar é tudo o que responde à porta 53 à frente dele.