Porque é que uma zona privada do Route 53 devolve NXDOMAIN para nomes públicos

As zonas privadas do Route 53 substituem a resposta de um nome em vez de se fundirem com o registo público, e isso surpreende as pessoas no pior momento. Adicione um registo interno para api.example.net numa zona privada para example.net, associe-a a uma VPC, e todos os outros nomes sob esse pai passam a responder apenas a partir da zona privada. Um cliente que ontem conseguia chegar a www.example.net hoje recebe uma resposta negativa. O percurso abaixo começa nessa consulta falhada e segue para fora até à zona que lhe respondeu.

Comece pela consulta, não pela consola

Reproduza a falha no cliente que a reportou e registe o nome exato e o tipo de registo. Um nome que falha para A pode ainda resolver para AAAA, e um navegador que repete um nome em cache esconde qual dos dois quebrou. Execute a consulta duas vezes: uma através do resolver que o cliente realmente usa e outra com um rastreio que o contorna.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

O segundo comando é o importante. A sua linha de estado e a secção de autoridade nomeiam a zona que produziu a resposta, pelo que consegue distinguir uma resposta negativa da zona privada de um tempo limite, de uma porta bloqueada ou de um resolver que nunca recebeu a consulta. resolvectl mostra que servidor superior foi questionado, e muitas vezes não é o resolver que assumiu que a VPN tinha enviado.

Se a consulta com rastreio devolve o endereço público e a normal não, o registo público está intacto e é a vista privada que responde. É essa única comparação que decide qual metade do resto desta página se aplica a si.

Leia qual zona respondeu

Uma resposta que transporta NXDOMAIN com o SOA da zona privada na secção de autoridade é uma resposta definitiva dessa zona, não uma falha de pesquisa. O Route 53 Resolver escolheu a zona alojada privada porque o nome correspondia, depois não encontrou nenhum registo do tipo pedido, e o comportamento documentado é devolver a resposta negativa em vez de encaminhar a pergunta para o DNS público.

A seleção segue a especificidade. Com vários espaços de nomes privados sobrepostos, ganha a zona correspondente mais específica, e um pai privado mais amplo não tem uma segunda oportunidade para um nome que a zona filha selecionada não tem. As regras de encaminhamento acrescentam outra camada, porque uma regra de resolver específica de um domínio pode sobrepor-se à associação da zona alojada privada. Enumere as associações e as regras antes de concluir que uma zona está vazia.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Ambos os comandos precisam de credenciais da conta que possui a zona, e o segundo precisa do ID da zona do primeiro. Substitua-o pelo seu; o marcador acima não é real de propósito.

Porque é que a zona privada ganha

É a associação que torna a zona visível para uma VPC, e é o resolver dessa VPC que a aplica. Uma zona privada que não está associada à VPC de onde vem o tráfego do cliente não tem qualquer efeito, ao passo que uma associação à VPC errada produz uma resposta privada para a população errada. Verifique a lista de associações antes de editar registos, porque uma zona pode estar correta e ainda assim invisível.

Os espaços de nomes sobrepostos são a segunda fonte de confusão. Uma zona privada para example.net e uma zona privada para api.example.net correspondem ambas a uma consulta de API, e responde a mais específica. Isso é útil quando quer um espaço de nomes interno estreito, e perigoso quando à zona estreita falta um registo que a mais ampla tem. As considerações sobre zonas alojadas privadas na documentação do Route 53 descrevem tanto o comportamento de queda como a precedência das regras, e valem a leitura antes de acrescentar uma segunda zona sobreposta.

Nada disto altera a zona pública. Os resolvers públicos continuam a responder corretamente aos registos públicos, e é por isso que a falha parece um problema do cliente para todos os que estão fora da VPC.

Escolha o espaço de nomes antes de acrescentar registos

Se apenas uma nova família de serviços internos precisa de nomes privados, dê-lhe um subdomínio privado dedicado e deixe o pai público em paz. Um nome como internal.example.net não pode ocultar www.example.net, e o raio de impacto de um registo em falta fica limitado aos nomes que inventou para o efeito. O custo é que os URL e os certificados existentes podem não corresponder ao novo nome.

Quando utilizadores públicos e privados têm de manter o mesmo nome de anfitrião, o DNS de vista dividida é o desenho suportado e exige que mantenha os registos em cada vista de forma explícita. Uma zona privada ampla com um único registo não preserva as dependências públicas por baixo dessa zona; substitui-as por uma zona que tem um registo.

Inventarie os nomes que uma aplicação chama realmente antes de apontar uma população de clientes para a vista privada. Os anfitriões de início de sessão, os de recursos estáticos, os destinos de redirecionamento e os pontos finais de API são os primeiros a quebrar, e costumam estar espalhados pelos registos de várias equipas.

Siga o caminho do resolver e depois a rota

Um portátil só vê a vista privada se as suas consultas chegarem ao resolver que tem a associação. Editar um ficheiro hosts no servidor VPN não publica nada para os clientes ligados, e um cliente configurado com um resolver público continuará a receber respostas públicas enquanto o túnel estiver ativo. Confirme o endereço do resolver que o cliente recebeu e depois repita a consulta a partir do cliente e não do servidor.

Assim que o nome resolver, teste o caminho até ao endereço devolvido como passo separado, por exemplo com ip route get contra o endereço que a consulta devolveu. Uma resposta privada correta sem rota até ao endereço é um problema de encaminhamento, e uma resposta de registo em falta é um problema de vista de DNS; tratá-los como um único problema produz correções que não duram. Deixe as verificações do nome de anfitrião TLS e do certificado do serviço inalteradas, porque um endereço privado muda para onde vai a ligação e nada sobre qual certificado é válido.

Termine registando na nota de alteração a zona, a associação, o resolver e os nomes que verificou. Assim, a próxima pessoa que acrescentar um registo saberá que espaço de nomes é autoritativo para essa população de clientes.