Configurar correctamente la caché del resolutor de NGINX

Entender el resolutor de NGINX y la caché de DNS

Un proxy inverso necesita, en primer lugar, una dirección IP para un backend con nombre de host. El Resolver de NGINX Para ello, consulta los servidores de nombres especificados en la configuración. La respuesta DNS recibida se almacena en caché, de modo que NGINX no tenga que volver a resolver el nombre para cada solicitud mientras dure su validez. Esta caché se aplica exclusivamente a la resolución de nombres del sistema de destino.

La directiva resolver contiene una o varias direcciones de resolutor o identificadores de resolutor compatibles. Si no se especifica un puerto diferente, NGINX utiliza el puerto 53; si hay varios servidores registrados, las solicitudes se distribuyen mediante el método «round-robin», según la documentación. Para una configuración de arranque robusta, suele ser recomendable utilizar direcciones IP fijas, ya que su resolución no depende del propio DNS.

De forma predeterminada, NGINX tiene en cuenta las direcciones IPv4 e IPv6 de un nombre. Esto resulta adecuado cuando la red transmite de forma fiable ambas familias de protocolos hasta el backend. Parámetros como ipv4=off o ipv6=off Excluyen de forma específica a una familia, pero no constituyen una optimización general de la caché. Su necesidad depende de la accesibilidad del backend concreto y no de la mera existencia de un registro AAAA.

El resolver no es ni un servidor DNS recursivo en toda regla ni una transferencia automática de todos los ajustes desde /etc/resolv.conf. NGINX utiliza los servidores de nombres especificados explícitamente. Para las zonas internas y los nombres de backend en producción, estos deben ser resolvers de confianza y debidamente protegidos, ubicados en la propia red. De este modo, la responsabilidad sobre los nombres privados y la protección frente a respuestas DNS manipuladas permanecen dentro de una infraestructura controlable.

La caché DNS no es una caché HTTP

La caché de respuestas DNS del resolutor almacena las asignaciones entre nombres y respuestas DNS, como direcciones A o AAAA. Su finalidad es poder volver a acceder a un servidor backend sin tener que repetir cada resolución de nombre. Por lo tanto, si cambia la dirección IP de un servidor backend, lo relevante es la validez de la respuesta DNS, y no el contenido de una respuesta HTTP enviada anteriormente.

Por separado, almacena proxy_cache Respuestas HTTP de un servidor ascendente. La clave incluye, según la configuración, por ejemplo, el URI, el host o el encabezado; una coincidencia proporciona al cliente una respuesta ya almacenada. Los problemas que pueden surgir aquí son páginas obsoletas, variantes incorrectas o coincidencias inesperadas en la caché. Esta función no determina qué dirección IP utiliza NGINX al establecer una nueva conexión con el backend.

La caché de archivos abiertos constituye un tercer nivel: almacena información de archivos y descriptores abiertos para el acceso al sistema de archivos local, pero no respuestas DNS ni contenidos HTTP. Quien desee profundizar en esta distinción para la distribución estática, puede encontrarla en el artículo sobre la Configuración de la caché de archivos abiertos de NGINX. Sin embargo, no ofrece ninguna base para decidir qué TTL de resolutor elegir.

Por lo tanto, vaciar, purgar o actualizar una caché HTTP no acelera un cambio en el DNS. Por el contrario, una nueva resolución de DNS no corrige una respuesta HTTP almacenada en caché de forma errónea. En el caso del proxy inverso, el Caché de DNS Además, se basa en nombres y direcciones: no comprueba el estado de una aplicación ni sustituye el equilibrio de carga, los reintentos ni la planificación correcta de los tiempos de espera con respecto al servidor de origen.

Cuándo debe NGINX volver a resolver los nombres

NGINX puede conocer un nombre de host ya en el momento de leer la configuración. El caso es diferente cuando se trata de un destino variable, como por ejemplo proxy_pass http://$backend;. NGINX busca primero el nombre resultante en los grupos de upstream definidos. Si no encuentra allí ningún nombre que coincida, necesita un resolver configurado en tiempo de ejecución para determinar la dirección de destino.

El mensaje no resolver defined En este contexto, no indica que falte una caché HTTP. Significa que NGINX no conoce ningún servidor DNS para la resolución necesaria en tiempo de ejecución. resolver puede utilizarse en el contexto http, server o location se encuentra. Una entrada clave en el httpEl bloque es adecuado cuando varios hosts virtuales utilizan el mismo resolutor; un ámbito más restringido solo es adecuado si los requisitos son realmente diferentes.

Hay que distinguir esta resolución de tiempo de ejecución, disponible desde hace tiempo, de la actualización dinámica de un grupo «upstream» clásico. La configuración del resolutor directamente en el upstream-Bloque, así como server hostname resolve Según la documentación de NGINX, están disponibles en la versión de código abierto a partir de la 1.27.3. Las instalaciones de código abierto anteriores no deben considerarse compatibles automáticamente con este patrón; históricamente, algunas de estas funciones estaban reservadas a NGINX Plus.

Antes de planificar los «upstreams» dinámicos, comprueba la información de compilación y de la versión instalada. El siguiente comando muestra la versión de NGINX, la versión del compilador y los parámetros de «configure» utilizados durante la compilación.

nginx -V

Compara el estado que se muestra en las implementaciones críticas con la documentación del paquete concreto utilizado y la de su proveedor. Lo determinante es si dicha instalación documenta y proporciona la función necesaria. Solo entonces se puede considerar un Upstream dinámico una decisión arquitectónica sólida.

Establecer TTL y valid de forma deliberada

La caché del resolutor de NGINX se rige, a falta de una configuración adicional, por la DNS-TTL en la respuesta del servidor de nombres consultado. Si el operador de DNS autoritativo modifica la dirección IP de un servidor backend, NGINX utiliza la respuesta anterior hasta que expire su TTL. Solo cuando sea necesaria una nueva resolución de nombres, NGINX volverá a consultar al resolver. De este modo, el periodo de validez se puede controlar allí donde se gestionan los datos de los nombres.

El parámetro valid sustituye por completo este TTL por el periodo configurado. Por lo tanto, no solo limita el TTL del DNS por arriba, sino que tampoco define una actualización periódica adicional al TTL. Un valor de valid=30s Puede acortar un TTL de DNS más largo, pero también alargar un TTL que se haya establecido deliberadamente corto. Esto debe ajustarse a la planificación de la migración y la implementación del backend.

Si la zona se mantiene de forma fiable, una configuración sin anulación es el punto de partida más lógico. La dirección del ejemplo se ha elegido de acuerdo con las redes de la documentación y no debe utilizarse como resolutor en producción. En su lugar, introduce la dirección de un resolutor DNS accesible y fiable de tu propia red.

resolver 192.0.2.53;
resolver_timeout 5s;

Una anulación puede resultar útil cuando no es posible modificar el TTL del DNS y existe una directriz operativa documentada. En ese caso, la desviación muestra de forma explícita durante cuánto tiempo NGINX mantiene las respuestas. No se trata de una optimización general del rendimiento: unos tiempos más cortos pueden generar más consultas DNS, mientras que unos tiempos más largos pueden retrasar el cambio a nuevas direcciones de backend.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

Por lo tanto, la decisión no parte de una indicación concreta de segundos, sino de la cuestión de quién controla los datos del DNS y con qué rapidez debe surtir efecto un cambio en el backend. válido supone una modificación deliberada de esta configuración. No es adecuado como solución general para acelerar el proxy inverso ni para ocultar problemas de DNS.

Resolver correctamente las variables en `proxy_pass`

Contiene proxy_pass una variable, NGINX debe gestionar el nombre de host resultante en tiempo de ejecución. En primer lugar, NGINX busca un grupo de servidores upstream adecuado; si no lo encuentra, necesita un resolutor configurado para ese nombre. Si no lo hay, el mensaje habitual es no resolver defined No se trata de un problema relacionado con la caché HTTP, sino de la falta de configuración de DNS para esta ruta de ejecución.

El siguiente ejemplo muestra de forma deliberada la resolución en tiempo de ejecución. El resolutor se encuentra en el http-Contexto y, por lo tanto, se aplica a varios hosts virtuales, siempre que no haya una configuración más específica que la anule. La dirección de documentación utilizada debe sustituirse por el resolutor interno del entorno correspondiente.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

        location / {
            set $backend api.internal.example;
            proxy_pass http://$backend;
        }
    }
}

La directiva resolver_timeout No controla la duración de la caché. Limita el tiempo que NGINX espera para resolver un nombre; el valor predeterminado documentado es de 30 segundos. La elección forma parte del resto de los «presupuestos de error»: un valor demasiado alto puede retrasar una solicitud fallida hasta que se reciba una respuesta de error, mientras que un valor demasiado bajo genera errores de resolución evitables cuando los resolutores internos funcionan con lentitud de forma ocasional.

Para una ubicación concreta y claramente delimitada, el resolver puede, en el location-Bloque. Si varias ubicaciones o servidores necesitan la misma resolución, se debe definir un ámbito común en el server- o http-Block requiere menos mantenimiento. NGINX permite esta directiva en los tres contextos; el ámbito de aplicación debería reflejar la estructura operativa real, y no limitarse a solucionar un único mensaje de error a corto plazo.

Incluso en el caso de destinos variables, el tiempo de espera del DNS y la conexión con el backend siguen siendo clases de error distintas. Una resolución de nombre correcta no garantiza ni que el puerto de destino sea accesible ni que la aplicación responda. Por el contrario, un tiempo de espera de upstream más largo no soluciona el problema de una dirección de resolutor inaccesible.

Configurar «upstreams» dinámicos con «resolve»

Para un grupo de backends específico, un «upstream» dinámico puede resultar más claro que un valor de destino variable en cada ubicación. Este patrón separa la definición de los miembros del backend del enrutamiento: proxy_pass Hace referencia al grupo, mientras que el nombre de host del servidor de origen se puede actualizar a través del DNS. Esto resulta especialmente adecuado cuando varias rutas apuntan a la misma aplicación.

El parámetro resolve para un server-Esta entrada existe históricamente desde NGINX 1.5.12. Sin embargo, según la documentación, en NGINX Open Source solo está disponible a partir de la versión 1.27.3; anteriormente, esta función estaba restringida a la versión comercial. La configuración del resolutor directamente en el upstreamEl bloque está documentado para código abierto a partir de la versión 1.27.3.

El Zona de memoria compartida No se trata ni de un tiempo de espera de la caché ni de una ruta de datos DNS. Proporciona memoria compartida dentro de NGINX, necesaria para las configuraciones de upstream que cambian dinámicamente. Si NGINX detecta otras direcciones para el nombre durante la resolución de DNS, el grupo de servidores de origen se puede ajustar en función de este estado gestionado internamente sin necesidad de reiniciar el sistema.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    upstream application_pool {
        zone application_pool 64k;
        server app.internal.example resolve;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://application_pool;
        }
    }
}

Al igual que en todos los ejemplos, se aplica lo siguiente: 192.0.2.53 solo para una dirección de documentación. En la práctica, el resolutor registrado debe conocer de forma fiable los nombres internos, ser accesible desde la red de NGINX y considerarse fiable. Además, antes de aplicarlo, hay que comprobar el alcance real de las funciones del paquete instalado, en lugar de basar la configuración únicamente en un ejemplo actual.

Un servicio al que solo se puede acceder a través de IPv4 puede justificar una restricción específica: resolver 192.0.2.53 ipv6=off; Impide las consultas AAAA y la selección de una dirección IPv6 para este contexto de resolutor. No obstante, se trata de una decisión relacionada con la arquitectura de la red. Si la pila dual funciona correctamente, no se debe desactivar IPv6 solo por costumbre; por defecto, NGINX resuelve ambas familias de direcciones IP.

Comprobar minuciosamente la configuración e implementarla

Antes de realizar cualquier cambio, comprueba primero en qué puntos se aplican realmente las directivas del resolutor. Para ello, busca la configuración activa, incluidos los archivos incorporados, y aclara si el resolutor se aplica a todo el http-Contexto: está destinado únicamente a un host virtual o a una sola ruta. Un ámbito demasiado restringido puede hacer que otra ruta de proxy variable no encuentre un resolutor; por el contrario, un ámbito demasiado amplio dificulta la asignación posterior de los cambios.

Tras cada ajuste, viene el Comprobación sintáctica. Lee la configuración e intenta abrir también los archivos a los que se hace referencia. De este modo, se pueden detectar errores ortográficos, directivas no válidas y problemas en los archivos «include» antes de una recarga. Sin embargo, esta comprobación no garantiza que el servidor DNS indicado sea accesible, que reconozca el nombre esperado o que el backend situado detrás de una dirección resuelta acepte conexiones.

nginx -t
nginx -s reload

No realices la recarga hasta que la comprobación se haya realizado con éxito. nginx -s reload Hace que NGINX inicie nuevos trabajadores con la nueva configuración y cierre de forma controlada los antiguos. Dependiendo del paquete instalado y del sistema operativo, es posible que sea el gestor de servicios correspondiente el que active la recarga. Para ello, utiliza el procedimiento de funcionamiento documentado de la instalación, en lugar de aplicar comandos desde un entorno externo.

A continuación, planifica una comprobación técnica dentro del plazo previsto para la modificación. Compara el TTL del DNS previsto con el momento a partir del cual se utilizará una nueva dirección de backend y comprueba la accesibilidad del servicio a través de la familia de direcciones IP realmente permitida. Documenta, además, la dirección del resolutor, el ámbito seleccionado y un posible valid-Override. De este modo, en caso de fallo, se puede determinar si la causa es el DNS, el enrutamiento o la aplicación.

Localizar de forma sistemática los errores típicos del resolver

Empieza a buscar el error en la expresión de destino en proxy_pass. Si contiene una variable, NGINX deberá resolver el nombre de host que contiene en tiempo de ejecución, siempre que este no pertenezca a un grupo de servidores upstream definido. El mensaje no resolver defined por lo tanto, señala en primer lugar la ausencia de un elemento o que este no sea visible en el contexto relevante Configuración del resolutor . Añade un servidor de nombres fiable en el contexto adecuado, en lugar de sustituir precipitadamente el nombre de host por una dirección IP fija.

Si hay un resolutor configurado, lo siguiente que debes comprobar es su dirección, ruta de red y competencia para la zona utilizada. Un resolutor público no puede conocer los nombres internos; por el contrario, un resolutor inaccesible provoca tiempos de espera en la resolución. Comprueba también si la directiva se ve anulada por una configuración más específica. NGINX solo utiliza los servidores de nombres especificados expresamente, no aplica automáticamente todas las configuraciones de /etc/resolv.conf.

Si tras un cambio de DNS sigue activa una dirección de destino antigua, comprueba el TTL de respuesta y si está activado un valid. Una anulación prolongada sustituye el TTL de la respuesta DNS y puede retrasar en consecuencia la aplicación de un cambio. La corrección admisible no es una duración lo más corta posible de forma general, sino un valor que se adapte a la ventana de cambio y a la capacidad de la infraestructura DNS; a menudo, la omisión de valid la solución más limpia.

Si se producen problemas de conexión tras una resolución correcta, separa el DNS de la conexión al backend. Comprueba si hay respuestas A y AAAA y si el destino se enruta y es accesible realmente a través de IPv6. ipv6=off Solo es adecuado para un caso de arquitectura en el que se demuestre que funciona exclusivamente con IPv4. Un tiempo de espera de DNS afecta a la resolución de nombres; por el contrario, un error de conexión a una dirección IP ya conocida se debe a problemas de enrutamiento, cortafuegos, puertos o aplicaciones.

En el caso de los «upstreams» dinámicos, también deben indicarse el número de versión, la zona de memoria compartida y resolve son compatibles. La compatibilidad con el código abierto documentada a este respecto es válida a partir de NGINX 1.27.3; las instalaciones anteriores no deben considerarse equivalentes. status_zone Además, las estadísticas de los resolutores basadas en API no constituyen una solución de supervisión general para NGINX Open Source, ya que las funciones mencionadas se refieren al ámbito comercial.

Seleccionar una estrategia de resolver para el funcionamiento

La estrategia adecuada no parte de un valor de caché genérico, sino del control sobre el DNS y la frecuencia de cambios. Si tu equipo puede gestionar la zona autoritativa y los TTL de esta reflejan de forma realista la ventana de implementación, entonces una Resolución controlada por TTL sin valid suele ser el punto de partida más lógico. El DNS sigue siendo, por tanto, la fuente de referencia para determinar durante cuánto tiempo se utiliza una respuesta.

Un acento colocado a propósito valid Es una opción válida si no puedes modificar el TTL y puedes justificar operativamente una duración de caché diferente. Ten en cuenta qué consecuencias de la interrupción del servicio son aceptables: un valor más largo reduce las posibles consultas DNS, pero puede apuntar a una dirección que ya no sea válida tras un traslado. No es ni un límite máximo para el TTL del DNS ni un regulador general del rendimiento.

Selecciona a continuación el patrón de NGINX en función de la estructura de enrutamiento. Una variable proxy_pass Es adecuado cuando el destino se determina en tiempo de ejecución para cada solicitud o configuración; para ello se necesita un resolutor en el ámbito adecuado. Para un grupo de backends con nombre y cambios de dirección basados en DNS, se necesita un upstream con zone y resolve Está claro, siempre y cuando NGINX Open Source 1.27.3 o una versión posterior esté realmente disponible.

Solo entonces decides Tiempos de espera y familias de direcciones IP. El tiempo de espera del resolutor debe coincidir con los tiempos de espera del cliente y del servidor de origen, para que la ausencia de una respuesta DNS no provoque retrasos desproporcionados. Solo debes habilitar IPv4 o IPv6 según la arquitectura de la red. Utiliza exclusivamente resolutores seguros que puedan responder de forma fiable a las zonas internas.

La resolución de DNS y el «upstream keepalive» cumplen funciones diferentes. El resolutor determina qué dirección de backend puede utilizar NGINX; el «keepalive» mantiene las conexiones de backend ya establecidas, aunque estén inactivas, para su reutilización. Por lo tanto, un cambio en la reutilización de conexiones no sustituye ni a la planificación del TTL ni a la comprobación del resolutor. Para el dimensionamiento de este nivel de conexión, el artículo sobre Keepalive de NGINX en el upstream la estrategia del resolver.