El DNS privado funciona en la VPC pero no a través de la VPN
Un nombre privado que resuelve dentro de EC2 pero no a través de la VPN es un problema de ruta del resolver. Lee la forma del fallo antes de editar el registro de la zona.
Un nombre privado resuelve desde una instancia EC2 pero no desde un portátil conectado por la VPN, y la zona se ve correcta en la consola. El instinto es editar el registro, que casi nunca es el problema. El registro responde a alguien; simplemente no responde a tu portátil. Lo que cambia entre los dos clientes es qué resolver consultan y si ese resolver tiene una ruta admitida hacia la vista DNS de la VPC.
Empiezo demostrando que el registro existe y dedico el resto del tiempo a la ruta de la consulta. Son sistemas separados y fallan de maneras distintas.
Lee la forma del fallo antes de cambiar nada
Tres resultados significan tres cosas distintas, y una sola consulta los distingue: ejecuta dig para el nombre contra el resolver que el cliente usa realmente.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Un tiempo de espera es una afirmación sobre la red. NXDOMAIN es una afirmación sobre la vista DNS. Una respuesta pública es una afirmación sobre la política. Editar un registro de zona mientras hay un tiempo de espera tira a la basura la única prueba útil del caso.
Por qué la dirección más dos de la VPC no es un resolver remoto
La dirección CIDR más dos es un servicio local para los recursos dentro de la VPC. AWS documenta que reenviar consultas desde redes locales, o desde los servidores DNS de otra VPC, directamente a esa dirección no está admitido y puede producir resultados inestables.
Eso no significa que un experimento nunca parezca funcionar. Significa que el comportamiento no es un contrato que puedas poner en un guion de soporte. La dirección admitida es un endpoint de Resolver de entrada: un par de direcciones dentro de tu VPC, accesible desde la red que controlas, que acepta consultas que llegan desde fuera de AWS.
Construye la ruta en el orden en que falla limpiamente
Tienen que existir tres saltos, y cada uno tiene su propia forma de fallar.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesEl reenviador necesita una ruta hacia las direcciones del endpoint a través de la VPN, y la ruta de vuelta también tiene que funcionar. Para el DNS convencional en el puerto 53 el endpoint responde por UDP y TCP, así que hay que permitir ambos protocolos y ambos tienen que sobrevivir a cualquier inspección con estado en medio.
Después revisa la vista DNS por separado. Una zona alojada privada solo es visible para las VPC con las que está asociada, o mediante un acuerdo de compartición deliberado. Un endpoint accesible no hace por sí solo que todas las zonas privadas sean resolubles en su contexto de resolución.
Un endpoint de salida sirve en la dirección opuesta y no responderá a una consulta que llegue desde tu portátil.
Verifica desde ambos extremos
Consulta desde el cliente contra el reenviador y luego desde el reenviador contra el endpoint. Si el cliente falla mientras el reenviador acierta, la brecha está entre esos dos.
Si fallan ambos, mira la política de seguridad del endpoint y la dirección de origen que ve realmente. Un reenviador detrás de NAT presenta la dirección NAT en lugar de la dirección VPN del portátil, y esa diferencia por sí sola basta para descartar la consulta. Si ambos aciertan pero la aplicación sigue fallando, puede que la aplicación use un resolver distinto del que probaste.
Mantén separados a propósito los espacios de nombres públicos y privados. El DNS dividido es una política que configuras, no un efecto secundario de que una consulta devuelva datos por casualidad.
Lo que no haría
No añadiría una regla NAT que hiciera funcionar una sola consulta y lo llamaría diseño.
No apuntaría a todos los clientes remotos a la dirección más dos porque una prueba devolvió un registro una vez. Y no ampliaría la política de seguridad del endpoint a todo el grupo de VPN cuando un solo reenviador necesita acceso. Si la organización ya ejecuta un reenviador aprobado dentro de la VPC, lee ese diseño primero, porque el segundo endpoint que añadas es el que nadie documenta.