Por que um registro SRV só ajuda um cliente que o consulta

Acrescentar um registro SRV à sua zona não ensina nenhum cliente VPN a procurá-lo. O cliente tem de conhecer a etiqueta, decidir enviar a consulta e agir conforme o que voltar, e o DNS não consegue fornecer as duas primeiras coisas. Por isso a maioria dos planos SRV falhados são problemas de cliente disfarçados de DNS. Leia primeiro o comportamento de descoberta do cliente e depois publique apenas a etiqueta que ele realmente consulta.

Um registro que ninguém consulta não pode ajudar ninguém

O SRV publica a localização de um serviço; não o anuncia. Nada empurra um registro para um cliente, e nenhum resolvedor oferece um nome que nunca foi pedido. A procura começa quando a aplicação decide fazê-la, por isso a etiqueta tem de vir da documentação do produto ou da observação do software na rede. Onde o cliente não tem qualquer passo de descoberta, um registro altera a zona e mais nada.

É por isso que um produto numa rede pode começar a funcionar enquanto outro não é afetado pela mesma alteração. A variável é o software, e o servidor DNS faz exatamente o que lhe foi dito. Volte a ler a zona depois da edição, porque uma etiqueta mal escrita esconde-se facilmente entre registos que parecem todos iguais.

Leia os campos antes de os escrever

Um registro transporta quatro valores, e cada um responde a uma pergunta diferente: a prioridade ordena os destinos que um cliente pode tentar, o peso reparte a carga entre destinos de igual prioridade, a porta nomeia a porta de transporte e o destino nomeia o anfitrião. A especificação também permite um destino de . para significar que o serviço está deliberadamente indisponível, o que é uma resposta útil e não uma avariada.

Nenhum desses campos transporta credenciais, uma política de certificados ou uma versão da aplicação, e um cliente que ignora o peso liga-se mesmo assim, apenas sem o equilíbrio previsto. O destino precisa de registos de endereço próprios e deve ser um nome canónico em vez de um alias. Publicar um registo que aponta para um anfitrião sem qualquer recetor produz um erro de ligação que se lê como uma falha de DNS, e esse é o tipo de engano mais caro. Publique a cadeia inteira ou nada dela.

Encontre a etiqueta que o cliente envia de facto

Estabeleça a etiqueta a partir de provas e não de uma suposição sobre o nome do produto. Ou a documentação indica o nome do serviço, ou uma captura mostra a consulta que sai do cliente ao arrancar. Ambas as vias terminam no mesmo ponto: um nome e um tipo exatos para testar contra o resolvedor.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Compare a resposta com o registo que publicou, caráter a caráter, porque os sublinhados e o ponto final fazem parte do nome. Uma resposta vazia a uma consulta que foi realmente enviada aponta para a zona, enquanto a ausência total de consulta aponta para o cliente, e essas conclusões levam-no a equipas diferentes. Uma resposta real parece-se com a linha abaixo, onde a prioridade 20 perde para qualquer registo de prioridade mais baixa e o cliente marca a porta 8443 no destino indicado.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

O destino também tem de existir

Um destino que resolve não é o mesmo que um serviço que responde. Verifique os registos de endereço do destino e depois verifique se algo está à escuta na porta e no protocolo publicados. Um registo TCP que aponta para um recetor apenas UDP é uma incoerência que nenhuma edição da zona repara. Mantenha o TTL curto enquanto o destino estiver em mudança, e alongue-o quando o nome deixar de se mover.

Os clientes que implementam mesmo a descoberta variam no quanto do registo respeitam. Alguns usam apenas a prioridade, outros tratam o peso como conselho e uns poucos ignoram a porta e assumem um valor predefinido. Essas diferenças pertencem às suas notas ao lado da etiqueta, porque explicam um comportamento que de outra forma parece uma falha do resolvedor.

A descoberta não é autenticação

Uma resposta SRV diz onde ligar, e não diz nada sobre em quem confiar depois de chegar. Deixe a validação do certificado e as verificações de identidade do servidor do cliente exatamente como estavam, porque um registo que outra pessoa pode falsificar não deve tornar-se uma decisão de confiança. As respostas DNS podem ser guardadas em cache e editadas por quem controla a zona, o que as torna um mau local para codificar políticas.

Para um cliente sem suporte de descoberta, distribua o perfil ou o URL de gateway que ele aceita, e registe que produto usa que método. Essa nota impede o próximo administrador de acrescentar um registo e esperar que funcione em todo o lado. A especificação SRV descreve a seleção entre destinos, e lê-la como um mecanismo de autorização é a forma como um registo útil se torna um pressuposto de segurança. Publique com intenção, nomeie a etiqueta na sua documentação e trate o cliente como o componente que decide se tudo isto tem importância.