Configurer correctement le cache du résolveur NGINX

Comprendre le résolveur NGINX et le cache DNS

Pour un backend dont le nom d'hôte est connu, un proxy inverse a d'abord besoin d'une adresse IP. Le Résolveur NGINX interroge pour cela les serveurs de noms définis dans la configuration. La réponse DNS obtenue est mise en cache afin que NGINX n'ait pas à résoudre à nouveau le nom pour chaque requête pendant sa durée de validité. Ce cache concerne exclusivement la résolution du nom vers le système cible.

La directive resolver contient une ou plusieurs adresses de résolveur ou des identifiants de résolveur pris en charge. En l'absence d'indication de port, NGINX utilise le port 53 ; lorsque plusieurs serveurs sont répertoriés, les requêtes sont traitées selon le principe du « round-robin », conformément à la documentation. Pour une configuration de démarrage robuste, les adresses IP fixes sont souvent préférables, car leur résolution ne dépend pas elle-même du DNS.

Par défaut, NGINX prend en charge les adresses IPv4 et IPv6 associées à un nom. Cela convient lorsque le réseau achemine de manière fiable les deux familles de protocoles jusqu'au backend. Des paramètres tels que ipv4=off ou ipv6=off Elles excluent délibérément une famille, mais ne constituent pas une optimisation générale du cache. C'est l'accessibilité du backend concerné qui détermine si elles sont nécessaires, et non la simple existence d'un enregistrement AAAA.

Le résolveur n'est ni un serveur DNS récursif à part entière, ni un outil permettant la reprise automatique de tous les paramètres depuis /etc/resolv.conf. NGINX utilise les serveurs de noms explicitement spécifiés. Pour les zones internes et les noms de backends en production, il est recommandé d’utiliser des résolveurs fiables et correctement sécurisés au sein de votre propre réseau. Cela permet de maintenir la responsabilité des noms privés et la protection contre les réponses DNS falsifiées au sein d’une infrastructure contrôlable.

Le cache DNS n'est pas un cache HTTP

Le cache de réponses DNS du résolveur stocke les correspondances entre les noms et les réponses DNS, telles que les adresses A ou AAAA. Son objectif est de pouvoir accéder à nouveau à un serveur backend sans avoir à répéter à chaque fois la résolution du nom. Si l'adresse IP d'un serveur backend change, c'est donc la validité de la réponse DNS qui importe, et non le contenu d'une réponse HTTP fournie précédemment.

Il enregistre cela séparément proxy_cache Réponses HTTP d'un serveur en amont. Selon la configuration, la clé peut par exemple inclure l’URI, l’hôte ou l’en-tête ; une correspondance renvoie au client une réponse déjà mise en cache. Les problèmes qui peuvent survenir ici se traduisent par des pages obsolètes, des variantes erronées ou des accès au cache inattendus. Cette fonction ne détermine pas quelle adresse IP NGINX utilise lors de l’établissement d’une nouvelle connexion au backend.

Le cache des fichiers ouverts constitue un troisième niveau : il stocke les informations relatives aux fichiers et les descripteurs ouverts pour les accès au système de fichiers local, mais ni les réponses DNS ni les contenus HTTP. Si vous souhaitez approfondir cette distinction dans le cadre de la diffusion statique, vous trouverez des informations à ce sujet dans l'article consacré à la Configuration du cache de fichiers ouverts NGINX. Il ne fournit toutefois aucune base de décision pour le choix d'un TTL de résolveur.

Le vidage, la purge ou l'actualisation d'un cache HTTP n'accélère donc pas une modification du DNS. À l'inverse, une nouvelle résolution DNS ne corrige pas une réponse HTTP mise en cache de manière erronée. Dans le cas d'un proxy inverse, le Cache DNS Il se limite en outre aux noms et adresses : il ne vérifie pas le bon fonctionnement d'une application et ne remplace pas l'équilibrage de charge, les tentatives de reconnexion ou la gestion correcte des délais d'expiration vers l'amont.

Quand NGINX doit-il effectuer une nouvelle résolution de nom ?

Un nom d'hôte peut déjà être connu de NGINX lors de la lecture de la configuration. Il en va autrement pour une cible variable, par exemple proxy_pass http://$backend;. NGINX recherche d'abord le nom obtenu dans les groupes en amont définis. S'il n'y trouve pas de nom correspondant, il a besoin, au moment de l'exécution, d'un résolveur configuré pour déterminer l'adresse de destination.

Le message no resolver defined Dans ce contexte, cela n'indique pas l'absence de cache HTTP. Cela signifie que NGINX ne connaît aucun serveur DNS pour effectuer la résolution nécessaire au moment de l'exécution. resolver peut, dans ce contexte, http, server ou location se trouvent. Une entrée centrale dans le httpLe bloc - est adapté lorsque plusieurs hébergeurs virtuels utilisent le même résolveur ; une portée plus restreinte n'est justifiée que si les exigences diffèrent réellement.

Il convient de distinguer cette résolution de durée, disponible depuis longtemps, de la mise à jour dynamique d'un groupe « upstream » classique. La configuration du résolveur directement dans le upstream- le bloc ainsi que server hostname resolve Selon la documentation, ces fonctionnalités sont disponibles dans la version open source de NGINX à partir de la version 1.27.3. Les installations open source plus anciennes ne doivent pas être considérées comme prenant automatiquement en charge ce modèle ; historiquement, certaines de ces fonctionnalités étaient réservées à NGINX Plus.

Avant de planifier des flux en amont dynamiques, vérifie les informations relatives à la version installée et à la compilation. La commande suivante affiche la version de NGINX, la version du compilateur et les paramètres de configuration utilisés lors de la compilation.

nginx -V

Pour les déploiements critiques, comparez l'état affiché avec la documentation du paquet concrètement utilisé et celle de son fournisseur. Ce qui importe, c'est de savoir si cette installation documente et fournit la fonctionnalité requise. Ce n'est qu'ensuite qu'un en amont dynamique un choix architectural solide.

Définir explicitement les paramètres TTL et valid

Sans paramètre supplémentaire, le cache du résolveur de NGINX suit la DNS-TTL dans la réponse du serveur de noms interrogé. Si l'opérateur DNS faisant autorité modifie l'adresse IP d'un serveur backend, NGINX utilise la réponse précédente jusqu'à l'expiration de son TTL. Ce n'est que lorsqu'une nouvelle résolution de nom est nécessaire par la suite que NGINX interroge à nouveau le résolveur. La durée de validité reste ainsi contrôlable là où les données de nom sont gérées.

Le paramètre valid remplace entièrement ce TTL par la durée configurée. Il ne se contente donc pas de limiter la durée maximale du TTL DNS, mais ne définit pas non plus de rafraîchissement régulier en plus du TTL. Une valeur de valid=30s Cela permet de raccourcir un TTL DNS trop long, mais aussi de prolonger un TTL délibérément court. Cela doit s'inscrire dans le cadre de la planification de la migration et du déploiement du backend.

Si la zone est gérée de manière fiable, une configuration sans remplacement constitue le point de départ logique. L'adresse indiquée dans l'exemple est choisie conformément aux réseaux de documentation et ne doit pas être reprise comme résolveur en production. Saisissez plutôt l'adresse d'un résolveur DNS accessible et fiable issu de votre propre réseau.

resolver 192.0.2.53;
resolver_timeout 5s;

Une redéfinition peut s'avérer utile lorsque le TTL DNS ne peut pas être modifié et qu'il existe une consigne opérationnelle documentée. Dans ce cas, cette dérogation indique clairement pendant combien de temps NGINX conserve les réponses. Il ne s'agit pas d'une optimisation générale des performances : des durées plus courtes peuvent entraîner davantage de requêtes DNS, tandis que des durées plus longues peuvent retarder la bascule vers de nouvelles adresses backend.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

La décision ne commence donc pas par une indication précise en secondes, mais par la question de savoir qui contrôle les données DNS et dans quel délai un changement de serveur backend doit prendre effet. valide Il s'agit d'une modification délibérée de cette règle. Elle ne doit pas être utilisée comme une solution universelle pour accélérer le proxy inverse ou masquer des problèmes de DNS.

Résolution correcte des variables dans proxy_pass

Contient proxy_pass une variable, NGINX doit traiter le nom d'hôte résultant lors de l'exécution. NGINX recherche d'abord un groupe en amont correspondant ; s'il n'en trouve pas, il a besoin d'un résolveur configuré pour ce nom. Si celui-ci fait défaut, le message typique est no resolver defined Cela ne fait pas référence à un cache HTTP, mais à l'absence de configuration DNS pour ce chemin d'exécution.

L'exemple suivant met délibérément en évidence la résolution d'exécution. Le résolveur se trouve dans le http-contexte et s'applique donc à plusieurs hôtes virtuels, sauf si un paramètre plus spécifique le remplace. L'adresse de documentation utilisée doit être remplacée par le résolveur interne de l'environnement concerné.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

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

La directive resolver_timeout ne contrôle pas la durée de mise en cache. Elle limite le temps pendant lequel NGINX attend la résolution d'un nom ; la valeur par défaut documentée est de 30 secondes. Ce choix relève des autres marges d’erreur : une valeur trop élevée peut retarder une requête ayant échoué jusqu’à la réponse d’erreur, tandis qu’une valeur trop faible génère des erreurs de résolution évitables lorsque les résolveurs internes sont temporairement lents.

Pour un site unique et clairement délimité, le résolveur peut, dans le location-Block. Si plusieurs sites ou serveurs ont besoin de la même résolution, il faut définir une portée commune dans le server- ou bien http-Block nécessite moins de maintenance. NGINX autorise cette directive dans les trois contextes ; son champ d'application doit refléter la structure opérationnelle réelle, et non pas simplement permettre de résoudre un message d'erreur ponctuel.

Même avec des cibles variables, le délai d'expiration DNS et la connexion au backend restent deux catégories d'erreurs distinctes. Une résolution de nom réussie ne prouve ni que le port de destination est accessible, ni que l'application répond. À l'inverse, un délai d'expiration en amont plus long ne résout pas le problème d'une adresse de résolveur inaccessible.

Configurer des flux en amont dynamiques avec « resolve »

Pour un groupe de backends désigné, un « upstream » dynamique peut être plus lisible qu'une valeur cible variable dans chaque location. Ce modèle sépare la définition des membres du backend du routage : proxy_pass fait référence au groupe, tandis que le nom d'hôte en amont peut être mis à jour via le DNS. Cela s'avère particulièrement utile lorsque plusieurs routes pointent vers la même application.

Le paramètre resolve pour un server-Cette entrée existe depuis la version 1.5.12 de NGINX. Cependant, selon la documentation, elle n'est disponible dans la version open source de NGINX qu'à partir de la version 1.27.3 ; auparavant, cette fonctionnalité était réservée à la version commerciale. La configuration du résolveur directement dans le fichier upstreamLe bloc - est documenté pour Open Source à partir de la version 1.27.3.

Le Zone de mémoire partagée Il ne s'agit ni d'un délai d'expiration du cache ni d'un chemin d'accès aux données DNS. Elle met à disposition, au sein de NGINX, une mémoire partagée dont ont besoin les configurations en amont qui évoluent dynamiquement. Si NGINX détecte d’autres adresses pour le nom lors de la résolution DNS, le groupe en amont peut être ajusté à l’aide de cet état géré en interne, sans redémarrage.

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;
        }
    }
}

Comme dans tous les exemples, 192.0.2.53 Uniquement pour une adresse de documentation. Dans la pratique, le résolveur enregistré doit connaître de manière fiable les noms internes, être accessible depuis le réseau NGINX et être considéré comme fiable. Avant la mise en service, il convient également de vérifier l'étendue réelle des fonctionnalités du paquet installé, plutôt que de dériver la configuration uniquement à partir d'un exemple actuel.

Un service accessible exclusivement via IPv4 peut justifier une restriction ciblée : resolver 192.0.2.53 ipv6=off; empêche les requêtes AAAA et la sélection d'une adresse IPv6 pour ce contexte de résolveur. Il s'agit toutefois d'un choix d'architecture réseau. Lorsque la double pile fonctionne correctement, il ne faut pas désactiver IPv6 par simple habitude ; par défaut, NGINX résout les deux familles d'adresses IP.

Vérifier minutieusement la configuration et la déployer

Avant d'effectuer une modification, vérifie d'abord à quel endroit les directives du résolveur s'appliquent réellement. Pour cela, recherche la configuration active, y compris les fichiers inclus, et vérifie si le résolveur s'applique à l'ensemble du http-contexte, s'il est destiné uniquement à un hôte virtuel ou à un seul chemin d'accès. Une portée trop restreinte peut empêcher un autre chemin de proxy variable de trouver un résolveur ; à l'inverse, une portée trop large complique l'attribution ultérieure des modifications.

Chaque ajustement est suivi du Vérification syntaxique. Il lit la configuration et tente également d'ouvrir les fichiers référencés. Cela permet de détecter les fautes de frappe, les directives non valides et les problèmes dans les fichiers d'inclusion avant un rechargement. Ce contrôle ne prouve toutefois pas que le serveur DNS indiqué est accessible, qu’il connaît le nom attendu ou que le backend situé derrière une adresse résolue accepte les connexions.

nginx -t
nginx -s reload

N'effectuez le rechargement qu'après avoir vérifié que tout est en ordre. nginx -s reload Cela déclenche le redémarrage de NGINX avec la nouvelle configuration et la fermeture contrôlée des anciens workers. Selon le paquet installé et le système d'exploitation, c'est le gestionnaire de services prévu à cet effet qui peut déclencher le rechargement. Pour ce faire, utilisez la procédure d’installation documentée, plutôt que de reprendre des commandes provenant d’un environnement tiers.

Prévois ensuite un contrôle technique pendant la fenêtre de modification prévue. Comparez le TTL DNS attendu avec le moment à partir duquel une nouvelle adresse de backend doit être utilisée, et vérifiez l’accessibilité du service via la famille d’adresses IP effectivement autorisée. Documentez également l’adresse du résolveur, la portée choisie et un éventuel valid-Override. Cela permet, en cas de dysfonctionnement, de déterminer si celui-ci est dû au DNS, au routage ou à l'application.

Identifier systématiquement les erreurs typiques des résolveurs

Commence par rechercher l'erreur dans l'expression cible dans proxy_pass. S'il contient une variable, NGINX doit résoudre le nom d'hôte qu'elle contient lors de l'exécution, à moins que celui-ci n'appartienne à un groupe en amont défini. Le message no resolver defined souligne donc tout d'abord l'absence d'un élément ou le fait que celui-ci ne soit pas visible dans le contexte concerné Configuration du résolveur Ajoutez un serveur de noms fiable dans le contexte approprié, au lieu de remplacer trop vite le nom d'hôte par une adresse IP fixe.

Si un résolveur est configuré, vérifie ensuite son adresse, son chemin de réseau et sa compétence pour la zone utilisée. Un résolveur public ne peut pas connaître les noms internes ; en revanche, un résolveur inaccessible génère des délais d'expiration de résolution. Vérifie également si la directive est remplacée par un paramètre plus spécifique. NGINX utilise uniquement les serveurs de noms explicitement spécifiés, et non automatiquement tous les paramètres de /etc/resolv.conf.

Si une ancienne adresse de destination reste active après un changement de DNS, vérifie le TTL de réponse et la présence d'un valid. Une longue valeur d'override remplace le TTL de la réponse DNS et peut retarder d'autant la prise en compte d'une modification. La correction admissible n'est pas une durée forfaitaire aussi courte que possible, mais une valeur adaptée à la fenêtre de modification et à la capacité de l'infrastructure DNS ; souvent, l'omission de valid la solution la plus propre.

En cas de problèmes de connexion après une résolution réussie, désassocie le DNS de la connexion backend. Vérifie si des réponses A et AAAA sont disponibles et si la destination est effectivement routée et accessible via IPv6. ipv6=off ne convient qu'à un cas d'architecture dont il est prouvé qu'elle fonctionne exclusivement en IPv4. Un délai d'expiration DNS affecte la résolution de nom ; en revanche, une erreur de connexion vers une adresse IP déjà connue renvoie au routage, au pare-feu, au port ou à l'application.

Pour les flux en amont dynamiques, il faut également indiquer le numéro de version, la zone de mémoire partagée et resolve sont compatibles. La prise en charge open source documentée à cet effet s'applique à partir de la version NGINX 1.27.3 ; les installations antérieures ne doivent pas être considérées comme équivalentes. status_zone De plus, les statistiques du résolveur basées sur l'API ne constituent pas une solution de surveillance générale pour NGINX Open Source, car les fonctionnalités mentionnées concernent l'offre commerciale.

Choisir une stratégie de résolveur pour l'exploitation

Une stratégie adaptée ne commence pas par une valeur de cache forfaitaire, mais par la maîtrise du DNS et le taux de modification. Si ton équipe est en mesure de gérer la zone faisant autorité et si les TTL de celle-ci reflètent de manière réaliste la fenêtre de déploiement, alors une Résolution contrôlée par TTL sans valid c'est généralement le point de départ le plus logique. Le DNS reste alors la source de référence pour déterminer la durée d'utilisation d'une réponse.

Un choix délibéré valid Cette option est envisageable si vous ne pouvez pas modifier la durée de vie (TTL) et si vous pouvez justifier, d'un point de vue opérationnel, une durée de mise en cache différente. Déterminez dans ce cas quelle conséquence d’une indisponibilité est acceptable : une valeur plus longue réduit le nombre de requêtes DNS potentielles, mais peut, après un déménagement, pointer vers une adresse qui n’est plus valide. Elle ne constitue ni une limite maximale pour le TTL DNS, ni un levier général de performance.

Sélectionnez ensuite le modèle NGINX en fonction de la structure de routage. Une variable proxy_pass Cette option est adaptée lorsque la destination est déterminée au moment de l'exécution, en fonction de la requête ou de la configuration ; cela nécessite un résolveur dans la portée appropriée. Pour un groupe de backends nommé avec des changements d'adresse basés sur le DNS, un upstream avec zone et resolve C'est clair, à condition que la version 1.27.3 ou une version plus récente de NGINX Open Source soit effectivement disponible.

Ce n'est qu'ensuite que tu décides Délais d'expiration et familles d'adresses IP. Le délai d'expiration du résolveur doit correspondre aux délais d'expiration du client et de l'amont afin qu'une réponse DNS manquante n'entraîne pas de retard disproportionné. N'activez IPv4 ou IPv6 qu'en fonction de l'architecture du réseau. Utilisez exclusivement des résolveurs sécurisés, capables de répondre de manière fiable aux zones internes.

La résolution DNS et le Keepalive en amont remplissent des fonctions différentes. Le résolveur détermine quelle adresse de backend NGINX peut utiliser ; le Keepalive conserve les connexions backend déjà établies mais inactives en vue de leur réutilisation. Une modification de la réutilisation des connexions ne remplace donc ni la planification TTL ni la vérification par le résolveur. Pour le dimensionnement de ce niveau de connexion, l'article sur Keepalive en amont de NGINX la stratégie du résolveur.