DNS ポート ガイド: ポート 53 での名前解決

クライアントはドメインに到達する必要がある場合、A、AAAA、CNAME、MX、TXT、NS、SRV などのレコードをリゾルバーに要求します。リゾルバーはキャッシュから応答することも、レコードが見つかるまでルート、TLD、および権威サーバーを介して DNS 階層をたどることもできます。

リクエストとレスポンスが小さいため、ほとんどのクライアント クエリでは UDP ポート 53 が使用されます。応答が大きすぎる場合、切り捨てが発生した場合、DNSSEC が応答サイズを増加した場合、サーバーがゾーン転送や信頼性の高いストリームを必要とするその他の操作を実行した場合、DNS は TCP に切り替えることができます。

UDP 53 は、日常的な DNS 解決の共通パスです。これをブロックすると、通常は通常の検索が中断されます。 TCP 53 は、完全な DNS 導入ではオプションではありません。TCP 53 は、大規模な応答、切り捨てられた UDP 応答からのフォールバック、DNSSEC 負荷の高い応答、および承認されたサーバー間のゾーン転送をサポートします。

UDP 53 は許可するが TCP 53 をブロックするファイアウォール ルールにより、診断が困難な断続的な障害が発生する可能性があります。小さなレコードは機能する可能性がありますが、大きな DNSSEC、TXT、またはメール関連の応答は失敗します。

権威 DNS サーバーは、管理するドメインのレコードを公開します。パブリックゾーンにサービスを提供する場合、インターネットからアクセスできる必要がありますが、それらのゾーンに対してのみ正式に応答する必要があり、オープン再帰を提供すべきではありません。

再帰リゾルバーはクライアントの検索を実行します。パブリック再帰リゾルバーは、その役割のために設計され、保護される必要があります。内部リゾルバーは通常、信頼できるネットワーク、VPN クライアント、または特定のアプリケーション環境に対してのみ応答する必要があります。

パブリック ゾーンをホストする権威 DNS サーバー用に、インターネットに対してポート 53 を開きます。 UDP と TCP の両方を考慮する必要があります。サーバーが内部のみにある場合は、名前解決が必要なネットワークへのアクセスを制限します。

レート制限、不正行為の監視、容量計画を備えたパブリック リゾルバーを意図的に運用する場合を除き、再帰リゾルバーをインターネット全体に公開しないでください。オープン リゾルバーは、リフレクション攻撃や増幅攻撃に悪用されることがよくあります。

ポート 53 を許可する前に、サーバーが権威、再帰、転送、キャッシュ、またはスプリット ホライズンであるかどうかを決定します。どのクライアントがそれを使用する必要があるか、どのゾーンがサービスを提供するか、再帰が有効になっているかどうか、ゾーン転送が承認されたセカンダリ サーバーに制限されているかどうかを確認します。

ポート チェッカーはポート 53 が到達可能であることを確認できますが、DNS が正確であるためにはプロトコル レベルのテストが必要です。 dig、nslookup、drill、またはリゾルバ ログを使用して、レコードの回答、再帰ポリシー、TCP フォールバック、DNSSEC の動作、および応答時間を検証します。

Windows Server では、DNS サーバーの役割は、Active Directory 統合ゾーン、内部レコード、および転送ルールを提供できます。特にサーバーにパブリック インターフェイスがある場合は、再帰とゾーン転送を慎重に制限してください。

Linux では、一般的な DNS サーバーには BIND、Unbound、PowerDNS、Knot DNS、CoreDNS、および dnsmasq が含まれます。 UDP および TCP 53 のリスニング インターフェイス、再帰ポリシー、許可されたクライアント、権限のあるゾーン、ロギング、およびファイアウォール ルールを構成します。

クラウド プラットフォームでは、プロバイダーがエニーキャスト、スケーリング、ベースライン DDoS 復元力を処理するため、パブリック権威ゾーンではマネージド DNS の方が安全であることがよくあります。セルフホスト DNS には、依然として冗長インスタンス、監視、明確なネットワーク ポリシーが必要です。

何を検証する必要があるかに応じて、UDP または TCP 53 の外部ポート チェックから始めます。次に、ターゲット リゾルバーに対して dig @server example.com A、dig @server example.com AAAA、または nslookup を実行して、実際の DNS 応答を確認します。

dig +tcp @server example.com TXT または別の大きな応答を使用して TCP を明示的にテストします。権限のあるサーバーの場合は、ネットワークの外部からレコードをクエリし、再帰が拒否されていることを確認します。再帰リゾルバーの場合は、許可されたソース ネットワークと許可されていないソース ネットワークの両方からクエリを実行します。

ポート 53 が閉じられている場合、DNS サービスが停止し、間違ったインターフェイスでリッスンしているか、ホスト ファイアウォールによってブロックされているか、クラウド セキュリティ グループによって制限されている可能性があります。 UDP は信頼できないように見えるが、TCP は動作する場合は、MTU、断片化、応答サイズ、EDNS 設定、および DNSSEC 関連の動作を検査してください。

ポートは開いているが検索が失敗する場合は、ゾーン データ、委任、グルー レコード、SOA および NS レコード、再帰ポリシー、フォワーダー、DNSSEC 検証、キャッシュ状態、およびログを確認します。 DNS 障害は、生のポートの到達可能性ではなく、ポリシーまたはゾーンの設定に起因することがよくあります。

オープン再帰リゾルバーを誤って実行しないでください。信頼できるクライアントへの再帰を制限し、既知のセカンダリ サーバーへのゾーン転送を制限し、DNS ソフトウェアにパッチを適用した状態を維持し、クエリ レート、NXDOMAIN スパイク、SERVFAIL スパイク、異常なソース ネットワークを監視します。

パブリック権威 DNS の場合は、冗長サーバー、必要に応じて DNSSEC、運用の柔軟性を確保するために十分に短い TTL、およびゾーン変更の明確な所有権を使用します。内部 DNS の場合は、インフラストラクチャ名やプライベート トポロジが公開されることが多いため、スプリット ホライズン レコードを保護します。