Por que as respostas DNS64 mudam assim que a VPN se conecta?

Uma resposta DNS64 codifica uma suposição de tradução. Verifique qual resolvedor respondeu, se o prefixo está encaminhado e se há um tradutor no seu caminho.

As respostas DNS64 descrevem uma disposição de rede, não uma propriedade do servidor. O resolvedor sintetiza um endereço IPv6 a partir de um IPv4, e o resultado só funciona onde há um tradutor no fim desse prefixo. Coloque uma VPN no caminho e essa disposição pode manter-se, mudar ou deixar de ser verdadeira conforme três condições.

Essas condições são o resolvedor que respondeu, a rota que o seu dispositivo tem até o prefixo sintetizado e se algo nessa rota realiza a tradução. Cada uma é observável, e é isso que torna a falha diagnosticável.

Para onde um registro AAAA sintetizado realmente aponta

Um resolvedor DNS64 responde a uma consulta AAAA de um nome só IPv4 incorporando o endereço IPv4 dentro de um prefixo que tem configurado para usar, e o prefixo bem conhecido para essa tarefa é 64:ff9b::/96 como descrito na RFC 6147. O registro parece qualquer outro registro AAAA para a aplicação, e essa é a ideia: um cliente só IPv6 pode tentar uma conexão sem saber que o destino nunca teve IPv6. Essa conexão depende então de uma função NAT64 que traduz entre as duas famílias em algum ponto do caminho. Sem esse tradutor, o endereço sintetizado é um destino de aparência plausível que não leva a lugar nenhum.

O registro, portanto, codifica duas coisas ao mesmo tempo: o endereço IPv4 original e a suposição de que há um tradutor acessível. Só a primeira é visível na própria resposta.

Três condições decidem se ainda funciona

A primeira condição é qual resolvedor produziu o registro, já que um sem DNS64 configurado não devolve nada para esse nome e a aplicação falha de outra forma. A segunda é se o seu dispositivo tem uma rota até o prefixo sintetizado, porque uma resposta pode ser válida enquanto falta o caminho até ela. A terceira é se o tradutor dono desse prefixo está na rota que você usaria, porque um túnel que carrega 64:ff9b::/96 para outro lugar alcança outra função ou nada. As três podem valer antes do túnel e falhar depois, e por isso o sintoma parece uma regressão repentina.

Verifique-as nessa ordem. Uma resposta ausente e uma rota ausente parecem iguais num navegador e completamente diferentes num log do resolvedor.

Quando o resolvedor muda, a resposta muda

Um cliente VPN costuma impor o seu próprio resolvedor ou assumir toda a rota da consulta, e esse resolvedor pode não sintetizar nada. As consultas de nomes só IPv4 então não devolvem nenhum registro AAAA, o que um cliente só IPv6 vive como um nome a que não consegue chegar. Também acontece o contrário: um resolvedor que sintetiza de fato pode dar-lhe um prefixo que a sua rota tunelizada não transporta.

A cache torna isso mais difícil de ver. Um registro sintetizado obtido na rede do escritório pode sobreviver ao contexto que o produziu, então o cliente continua ligando-se a um endereço cujo tradutor já não é acessível. Olhe para o resolvedor que responde agora e não para o que respondeu quando a entrada foi guardada. Limpar a cache sem registar a resposta antiga e a nova destrói a prova de que precisa.

Teste a consulta e a rota em separado

Consulte o nome diretamente antes de envolver a aplicação, e anote qual servidor respondeu. Os comandos abaixo mostram o registro AAAA, o resolvedor em uso e se existe uma rota até o prefixo sintetizado. Execute-os com o túnel desligado e depois novamente com ele ligado.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Leia os resultados como uma cadeia. Um registro AAAA ausente significa que o resolvedor à sua frente não sintetiza, então uma rota só IPv6 não funcionará para esse nome, faça o que fizer o cliente. Um registro presente sem rota significa que o prefixo não é transportado pela rota atual, e isso é uma decisão de encaminhamento e não uma falha do resolvedor. Uma rota presente enquanto o pedido continua a falhar aponta para o próprio tradutor, e isso pertence a outro dono.

Anote o resolvedor, o contexto de rede e a família de endereços ao lado de cada resultado. É essa nota que permite à comparação seguinte separar uma mudança de resolvedor de uma mudança de encaminhamento.

Artigos relacionados