Korrekt konfiguration af NGINX-resolver-cachen

Forståelse af NGINX-resolver og DNS-cache

En reverse proxy skal først og fremmest have en IP-adresse til et backend med et værtsnavn. Den NGINX-resolver forespørger i stedet de navneservere, der er angivet i konfigurationen. Det modtagne DNS-svar gemmes i cachen, så NGINX ikke behøver at opslå navnet på ny for hver forespørgsel i løbet af dets gyldighedsperiode. Denne cache vedrører udelukkende navneopslag til målsystemet.

Direktivet resolver indeholder en eller flere resolver-adresser eller understøttede resolver-identifikatorer. Hvis der ikke er angivet en anden port, bruger NGINX port 53; hvis der er angivet flere servere, behandles forespørgslerne ifølge dokumentationen efter round-robin-princippet. For en robust bootstrap-konfiguration er faste IP-adresser ofte at foretrække, da deres opløsning ikke selv afhænger af DNS.

Som standard tager NGINX højde for både IPv4- og IPv6-adresser for et navn. Dette er passende, hvis netværket pålideligt transporterer begge protokolfamilier helt frem til backend. Parametre som ipv4=off eller ipv6=off udelukker målrettet en bestemt familie, men udgør ikke en generel cache-optimering. Om de er nødvendige, afhænger af tilgængeligheden af det konkrete backend og ikke af den blotte eksistens af en AAAA-post.

Resolveren er hverken en fuldgyldig rekursiv DNS-server eller en automatisk overtagelse af alle indstillinger fra /etc/resolv.conf. NGINX bruger de eksplicit angivne navneservere. For interne zoner og produktive backend-navne bør det være en pålidelig og tilstrækkeligt sikret resolver i det eget netværk. På den måde forbliver ansvaret for private navne og beskyttelsen mod manipulerede DNS-svar inden for en infrastruktur, der kan kontrolleres.

DNS-cachen er ikke en HTTP-cache

Resolverens DNS-responscache gemmer sammenkoblinger mellem navne og DNS-svar, f.eks. A- eller AAAA-adresser. Formålet er at kunne opnå forbindelse til et backend igen uden at skulle gentage hver eneste navneopløsning. Hvis en backend-IP ændrer sig, er det derfor gyldigheden af DNS-svaret, der er relevant – ikke indholdet af et tidligere leveret HTTP-svar.

Uafhængigt heraf gemmer proxy_cache HTTP-svar fra en upstream. Nøglen omfatter, afhængigt af konfigurationen, for eksempel URI, host eller header; et hit leverer et allerede gemt svar til klienten. Problemer viser sig her i form af forældede sider, forkerte varianter eller uventede cache-hits. Denne funktion bestemmer ikke, hvilken IP NGINX bruger, når der oprettes en ny backend-forbindelse.

Open-File-Cache er et tredje lag: Den indeholder filoplysninger og åbne deskriptorer til adgang til det lokale filsystem, men hverken DNS-svar eller HTTP-indhold. Hvis man ønsker at uddybe denne afgrænsning i forbindelse med statisk levering, kan man finde den i artiklen om Konfiguration af NGINX Open File Cache. Han giver dog ikke noget grundlag for at vælge en Resolver-TTL.

Tømning, rensning eller opdatering af en HTTP-cache fremskynder derfor ikke en DNS-ændring. Omvendt løser en ny DNS-opslag ikke et problem med et forkert cachelagret HTTP-svar. Ved en reverse proxy begrænser DNS-cache desuden baserer sig på navne og adresser: Den kontrollerer hverken en applikations tilstand og erstatter heller ikke load-balancing, gentagne forsøg eller korrekt timeout-planlægning i forhold til upstream.

Hvornår NGINX skal opløse navne igen

NGINX kan allerede kende et værtsnavn, når konfigurationen indlæses. Det er anderledes med en variabel destination, f.eks. proxy_pass http://$backend;. NGINX søger først efter det resulterende navn i de definerede upstream-grupper. Hvis det ikke finder et passende navn der, har det brug for en konfigureret resolver under kørsel for at bestemme måladressen.

Meddelelsen no resolver defined Dette tyder ikke på, at der mangler en HTTP-cache. Det betyder, at NGINX ikke kender nogen DNS-server til den nødvendige opløsning under kørsel. resolver må i denne sammenhæng http, server eller location står. En central post i http-Block er velegnet, når flere virtuelle værter bruger den samme resolver; et snævrere anvendelsesområde er kun relevant, hvis kravene rent faktisk adskiller sig.

Denne kørselstidsopløsning, der har været tilgængelig i lang tid, skal adskilles fra den dynamiske opdatering af en klassisk upstream-gruppe. Resolver-konfigurationen direkte i upstream-blokken samt server hostname resolve Ifølge dokumentationen er de tilgængelige i NGINX Open Source fra version 1.27.3 og frem. Ældre Open Source-installationer må ikke antages automatisk at understøtte dette mønster; historisk set var sådanne funktioner delvist forbeholdt NGINX Plus.

Inden du planlægger dynamiske upstreams, skal du kontrollere de installerede output- og build-oplysninger. Følgende kommando viser NGINX-versionen, kompilatorversionen og de configure-parametre, der blev brugt under buildet.

nginx -V

Sammenlign den viste status ved kritiske implementeringer med dokumentationen for den konkrete pakke, der anvendes, og dens udbyder. Det afgørende er, om denne installation dokumenterer og stiller den nødvendige funktion til rådighed. Først derefter er en dynamisk upstream et robust arkitektonisk valg.

Indstil TTL og valid bevidst

NGINX’ resolver-cache følger som standard, uden yderligere angivelser, DNS-TTL i svaret fra den forespurgte navneserver. Hvis den autoritative DNS-udbyder ændrer IP-adressen på et backend, bruger NGINX det hidtidige svar, indtil dets TTL udløber. Først når der efterfølgende igen er behov for en navneopløsning, forespørger NGINX resolveren på ny. Dermed forbliver gyldighedsperioden styrbar dér, hvor navnedataene vedligeholdes.

Parameteren valid erstatter denne TTL fuldstændigt med den konfigurerede periode. Den sætter altså ikke kun en øvre grænse for DNS-TTL’en og definerer heller ikke en regelmæssig opdatering ud over TTL’en. En værdi på valid=30s kan forkorte en længere DNS-TTL, men også forlænge en bevidst kort TTL. Dette skal passe ind i planlægningen af flytningen og implementeringen af backend-systemet.

Hvis zonen vedligeholdes pålideligt, er en konfiguration uden overskrivning det mest fornuftige udgangspunkt. Adressen i eksemplet er valgt i overensstemmelse med dokumentationsnetværkene og må ikke anvendes som en produktiv resolver. Indtast i stedet adressen på en tilgængelig og pålidelig DNS-resolver fra dit eget netværk.

resolver 192.0.2.53;
resolver_timeout 5s;

En overstyring kan være hensigtsmæssig, hvis DNS-TTL ikke kan ændres, og der findes en dokumenteret driftsmæssig retningslinje. Derefter viser afvigelsen tydeligt, hvor længe NGINX opbevarer svarene. Det er ikke en generel ydeevneoptimering: Kortere tider kan udløse flere DNS-forespørgsler, mens længere tider kan forsinke overgangen til nye backend-adresser.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

Afgørelsen tager derfor ikke udgangspunkt i et bestemt antal sekunder, men i spørgsmålet om, hvem der kontrollerer DNS-dataene, og hvor hurtigt et skift af backend skal træde i kraft. gyldig er et bevidst indgreb i denne regel. Det egner sig ikke som en generel løsning til at gøre reverse proxyen hurtigere eller til at skjule DNS-problemer.

Korrekt opløsning af variabler i proxy_pass

Indeholder proxy_pass en variabel, skal NGINX behandle det resulterende værtsnavn under kørsel. Først søger NGINX efter en passende upstream-gruppe; hvis den ikke finder nogen, har den brug for en konfigureret resolver til navnet. Mangler denne, er den typiske meddelelse no resolver defined Der er ikke tale om en HTTP-cache, men om manglende DNS-konfiguration for denne eksekveringssti.

Følgende eksempel gør kørselstidsopløsningen bevidst synlig. Resolveren befinder sig i http-konteksten og gælder derfor for flere virtuelle værter, medmindre en mere specifik indstilling tilsidesætter den. Den anvendte dokumentationsadresse skal erstattes med det pågældende miljøs interne resolver.

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 bestemmer ikke cachevarigheden. Den begrænser, hvor længe NGINX venter på en navneopløsning; den dokumenterede standard er 30 sekunder. Valget hører til de øvrige fejlbudgetter: En for høj værdi kan forsinke en mislykket forespørgsel indtil fejlmeddelelsen, mens en for lav værdi medfører unødvendige opslagsfejl, når de interne opslagsmaskiner midlertidigt er langsomme.

For en enkelt, klart afgrænset placering kan resolveren i location-blokken. Hvis flere lokationer eller servere har brug for den samme opløsning, skal der oprettes et fælles scope i server- eller http-Blok kræver mindre vedligeholdelse. NGINX tillader direktivet i alle tre sammenhænge; anvendelsesområdet bør afspejle den faktiske driftsstruktur og ikke blot løse en enkelt fejlmeddelelse på kort sigt.

Selv ved variable mål forbliver DNS-timeout og forbindelsen til backend separate fejlkategorier. En vellykket navneopløsning beviser hverken, at målporten er tilgængelig, eller at applikationen svarer. Omvendt løser en længere upstream-timeout ikke problemet med en utilgængelig resolver-adresse.

Konfigurer dynamiske upstreams med `resolve`

For en navngivet backend-gruppe kan en dynamisk upstream være mere overskuelig end en variabel målværdi på hvert enkelt sted. Mønsteret adskiller definitionen af backend-medlemmerne fra routingen: proxy_pass henviser til gruppen, mens værtsnavnet i upstream kan opdateres via DNS. Dette er især velegnet, når flere ruter peger på den samme applikation.

Parameteren resolve til en server-Indstillingen har historisk set eksisteret siden NGINX 1.5.12. I NGINX Open Source er den ifølge dokumentationen dog først tilgængelig fra version 1.27.3; før da var denne funktion begrænset til den kommercielle version. Også resolver-konfigurationen direkte i upstream-Blokken er dokumenteret som open source fra version 1.27.3.

Die Shared-Memory-Zone Der er her tale om hverken en cache-timeout eller en DNS-datavej. Den stiller fælles hukommelse til rådighed inden for NGINX, som er nødvendig for dynamisk ændrede upstream-konfigurationer. Hvis NGINX ved DNS-opløsningen finder andre adresser for navnet, kan upstream-gruppen tilpasses på baggrund af denne internt administrerede tilstand uden genstart.

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

Som i alle eksempler gælder det, at 192.0.2.53 kun til en dokumentationsadresse. I praksis skal den registrerede resolver kende de interne navne pålideligt, være tilgængelig fra NGINX-netværket og betragtes som pålidelig. Inden implementeringen skal man desuden kontrollere det installerede pakkes faktiske funktionsomfang i stedet for udelukkende at udlede konfigurationen ud fra et aktuelt eksempel.

En tjeneste, der udelukkende er tilgængelig via IPv4, kan berettige en målrettet begrænsning: resolver 192.0.2.53 ipv6=off; forhindrer AAAA-forespørgsler og valg af en IPv6-adresse for denne resolver-kontekst. Dette er dog et valg, der skal træffes på netværksarkitekturniveau. Når Dual Stack fungerer korrekt, bør IPv6 ikke deaktiveres blot af vane; som standard løser NGINX begge IP-familier.

Kontroller konfigurationen grundigt og implementer den

Inden du foretager en ændring, skal du først kontrollere, hvor resolver-direktiverne rent faktisk gælder. Gennemgå derfor den aktive konfiguration, herunder de indlæste filer, og fastslå, om resolveren gælder for hele http-kontekst, der kun er beregnet til en virtuel vært eller blot til en enkelt sti. Et for snævert anvendelsesområde kan medføre, at en anden variabel proxy-sti ikke kan finde en resolver; et for bredt anvendelsesområde gør derimod den senere tilknytning af ændringer vanskelig.

Efter hver tilpasning følger Syntakscheck. Den indlæser konfigurationen og forsøger også at åbne de filer, der henvises til. På den måde kan man opdage stavefejl, ugyldige direktiver og problemer i include-filer, inden man genindlæser. Kontrollen beviser dog ikke, at den angivne DNS-server er tilgængelig, kender det forventede navn eller at backend'et bag en opløst adresse accepterer forbindelser.

nginx -t
nginx -s reload

Udfør først genindlæsningen, når kontrollen er gennemført med et positivt resultat. nginx -s reload får NGINX til at starte nye worker-processer med den nye konfiguration og afslutte de gamle worker-processer på en kontrolleret måde. Afhængigt af den installerede pakke og operativsystemet kan den dertilhørende servicemanager i stedet udløse genindlæsningen. Brug derfor den dokumenterede fremgangsmåde for installationen i stedet for at overtage kommandoer fra et eksternt miljø.

Planlæg derefter en teknisk test inden for det fastsatte ændringsvindue. Sammenlign den forventede DNS-TTL med det tidspunkt, hvorfra en ny backend-adresse skal tages i brug, og kontroller, om tjenesten er tilgængelig via den faktisk tilladte IP-familie. Dokumenter desuden resolver-adressen, det valgte omfang og en eventuel valid-Override. På den måde kan man i tilfælde af en fejl skelne mellem, om årsagen ligger i DNS, routing eller applikationen.

Systematisk indsnævring af typiske resolver-fejl

Start fejlfindingen ved måludtrykket i proxy_pass. Hvis den indeholder en variabel, skal NGINX løse det indeholdte værtsnavn under kørsel, medmindre dette tilhører en defineret upstream-gruppe. Meddelelsen no resolver defined påpeger derfor først og fremmest, at der mangler en eller at den ikke er synlig i den relevante sammenhæng Resolver-konfiguration . Tilføj en pålidelig navneserver i den relevante sammenhæng, i stedet for forhastet at erstatte værtsnavnet med en fast IP-adresse.

Hvis der er konfigureret en resolver, skal du herefter kontrollere dens adresse, netværkssti og ansvarsområde for den anvendte zone. En offentlig resolver kan ikke kende interne navne; en resolver, der ikke kan nås, medfører derimod timeout ved navneopløsning. Kontroller desuden, om direktivet overskrives af en mere specifik indstilling. NGINX bruger kun de udtrykkeligt angivne navneservere, ikke automatisk alle indstillinger fra /etc/resolv.conf.

Hvis en gammel destinationsadresse forbliver aktiv efter et DNS-skift, skal du kontrollere svarets TTL og se, om der er angivet en valid. En lang override erstatter TTL-værdien i DNS-svaret og kan dermed forsinke gennemførelsen af en ændring. Den tilladte korrektion er ikke en generel, så kort varighed som muligt, men en værdi, der passer til ændringsvinduet og DNS-infrastrukturens belastbarhed; ofte er udeladelsen af valid den renere løsning.

Hvis der opstår forbindelsesproblemer efter en vellykket opløsning, skal du adskille DNS fra backend-forbindelsen. Kontroller, om der foreligger A- og AAAA-svar, og om destinationen rent faktisk routes via IPv6 og er tilgængelig. ipv6=off er kun egnet til en arkitektur, hvor det kan påvises, at der udelukkende anvendes IPv4. En DNS-timeout vedrører navneopløsningen; en forbindelsesfejl til en allerede kendt IP-adresse skyldes derimod routing, firewall, port eller applikation.

For dynamiske upstreams skal der desuden angives versionsnummer, shared-memory-zone og resolve er kompatible. Den dokumenterede open source-understøttelse gælder fra og med NGINX 1.27.3; ældre installationer må ikke betragtes som ækvivalente. status_zone Desuden udgør API-baserede resolver-statistikker ikke en generel overvågningsløsning til NGINX Open Source, da de nævnte funktioner vedrører kommerciel brug.

Vælg en resolver-strategi til driften

Den rigtige strategi starter ikke med en fast cache-værdi, men med DNS-kontrol og ændringsfrekvens. Hvis dit team kan vedligeholde den autoritative zone, og hvis dens TTL’er realistisk afspejler implementeringsvinduet, er en TTL-styret opløsning uden valid er som regel det mest logiske udgangspunkt. DNS forbliver så den afgørende kilde til, hvor længe et svar anvendes.

Et bevidst valgt valid kan komme på tale, hvis du ikke kan påvirke TTL’en og kan begrunde en afvigende cache-varighed ud fra driftsmæssige årsager. Husk at fastlægge, hvilke konsekvenser af nedbrud der er acceptable: En længere værdi reducerer antallet af mulige DNS-forespørgsler, men kan efter en flytning pege på en adresse, der ikke længere er gyldig. Den er hverken en øvre grænse for DNS-TTL eller en generel præstationsregulator.

Vælg derefter NGINX-mønsteret ud fra routingstrukturen. En variabel proxy_pass er egnet, når målet bestemmes under kørsel for hver forespørgsel eller konfiguration; dette kræver en resolver i det relevante omfang. For en navngivet backend-gruppe med DNS-baserede adresseændringer kræves en upstream med zone og resolve klart, forudsat at NGINX Open Source 1.27.3 eller nyere faktisk er tilgængelig.

Først derefter beslutter du Timeouts og IP-familier. Resolver-timeoutet skal stemme overens med klient- og upstream-timeouts, så en udeblivet DNS-svar ikke forsinker fejlmeldinger uforholdsmæssigt meget. IPv4 eller IPv6 skal du kun aktivere i overensstemmelse med netværksarkitekturen. Brug udelukkende sikre resolvere, der pålideligt kan besvare interne zoner.

DNS-opløsning og upstream-keepalive løser forskellige opgaver. Resolveren afgør, hvilken backend-adresse NGINX kan bruge; keepalive opretholder allerede etablerede, inaktive backend-forbindelser med henblik på genbrug. En ændring af genbrug af forbindelser erstatter derfor hverken TTL-planlægning eller resolver-kontrol. For dimensionering af dette forbindelsesniveau supplerer artiklen om NGINX Upstream Keepalive Resolver-strategien.