Recursão indisponível: uma política de DNS, não um túnel quebrado

O nome interno resolve, e o mesmo servidor responde a um nome externo com uma recusa sobre recursão. Essa combinação não é contradição. Publicar as próprias zonas e resolver a internet inteira são dois serviços separados que um servidor pode oferecer, e ele pode fazer o primeiro sem o segundo. Trate a recusa como uma declaração de política e depois verifique se a política corresponde ao desenho.

Uma recusa e um tempo esgotado são respostas diferentes

Anote o nome, o tipo de consulta, o servidor que responde, o status e os registros devolvidos. Um aviso de recursão não invalida automaticamente uma resposta autoritativa que veio com ele. Escreva o status antes de interpretá-lo. Um status reconstruído de memória uma hora depois é outro fato.

O cabeçalho DNS carrega um pedido de recursão e uma indicação de se o servidor a oferece, e a especificação do protocolo mantém esses indicadores separados dos dados da resposta. Por isso uma resposta pode ser útil e ainda assim trazer uma queixa. Um tempo esgotado, uma resposta negativa e uma recusa são três resultados diferentes. Cada um aponta para uma camada diferente, e só a recusa é o servidor falando sobre política.

Leia primeiro o código de status e depois decida se o aviso importa para esta consulta. Uma resposta autoritativa que nomeia a zona é utilizável mesmo quando o bit recursivo é recusado. Uma recusa sem resposta é resultado de política, não um caminho de pacotes quebrado.

O que o resolvedor registrou como sua origem

O cliente pode chegar de um conjunto de endereços fora das faixas recursivas permitidas do servidor, ou uma tradução pode fazê-lo parecer um gateway. O endereço do próprio adaptador do cliente não é prova do que o resolvedor recebeu. Pergunte ao administrador do servidor pela origem observada em vez de inferi-la do seu lado do caminho. Os dois endereços podem diferir em cada salto que traduz.

Consulte o mesmo nome a partir do cliente e de um host em que o servidor já confia. A diferença entre as duas respostas é a condição de origem, e é mais útil do que qualquer uma das respostas isolada.

dig +short host.corp.example
dig +short example.com

Se a implantação quer recursão para clientes VPN, o administrador autoriza a faixa de origem adequada através dos próprios controles do servidor. Abrir a recursão para todas as redes para que um teste passe é uma mudança muito maior do que a que está sendo testada. Escreva a faixa autorizada ao lado da regra, porque o próximo revisor vai perguntar a quais origens a política deveria servir. Uma faixa de origem sem dono é como um teste temporário se torna permanente.

O DNS dividido é um desenho, não uma falha

Algumas implantações enviam só os domínios de trabalho ao resolvedor privado e todo o resto a outro resolvedor aprovado. Isso é um desenho de encaminhamento de consultas, e não é prova de que o servidor privado precise de uma política mais frouxa. Com esse desenho, um nome externo que falha pelo resolvedor privado é o resultado pretendido e não uma falha. A recusa é o desenho funcionando, não um sintoma a silenciar.

Um resolvedor público pode restaurar a navegação enquanto quebra nomes internos ou envia consultas privadas para onde não deveriam ir. Escreva o comportamento pretendido antes de mudar qualquer endereço de resolvedor.

Verifique a política com duas consultas

Depois da correção pretendida, consulte um nome privado permitido e um nome externo a partir do cliente real. O que voltar deve ser o que a política promete, não apenas um diagnóstico mais silencioso. Anote o servidor que responde com cada resposta e depois compare o par com a política. A comparação é o teste, e uma única consulta bem-sucedida não é.

resolvectl query host.corp.example
resolvectl query example.com

Se o nome privado funciona e o nome público é recusado, a política faz o que diz. Se o nome privado também falhar, o problema é a zona, a rota ou a autorização de origem, e a recursão é uma distração. Os dois resultados são úteis, e cada um elimina metade das hipóteses restantes.

Leia a recusa como evidência

Uma recusa é uma resposta. Significa que o servidor recebeu a consulta e se recusou a fazer o trabalho pedido, o que é diferente de um pacote que nunca chegou. Essa distinção é todo o diagnóstico. Registre-a como resposta, não como falha de conectividade.

Essa distinção diz onde olhar: os registros do servidor, sua política de acesso e a origem que ele registrou. Uma mudança de firewall não corrige uma recusa de política, e uma mudança de política não corrige uma rota ausente. Mantenha as duas hipóteses separadas até que uma delas tenha evidência.

Escreva o resultado e o dono da política no ticket, para que a próxima pessoa comece pela decisão e não pelo aviso. Nomeie a faixa de origem autorizada e os dois nomes que você testou. Um ticket com esses três fatos pode ser executado novamente; um que diz "a recursão está quebrada" não pode.