NGINXのリゾルバーキャッシュを正しく設定する

NGINXのリゾルバーとDNSキャッシュの仕組みを理解する

リバースプロキシは、ホスト名を持つバックエンドに対して、まずIPアドレスを必要とします。その NGINXリゾルバー その代わりに、設定で指定されたネームサーバーに問い合わせを行います。返されたDNS応答はキャッシュされるため、NGINXはその有効期間中は、リクエストごとにその名前を再度解決する必要がなくなります。このキャッシュは、ターゲットシステムへの名前解決にのみ適用されます。.

指令 resolver 1つまたは複数のリゾルバーアドレス、あるいはサポートされているリゾルバー識別子が含まれます。ポートが特に指定されていない場合、NGINXはポート53を使用します。複数のサーバーが登録されている場合、ドキュメントによると、リクエストはラウンドロビン方式で処理されます。 堅牢なブートストラップ設定を行う場合、固定IPアドレスは、その解決がDNS自体に依存しないため、追跡しやすいことがよくあります。.

NGINX はデフォルトで、ホスト名の IPv4 および IPv6 アドレスを認識します。これは、ネットワークが両方のプロトコルファミリーをバックエンドまで確実に転送できる場合に適しています。次のようなパラメータは ipv4=off 或いは ipv6=off 特定のファミリーを意図的に除外するものですが、一般的なキャッシュ最適化というわけではありません。これらが本当に必要かどうかは、具体的なバックエンドへの到達可能性によって決まり、単にAAAAレコードが存在するかどうかに左右されるものではありません。.

このリゾルバーは、本格的な再帰型DNSサーバーでもなければ、すべての設定を自動的に引き継ぐものでもありません。 /etc/resolv.conf. NGINXは、明示的に指定されたネームサーバーを使用します。内部ゾーンや本番環境のバックエンド名については、自社ネットワーク内にあり、信頼性が高く、適切に保護されたリゾルバーを使用すべきです。そうすることで、プライベートな名前に対する管理責任と、改ざんされたDNS応答からの保護を、管理可能なインフラストラクチャ内で維持することができます。.

DNSキャッシュはHTTPキャッシュではありません

リゾルバーのDNSレスポンスキャッシュは、名前とDNSレスポンス（AレコードやAAAAレコードなどのアドレスなど）との対応関係を保存します。その目的は、名前解決を毎回繰り返すことなく、バックエンドに再度アクセスできるようにすることにあります。 したがって、バックエンドのIPアドレスが変更された場合、重要なのはDNS応答の有効期限であり、以前に返されたHTTP応答の内容ではありません。.

これとは別に保存します proxy_cache アップストリームからのHTTPレスポンス。 キーには、設定に応じてURI、ホスト、ヘッダーなどが含まれます。一致した場合、クライアントには既に保存されているレスポンスが返されます。ここで発生する問題としては、ページが古くなっている、誤ったバリエーションが返される、予期しないキャッシュヒットなどが挙げられます。この機能は、NGINXが新しいバックエンド接続を確立する際にどのIPアドレスを使用するかを決定するものではありません。.

オープンファイルキャッシュは第3のレイヤーです。これは、ローカルファイルシステムへのアクセスに関するファイル情報やオープンなディスクリプタを保持しますが、DNS応答やHTTPコンテンツは保持しません。静的配信に関するこの区別についてさらに詳しく知りたい方は、以下の記事をご覧ください。 NGINXのオープンファイルキャッシュの設定. 。しかし、リゾルバーのTTLを選択するための判断材料は提供していない。.

したがって、HTTPキャッシュのクリア、パージ、または調整を行っても、DNSの変更が速くなることはありません。逆に、新しいDNS解決を行っても、誤ってキャッシュされたHTTPレスポンスは修正されません。リバースプロキシの場合、 DNSキャッシュ さらに、名前とアドレスのみに基づいて動作します。アプリケーションの健全性を検証するわけでもなく、ロードバランシングやリトライ、あるいはアップストリームへの適切なタイムアウト設定に代わるものでもありません。.

NGINX が名前を再度解決する必要がある場合

ホスト名は、NGINXが設定を読み込む時点で既に判明している場合があります。一方、可変のターゲットの場合は事情が異なり、例えば proxy_pass http://$backend;. NGINXはまず、定義されたアップストリームグループ内で結果として得られる名前を検索します。そこで一致する名前が見つからない場合、実行時に宛先アドレスを特定するために、設定済みのリゾルバーが必要となります。.

その報告 no resolver defined この文脈において、HTTPキャッシュが存在しないことを示しているわけではありません。これは、NGINXが必要な実行時の解決を行うためのDNSサーバーを認識していないことを意味します。. resolver この文脈では http, server 或いは location にある。の中心的なエントリとして http-Blockは、複数の仮想ホストが同じリゾルバーを使用する場合に適しています。より狭いスコープは、実際に要件が異なる場合にのみ適しています。.

この長期間利用可能な実行時間分解能については、従来のアップストリーム・グループの動的な更新とは区別する必要があります。リゾルバーの設定は、直接 upstream-ブロックおよび server hostname resolve ドキュメントによると、NGINXのオープンソース版ではバージョン1.27.3以降で利用可能です。それ以前のオープンソース版については、このパターンを自動的にサポートしていると見なしてはなりません。歴史的に、関連する機能の一部はNGINX Plusに限定されていたためです。.

動的なアップストリームを計画する前に、インストール済みの出力とビルド情報を確認してください。次のコマンドを実行すると、NGINXのバージョン、コンパイラのバージョン、およびビルド時に使用されたconfigureパラメータが表示されます。.

nginx -V

重要なデプロイメントにおいて、表示された状態を、実際に使用しているパッケージおよびその提供元のドキュメントと照らし合わせて確認してください。重要なのは、そのインストールが必要な機能をドキュメントに記載し、提供しているかどうかです。その確認が終わって初めて、 動的なアップストリーム 堅牢なアーキテクチャ上の決定。.

TTL と valid を明示的に設定する

NGINXのリゾルバーキャッシュは、追加の設定がない場合、以下の設定に従います。 DNS-TTL 問い合わせたネームサーバーからの応答内。権威DNS事業者がバックエンドのIPアドレスを変更した場合、NGINXはTTLが切れるまで従来の応答を使用します。 その後、再度名前解決が必要になった時点で初めて、NGINXはリゾルバーに再問い合わせを行います。これにより、名前データの管理が行われている場所で有効期間を制御できるようになります。.

パラメータ valid このTTLを、設定された期間で完全に置き換えます。つまり、DNSのTTLの上限を制限するだけでなく、TTLに加えて定期的な更新も定義しません。値は valid=30s 長いDNSのTTLを短縮することもできますが、意図的に短く設定されたTTLを延長することも可能です。これは、バックエンドの移行およびデプロイ計画と整合性がとれている必要があります。.

ゾーンが確実に管理されている場合、オーバーライドを行わない設定が、妥当な出発点となります。例示されているアドレスは、ドキュメントネットワークに基づいて選択されたものであり、本番環境のリゾルバーとして採用してはなりません。代わりに、自ネットワーク内の到達可能で信頼できるDNSリゾルバーのアドレスを入力してください。.

resolver 192.0.2.53;
resolver_timeout 5s;

DNSのTTLを変更できず、文書化された運用上の規定が存在する場合、オーバーライドが有効な手段となることがあります。 そうすることで、NGINXがレスポンスを保持する期間が明確に可視化されます。これは一般的なパフォーマンス最適化ではありません。保持時間を短くするとDNSクエリの回数が増える可能性があり、長くすると新しいバックエンドアドレスへの切り替えが遅れる可能性があります。.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

したがって、この判断は特定の秒数から始まるのではなく、誰がDNSデータを管理しているのか、そしてバックエンドの切り替えがどのくらいの速さで有効になる必要があるのかという問いから始まる。. 有効 これは、このルールに対する意図的な変更です。リバースプロキシの速度向上やDNSの問題を隠蔽するための、画一的な手段としては適していません。.

proxy_pass 内の変数を正しく展開する

内容： proxy_pass 変数である場合、NGINXは実行時にその結果として得られるホスト名を処理する必要があります。まず、NGINXは該当するアップストリームグループを検索します。見つからない場合は、その名前に対して設定済みのリゾルバーが必要となります。これが存在しない場合、通常次のようなメッセージが表示されます。 no resolver defined HTTPキャッシュに関する指摘ではなく、この実行パスに対するDNS設定が欠落していることを示しています。.

次のサンプルコードでは、実行時の解決処理を意図的に可視化しています。リゾルバーは http-コンテキストに定義されるため、より具体的な設定によって上書きされない限り、複数の仮想ホストに適用されます。指定されたドキュメントのアドレスは、各環境の内部リゾルバーで置き換える必要があります。.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

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

指令 resolver_timeout キャッシュの有効期間を制御するものではありません。これは、NGINXが名前解決を待機する時間を制限するものであり、ドキュメントに記載されているデフォルト値は30秒です。 この設定は、その他のエラー許容範囲の一部です。値が高すぎると、リクエストが失敗してからエラー応答が返されるまでの時間が長くなり、低すぎると、一時的に動作が遅い内部リゾルバーを使用している場合に、回避可能な解決エラーが発生する可能性があります。.

単一の、明確に区切られたロケーションについては、リゾルバーは location-ブロックに記述します。複数のロケーションやサーバーで同じ解像度が必要な場合は、 server- または http-Blockはメンテナンスの手間が少ない。NGINXでは、このディレクティブを3つのコンテキストすべてで指定できる。その適用範囲は、単一のエラーメッセージを一時的に解消するだけでなく、実際の運用構造を反映したものであるべきだ。.

ターゲットが変動する場合でも、DNSタイムアウトとバックエンドへの接続は別々のエラーカテゴリとして扱われます。名前解決が成功したからといって、ターゲットポートに到達できることや、アプリケーションが応答することを保証するものではありません。逆に、アップストリームタイムアウトの値を大きくしても、到達不可能なリゾルバーのアドレスが解決されるわけではありません。.

resolve を使用して動的なアップストリームを設定する

特定のバックエンドグループについては、各ロケーションで変数によるターゲット値を指定するよりも、動的なアップストリームの方が分かりやすい場合があります。このパターンでは、バックエンドメンバーの定義とルーティングを分離しています： proxy_pass このグループを指し示す一方で、アップストリームのホスト名はDNSを介して更新可能です。これは、複数のルートが同じアプリケーションを指している場合に特に適しています。.

パラメータ resolve ～のための server-このエントリは、NGINX 1.5.12 から歴史的に存在しています。ただし、ドキュメントによると、NGINX オープンソース版ではバージョン 1.27.3 以降で初めて利用可能となり、それ以前は商用版に限定されていた機能でした。また、 upstream-Blockは、バージョン1.27.3以降でオープンソースとして文書化されています。.

仝 共有メモリ領域 これはキャッシュのタイムアウトでも、DNSのデータパスでもありません。これは、動的に変更されるアップストリーム設定に必要な、NGINX内部の共有メモリを提供するものです。 NGINXがDNS解決の際にその名前に対して別のアドレスを検出した場合、この内部で管理される状態に基づいて、再起動することなくアップストリームグループを調整することができます。.

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

他のすべての例と同様に、 192.0.2.53 ドキュメント用アドレスに限定されます。 実際には、登録されたリゾルバーは内部名を確実に把握しており、NGINXネットワークからアクセス可能であり、かつ信頼できるものである必要があります。また、導入に先立ち、最新のサンプルから設定を単純に導き出すのではなく、インストールされたパッケージの実際の機能範囲を確認する必要があります。.

IPv4経由でのみアクセス可能なサービスについては、特定の制限を設けることが正当化される場合があります： resolver 192.0.2.53 ipv6=off; このリゾルバーコンテキストにおけるAAAAクエリおよびIPv6アドレスの選択を無効にします。ただし、これはネットワークアーキテクチャ上の判断となります。デュアルスタックが正常に機能している場合、単なる習慣だけでIPv6を無効にしてはなりません。NGINXはデフォルトで、両方のIPファミリーをリゾルブします。.

設定を確実に確認し、展開する

変更を行う前に、まずリゾルバーのディレクティブが実際にどの箇所で適用されているかを確認してください。そのためには、インクルードされたファイルも含めたアクティブな設定を探し、リゾルバーが全体に対して http-コンテキストが、1つの仮想ホストのみ、あるいは単一のパスのみに限定されている場合。スコープが狭すぎると、別の可変プロキシパスがリゾルバーを見つけられなくなる可能性があります。一方、スコープが広すぎると、後で変更を割り当てるのが困難になります。.

調整のたびに、その後に続くのは 構文チェック. 設定を読み込み、参照されているファイルのオープンも試みます。これにより、リロード前に、入力ミス、無効なディレクティブ、およびインクルードファイル内の問題を検出できます。 ただし、このチェックでは、登録されたDNSサーバーに到達できるか、期待される名前を認識しているか、あるいは解決されたアドレスの背後にあるバックエンドが接続を受け付けているかについては確認できません。.

nginx -t
nginx -s reload

検証が正常に完了してから、リロードを実行してください。. nginx -s reload これにより、NGINXは新しい設定で新しいワーカーを起動し、古いワーカーを安全に終了させます。インストールされているパッケージやOSによっては、代わりに、そこに用意されているサービスマネージャーがリロードを実行する場合もあります。 その際は、外部環境からのコマンドをそのまま使用するのではなく、インストールに関するドキュメントに記載された手順に従ってください。.

その後、予定されている変更期間内に技術的なテストを実施してください。 予想されるDNS TTLと、新しいバックエンドアドレスの使用開始予定時刻を照合し、実際に許可されているIPファミリー経由でサービスに到達できるかどうかを確認してください。また、リゾルバーのアドレス、選択されたスコープ、および考えられる valid-オーバーライド。これにより、障害が発生した際に、その原因がDNS、ルーティング、あるいはアプリケーションのいずれにあるかを特定することができます。.

典型的なレゾルバのエラーを体系的に絞り込む

ターゲット式でのトラブルシューティングを、以下の場所から開始してください。 proxy_pass. 変数が含まれている場合、そのホスト名が定義済みのアップストリームグループに属していない限り、NGINXは実行時にそのホスト名を解決する必要があります。このメッセージ no resolver defined したがって、まず、欠落している、あるいは文脈上認識できない リゾルバーの設定 。ホスト名を安易に固定IPアドレスに置き換えるのではなく、適切な文脈に合わせて信頼できるネームサーバーを追加してください。.

リゾルバーが設定されている場合は、次にそのアドレス、ネットワークパス、および使用中のゾーンに対する管轄範囲を確認してください。 パブリックリゾルバーは内部名を認識できません。一方、到達不能なリゾルバーは解決タイムアウトを発生させます。また、そのディレクティブがより具体的な設定によって上書きされていないかどうかも確認してください。NGINXは明示的に指定されたネームサーバーのみを使用し、 /etc/resolv.conf.

DNSの変更後も古い宛先アドレスが有効なままになっている場合は、応答のTTLと設定されている valid. 長いオーバーライドは、DNS応答のTTLを上書きし、変更の反映をそれに応じて遅らせる可能性があります。許容される修正期間は、一律に可能な限り短い期間というわけではなく、変更ウィンドウやDNSインフラの許容範囲に見合った値である必要があります。多くの場合、 valid よりクリーンな解決策。.

解決に成功した後、接続に問題が発生した場合は、DNSをバックエンド接続から切り離してください。AレコードおよびAAAAレコードの応答があるかどうか、また宛先がIPv6経由で実際にルーティングされ、到達可能かどうかを確認してください。. ipv6=off これは、IPv4のみを使用していることが確認されているアーキテクチャの場合にのみ適しています。DNSタイムアウトは名前解決に影響しますが、既知のIPアドレスへの接続エラーは、ルーティング、ファイアウォール、ポート、またはアプリケーションに起因するものです。.

動的なアップストリームについては、さらにバージョン状態、共有メモリ領域、および resolve 互換性があります。これに関して文書化されているオープンソースのサポートは、NGINX 1.27.3 以降に適用されます。それ以前のバージョンは、同等のものとみなしてはなりません。. status_zone また、APIベースのリゾルバー統計は、NGINXオープンソース向けの汎用的なモニタリングソリューションではありません。というのも、前述の機能は商用版を対象としたものだからです。.

運用に向けたリゾルバー戦略の選定

適切な戦略は、一律のキャッシュ値から始めるのではなく、DNSの管理権限と変更頻度から始めるべきです。チームが権威ゾーンを管理でき、そのTTLがデプロイメントの期間を現実的に反映しているならば、 TTL制御による分解能 なし valid たいてい、最も理解しやすい出発点となる。その場合、DNSは、その応答がどのくらいの期間使用されるかについて、依然として決定的な情報源となる。.

意図的に配置された valid TTLを変更できず、かつ運用上の理由から異なるキャッシュ期間を設定できる場合に検討の余地があります。 その際、どの程度の障害の影響が許容範囲であるかを明確にしておく必要があります。値を大きく設定すると、DNSクエリの回数は減少しますが、サーバーの移転後には、もはや有効ではないアドレスを指してしまう可能性があります。これは、DNS TTLの上限値でもなければ、パフォーマンスを調整するための汎用的なスイッチでもありません。.

その後、ルーティング構造に基づいてNGINXテンプレートを選択してください。可変の proxy_pass これは、リクエストごとまたは設定ごとに実行時に宛先が決定される場合に適しています。そのためには、適切なスコープ内のリゾルバーが必要です。DNS ベースのアドレス変更を行う名前付きバックエンドグループの場合、アップストリームには zone そして resolve NGINX Open Source 1.27.3 以降が実際に利用可能であれば、より明確になります。.

その後に初めて、あなたは決めるのです タイムアウトとIPファミリー. リゾルバーのタイムアウトは、クライアントおよびアップストリームのタイムアウトと一致させる必要があります。これにより、DNS応答が得られなかった場合に、エラーの通知が過度に遅れることを防ぎます。IPv4またはIPv6は、ネットワークアーキテクチャに応じて有効にしてください。 内部ゾーンに対して確実に応答できる、セキュリティ対策が施されたリゾルバーのみを使用してください。.

DNS解決とアップストリーム・キープアライブは、それぞれ異なる役割を果たします。リゾルバーは、NGINXがどのバックエンドアドレスを使用できるかを決定し、キープアライブは、すでに確立されているが非アクティブなバックエンド接続を、再利用のために維持します。 したがって、接続の再利用に関する変更は、TTLの計画やリゾルバーによるチェックの代わりにはなりません。この接続レベルの設計については、以下の記事が補足しています。 NGINX のアップストリーム・キープアライブ リゾルバー戦略。.