Por qué una zona privada de Route 53 devuelve NXDOMAIN para nombres públicos

Las zonas privadas de Route 53 sustituyen la respuesta de un nombre en lugar de fusionarse con el registro público, y eso sorprende a la gente en el peor momento. Añada un registro interno para api.example.net en una zona privada para example.net, asóciela a una VPC y todos los demás nombres bajo ese principal ahora responden solo desde la zona privada. Un cliente que ayer podía llegar a www.example.net hoy recibe una respuesta negativa. El recorrido siguiente parte de esa consulta fallida y avanza hacia fuera hasta la zona que la respondió.

Empiece por la consulta, no por la consola

Reproduzca el fallo en el cliente que lo notificó y anote el nombre exacto y el tipo de registro. Un nombre que falla para A puede seguir resolviéndose para AAAA, y un navegador que reintenta un nombre en caché oculta cuál de los dos se rompió. Ejecute la consulta dos veces: una a través del resolutor que el cliente usa realmente y otra con un trazado que lo evite.

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

El segundo comando es el importante. Su línea de estado y su sección de autoridad nombran la zona que produjo la respuesta, así que puede distinguir una respuesta negativa de la zona privada de un tiempo de espera, un puerto bloqueado o un resolutor que nunca recibió la consulta. resolvectl muestra qué servidor superior se consultó, que a menudo no es el resolutor que supuso que había enviado la VPN.

Si la consulta trazada devuelve la dirección pública y la normal no, el registro público está intacto y responde la vista privada. Esa única comparación decide qué mitad del resto de esta página se le aplica.

Lea qué zona respondió

Una respuesta que lleva NXDOMAIN con el SOA de la zona privada en la sección de autoridad es una respuesta definitiva de esa zona, no un fallo de búsqueda. Route 53 Resolver eligió la zona alojada privada porque el nombre coincidía, luego no encontró ningún registro del tipo solicitado, y el comportamiento documentado es devolver la respuesta negativa en lugar de reenviar la pregunta al DNS público.

La selección sigue la especificidad. Con varios espacios de nombres privados superpuestos, gana la zona coincidente más específica, y un principal privado más amplio no tiene una segunda oportunidad para un nombre que la zona hija seleccionada no tiene. Las reglas de reenvío añaden otra capa, ya que una regla de resolutor específica de un dominio puede vencer a la asociación de la zona alojada privada. Enumere las asociaciones y las reglas antes de concluir que una zona está vacía.

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 comandos necesitan credenciales de la cuenta que posee la zona, y el segundo necesita el identificador de zona del primero. Sustitúyalo por el suyo; el marcador de arriba deliberadamente no es real.

Por qué gana la zona privada

La asociación es lo que hace visible la zona para una VPC, y el resolutor de esa VPC es lo que la aplica. Una zona privada que no está asociada a la VPC de la que llega el tráfico del cliente no tiene ningún efecto, mientras que una asociación con la VPC equivocada produce una respuesta privada para la población equivocada. Revise la lista de asociaciones antes de editar registros, porque una zona puede ser correcta y aun así invisible.

Los espacios de nombres superpuestos son la segunda fuente de confusión. Una zona privada para example.net y una zona privada para api.example.net coinciden ambas con una consulta de API, y responde la más específica. Eso es útil cuando quiere un espacio de nombres interno estrecho y peligroso cuando a la zona estrecha le falta un registro que la más amplia tiene. Las consideraciones sobre zonas alojadas privadas en la documentación de Route 53 describen tanto el comportamiento de caída como la precedencia de las reglas, y vale la pena leerlas antes de añadir una segunda zona superpuesta.

Nada de esto cambia la zona pública. Los resolutores públicos siguen respondiendo correctamente los registros públicos, y por eso el fallo parece un problema del cliente para todos los que están fuera de la VPC.

Elija el espacio de nombres antes de añadir registros

Si solo una nueva familia de servicios internos necesita nombres privados, dele un subdominio privado dedicado y deje en paz al principal público. Un nombre como internal.example.net no puede ocultar www.example.net, y el radio de impacto de un registro ausente se limita a los nombres que inventó para ese propósito. El coste es que las URL y los certificados existentes pueden no coincidir con el nombre nuevo.

Cuando los usuarios públicos y privados deben conservar el mismo nombre de host, el DNS de vista dividida es el diseño admitido y exige que mantenga los registros en cada vista de forma explícita. Una zona privada amplia con un solo registro no conserva las dependencias públicas bajo esa zona; las sustituye por una zona que tiene un registro.

Haga inventario de los nombres que una aplicación llama realmente antes de dirigir una población de clientes a la vista privada. Los hosts de inicio de sesión, los de recursos estáticos, los destinos de redirección y los puntos de conexión de API son los primeros que se rompen, y suelen estar repartidos entre los registros de varios equipos.

Siga la ruta del resolutor y luego la ruta de red

Un portátil solo ve la vista privada si sus consultas llegan al resolutor que tiene la asociación. Editar un archivo hosts en el servidor VPN no publica nada a los clientes conectados, y un cliente configurado con un resolutor público seguirá recibiendo respuestas públicas mientras el túnel esté activo. Confirme la dirección del resolutor que recibió el cliente y luego repita la consulta desde el cliente y no desde el servidor.

Una vez que el nombre se resuelve, pruebe la ruta hacia la dirección devuelta como paso aparte, por ejemplo con ip route get contra la dirección que devolvió la consulta. Una respuesta privada correcta sin ruta hacia la dirección es un problema de enrutamiento, y una respuesta de registro ausente es un problema de vista de DNS; tratarlos como un solo asunto produce correcciones que no se sostienen. Deje sin cambios las comprobaciones del nombre de host TLS y del certificado, porque una dirección privada cambia a dónde va la conexión y nada sobre qué certificado es válido.

Termine anotando en la nota de cambio la zona, la asociación, el resolutor y los nombres que verificó. Así la siguiente persona que añada un registro sabrá qué espacio de nombres es autoritativo para esa población de clientes.