DNS do WireGuard no iPhone: o domínio é só um sufixo de pesquisa

Você escreve uma linha com um endereço de resolvedor e um domínio da empresa, esperando que só os nomes desse domínio usem o resolvedor do túnel. No cliente Apple, agora todos os nomes vão para lá, e os nomes curtos do domínio também são resolvidos. A linha faz duas coisas separadas, e só uma delas trata de quais consultas o túnel atende. A outra é uma conveniência de digitação que uma leitura ilusória promoveu a política.

No que a linha DNS é decomposta

O cliente lê a entrada como uma lista e classifica cada item pela forma. Tudo o que parece um endereço vira servidor DNS; tudo o que parece um domínio vira sufixo de pesquisa. Ambos acabam nas configurações do túnel, mas em campos diferentes. Uma linha ilustrativa para um túnel que carrega um resolvedor privado e um domínio interno fica assim.

DNS = 10.24.8.53, lab.internal.example

O endereço fornece o resolvedor. O domínio fornece um sufixo que permite ao cliente digitar um nome curto e ao sistema acrescentar o restante antes de perguntar. Nenhum dos dois diz nada sobre limitar o resolvedor a esse domínio, e essa é justamente a parte que as pessoas esperam e não recebem. Só um campo da plataforma pode expressar essa restrição, e não é este.

Dois campos da Apple, dois trabalhos diferentes

A Apple expõe a distinção no seu objeto de configurações de DNS. A lista de domínios de pesquisa é documentada como a lista usada para qualificar nomes de host de um único rótulo: digite um nome de host nu e o sistema pode acrescentar cada sufixo por vez. Isso é uma regra de preenchimento, não uma regra de roteamento. Nada nessa lista decide qual servidor é consultado.

A lista de domínios de correspondência é outra propriedade. Ela decide quais espaços de nomes usam este conjunto de configurações de DNS, e uma entrada vazia significa o domínio padrão em vez de um sufixo específico. gerador de configurações do túnel de pacotes no cliente Apple segue esse modelo. Ele coloca os sufixos de pesquisa analisados na lista de pesquisa e, quando há servidores, define a lista de correspondência como a string vazia. O resultado é um resolvedor de túnel que responde a tudo o que o sistema envia a ele, mais um sufixo que ajuda com nomes curtos.

Então um domínio nessa linha não é um seletor de espaço de nomes. Adicionar outro não restringe quais consultas o túnel usa, e removê-lo também não as amplia. A única coisa que muda é quantos nomes curtos são completados.

Por que cada nome ainda chega ao resolvedor do túnel

Com a entrada de correspondência vazia, o túnel é um resolvedor candidato para nomes comuns, não apenas para o domínio da empresa. Numa configuração de túnel completo isso costuma importar pouco, porque todo o tráfego já está no túnel. Num túnel dividido importa muito. Nomes públicos agora podem ser resolvidos por um resolvedor que só tem uma zona privada, e uma falha parece um VPN quebrado quando na verdade é um resolvedor que responde só a parte do espaço de nomes. O túnel está bem, as consultas saem, e as respostas voltam vazias.

Há dois consertos disponíveis e são decisões diferentes. Transforme o resolvedor do túnel num resolvedor completo que encaminhe nomes públicos pelo caminho aprovado, ou pare de enviar nomes públicos para ele mudando a configuração do cliente em vez da lista de domínios. O primeiro mantém cada consulta no túnel e confia na origem superior. O segundo mantém algumas consultas locais e aceita que nomes privados podem deixar de resolver enquanto o túnel está desligado.

Do que um DNS dividido realmente precisaria

Uma política de resolvedor limitada a um espaço de nomes exige um cliente que permita expressá-la: faça corresponder domínios nas plataformas Apple, ou uma configuração equivalente no produto que você usa. Um campo de configuração que só aceita servidores e sufixos não pode expressá-la, por mais bem pontuado que seja. Um perfil pode carregar a política porque descreve uma configuração gerenciada, e não uma dica no momento da conexão. Ele pode nomear o domínio, os servidores e o que deve acontecer quando esse domínio não estiver acessível. Essa é a diferença entre uma configuração e um contrato.

Nos dispositivos Apple gerenciados isso costuma ser entregue por um perfil de configuração que carrega as configurações de DNS específicas do domínio. É um mecanismo diferente do arquivo de configuração do WireGuard, e os dois só podem coexistir se o cliente respeitar o perfil. Verifique como o seu cliente realmente chama o campo antes de supor que os dois produtos se comportam igual. Um script com wg-quick num Mac e o aplicativo WireGuard num iPhone leem linhas parecidas e as instalam por camadas diferentes.

Leia as configurações instaladas, não o arquivo

Num Mac você pode inspecionar com o que o sistema acabou, o que é mais informativo do que reler o arquivo que você escreveu. A lista de resolvedores mostra quais servidores estão configurados para quais domínios, e as consultas delimitadas mostram qual venceu. Um cliente que estraga a linha mostra isso aqui em vez de no arquivo que você escreveu. No iOS não há uma linha de comando equivalente, então a prova ali é um resultado: um nome privado que resolve pelo túnel e um nome público cuja resposta revela qual resolvedor respondeu.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Esses dois comandos imprimem a configuração atual do resolvedor e os servidores DNS do serviço ativo. Se o resolvedor do túnel aparecer como resolvedor padrão sem restrição de domínio, a configuração está fazendo exatamente o que o cliente pediu. Corrija isso mudando o mecanismo, não adicionando um segundo sufixo e esperando que o comportamento mude.