Por que unha zona privada de Route 53 devolve NXDOMAIN para nomes públicos

As zonas privadas de Route 53 substitúen a resposta dun nome en lugar de fusionarse co rexistro público, e iso sorprende a xente no peor momento. Engada un rexistro interno para api.example.net nunha zona privada para example.net, asíciea a unha VPC e todos os demais nomes baixo ese principal agora responden só desde a zona privada. Un cliente que onte podía chegar a www.example.net hoxe recibe unha resposta negativa. O percorrido seguinte parte desa consulta fallida e avanza cara a fóra ata a zona que a respondeu.

Comece pola consulta, non pola consola

Reproduza o fallo no cliente que o notificou e anote o nome exacto e o tipo de rexistro. Un nome que falla para A pode seguir resolvéndose para AAAA, e un navegador que reintenta un nome na caché oculta cal dos dous se rompeu. Execute a consulta dúas veces: unha a través do resolvedor que o cliente usa realmente e outra cunha traza que o evite.

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

O segundo comando é o importante. A súa liña de estado e a súa sección de autoridade nomean a zona que produciu a resposta, así que pode distinguir unha resposta negativa da zona privada dun tempo de espera, un porto bloqueado ou un resolvedor que nunca recibiu a consulta. resolvectl mostra que servidor superior se consultou, que a miúdo non é o resolvedor que supuxo que enviara a VPN.

Se a consulta trazada devolve o enderezo público e a normal non, o rexistro público está intacto e responde a vista privada. Esa única comparación decide que metade do resto desta páxina se lle aplica.

Lea que zona respondeu

Unha resposta que leva NXDOMAIN co SOA da zona privada na sección de autoridade é unha resposta definitiva desa zona, non un fallo de busca. Route 53 Resolver escolleu a zona aloxada privada porque o nome coincidía, logo non atopou ningún rexistro do tipo solicitado, e o comportamento documentado é devolver a resposta negativa en lugar de reenviar a pregunta ao DNS público.

A selección segue a especificidade. Con varios espazos de nomes privados superpostos, gaña a zona coincidente máis específica, e un principal privado máis amplo non ten unha segunda oportunidade para un nome que a zona filla seleccionada non ten. As regras de reenvío engaden outra capa, xa que unha regra de resolvedor específica dun dominio pode vencer a asociación da zona aloxada privada. Enumere as asociacións e as regras antes de concluír que unha zona está baleira.

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 necesitan credenciais da conta que posúe a zona, e o segundo necesita o identificador de zona do primeiro. Substitúaoo polo seu; o marcador de arriba deliberadamente non é real.

Por que gaña a zona privada

A asociación é o que fai visible a zona para unha VPC, e o resolvedor desa VPC é o que a aplica. Unha zona privada que non está asociada á VPC da que chega o tráfico do cliente non ten ningún efecto, mentres que unha asociación coa VPC equivocada produce unha resposta privada para a poboación equivocada. Revise a lista de asociacións antes de editar rexistros, porque unha zona pode ser correcta e aínda así invisible.

Os espazos de nomes superpostos son a segunda fonte de confusión. Unha zona privada para example.net e unha zona privada para api.example.net coinciden ambas cunha consulta de API, e responde a máis específica. Iso é útil cando quere un espazo de nomes interno estreito e perigoso cando á zona estreita lle falta un rexistro que a máis ampla ten. As consideracións sobre zonas aloxadas privadas na documentación de Route 53 describen tanto o comportamento de caída como a precedencia das regras, e paga a pena lelas antes de engadir unha segunda zona superposta.

Nada disto cambia a zona pública. Os resolvedores públicos seguen respondendo correctamente os rexistros públicos, e por iso o fallo parece un problema do cliente para todos os que están fóra da VPC.

Escolla o espazo de nomes antes de engadir rexistros

Se só unha nova familia de servizos internos necesita nomes privados, déalle un subdominio privado dedicado e deixe en paz o principal público. Un nome como internal.example.net non pode ocultar www.example.net, e o radio de impacto dun rexistro ausente limítase aos nomes que inventou para ese propósito. O custo é que as URL e os certificados existentes poden non coincidir co nome novo.

Cando os usuarios públicos e privados deben conservar o mesmo nome de host, o DNS de vista dividida é o deseño admitido e esixe que manteña os rexistros en cada vista de forma explícita. Unha zona privada ampla cun só rexistro non conserva as dependencias públicas baixo esa zona; substitúeas por unha zona que ten un rexistro.

Faga inventario dos nomes que unha aplicación chama realmente antes de dirixir unha poboación de clientes á vista privada. Os hosts de inicio de sesión, os de recursos estáticos, os destinos de redirección e os puntos de conexión de API son os primeiros que se rompen, e adoitan estar repartidos entre os rexistros de varios equipos.

Siga a ruta do resolvedor e despois a ruta de rede

Un portátil só ve a vista privada se as súas consultas chegan ao resolvedor que ten a asociación. Editar un ficheiro hosts no servidor VPN non publica nada aos clientes conectados, e un cliente configurado cun resolvedor público seguirá recibindo respostas públicas mentres o túnel estea activo. Confirme o enderezo do resolvedor que recibiu o cliente e despois repita a consulta desde o cliente e non desde o servidor.

Unha vez que o nome se resolve, probe a ruta cara ao enderezo devolto como paso aparte, por exemplo con ip route get contra o enderezo que devolveu a consulta. Unha resposta privada correcta sen ruta cara ao enderezo é un problema de encamiñamento, e unha resposta de rexistro ausente é un problema de vista de DNS; tratalos como un só asunto produce correccións que non se manteñen. Deixe sen cambios as comprobacións do nome de host TLS e do certificado, porque un enderezo privado cambia a onde vai a conexión e nada sobre que certificado é válido.

Remate anotando na nota de cambio a zona, a asociación, o resolvedor e os nomes que verificou. Así a seguinte persoa que engada un rexistro saberá que espazo de nomes é autoritativo para esa poboación de clientes.