La recursión no está disponible: una política de DNS, no un túnel roto

El nombre interno se resuelve, y el mismo servidor responde a un nombre externo con una denegación sobre la recursión. Esa combinación no es una contradicción. Publicar sus propias zonas y resolver todo internet son dos servicios separados que un servidor puede ofrecer, y puede hacer el primero sin el segundo. Trata la denegación como una declaración de política y luego comprueba si la política coincide con el diseño.

Una denegación y un tiempo de espera son respuestas distintas

Anota el nombre, el tipo de consulta, el servidor que responde, el estado y los registros devueltos. Un aviso de recursión no invalida automáticamente una respuesta autoritativa que llegó con él. Escribe el estado antes de interpretarlo. Un estado reconstruido de memoria una hora después es un hecho distinto.

La cabecera DNS lleva una petición de recursión y una indicación de si el servidor la ofrece, y la especificación del protocolo mantiene esos indicadores separados de los datos de la respuesta. Por eso una respuesta puede ser útil y aun así llevar una queja. Un tiempo de espera, una respuesta negativa y una denegación son tres resultados diferentes. Cada uno apunta a una capa distinta, y solo la denegación es el servidor diciéndote algo sobre la política.

Lee primero el código de estado y luego decide si el aviso importa para esta consulta. Una respuesta autoritativa que nombra la zona es utilizable incluso cuando se deniega el bit recursivo. Una denegación sin respuesta es un resultado de política, no una ruta de paquetes rota.

Qué registró el resolutor como tu origen

El cliente puede llegar desde un conjunto de direcciones fuera de los rangos recursivos permitidos del servidor, o una traducción puede hacer que parezca una puerta de enlace. La dirección del propio adaptador del cliente no es prueba de lo que recibió el resolutor. Pide al administrador del servidor el origen observado en lugar de inferirlo desde tu lado del camino. Las dos direcciones pueden diferir en cada salto que traduce.

Consulta el mismo nombre desde el cliente y desde un equipo en el que el servidor ya confía. La diferencia entre las dos respuestas es la condición de origen, y es más útil que cualquiera de las respuestas por separado.

dig +short host.corp.example
dig +short example.com

Si el despliegue quiere recursión para clientes de VPN, el administrador autoriza el rango de origen adecuado mediante los propios controles del servidor. Abrir la recursión a todas las redes para que pase una prueba es un cambio mucho mayor que el que se está probando. Escribe el rango autorizado junto a la regla, porque el siguiente revisor preguntará a qué orígenes debía servir la política. Un rango de origen sin propietario es la forma en que una prueba temporal se vuelve permanente.

El DNS dividido es un diseño, no una falla

Algunos despliegues envían solo los dominios de trabajo al resolutor privado y todo lo demás a otro resolutor aprobado. Eso es un diseño de enrutamiento de consultas, y no es prueba de que el servidor privado necesite una política más laxa. Con ese diseño, un nombre externo que falla a través del resolutor privado es el resultado previsto y no una falla. La denegación es el diseño funcionando, no un síntoma que haya que silenciar.

Un resolutor público puede restaurar la navegación mientras rompe nombres internos o envía consultas privadas donde no deberían ir. Escribe el comportamiento previsto antes de cambiar cualquier dirección de resolutor.

Verifica la política con dos consultas

Tras la corrección prevista, consulta un nombre privado permitido y un nombre externo desde el cliente real. Lo que vuelva debería ser lo que promete la política, no solo un diagnóstico más silencioso. Anota el servidor que responde con cada respuesta y luego compara la pareja con la política. La comparación es la prueba, y una sola búsqueda exitosa no lo es.

resolvectl query host.corp.example
resolvectl query example.com

Si el nombre privado funciona y el nombre público es denegado, la política hace lo que dice. Si el nombre privado también falla, el problema es la zona, la ruta o la autorización de origen, y la recursión es una distracción. Ambos resultados son útiles, y cada uno descarta la mitad de las hipótesis restantes.

Lee la denegación como evidencia

Una denegación es una respuesta. Significa que el servidor recibió la consulta y se negó a hacer el trabajo solicitado, lo cual es distinto de un paquete que nunca llegó. Esa distinción es todo el diagnóstico. Regístrala como una respuesta y no como un fallo de conectividad.

Esa distinción te dice dónde mirar: los registros del servidor, su política de acceso y el origen que registró. Un cambio de cortafuegos no puede arreglar una denegación de política, y un cambio de política no puede arreglar una ruta que falta. Mantén las dos hipótesis separadas hasta que una tenga evidencia.

Escribe el resultado y el propietario de la política en el ticket, para que la siguiente persona empiece por la decisión y no por el aviso. Nombra el rango de origen autorizado y los dos nombres que probaste. Un ticket con esos tres hechos se puede volver a ejecutar; uno que diga "la recursión está rota", no.