DNSクエリとは、クライアントがDNSサーバーに対して送信するリクエストメッセージであり、特定のドメイン名、レコードタイプ、およびクラスに一致するレコードを要求するもので、RFC 1035の仕様に基づいて応答されます。 このクエリは、ほぼすべてのネットワーク接続のきっかけとなり、DNS サービスの需要を直接的に測る指標となります。レコードタイプ、クライアント、応答コードごとのトラフィック量の分析により、必要な処理能力が明らかになり、設定ミスを特定することができます。 NXDOMAIN応答の急増、クエリの集中攻撃、UDP応答の切り捨てなどを含むクエリパターンの監視は、運用の信頼性とセキュリティにとって極めて重要です。なぜなら、監視されていないクエリトラフィックでは、問題を事前に解決することができず、ユーザーからの苦情として表面化してしまうだけだからです。
DNSクエリの仕組み
DNSクエリには、名前、レコードタイプ、およびクラスで構成される問い合わせが含まれます。クライアントはこれをリゾルバーに送信し、リゾルバーはキャッシュから回答するか、DNS階層を辿って回答を見つけ出します。
- クエリの構築:クライアントは、検索対象のドメイン名、レコードタイプ(A、AAAA、MX、TXTなど)、およびクラス(インターネットの場合はほぼ常にIN)を指定してクエリを作成します。
- リゾルバへの送信:クライアントのスタブリゾルバは、通常ポート53のUDPを介して、設定された再帰リゾルバにクエリを送信します。
- キャッシュの確認:再帰的リゾルバーは、同じ名前およびタイプに対して有効期限が切れていないキャッシュされた回答を保持している場合、それを返します。
- 権威サーバーへのクエリ:キャッシュされた回答がない場合、リゾルバーは、回答またはエラーが返されるまで、ルートサーバー、トップレベルドメインサーバー、および権威サーバーに対して反復的なクエリを送信します。
- 応答の返送:リゾルバーはクライアントに応答を送信し、レコードの有効期間(TTL)で設定された時間だけそれをキャッシュします。
クエリは通常UDPを使用し、応答が途切れた場合はクライアントがTCPで再試行します。応答コードは、エラーがない場合や、存在しない名前に対するNXDOMAINなど、結果を報告します。EDNSなどの拡張機能や、DNS overTLSのような暗号化トランスポートは、クエリの内容ではなく、その伝達方法を変えるものです。
DNSクエリでよくある問題
多くの場合、ランダムな名前に対するものや、なりすましされた送信元からのクエリが大量に集中すると、リゾルバーのCPU、ソケット、またはアップストリームの帯域幅を枯渇させる可能性があります。症状としては、レイテンシの増加、SERVFAILやタイムアウトの発生、および通常の基準値を大幅に上回るクエリレートなどが挙げられます。
TTL やキャッシュを無視する設定ミスのあるクライアントやアプリケーションは、1 秒間に何度も同じクエリを送信することがあります。これは、ログ上で、1 つの名前に対して 1 つのクライアントが「トップトークラー」リストの上位を占めている状態として現れます。
NXDOMAIN応答が急増する場合は、多くの場合、アプリケーションの不具合、誤った検索ドメインサフィックス、または削除された名前を指す古い設定が原因です。また、クライアントが複数の検索サフィックスを追加することで、1回の検索あたりの失敗するクエリ数が倍増することもあります。
応答がクライアントがUDPで受け入れるサイズを超えると、サーバーは切り捨てフラグを設定し、クライアントはTCP経由で再試行する必要があります。TCPポート53をブロックするファイアウォールは、DNSSECデータを含むような大きな応答に対して断続的な障害を引き起こします。
パブリックまたは古いリゾルバーが設定されたクライアントは、内部DNSをバイパスするため、内部ドメイン名の解決に失敗したり、異なる応答が返されたりすることがあります。これは、DHCPのスコープが変更された後や、DNS設定がハードコードされているデバイスで頻繁に発生します。