Uma regra de domínio VPN quebra quando um CDN muda os seus endereços

Você copia o endereço de uma consulta para a sua regra de encaminhamento, o site funciona e, uma semana depois, já não funciona. Nada na regra mudou. O serviço mudou para outro endereço de borda, o cliente resolveu outro nome de host ou a sessão passou para IPv6. A decisão à sua frente é se uma regra baseada no nome ou um intervalo explícito é o instrumento certo para este serviço, e três condições decidem isso. O que segue separa o nome do endereço, porque apenas um dos dois é estável.

Por que uma consulta não é um inventário

Uma rede de distribuição de conteúdo responde com um endereço escolhido para o resolver, a região e o momento. Pergunte duas vezes de redes diferentes e você pode obter respostas diferentes. Pergunte uma vez e trate a resposta como a lista de endereços do serviço, e a regra que você escrever será um instantâneo, não uma regra. Esse é todo o problema de tratar uma resposta DNS como configuração.

Há uma segunda lacuna. Um único nome de host visível raramente cobre a aplicação inteira, porque login, mídia e tráfego de API costumam usar nomes separados. Uma regra construída a partir do nome de host da barra de endereços pode cobrir a página e perder o vídeo, o que é lido como falha parcial e não como erro de encaminhamento.

A terceira lacuna é a família de endereços. Uma regra só para v4 não diz nada sobre o registro AAAA que o cliente pode preferir.

Três condições que decidem regra de domínio ou intervalos

Primeiro, o serviço publica um conjunto estável de prefixos que você possa possuir e documentar? Se sim, os intervalos explícitos são honestos e baratos. Se não, uma regra de domínio é o único mecanismo capaz de acompanhar o serviço.

Segundo, o mecanismo de domínio do seu cliente se atualiza? Uma regra que resolve uma vez na conexão e nunca mais é um instantâneo com melhor imagem de marca. Terceiro, o mecanismo cobre subdomínios e as duas famílias de endereços, ou apenas os nomes que você digitou?

Responda a essas três e a escolha costuma ser óbvia. Adivinhar produz uma regra que funciona em teste e falha em produção.

Teste uma sessão, não uma página

Carregue a página e depois execute a operação que importa: entrar, iniciar a reprodução, enviar um arquivo. Cada uma pode alcançar um host diferente, e a que falha é a que sua regra perdeu.

Liste o que a sessão realmente contata em vez do que a página mostra:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Mantenha o resolver visível durante a comparação, porque uma regra que funciona a partir de um resolver e falha a partir de outro fala da resposta do CDN, não do túnel. Um TTL curto também significa que a resposta que você registrou tem prazo de validade.

O que cada mecanismo realmente cobre

Os dois mecanismos parecem intercambiáveis numa página de configurações e se comportam de forma diferente por baixo.

Uma rota de endereço do núcleo combina prefixos. Ela não faz ideia do que seja um nome de host, então não consegue acompanhar um serviço que troca de endereços. Uma regra de domínio resolve nomes e encaminha o resultado; ela acompanha o serviço, mas depende do resolver, do comportamento de atualização e do tratamento dos subdomínios pelo cliente, então uma regra que acompanha nomes precisa ser testada com o resolver que o cliente realmente usa.

Nenhuma é um superconjunto da outra, e é por isso que misturá-las sem uma nota gera confusão mais tarde.

Verifique de novo quando o serviço mudar

Depois de uma atualização do cliente ou de uma mudança no serviço, execute o mesmo teste de sessão outra vez. Uma lista de endereços que funcionava antes é evidência sobre aquele período, não um inventário permanente da infraestrutura do serviço.

Anote qual mecanismo cobre qual nome de host, e a data da última verificação.

Essa nota é a diferença entre uma regra que você consegue defender e uma regra que ninguém ousa tocar. Se o serviço publica a própria lista de prefixos, use-a e cite a data. Se não, diga isso, e mantenha a regra de domínio com o seu comportamento de atualização escrito ao lado.