Configurare correttamente la cache del resolver di NGINX

Comprendere il resolver NGINX e la cache DNS

Per un backend con nome host, un proxy inverso necessita innanzitutto di un indirizzo IP. Il Resolver NGINX a tal fine interroga i server dei nomi specificati nella configurazione. La risposta DNS ricevuta viene memorizzata nella cache, in modo che NGINX non debba risolvere nuovamente il nome per ogni richiesta durante il suo periodo di validità. Questa cache riguarda esclusivamente la risoluzione del nome verso il sistema di destinazione.

La direttiva resolver contiene uno o più indirizzi di resolver o identificatori di resolver supportati. Se non viene specificata una porta diversa, NGINX utilizza la porta 53; se sono presenti più server configurati, le richieste vengono gestite secondo l’algoritmo round-robin, come indicato nella documentazione. Per una configurazione bootstrap robusta, gli indirizzi IP fissi sono spesso preferibili, poiché la loro risoluzione non dipende a sua volta dal DNS.

Per impostazione predefinita, NGINX tiene conto degli indirizzi IPv4 e IPv6 associati a un nome. Ciò è appropriato se la rete trasmette in modo affidabile entrambe le famiglie di protocolli fino al backend. Parametri come ipv4=off oppure ipv6=off escludono in modo mirato una famiglia, ma non costituiscono un’ottimizzazione generale della cache. La loro necessità dipende dall’accessibilità del backend specifico e non dalla semplice esistenza di un record AAAA.

Il resolver non è né un server DNS ricorsivo a tutti gli effetti, né un sistema che importa automaticamente tutte le impostazioni da /etc/resolv.conf. NGINX utilizza i server dei nomi specificati esplicitamente. Per le zone interne e i nomi dei backend di produzione, è opportuno che i resolver siano affidabili e adeguatamente protetti all’interno della propria rete. In questo modo, la responsabilità per i nomi privati e la protezione dalle risposte DNS manomesse rimangono all’interno di un’infrastruttura controllabile.

La cache DNS non è una cache HTTP

La cache delle risposte DNS del resolver memorizza le associazioni tra nomi e risposte DNS, come gli indirizzi A o AAAA. Il suo scopo è quello di poter raggiungere nuovamente un backend senza dover ripetere ogni volta la risoluzione del nome. Se l’IP di un backend cambia, è quindi rilevante la validità della risposta DNS, non il contenuto di una risposta HTTP fornita in precedenza.

Separatamente da ciò, salva proxy_cache Risposte HTTP di un upstream. A seconda della configurazione, la chiave può includere, ad esempio, l'URI, l'host o l'intestazione; una corrispondenza fornisce al client una risposta già memorizzata. I problemi che possono verificarsi in questo caso sono pagine non aggiornate, varianti errate o hit della cache imprevisti. Questa funzione non determina quale indirizzo IP NGINX utilizzi quando stabilisce una nuova connessione al backend.

La cache dei file aperti costituisce un terzo livello: memorizza le informazioni sui file e i descrittori aperti per gli accessi al file system locale, ma non le risposte DNS né i contenuti HTTP. Chi desidera approfondire questa distinzione per la distribuzione statica, può trovare ulteriori informazioni nell'articolo dedicato a Configurazione della cache dei file aperti di NGINX. Tuttavia, non fornisce alcun criterio per la scelta del TTL del resolver.

Lo svuotamento, la pulizia o l’aggiornamento di una cache HTTP non accelera quindi l’aggiornamento del DNS. Viceversa, una nuova risoluzione DNS non corregge una risposta HTTP memorizzata in modo errato nella cache. Nel caso di un reverse proxy, il Cache DNS si basa inoltre su nomi e indirizzi: non verifica né la correttezza di un’applicazione, né sostituisce il bilanciamento del carico, i tentativi di riconnnessione o la corretta pianificazione dei timeout verso l’upstream.

Quando NGINX deve risolvere nuovamente i nomi

NGINX può già conoscere un nome host al momento della lettura della configurazione. Diverso è il caso di una destinazione variabile, ad esempio proxy_pass http://$backend;. NGINX cerca innanzitutto il nome risultante nei gruppi upstream definiti. Se non trova alcun nome corrispondente, ha bisogno, in fase di esecuzione, di un resolver configurato per determinare l'indirizzo di destinazione.

Il messaggio no resolver defined In questo contesto, non indica la mancanza di una cache HTTP. Significa che NGINX non conosce alcun server DNS per la risoluzione necessaria in fase di esecuzione. resolver può essere utilizzato nel contesto http, server oppure location si trovano. Una voce fondamentale nel httpIl blocco - è indicato quando più host virtuali utilizzano lo stesso resolver; un ambito più ristretto è appropriato solo in caso di requisiti effettivamente diversi.

Da questa risoluzione del tempo di esecuzione, disponibile da tempo, va distinta l’aggiornamento dinamico di un classico gruppo upstream. La configurazione del resolver direttamente nel upstream-blocco e server hostname resolve Secondo la documentazione, in NGINX Open Source sono disponibili a partire dalla versione 1.27.3. Le installazioni Open Source precedenti non devono essere considerate come se supportassero automaticamente questo modello; storicamente, alcune di queste funzionalità erano riservate a NGINX Plus.

Prima di pianificare gli upstream dinamici, controlla le informazioni relative alla versione installata e alla compilazione. Il comando seguente mostra la versione di NGINX, la versione del compilatore e i parametri di configurazione utilizzati durante la compilazione.

nginx -V

Confronta lo stato visualizzato in caso di distribuzioni critiche con la documentazione del pacchetto effettivamente utilizzato e del relativo fornitore. È determinante verificare se tale installazione documenti e fornisca la funzionalità richiesta. Solo allora è possibile upstream dinamico una scelta architettonica solida.

Impostare in modo esplicito TTL e valid

La cache del resolver di NGINX, in assenza di ulteriori impostazioni, si basa sulla DNS-TTL nella risposta del server dei nomi interpellato. Se il gestore DNS autorevole modifica l’indirizzo IP di un backend, NGINX utilizza la risposta precedente fino alla scadenza del suo TTL. Solo quando in seguito è nuovamente necessaria una risoluzione del nome, NGINX interroga nuovamente il resolver. In questo modo, la durata di validità rimane controllabile nel punto in cui vengono gestiti i dati relativi ai nomi.

Il parametro valid sostituisce completamente questo TTL con il periodo configurato. Pertanto, non solo limita il TTL DNS verso l’alto, ma non definisce nemmeno un aggiornamento periodico in aggiunta al TTL. Un valore pari a valid=30s può ridurre un TTL DNS più lungo, ma anche prolungare un TTL volutamente breve. Ciò deve essere in linea con la pianificazione del trasferimento e della distribuzione del backend.

Se la zona viene gestita in modo affidabile, una configurazione senza override costituisce il punto di partenza più logico. L’indirizzo riportato nell’esempio è stato scelto in base alle reti descritte nella documentazione e non deve essere utilizzato come resolver produttivo. Inserisci invece l’indirizzo di un resolver DNS raggiungibile e affidabile proveniente dalla propria rete.

resolver 192.0.2.53;
resolver_timeout 5s;

Un override può essere utile quando non è possibile modificare il TTL del DNS ed esiste una politica operativa documentata. In tal caso, la deroga rende esplicitamente visibile per quanto tempo NGINX mantiene le risposte. Non si tratta di un'ottimizzazione generale delle prestazioni: tempi più brevi possono generare un maggior numero di query DNS, mentre tempi più lunghi possono ritardare il passaggio a nuovi indirizzi di backend.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

La decisione non parte quindi da un’indicazione precisa in secondi, ma dalla domanda su chi controlli i dati DNS e con quale rapidità debba diventare effettivo un cambio di backend. valido rappresenta un intervento deliberato su questa configurazione. Non è adatto come soluzione generica per velocizzare il reverse proxy o per mascherare problemi relativi al DNS.

Risolvere correttamente le variabili in proxy_pass

Contiene proxy_pass una variabile, NGINX deve gestire il nome host risultante in fase di esecuzione. Innanzitutto, NGINX cerca un gruppo upstream corrispondente; se non lo trova, ha bisogno di un resolver configurato per quel nome. Se questo manca, viene visualizzato il tipico messaggio no resolver defined Non si tratta di un riferimento alla cache HTTP, bensì alla mancanza di una configurazione DNS per questo percorso di esecuzione.

Il seguente esempio mette volutamente in evidenza la risoluzione del runtime. Il resolver si trova nel http-contesto e, di conseguenza, si applica a più host virtuali, a meno che un’impostazione più specifica non la sovrascriva. L’indirizzo di documentazione utilizzato deve essere sostituito dal resolver interno del rispettivo ambiente.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

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

La direttiva resolver_timeout Non controlla la durata della cache. Limita il tempo che NGINX attende per la risoluzione di un nome; il valore predefinito documentato è di 30 secondi. La scelta rientra tra gli altri «margini di errore»: un valore troppo elevato può ritardare una richiesta non riuscita fino alla risposta di errore, mentre un valore troppo basso genera errori di risoluzione evitabili in caso di resolver interni temporaneamente lenti.

Per una singola sede chiaramente definita, il resolver può essere impostato nel location-Block. Se più location o server richiedono la stessa risoluzione, è necessario definire uno scope comune nel server- o http-Block richiede meno manutenzione. NGINX consente l'uso della direttiva in tutti e tre i contesti; l'ambito di applicazione dovrebbe rispecchiare l'effettiva struttura operativa, non limitarsi a risolvere temporaneamente un singolo messaggio di errore.

Anche nel caso di destinazioni variabili, il timeout DNS e la connessione al backend rimangono classi di errore distinte. Una risoluzione del nome riuscita non dimostra né che la porta di destinazione sia raggiungibile, né che l'applicazione risponda. Viceversa, un timeout upstream più lungo non risolve il problema di un indirizzo del resolver irraggiungibile.

Configurazione degli upstream dinamici con `resolve`

Per un gruppo di backend specificato, un upstream dinamico può risultare più leggibile rispetto a un valore di destinazione variabile in ogni location. Questo modello separa la definizione dei membri del backend dal routing: proxy_pass si riferisce al gruppo, mentre il nome host nell'upstream può essere aggiornato tramite DNS. Ciò è particolarmente utile quando più percorsi puntano alla stessa applicazione.

Il parametro resolve per un server- Questa voce esiste storicamente a partire da NGINX 1.5.12. Tuttavia, secondo la documentazione, nella versione open source di NGINX è disponibile solo a partire dalla versione 1.27.3; in precedenza questa funzione era limitata alla versione commerciale. Anche la configurazione del resolver direttamente nel upstream- Il blocco è documentato per l'Open Source a partire dalla versione 1.27.3.

Il sito Zona di memoria condivisa Non si tratta né di un timeout della cache né di un percorso dei dati DNS. Fornisce memoria condivisa all’interno di NGINX, necessaria per le configurazioni upstream soggette a modifiche dinamiche. Se durante la risoluzione DNS NGINX rileva indirizzi diversi per il nome, il gruppo upstream può essere adattato sulla base di questo stato gestito internamente senza necessità di riavvio.

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

Come in tutti gli esempi, vale quanto segue: 192.0.2.53 solo per un indirizzo di documentazione. In pratica, il resolver registrato deve conoscere in modo affidabile i nomi interni, essere raggiungibile dalla rete NGINX ed essere considerato affidabile. Prima di procedere, è inoltre necessario verificare l'effettiva funzionalità del pacchetto installato, anziché ricavare la configurazione esclusivamente da un esempio attuale.

Un servizio accessibile esclusivamente tramite IPv4 può giustificare una limitazione mirata: resolver 192.0.2.53 ipv6=off; Impedisce le richieste AAAA e la selezione di un indirizzo IPv6 per questo contesto di risoluzione. Si tratta tuttavia di una scelta relativa all'architettura di rete. Se il dual stack funziona correttamente, l'IPv6 non dovrebbe essere disattivato solo per abitudine; per impostazione predefinita, NGINX risolve entrambe le famiglie di indirizzi IP.

Verificare accuratamente la configurazione e implementarla

Prima di apportare una modifica, verifica innanzitutto in quali punti si applicano effettivamente le direttive del resolver. A tal fine, cerca la configurazione attiva, compresi i file inclusi, e verifica se il resolver è attivo per l’intero http-contesto, destinato solo a un host virtuale o semplicemente a un singolo percorso. Un ambito troppo ristretto può impedire a un altro percorso proxy variabile di trovare un resolver; un ambito troppo ampio, invece, rende più difficile l'assegnazione successiva delle modifiche.

Dopo ogni modifica segue il Controllo della sintassi. Legge la configurazione e tenta anche di aprire i file a cui si fa riferimento. In questo modo è possibile individuare errori di scrittura, direttive non valide e problemi nei file di inclusione prima di un ricaricamento. Tuttavia, il controllo non garantisce che il server DNS specificato sia raggiungibile, che riconosca il nome previsto o che il backend associato a un indirizzo risolto accetti le connessioni.

nginx -t
nginx -s reload

Esegui il ricaricamento solo dopo aver verificato che tutto funzioni correttamente. nginx -s reload fa sì che NGINX avvii nuovi worker con la nuova configurazione e chiuda in modo controllato quelli vecchi. A seconda del pacchetto installato e del sistema operativo, potrebbe essere invece il gestore dei servizi previsto in quel contesto ad avviare il ricaricamento. A tal fine, utilizzare la procedura operativa documentata dell’installazione, anziché utilizzare comandi provenienti da un ambiente esterno.

Pianifica quindi un test tecnico nella finestra di modifica prevista. Confronta il TTL DNS previsto con il momento a partire dal quale dovrà essere utilizzato un nuovo indirizzo backend e verifica la raggiungibilità del servizio tramite la famiglia di indirizzi IP effettivamente consentita. Documenta inoltre l’indirizzo del resolver, l’ambito selezionato e un eventuale valid-Override. In questo modo, in caso di malfunzionamento, è possibile distinguere se la causa sia da ricercarsi nel DNS, nel routing o nell’applicazione.

Individuare sistematicamente i guasti tipici del resolver

Inizia la ricerca degli errori nell'espressione di destinazione in proxy_pass. Se contiene una variabile, NGINX deve risolvere il nome host in essa contenuto in fase di esecuzione, a meno che questo non appartenga a un gruppo upstream definito. Il messaggio no resolver defined sottolinea quindi innanzitutto la mancanza di un elemento o la sua invisibilità nel contesto operativo Configurazione del resolver . Aggiungi un nameserver affidabile nel contesto appropriato, invece di sostituire frettolosamente il nome host con un indirizzo IP fisso.

Se è configurato un resolver, verifica quindi il suo indirizzo, il percorso di rete e la competenza per la zona utilizzata. Un resolver pubblico non può conoscere i nomi interni; un resolver non raggiungibile, invece, genera timeout di risoluzione. Verifica inoltre se la direttiva viene sovrascritta da un’impostazione più specifica. NGINX utilizza solo i server dei nomi espressamente specificati, non applica automaticamente tutte le impostazioni da /etc/resolv.conf.

Se, dopo una modifica del DNS, rimane attivo un vecchio indirizzo di destinazione, controlla il TTL della risposta e se è impostato un valid. Un override di lunga durata sostituisce il TTL della risposta DNS e può ritardare di conseguenza l’applicazione di una modifica. La correzione consentita non è una durata forfettaria il più breve possibile, bensì un valore adeguato alla finestra di modifica e alla capacità dell’infrastruttura DNS; spesso l’omissione di valid la soluzione più pulita.

In caso di problemi di connessione dopo una risoluzione riuscita, disconnetti il DNS dalla connessione backend. Verifica se sono presenti risposte A e AAAA e se la destinazione è effettivamente instradata e raggiungibile tramite IPv6. ipv6=off È adatto solo a un caso di architettura in cui sia dimostrabile che si utilizza esclusivamente IPv4. Un timeout DNS riguarda la risoluzione dei nomi; un errore di connessione a un indirizzo IP già noto, invece, è riconducibile al routing, al firewall, alla porta o all’applicazione.

Per gli upstream dinamici occorre inoltre specificare la versione, la zona di memoria condivisa e resolve essere compatibili. Il supporto open source documentato a tal fine è valido a partire dalla versione NGINX 1.27.3; le installazioni precedenti non devono essere considerate equivalenti. status_zone Inoltre, le statistiche dei resolver basate su API non costituiscono una soluzione di monitoraggio generica per NGINX Open Source, poiché le funzionalità citate riguardano l'ambito commerciale.

Scegliere la strategia del resolver per il funzionamento

La strategia giusta non parte da un valore di cache predefinito, ma dal controllo sul DNS e dalla frequenza delle modifiche. Se il tuo team è in grado di gestire la zona autorevole e se i relativi TTL rispecchiano in modo realistico la finestra di deployment, allora una Risoluzione controllata tramite TTL senza valid di solito il punto di partenza più comprensibile. Il DNS rimane quindi la fonte di riferimento per determinare per quanto tempo viene utilizzata una risposta.

Un elemento inserito intenzionalmente valid È una soluzione da prendere in considerazione se non puoi modificare il TTL e riesci a giustificare operativamente una durata della cache diversa. Tieni presente quale livello di inattività è accettabile: un valore più lungo riduce il numero di possibili richieste DNS, ma dopo un trasferimento potrebbe puntare a un indirizzo non più valido. Non costituisce né un limite massimo per il TTL DNS né un regolatore generale delle prestazioni.

Scegli quindi il modello NGINX in base alla struttura di routing. Una variabile proxy_pass È indicato quando la destinazione viene determinata in fase di esecuzione per ogni richiesta o configurazione; a tal fine è necessario un resolver nell’ambito appropriato. Per un gruppo di backend denominato con modifiche di indirizzo basate sul DNS, è necessario un upstream con zone e resolve ovviamente, a condizione che NGINX Open Source 1.27.3 o una versione più recente sia effettivamente disponibile.

Solo dopo potrai decidere Timeout e famiglie di indirizzi IP. Il timeout del resolver deve essere in linea con i timeout del client e dell’upstream, in modo che l’assenza di una risposta DNS non causi ritardi sproporzionati. IPv4 o IPv6 vanno abilitati solo in base all’architettura di rete. Utilizza esclusivamente resolver sicuri, in grado di rispondere in modo affidabile alle zone interne.

La risoluzione DNS e l’upstream keepalive svolgono compiti diversi. Il resolver determina quale indirizzo backend NGINX può utilizzare; il keepalive mantiene attive le connessioni backend già stabilite ma inattive, in vista di un loro riutilizzo. Una modifica al riutilizzo delle connessioni non sostituisce quindi né la pianificazione del TTL né il controllo del resolver. Per il dimensionamento di questo livello di connessione, l’articolo su Keepalive upstream di NGINX la strategia del resolver.