De NGINX-resolvercache correct configureren

NGINX-resolver en DNS-cache begrijpen

Een reverse proxy heeft voor een backend met een hostnaam eerst een IP-adres nodig. De NGINX-resolver raadt daarvoor de in de configuratie opgegeven naamservers op. Het ontvangen DNS-antwoord wordt in de cache opgeslagen, zodat NGINX de naam tijdens de geldigheidsduur ervan niet bij elk verzoek opnieuw hoeft op te zoeken. Deze cache heeft uitsluitend betrekking op het opzoeken van de naam van het doelsysteem.

De richtlijn resolver bevat een of meer resolver-adressen of ondersteunde resolver-identificatoren. Tenzij anders aangegeven, gebruikt NGINX poort 53; als er meerdere servers zijn opgegeven, worden de verzoeken volgens de documentatie volgens het round-robin-principe verwerkt. Voor een robuuste bootstrap-configuratie zijn vaste IP-adressen vaak aan te raden, omdat de resolutie ervan niet zelf afhankelijk is van DNS.

Standaard houdt NGINX rekening met zowel IPv4- als IPv6-adressen van een naam. Dit is geschikt wanneer het netwerk beide protocolfamilies betrouwbaar naar de backend doorgeeft. Parameters zoals ipv4=off of ipv6=off sluiten een bepaalde familie doelgericht uit, maar vormen geen algemene cache-optimalisatie. Of ze nodig zijn, hangt af van de bereikbaarheid van de specifieke backend en niet van het loutere bestaan van een AAAA-record.

De resolver is noch een volwaardige recursieve DNS-server, noch een automatische overname van alle instellingen uit /etc/resolv.conf. NGINX maakt gebruik van de expliciet opgegeven naamservers. Voor interne zones en productieve backend-namen moeten dit betrouwbare, adequaat beveiligde resolvers binnen het eigen netwerk zijn. Zo blijven de verantwoordelijkheid voor privé-namen en de bescherming tegen gemanipuleerde DNS-antwoorden binnen een beheersbare infrastructuur.

Een DNS-cache is geen HTTP-cache

De DNS-responscache van de resolver slaat koppelingen op tussen namen en DNS-antwoorden, zoals A- of AAAA-adressen. Het doel hiervan is om een backend opnieuw te kunnen bereiken zonder elke naamomzetting te hoeven herhalen. Als het IP-adres van een backend verandert, is daarom de geldigheid van het DNS-antwoord relevant – niet de inhoud van een eerder geleverd HTTP-antwoord.

Los daarvan slaat het op proxy_cache HTTP-responsen van een upstream. Afhankelijk van de configuratie omvat de sleutel bijvoorbeeld de URI, host of header; bij een treffer wordt een reeds opgeslagen antwoord aan de client geleverd. Problemen die hierbij kunnen optreden zijn verouderde pagina's, verkeerde varianten of onverwachte cache-treffers. Deze functie bepaalt niet welk IP-adres NGINX gebruikt bij het tot stand brengen van een nieuwe backend-verbinding.

De Open-File-Cache is een derde niveau: deze bevat bestandsinformatie en open descriptoren voor lokale toegang tot het bestandssysteem, maar geen DNS-antwoorden of HTTP-inhoud. Wie deze afbakening voor statische levering nader wil bestuderen, kan dit vinden in het artikel over de Configuratie van de NGINX Open File Cache. Hij biedt echter geen houvast bij de keuze van een Resolver-TTL.

Het leegmaken, purgen of vernieuwen van een HTTP-cache versnelt daarom geen DNS-wijziging. Omgekeerd lost een nieuwe DNS-resolutie geen foutief in de cache opgeslagen HTTP-antwoord op. Bij een reverse proxy beperkt de DNS-cache het is bovendien gebaseerd op namen en adressen: het controleert noch de gezondheid van een applicatie, noch vervangt het load-balancing, herhalingspogingen of de juiste time-outplanning naar de upstream.

Wanneer NGINX namen opnieuw moet omzetten

Een hostnaam kan al bij het inlezen van de configuratie bekend zijn bij NGINX. Dit is anders bij een variabele bestemming, bijvoorbeeld proxy_pass http://$backend;. NGINX zoekt de resulterende naam eerst in gedefinieerde upstream-groepen. Als het daar geen passende naam vindt, heeft het tijdens de uitvoering een geconfigureerde resolver nodig om het doeladres te bepalen.

Het bericht no resolver defined Dit duidt in dit verband niet op een ontbrekende HTTP-cache. Het betekent dat NGINX geen DNS-server kent voor de benodigde resolutie tijdens de uitvoering. resolver mag in deze context http, server of location staan. Een centrale vermelding in de http-Block is geschikt wanneer meerdere virtuele hosts gebruikmaken van dezelfde resolver; een beperktere scope is alleen zinvol als de vereisten daadwerkelijk verschillen.

Deze runtime-resolutie, die al lange tijd beschikbaar is, moet worden onderscheiden van de dynamische bijwerking van een klassieke upstream-groep. De resolver-configuratie direct in de upstream-blok en server hostname resolve Volgens de documentatie zijn deze in NGINX Open Source beschikbaar vanaf versie 1.27.3. Oudere Open Source-installaties mogen niet worden beschouwd als zouden ze dit patroon automatisch ondersteunen; dergelijke functies waren in het verleden deels voorbehouden aan NGINX Plus.

Voordat je dynamische upstreams gaat plannen, controleer je de geïnstalleerde uitvoer en de build-informatie. Het volgende commando geeft de NGINX-versie, de compiler-versie en de configure-parameters weer die bij het bouwen zijn gebruikt.

nginx -V

Vergelijk de weergegeven status bij kritieke implementaties met de documentatie van het daadwerkelijk gebruikte pakket en de aanbieder daarvan. Het is van doorslaggevend belang of deze installatie de benodigde functie documenteert en beschikbaar stelt. Pas daarna is een dynamische upstream een robuuste architecturale keuze.

TTL en valid bewust instellen

De resolver-cache van NGINX volgt, zonder aanvullende instellingen, de DNS-TTL in het antwoord van de geraadpleegde naamserver. Als de autoritatieve DNS-beheerder het IP-adres van een backend wijzigt, gebruikt NGINX het eerdere antwoord totdat de TTL is verstreken. Pas wanneer daarna opnieuw een naamomzetting nodig is, vraagt NGINX de resolver opnieuw op. Zo blijft de geldigheidsduur beheersbaar op de plek waar de naamgegevens worden bijgehouden.

De parameter valid vervangt deze TTL volledig door de geconfigureerde tijdsduur. Het beperkt de DNS-TTL dus niet alleen naar boven toe en definieert ook geen regelmatige verversing naast de TTL. Een waarde van valid=30s kan een langere DNS-TTL verkorten, maar ook een bewust korte TTL verlengen. Dit moet aansluiten bij de verhuis- en implementatieplanning van de backend.

Als de zone op betrouwbare wijze wordt onderhouden, is een configuratie zonder override het logische uitgangspunt. Het adres in het voorbeeld is gekozen op basis van de documentatienetwerken en mag niet worden overgenomen als productieve resolver. Voer in plaats daarvan het adres in van een bereikbare en betrouwbare DNS-resolver uit je eigen netwerk.

resolver 192.0.2.53;
resolver_timeout 5s;

Een override kan zinvol zijn als de DNS-TTL niet kan worden aangepast en er een gedocumenteerde bedrijfsrichtlijn bestaat. Dan maakt de afwijking expliciet zichtbaar hoe lang NGINX antwoorden vasthoudt. Het is geen algemene prestatieoptimalisatie: kortere tijden kunnen meer DNS-verzoeken veroorzaken, langere tijden kunnen de overstap naar nieuwe backend-adressen vertragen.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

De beslissing begint daarom niet met een vast aantal seconden, maar met de vraag wie de DNS-gegevens beheert en hoe snel een backend-wijziging van kracht moet worden. geldig is een bewuste ingreep in deze regeling. Het is niet geschikt als algemene oplossing om de reverse proxy sneller te maken of DNS-problemen te verdoezelen.

Variabelen in `proxy_pass` correct omzetten

Bevat proxy_pass een variabele, moet NGINX de resulterende hostnaam tijdens de uitvoering verwerken. Eerst zoekt NGINX naar een geschikte upstream-groep; als het die niet vindt, heeft het een geconfigureerde resolver nodig voor de naam. Ontbreekt deze, dan is de typische melding no resolver defined geen verwijzing naar een HTTP-cache, maar naar de ontbrekende DNS-configuratie voor dit uitvoeringspad.

Het volgende voorbeeld maakt de runtime-resolutie bewust zichtbaar. De resolver staat in de http-context en geldt daardoor voor meerdere virtuele hosts, tenzij een specifiekere instelling deze overschrijft. Het gebruikte documentatieadres moet worden vervangen door de interne resolver van de betreffende omgeving.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

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

De richtlijn resolver_timeout heeft geen invloed op de cacheduur. Het bepaalt hoe lang NGINX wacht op het omzetten van een naam; de gedocumenteerde standaardwaarde is 30 seconden. De keuze valt onder de overige foutmarges: een te hoge waarde kan ervoor zorgen dat een mislukte aanvraag pas na een foutmelding wordt afgehandeld, terwijl een te lage waarde bij tijdelijk trage interne resolvers vermijdbare resolutiefouten veroorzaakt.

Voor een afzonderlijke, duidelijk afgebakende locatie kan de resolver in de location-blok staan. Als meerdere locaties of servers dezelfde resolutie nodig hebben, is een gemeenschappelijke scope in het server- of http-Block vereist minder onderhoud. NGINX staat de richtlijn in alle drie de contexten toe; het toepassingsgebied moet de daadwerkelijke bedrijfsstructuur weerspiegelen, en niet alleen bedoeld zijn om een enkele foutmelding tijdelijk op te lossen.

Ook bij variabele doelen blijven de DNS-time-out en de verbinding met de backend afzonderlijke foutklassen. Een succesvolle naamresolutie bewijst noch dat de doelpoort bereikbaar is, noch dat de toepassing reageert. Omgekeerd lost een langere upstream-time-out een onbereikbaar resolver-adres niet op.

Dynamische upstreams configureren met resolve

Voor een bepaalde backend-groep kan een dynamische upstream duidelijker zijn dan een variabele bestemmingswaarde op elke locatie. Dit patroon scheidt de definitie van de backend-leden van de routing: proxy_pass verwijst naar de groep, terwijl de hostnaam in de upstream via DNS kan worden bijgewerkt. Dit is met name handig wanneer meerdere routes naar dezelfde toepassing leiden.

De parameter resolve voor een server-Deze instelling bestaat al sinds NGINX 1.5.12. In de open-sourceversie van NGINX is deze volgens de documentatie echter pas vanaf versie 1.27.3 beschikbaar; daarvoor was deze functie beperkt tot commerciële gebruikers. Ook de resolver-configuratie rechtstreeks in het upstream-Block is vanaf versie 1.27.3 gedocumenteerd voor open source.

De Shared-Memory-Zone Het gaat hierbij niet om een cache-time-out of een DNS-gegevenspad. Het stelt binnen NGINX gedeeld geheugen beschikbaar dat nodig is voor dynamisch gewijzigde upstream-configuraties. Als NGINX bij de DNS-resolutie andere adressen voor de naam detecteert, kan de upstream-groep op basis van deze intern beheerde status worden aangepast zonder dat er een herstart nodig is.

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

Zoals bij alle voorbeelden geldt 192.0.2.53 alleen voor een documentatieadres. In de praktijk moet de geregistreerde resolver de interne namen betrouwbaar kennen, bereikbaar zijn vanuit het NGINX-netwerk en als betrouwbaar worden beschouwd. Voorafgaand aan de implementatie moet bovendien de daadwerkelijke functionaliteit van het geïnstalleerde pakket worden gecontroleerd, in plaats van de configuratie uitsluitend af te leiden uit een actueel voorbeeld.

Een dienst die uitsluitend via IPv4 bereikbaar is, kan een gerichte beperking rechtvaardigen: resolver 192.0.2.53 ipv6=off; voorkomt AAAA-verzoeken en het selecteren van een IPv6-adres voor deze resolver-context. Dit is echter een beslissing die betrekking heeft op de netwerkarchitectuur. Als dual stack goed functioneert, mag IPv6 niet louter uit gewoonte worden uitgeschakeld; standaard verwerkt NGINX beide IP-families.

De configuratie zorgvuldig controleren en implementeren

Voordat je een wijziging aanbrengt, controleer je eerst op welke plaatsen de Resolver-richtlijnen daadwerkelijk van toepassing zijn. Bekijk hiervoor de actieve configuratie, inclusief de ingesloten bestanden, en ga na of de Resolver voor het gehele http-context, die alleen voor een virtuele host of slechts voor één enkel pad is bedoeld. Een te beperkt bereik kan ertoe leiden dat een ander variabel proxypad geen resolver vindt; een te breed bereik maakt het daarentegen moeilijker om wijzigingen achteraf toe te wijzen.

Na elke aanpassing volgt de Syntaxicontrole. Het leest de configuratie in en probeert ook de bestanden waarnaar wordt verwezen te openen. Zo kunnen typefouten, ongeldige richtlijnen en problemen in include-bestanden worden opgespoord voordat de pagina opnieuw wordt geladen. De controle bewijst echter niet dat de opgegeven DNS-server bereikbaar is, de verwachte naam kent of dat de backend achter een omgezet adres verbindingen accepteert.

nginx -t
nginx -s reload

Voer de herlaadbeurt pas uit nadat de controle met succes is doorlopen. nginx -s reload zorgt ervoor dat NGINX nieuwe workers met de nieuwe configuratie start en oude workers op een gecontroleerde manier afsluit. Afhankelijk van het geïnstalleerde pakket en het besturingssysteem kan in plaats daarvan de daarin voorziene servicemanager de herlaadactie in gang zetten. Gebruik hiervoor de gedocumenteerde procedure van de installatie, in plaats van commando’s uit een externe omgeving over te nemen.

Plan vervolgens een technische controle in de daarvoor bestemde wijzigingsperiode. Vergelijk de verwachte DNS-TTL met het tijdstip waarop een nieuw backend-adres moet worden gebruikt en controleer of de dienst bereikbaar is via de daadwerkelijk toegestane IP-familie. Documenteer bovendien het resolver-adres, de gekozen scope en een mogelijke valid-Override. Zo kan bij een storing worden vastgesteld of de oorzaak bij het DNS, de routing of de toepassing ligt.

Typische resolverfouten systematisch opsporen

Begin met het opsporen van fouten in de doeluitdrukking in proxy_pass. Als deze een variabele bevat, moet NGINX de daarin opgenomen hostnaam tijdens de uitvoering omzetten, tenzij deze tot een gedefinieerde upstream-groep behoort. Het bericht no resolver defined wijst daarom allereerst op een ontbrekend element of een element dat in de relevante context niet zichtbaar is Resolver-configuratie . Voeg in de juiste context een betrouwbare naamserver toe, in plaats van de hostnaam overhaast te vervangen door een vast IP-adres.

Als er een resolver is geconfigureerd, controleer je vervolgens het adres, het netwerkpad en de bevoegdheid voor de gebruikte zone. Een openbare resolver kan geen interne namen kennen; een onbereikbare resolver veroorzaakt daarentegen time-outs bij het omzetten van namen. Controleer bovendien of de richtlijn wordt overschreven door een specifiekere instelling. NGINX gebruikt alleen de expliciet opgegeven naamservers, niet automatisch alle instellingen uit /etc/resolv.conf.

Als er na een DNS-wijziging nog een oud doeladres actief is, controleer dan de TTL van het antwoord en of er een valid. Een lange override vervangt de TTL van het DNS-antwoord en kan de doorvoering van een wijziging dienovereenkomstig vertragen. De toegestane correctie is niet zomaar een zo kort mogelijke duur, maar een waarde die past bij het wijzigingsvenster en de belastbaarheid van de DNS-infrastructuur; vaak is het weglaten van valid de schonere oplossing.

Als er na een succesvolle resolutie verbindingsproblemen optreden, koppel je DNS los van de backend-verbinding. Controleer of er A- en AAAA-antwoorden zijn en of de bestemming daadwerkelijk via IPv6 wordt gerouteerd en bereikbaar is. ipv6=off is alleen geschikt voor een architectuur waarbij aantoonbaar uitsluitend IPv4 wordt gebruikt. Een DNS-time-out heeft betrekking op de naamomzetting; een verbindingsfout met het reeds bekende IP-adres duidt daarentegen op een probleem met de routing, de firewall, de poort of de toepassing.

Voor dynamische upstreams moeten bovendien de versienummer, de shared-memory-zone en resolve op elkaar aansluiten. De hiervoor gedocumenteerde open-source-ondersteuning geldt vanaf NGINX 1.27.3; oudere installaties mogen niet als gelijkwaardig worden beschouwd. status_zone Bovendien vormen API-gebaseerde resolver-statistieken geen algemene monitoringoplossing voor NGINX Open Source, aangezien de genoemde functies betrekking hebben op commerciële toepassingen.

Een resolver-strategie voor de bedrijfsvoering kiezen

De juiste strategie begint niet met een vaste cachewaarde, maar met DNS-soevereiniteit en de wijzigingsfrequentie. Als jouw team de autoritatieve zone kan onderhouden en de TTL’s daarvan een realistisch beeld geven van het implementatievenster, dan is een TTL-gestuurde resolutie zonder valid meestal het meest logische uitgangspunt. DNS blijft dan de belangrijkste bron om te bepalen hoe lang een antwoord wordt gebruikt.

Een bewust gekozen valid is een optie als je de TTL niet kunt beïnvloeden en een afwijkende cacheduur operationeel kunt rechtvaardigen. Bepaal daarbij welke gevolgen van een storing acceptabel zijn: een langere waarde vermindert het aantal mogelijke DNS-verzoeken, maar kan na een verhuizing naar een adres verwijzen dat niet meer klopt. Het is noch een bovengrens voor de DNS-TTL, noch een algemene prestatieschakelaar.

Kies vervolgens het NGINX-patroon op basis van de routingstructuur. Een variabele proxy_pass is geschikt wanneer de bestemming per verzoek of configuratie tijdens de uitvoering wordt bepaald; hiervoor is een resolver in de juiste scope vereist. Voor een benoemde backend-groep met op DNS gebaseerde adreswijzigingen is een upstream nodig met zone en resolve duidelijker, mits NGINX Open Source 1.27.3 of nieuwer daadwerkelijk beschikbaar is.

Pas daarna bepaal je Time-outs en IP-families. De time-out van de resolver moet worden afgestemd op de time-outs van de client en de upstream, zodat een uitblijvend DNS-antwoord de foutmelding niet onnodig vertraagt. Schakel IPv4 of IPv6 alleen in overeenkomstig de netwerkarchitectuur. Gebruik uitsluitend beveiligde resolvers die betrouwbaar kunnen reageren op interne zones.

DNS-resolutie en upstream-keepalive vervullen verschillende taken. De resolver bepaalt welk backend-adres NGINX kan gebruiken; keepalive houdt reeds tot stand gebrachte, inactieve backend-verbindingen in stand voor hergebruik. Een wijziging in het hergebruik van verbindingen vervangt daarom noch de TTL-planning, noch de resolvercontrole. Voor het dimensioneren van dit verbindingsniveau vult het artikel over NGINX Upstream Keepalive de resolverstrategie.