Konfigurera NGINX Resolver-cachen korrekt

Att förstå NGINX-resolver och DNS-cache

En omvänd proxy behöver först och främst en IP-adress för ett backend med värdnamn. Den NGINX-resolver för detta ändamål gör NGINX en förfrågan till de namnservrar som anges i konfigurationen. Det mottagna DNS-svaret lagras i cachen så att NGINX inte behöver lösa namnet på nytt för varje förfrågan under dess giltighetstid. Denna cache gäller uteslutande namnupplösningen till målsystemet.

Direktivet resolver innehåller en eller flera resolveradresser respektive resolveridentifierare som stöds. Om ingen annan port anges använder NGINX port 53; om flera servrar är angivna sker förfrågningarna enligt dokumentationen enligt round-robin-metoden. För en robust bootstrap-konfiguration är fasta IP-adresser ofta att föredra, eftersom deras upplösning inte i sig är beroende av DNS.

Som standard tar NGINX hänsyn till både IPv4- och IPv6-adresser för ett namn. Detta är lämpligt om nätverket på ett tillförlitligt sätt vidarebefordrar båda protokollfamiljerna till backend. Parametrar som ipv4=off eller . ipv6=off utesluter specifikt en viss familj, men utgör ingen allmän cacheoptimering. Huruvida de är nödvändiga avgörs av tillgängligheten till just det aktuella backend-systemet, och inte av att det enbart finns en AAAA-post.

Resolver är varken en fullfjädrad rekursiv DNS-server eller en automatisk övertagning av alla inställningar från /etc/resolv.conf. NGINX använder de uttryckligen angivna namnservrarna. För interna zoner och produktiva backend-namn bör de pålitliga, tillräckligt säkra resolverna finnas i det egna nätverket. På så sätt förblir ansvaret för privata namn och skyddet mot manipulerade DNS-svar inom en infrastruktur som går att kontrollera.

DNS-cache är inte samma sak som HTTP-cache

Resolverns DNS-svar-cache lagrar kopplingar mellan namn och DNS-svar, till exempel A- eller AAAA-adresser. Syftet är att kunna nå en backend igen utan att behöva upprepa varje namnupplösning. Om en backend-IP ändras är det därför DNS-svarets giltighet som är relevant – inte innehållet i ett tidigare levererat HTTP-svar.

Detta lagras separat proxy_cache HTTP-svar från en uppströms. Beroende på konfigurationen omfattar nyckeln till exempel URI, värd eller rubrik; en träff levererar ett redan lagrat svar till klienten. Problem uppstår här i form av föråldrade sidor, felaktiga varianter eller oväntade cacheträffar. Denna funktion avgör inte vilken IP-adress NGINX använder när en ny backend-anslutning upprättas.

Open-File-Cache är en tredje nivå: den lagrar filinformation och öppna deskriptorer för lokala filsystemåtkomster, men varken DNS-svar eller HTTP-innehåll. Den som vill fördjupa sig i denna avgränsning för statisk leverans kan läsa mer i artikeln om Konfiguration av NGINX Open File Cache. Han ger dock ingen grund för att välja en resolver-TTL.

Att tömma, rensa eller uppdatera en HTTP-cache påskyndar därför inte en DNS-ändring. Omvänt åtgärdar en ny DNS-upplösning inte ett felaktigt cachat HTTP-svar. Vid en omvänd proxy begränsar DNS-cache Dessutom baseras den på namn och adresser: Den kontrollerar varken en applikations stabilitet och ersätter inte heller lastbalansering, återförsök eller korrekt tidsgränsplanering mot uppströms.

När NGINX måste lösa upp namn på nytt

Ett värdnamn kan redan vara känt för NGINX när konfigurationen läses in. Det är annorlunda när det gäller ett variabelt mål, till exempel proxy_pass http://$backend;. NGINX söker först efter det resulterande namnet i definierade uppströmsgrupper. Om det inte hittar något passande namn där behöver det en konfigurerad resolver under körning för att fastställa måladressen.

Anmälan no resolver defined Detta tyder inte på att det saknas en HTTP-cache. Det innebär att NGINX inte känner till någon DNS-server för den nödvändiga upplösningen vid körning. resolver får i sammanhanget http, server eller . location står. En central post i http-Block är lämpligt när flera virtuella värdar använder samma resolver; ett snävare tillämpningsområde är endast lämpligt om kraven faktiskt skiljer sig åt.

Denna körtidsupplösning, som länge funnits tillgänglig, ska skiljas från den dynamiska uppdateringen av en klassisk uppströmsgrupp. Resolverkonfigurationen direkt i upstream-blocket samt server hostname resolve Enligt dokumentationen i NGINX Open Source är dessa tillgängliga från och med version 1.27.3. Äldre Open Source-installationer får inte behandlas som om de automatiskt stöder detta mönster; historiskt sett var sådana funktioner delvis förbehållna NGINX Plus.

Innan du planerar dynamiska uppströmsflöden bör du kontrollera den installerade utgåvan och bygginformationen. Följande kommando visar NGINX-versionen, kompilatorversionen och de Configure-parametrar som användes vid byggningen.

nginx -V

Jämför den visade statusen vid kritiska distributioner med dokumentationen för det specifika paket som används och dess leverantör. Det avgörande är om denna installation dokumenterar och tillhandahåller den nödvändiga funktionen. Först därefter är en dynamisk uppströms ett hållbart arkitektoniskt val.

Ange TTL och valid medvetet

NGINX:s resolver-cache följer, utan någon ytterligare inställning, DNS-TTL i svaret från den tillfrågade namnservern. Om den auktoritativa DNS-operatören ändrar IP-adressen för en backend använder NGINX det tidigare svaret fram till dess att dess TTL löper ut. Först när en namnupplösning återigen krävs efter detta skickar NGINX en ny förfrågan till resolveren. På så sätt kan giltighetstiden styras där namndata underhålls.

Parametern valid ersätter denna TTL helt med den konfigurerade tidsperioden. Den begränsar alltså inte bara DNS-TTL:s övre gräns och definierar inte heller någon regelbunden uppdatering utöver TTL. Ett värde på valid=30s kan förkorta en längre DNS-TTL, men också förlänga en medvetet kort TTL. Detta måste stämma överens med planeringen av flytt och driftsättning av backend-systemet.

Om zonen underhålls på ett tillförlitligt sätt är en konfiguration utan överskrivning den rimliga utgångspunkten. Adressen i exemplet har valts i enlighet med dokumentationsnätverken och får inte användas som en produktiv resolver. Ange istället adressen till en tillgänglig och pålitlig DNS-resolver från ditt eget nätverk.

resolver 192.0.2.53;
resolver_timeout 5s;

En överskrivning kan vara lämplig om DNS-TTL inte går att påverka och det finns en dokumenterad driftsriktlinje. Då visar avvikelsen tydligt hur länge NGINX behåller svaren. Det är ingen allmän prestandaoptimering: kortare tider kan utlösa fler DNS-förfrågningar, medan längre tider kan fördröja övergången till nya backend-adresser.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

Beslutet utgår därför inte från en fast angiven tid i sekunder, utan från frågan om vem som kontrollerar DNS-uppgifterna och hur snabbt ett byte av backend måste träda i kraft. giltig är ett medvetet ingrepp i denna regel. Det lämpar sig inte som en generell lösning för att göra omvända proxyservrar snabbare eller för att dölja DNS-problem.

Lösa upp variabler i proxy_pass korrekt

Innehåller proxy_pass en variabel måste NGINX hantera det resulterande värdnamnet under körning. Först söker NGINX efter en lämplig uppströmsgrupp; om den inte hittar någon behöver den en konfigurerad resolver för namnet. Om denna saknas är det vanliga meddelandet no resolver defined Inget tecken på en HTTP-cache, utan på att DNS-konfigurationen saknas för denna körningsväg.

Följande exempel visar medvetet upplösningen av körningstiden. Resolvern finns i http-kontexten och gäller därmed för flera virtuella värdar, såvida inte en mer specifik inställning åsidosätter den. Den använda dokumentationsadressen måste ersättas med den interna resolveren för respektive miljö.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

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

Direktivet resolver_timeout styr inte cachelagringstiden. Den begränsar hur länge NGINX väntar på en namnupplösning; det dokumenterade standardvärdet är 30 sekunder. Valet ingår i de övriga felbudgetarna: ett för högt värde kan fördröja en misslyckad förfrågan ända fram till felmeddelandet, medan ett för lågt värde orsakar onödiga upplösningsfel vid tillfälligt långsamma interna upplösare.

För en enskild, tydligt avgränsad plats kan resolveren i location-blocket. Om flera platser eller servrar kräver samma upplösning, krävs ett gemensamt tillämpningsområde i server- eller http-Block kräver mindre underhåll. NGINX tillåter direktiven i alla tre sammanhangen; tillämpningsområdet bör återspegla den faktiska driftsstrukturen, inte bara åtgärda ett enskilt felmeddelande på kort sikt.

Även vid variabla mål förblir DNS-timeout och anslutningen till backend separata felkategorier. En lyckad namnupplösning bevisar varken att målporten är tillgänglig eller att applikationen svarar. Omvänt löser en längre uppströms-timeout inte problemet med en oåtkomlig resolveradress.

Konfigurera dynamiska uppströms med resolve

För en namngiven backend-grupp kan en dynamisk uppströms vara lättare att läsa än ett variabelt målvärde på varje plats. Mönstret skiljer definitionen av backend-medlemmarna från routningen: proxy_pass hänvisar till gruppen, medan värdnamnet i uppströmsnätverket kan uppdateras via DNS. Detta är särskilt lämpligt när flera rutter pekar mot samma applikation.

Parametern resolve för en server-Denna inställning har funnits sedan NGINX 1.5.12. Enligt dokumentationen finns den dock i NGINX Open Source först från och med version 1.27.3; tidigare var denna funktion begränsad till den kommersiella versionen. Även resolver-konfigurationen direkt i upstream-Blocket är dokumenterat för öppen källkod från och med version 1.27.3.

Die Delad minneszon Det handlar varken om en cache-timeout eller en DNS-dataväg. Den tillhandahåller gemensamt minne inom NGINX som krävs för dynamiskt ändrade uppströms-konfigurationer. Om NGINX vid DNS-upplösningen identifierar andra adresser för namnet kan uppströmsgruppen anpassas utifrån detta internt hanterade tillstånd utan omstart.

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

Precis som i alla exempel gäller att 192.0.2.53 endast för en dokumentationsadress. I praktiken måste den registrerade resolveren känna till interna namn på ett tillförlitligt sätt, vara tillgänglig från NGINX-nätverket och anses vara pålitlig. Innan konfigurationen tas över bör dessutom den faktiska funktionsomfattningen för det installerade paketet kontrolleras, istället för att enbart basera konfigurationen på ett aktuellt exempel.

En tjänst som endast är tillgänglig via IPv4 kan motivera en målinriktad begränsning: resolver 192.0.2.53 ipv6=off; förhindrar AAAA-förfrågningar och val av en IPv6-adress för detta resolver-sammanhang. Detta är dock ett val som rör nätverksarkitekturen. Om dual stack fungerar bör IPv6 inte inaktiveras enbart av vana; som standard löser NGINX båda IP-familjerna.

Kontrollera konfigurationen noggrant och rulla ut den

Innan du gör en ändring bör du först kontrollera var Resolver-direktiven faktiskt gäller. För att göra detta söker du upp den aktiva konfigurationen, inklusive inkluderade filer, och klargör om Resolver gäller för hela http-kontext, som endast är avsedd för en virtuell värd eller endast för en enskild sökväg. Ett för snävt tillämpningsområde kan leda till att en annan variabel proxysökväg inte hittar någon resolver; ett för brett tillämpningsområde försvårar däremot den senare tilldelningen av ändringar.

Efter varje justering följer Syntaxkontroll. Den läser in konfigurationen och försöker även öppna de filer som refereras till. På så sätt kan stavfel, ogiltiga direktiv och problem i inkluderade filer upptäckas innan en omladdning. Kontrollen bevisar dock inte att den angivna DNS-servern är tillgänglig, känner till det förväntade namnet eller att backend-servern bakom en upplöst adress accepterar anslutningar.

nginx -t
nginx -s reload

Utför omladningen först efter att kontrollen har genomförts med gott resultat. nginx -s reload får NGINX att starta nya worker-processer med den nya konfigurationen och avsluta gamla worker-processer på ett kontrollerat sätt. Beroende på vilket paket som är installerat och vilket operativsystem som används kan istället den tjänstehanterare som finns där utlösa omladdningen. Använd därför den dokumenterade driftsvägen för installationen istället för att använda kommandon från en främmande miljö.

Planera därefter en teknisk testkörning inom det avsedda ändringsfönstret. Jämför den förväntade DNS-TTL-tiden med den tidpunkt från och med vilken en ny backend-adress ska användas, och kontrollera att tjänsten är tillgänglig via den faktiskt tillåtna IP-familjen. Dokumentera dessutom resolveradressen, det valda omfånget och en eventuell valid-Override. På så sätt går det att avgöra vid ett fel om orsaken ligger i DNS, routningen eller applikationen.

Systematiskt avgränsa typiska resolverfel

Börja felsökningen med måluttrycket i proxy_pass. Om den innehåller en variabel måste NGINX lösa upp det värdnamn som finns i den vid körning, förutsatt att det inte tillhör en definierad uppströmsgrupp. Meddelandet no resolver defined påpekar därför inledningsvis att det saknas eller inte syns i det relevanta sammanhanget Resolver-konfiguration . Lägg till en pålitlig namnserver i rätt sammanhang, istället för att förhastat ersätta värdnamnet med en fast IP-adress.

Om en resolver är konfigurerad ska du därefter kontrollera dess adress, nätväg och ansvarsområde för den zon som används. En offentlig resolver kan inte känna till interna namn; en resolver som inte går att nå orsakar däremot tidsöverskridningar vid namnupplösning. Kontrollera dessutom om direktivet åsidosätts av en mer specifik inställning. NGINX använder endast de namnservrar som uttryckligen anges, inte automatiskt alla inställningar från /etc/resolv.conf.

Om en gammal måladress fortfarande är aktiv efter ett DNS-byte, kontrollera svarets TTL och om en valid. En lång överskrivning ersätter TTL-värdet i DNS-svaret och kan därmed fördröja införandet av en ändring. Den tillåtna korrigeringen är inte en generellt sett så kort varaktighet som möjligt, utan ett värde som passar ändringsfönstret och DNS-infrastrukturens kapacitet; ofta innebär utelämnandet av valid den renare lösningen.

Om det uppstår anslutningsproblem efter en lyckad upplösning ska du koppla bort DNS från backend-anslutningen. Kontrollera om det finns A- och AAAA-svar och om målet faktiskt routas via IPv6 och är nåbart. ipv6=off är endast lämpligt för en arkitektur där det bevisligen endast används IPv4. En DNS-timeout påverkar namnupplösningen; ett anslutningsfel till en redan känd IP-adress tyder däremot på problem med routning, brandvägg, port eller applikation.

För dynamiska uppströmmar måste dessutom versionsstatus, delat minnesområde och resolve är kompatibla. Det dokumenterade stödet för öppen källkod gäller från och med NGINX 1.27.3; äldre installationer får inte betraktas som likvärdiga. status_zone Dessutom utgör API-baserade resolver-statistikuppgifter ingen allmän övervakningslösning för NGINX Open Source, eftersom de nämnda funktionerna avser kommersiell användning.

Välj driftsstrategi för resolvern

En lämplig strategi utgår inte från ett generellt cachevärde, utan från DNS-kontroll och ändringsfrekvens. Om ditt team kan underhålla den auktoritativa zonen och om dess TTL-värden på ett realistiskt sätt återspeglar driftsättningsfönstret, är en TTL-styrd upplösning utan valid oftast den mest begripliga utgångspunkten. DNS förblir då den avgörande källan för hur länge ett svar används.

Ett medvetet placerat valid är ett alternativ om du inte kan påverka TTL och kan motivera en avvikande cachelängd ur driftssynpunkt. Notera samtidigt vilka konsekvenser av avbrott som är acceptabla: Ett längre värde minskar antalet möjliga DNS-förfrågningar, men kan efter en flytt peka på en adress som inte längre är giltig. Det är varken en övre gräns för DNS-TTL eller en allmän prestandaknapp.

Välj sedan NGINX-mönstret utifrån routingstrukturen. En variabel proxy_pass är lämpligt när målet bestäms vid körning, för varje förfrågan eller konfiguration; för detta krävs en resolver inom rätt omfattning. För en namngiven backend-grupp med DNS-baserade adressändringar krävs en uppströms med zone och resolve tydligare, förutsatt att NGINX Open Source 1.27.3 eller senare faktiskt är tillgänglig.

Först därefter bestämmer du Timeouts och IP-familjer. Resolver-timeouten måste stämma överens med klient- och uppströms-timeouterna, så att ett uteblivet DNS-svar inte orsakar oproportionerligt långa fördröjningar. Du aktiverar endast IPv4 eller IPv6 i enlighet med nätverksarkitekturen. Använd uteslutande säkra resolver som på ett tillförlitligt sätt kan besvara interna zoner.

DNS-upplösning och Upstream-Keepalive fyller olika syften. Resolver avgör vilken backend-adress NGINX kan använda; Keepalive behåller redan upprättade, inaktiva backend-anslutningar för återanvändning. En ändring av återanvändningen av anslutningar ersätter därför varken TTL-planering eller resolver-kontroll. För dimensioneringen av denna anslutningsnivå kompletterar artikeln om NGINX Upstream Keepalive Resolver-strategin.