Por que o MagicDNS resolve dispositivos mas não nomes de host do escritório

O MagicDNS dá a cada dispositivo de uma tailnet um nome derivado do nome da sua máquina e do domínio DNS da tailnet. Esse nome é criado pelo Tailscale e recebe resposta ao longo do caminho do resolvedor do Tailscale. Um nome de host de escritório como files.office.example pertence a uma zona que o Tailscale nunca escreveu, então renomear um dispositivo não pode criá-lo. Os dois espaços de nomes coexistem; eles apenas têm donos diferentes.

Esse mecanismo está por trás de um relato muito comum: o host do Tailscale responde, e o servidor de arquivos ainda retorna um erro de resolução.

Dois espaços de nomes, dois donos

O nome de um dispositivo é gerado a partir do nome de host da própria máquina, as colisões são resolvidas pelo Tailscale, e o resultado vive sob o domínio da tailnet. A zona do escritório é mantida por quem administra o resolvedor do escritório, com registros criados por um administrador ou por registro dinâmico. Nomes curtos escondem a diferença: files pode ser uma expansão de sufixo de busca respondida pelo DNS do escritório, um dispositivo da tailnet, ou nada. Consultar o nome completo mostra qual sistema realmente respondeu.

Mudar o nome de máquina do roteador de sub-rede não faz nada pela zona do escritório. Ele renomeia um dispositivo do Tailscale e deixa o registro no servidor do escritório intacto, por isso renomear e tentar de novo nunca converge.

Aponte a zona do escritório para o seu resolvedor

O DNS dividido do Tailscale envia consultas para domínios escolhidos a um servidor de nomes que você especifica, e todo o resto segue a política restante. Adicione o domínio que o resolvedor do escritório realmente atende, não o sufixo de busca que você digita por acaso. Um sufixo de busca diz ao cliente o que acrescentar; ele não diz ao resolvedor onde olhar. Essas duas configurações parecem semelhantes em um console e se comportam de forma completamente diferente.

Um servidor de nomes restrito precisa ser autoritativo para o domínio associado a ele, ou a resposta será um encaminhamento em vez de um endereço.

A alcançabilidade vem antes da resolução

O cliente também precisa alcançar esse servidor de nomes. Para um resolvedor em uma LAN privada, a rota da sub-rede deve ser anunciada e aceita, a política de acesso deve permitir a consulta, e deve existir um caminho de volta. Um endereço DNS correto no console de administração prova apenas que a configuração foi salva. Se os pacotes não conseguirem alcançar o resolvedor, o sintoma é um tempo limite, que se parece diferente de uma resposta autoritativa de que tal registro não existe.

Essa diferença é diagnóstica. Um tempo limite aponta para roteamento ou política, enquanto uma resposta negativa imediata aponta para o registro ou a zona. Leia qual dos dois você recebe antes de alterar qualquer configuração de DNS.

Separe a falha do nome da falha do serviço

Se o recurso responde no seu endereço privado mas não pelo nome de host, a investigação permanece no DNS. Se nenhum dos dois funcionar, corrija primeiro o roteamento ou o serviço, porque um nome que resolve para um endereço inalcançável não é progresso. Consulte o nome completo e anote qual servidor respondeu. No macOS algumas ferramentas de linha de comando seguem um caminho diferente do de aplicativos comuns, então um terminal dig e um navegador podem discordar sobre o mesmo nome.

Repita o teste com um nó de saída selecionado se esse for o modo normal do dispositivo. O tratamento de DNS do nó de saída difere da configuração sem nó de saída, e testar apenas em um modo pode deixar passar a falha que os usuários realmente veem.

Anote a zona, o endereço do resolvedor e a rota que transporta a consulta. Esses três explicam a maioria das surpresas do MagicDNS sem outra rodada de renomeação.