DNSセキュリティ：ベストプラクティスとセキュリティ強化チェックリスト
by
最終更新日: 12 読了時間：12分
DNSセキュリティとは、ドメインのDNSを正確かつ利用可能な状態に保ち、管理者の管理下に置くための一連の対策のことです。これにより、攻撃者がトラフィックをリダイレクトしたり、ドメインをなりすましたり、ドメインをオフラインにしたりすることを防ぎます。
以下では、DNSセキュリティが現代のインフラストラクチャの基盤となる理由を解説し、広義のDNSセキュリティとDNSSECの混同を解消するとともに、実践可能な12項目のセキュリティ強化チェックリストを提供し、何を優先して修正すべきかを示した優先順位付きの計画を提示します。
DNSセキュリティとは何ですか？
DNS DNSは、あらゆるWebリクエスト、API呼び出し、電子メールの配信の背後で機能していますが、当初は組み込みの認証機能や暗号による検証機能を持たずに開発されました。DNSセキュリティとは、ドメイン名やネームサーバーのインフラを、不正な改ざん、盗聴、および運用上の混乱から保護するために必要なポリシー、設定、プロトコル、および監視手法を包括するものです。
効果的なDNSセキュリティを実現するには、単一のツールに頼るのではなく、4つの異なる運用レイヤーにわたる防御体制が不可欠です：
- レジストラ層： ドメイン登録、ドメイン所有権記録、および管理用アクセス認証情報を保護し、不正なアカウント乗っ取りを防止するための制御機能です。
- 権威ネームサーバー層： お客様のパブリックゾーンファイルをホストする権威サーバーに対して適用される保護措置であり、堅牢な稼働時間、冗長性、および管理されたゾーン転送を保証します。
- 解像度およびトランスポート層： 再帰的リゾルバおよびクエリトラフィックに対して適用される措置であり、経路上の盗聴、改ざん、およびローカルキャッシュの操作からルックアップ要求を保護する。
- レコードおよびIDレイヤー： ゾーン内で公開されている暗号化レコードおよびセキュリティポリシー。これには、DNSSEC署名、CA認証ポリシー、および電子メール認証基準が含まれます。
セキュリティ侵害の多くは、これらの層のいずれかに存在する、本来なら防げたはずの脆弱性から始まります。これらの層がどのように相互作用しているかを理解することで、セキュリティチームは潜在的な DNSの脆弱性 を排除するのに役立ちます。正式なコンプライアンスプログラムに従っている組織は、 NISTのDNSセキュリティガイドライン を参照して、連邦政府のベースライン要件を確認することもできます。
DNSのセキュリティはなぜ重要なのでしょうか？
ドメインネームシステム（DNS）のプロトコルの中核部分は、暗号による発信元検証を行わずにクエリを平文で送信するため、生のDNSトラフィックは本質的に受信した応答を信頼することになります。多くの組織では、ファイアウォールやWebアプリケーションファイアウォール（WAF）、エンドポイント検知エージェントに多額の投資を行っている一方で、DNSゾーンの監視は概ね行われていません。
攻撃者がDNSを悪用すると、境界防御を完全に迂回することができます。DNSゾーンが侵害されると、攻撃者は企業のWebトラフィックを悪意のあるレプリカへ迂回させたり、貴社のブランド名で有効なTLS証明書を発行したり、あるいは物理的なネットワークサーバーに一切触れることなく、機密の電子メール通信を傍受したりすることが可能になります。
包括的なDNSセキュリティ対策が講じられていない場合、組織は以下のような深刻な脅威に直面することになります：
- DNSハイジャック およびレジストラの乗っ取り： 攻撃者はレジストラの認証情報を乗っ取るか、ソーシャルエンジニアリングを悪用して、権威ネームサーバーを不正なホストにリダイレクトさせる。
- DNSスプーフィング および キャッシュポイズニング： 攻撃者は、脆弱性のある再帰型リゾルバーに偽のリソースレコードを注入し、ユーザーを認証情報を収集するサイトへリダイレクトさせる。
- DNS増幅攻撃 およびDDoS： 公開されている再帰型リゾルバーが悪用され、被害者となる標的に対して大量の応答を跳ね返すことで、帯域幅を飽和させ、サービス全体をダウンさせる。
- レコードの未処理とサブドメインの乗っ取り: 無効化されたクラウドリソースやホスティングバケットを指す、孤立したDNSレコードが、外部の攻撃者によって乗っ取られ、あなたのブランド名を悪用して悪意のあるコンテンツがホストされる。
- 脆弱なDNSレコードを悪用したメールのなりすまし： SPF、DKIM、DMARCポリシーが欠落しているか、設定が誤っていると、詐欺師が貴社の企業ドメインを装ったスピアフィッシングメールを送信できるようになります。
攻撃手法の詳細な解説については、10種類のDNS攻撃に関するガイドをご覧ください。 DNS攻撃の種類のガイドをご覧いただき、無料の DNSSECチェッカーでドメインをテストしてみてください。
DNSセキュリティとDNSSECの比較
ITチームの間でよく見られる誤解の一つは、DNSセキュリティとDNSSECを同義語として扱うことです。しかし、これらは同義ではありません。
DNSSEC（ドメインネームシステムセキュリティ拡張）は、より広範なセキュリティフレームワークにおける特定の技術的対策です。DNSSECは、公開鍵暗号技術を用いて、ゾーンファイル内のDNSレコードにデジタル署名を付与します。検証を行うリゾルバーが署名付きのドメインをチェックする際、ルートゾーンに至る信頼チェーンに基づいて署名を検証し、受信した応答が転送中に改ざんされていないことを確認します。
広範なDNSセキュリティとは、管理ライフサイクル全体と防御アーキテクチャを指します。DNSSECはレコードの真正性と完全性を確保しますが、あらゆる脅威を解決するわけではありません：
- DNSSECは、クエリトラフィックを暗号化したり、盗聴者に対する機密性を確保したりするものではありません。
- DNSSECは、レジストラのアカウントを乗っ取り、パブリックデリゲーションレコードを改ざんする攻撃者を阻止することはできません。
- DNSSECは、ボリューム型DDoS攻撃を緩和したり、オープンリゾルバーが増幅型攻撃に参加するのを阻止したりすることはありません。
- DNSSECは、運用を終了したサードパーティのクラウド資産を指す、未解決のCNAMEレコードを検出しません。
DNSSECは、セキュリティ強化されたインフラストラクチャに不可欠な要素ですが、レジストラロック、通信の暗号化、厳格な電子メール管理、および継続的なゾーン監視と併せて機能させる必要があります。暗号による検証の仕組みについて詳しくは、当社のガイド「 DNSSECガイドで詳しくご覧ください。
DNSセキュリティのベストプラクティス：セキュリティ強化チェックリスト
ドメインのセキュリティを確保するには、体系的で再現性のある運用習慣が必要です。以下のチェックリストでは、インフラストラクチャのレイヤーと実装の複雑さに基づいて分類された、12の必須対策を取り上げています。
| ベストプラクティス | レイヤー | 努力の度合い |
|---|---|---|
| レジストラレベルでドメインをロックする | 登録担当者 | 低 |
| レジストラで多要素認証（MFA）と役割ベースのアクセス制御を徹底する | 登録担当者 | 低 |
| ゾーン転送の制限 (AXFR) | ネームサーバー | 低 |
| 冗長化された権威ネームサーバーを展開する | ネームサーバー | 中 |
| 最新の暗号技術を用いたDNSSECの実装 | 記録と身元 | 中 |
| 認証局承認（CAA）レコードを公開する | 記録と身元 | 低 |
| 未処理レコードおよび孤立レコードの監査 | 記録と身元 | 中 |
| 適切なTTL値を設定し、伝播ウィンドウを追跡する | ネームサーバー | 低 |
| クライアントからリゾルバーへの転送の暗号化 (DoH / DoT / DoQ) | 解像度と転送 | 中 |
| Hardenのローカルリゾルバおよびネームサーバーソフトウェア | 解像度と転送 | 高 |
| レスポンスポリシーゾーン（RPZ）の実装 | 解像度と転送 | 中 |
| 電子メール認証プロトコルの適用：SPF、DKIM、DMARC | 記録と身元 | 中 |
1. レジストラレベルでドメインをロックする
認証されていない転送要求は、重要なドメイン資産にとって最大の脆弱性の一つです。 clientTransferProhibited および clientUpdateProhibited ステータスコードを適用してください。
価値の高い企業ドメインについては、レジストラにレジストリロックの申請を行ってください。レジストリロックが設定されている場合、ネームサーバーの委任設定やWHOISの管理担当者情報の変更を行う前に、指定された担当者との電話確認など、オフラインでの本人確認が必要となります。
2. レジストラにおいて、多要素認証（MFA）と役割ベースのアクセス制御を実施する
ドメイン登録業者およびDNSホスティングプロバイダーの管理アカウントが、パスワードのみに依存していないことを確認してください。ハードウェアベースの 多要素認証 （MFA）を適用してください。
レジストラのログイン認証情報は、チームの共有受信箱には保管しないでください。厳格なロールベースのアクセス制御（RBAC）を導入し、一般のITスタッフには読み取り専用アクセス権限のみを付与し、ドメイン管理権限は指定されたドメイン管理者に限定してください。
3. ゾーン転送の制限 (AXFR)
権威DNSサーバーは、プライマリサーバーとセカンダリサーバー間でDNSデータを複製するために、フルゾーン転送（AXFR）を使用します。ネームサーバーが任意のIPアドレスからのAXFRリクエストを無制限に許可している場合、攻撃者はゾーンファイル全体をダウンロードできてしまいます。これにより、内部のホスト名構造、ステージングサーバー、および隠されたネットワークインフラが露見してしまいます。
プライマリネームサーバーの設定を行い、承認済みのセカンダリネームサーバーの明示的なIPアドレスへのAXFR転送のみを許可するようにしてください。設定内容は、ターミナルプロンプトから確認できます：
dig AXFR yourdomain.com @ns1.yourdomain.com
サーバーから「転送失敗」や「REFUSED」エラーではなく、DNSレコードの完全なリストが返された場合、ゾーン転送の設定が開放されているため、直ちに制限を設ける必要があります。
4. 異なるネットワークに冗長化された権威ネームサーバーを展開する
単一のDNSプロバイダーや単一の物理データセンターに依存すると、単一障害点が生まれます。プロバイダーがDDoS攻撃やネットワーク障害に見舞われた場合、オンライン上のすべてのサービスが利用できなくなってしまいます。
別々の自律システム番号（ASN）および地理的に分散したネットワーク上でホストされている、少なくとも2台の権威ネームサーバーを展開してください。デュアルプロバイダー方式の権威DNSモデルを採用することで、一方のプロバイダーでインフラ障害が発生した場合でも、もう一方のプロバイダーがシームレスにクエリの解決を継続できるようになります。
5. 最新の暗号技術を用いたDNSSECの実装
DNSSECは、DNSレコードにデジタル署名を追加します。再帰的リゾルバがDNSSEC対応のゾーンにクエリを送信すると、ルートゾーンに至る信頼チェーンに基づいて、暗号署名（RRSIGレコード）の検証を行います。これにより、応答が転送中に改ざんされていないことが保証されます。
DNSSECを導入する際は、改訂版のNIST SP 800-81r3ガイドラインに従ってください：
- 従来のRSA鍵ではなく、ECDSA Curve P-256やEd25519などの最新の楕円曲線暗号を使用してください。鍵サイズを小さくすることで、UDP経由でのパケット断片化のリスクを低減できます。
- 侵害された鍵の露出期間を制限するため、署名の有効期間を5日から7日の間に設定してください。
- ゾーン署名鍵（ZSK）の鍵更新は1～3年ごとに実施し、鍵署名鍵（KSK）は、実用的な範囲で安全なハードウェア構成に保管してください。
専用の DNSSECチェッカーでチェックすることで確認できます。
6. 認証局認可（CAA）レコードを公開する
A CAAレコード により、ドメイン所有者は、自身のドメインおよびサブドメインに対してデジタルTLS証明書を発行する権限を持つ認証局（CA）を指定することができます。
証明書を発行する前に、パブリックCAはドメインのDNSに対してCAAレコードの照会を行う必要があります。CAAレコードが存在する場合、指定された認証局（例えば、Let’s EncryptやDigiCertなど）のみが発行リクエストに対応することが許可されます。これにより、悪意のある従業員や侵害されたサードパーティシステムが、承認されていないベンダーを通じて不正な証明書をリクエストすることを防ぐことができます。
CAAレコード内に、有効なセキュリティ担当者のメールボックスを指す「iodef」タグを含めてください。これにより、不正なCAがお客様のドメインに対する証明書発行依頼を受け取った場合に、即座にアラートを受け取ることができます。レコードの構文は、当社の CAAチェッカーでレコードの構文を検証してください。
7. 未処理レコードおよび孤立レコードの監査
公開されているレコードの一覧を定期的に確認し、使用されなくなったホスト名を見つけ出してください。サードパーティのクラウドホストを指すCNAMEレコード、廃止されたメールプロバイダーにマッピングされているサブドメイン、および使用されなくなったIPアドレスを指す古いAレコードには特に注意を払ってください。
構造的な更新を行う前に、信頼できる DNSレコード 検索ツールを使用して、公開済みのレコードを確認してください。さまざまな 種類のDNSレコード をすべて確認することで、サブドメイン乗っ取り攻撃による意図しない情報漏洩を防ぐことができます。
8. 適切なTTL値を設定し、伝播ウィンドウを追跡する
Time-To-Live（TTL）の設定により、再帰的リゾルバーがDNSレコードをキャッシュしておく期間が決定され、その期間が経過すると、権威ネームサーバーに新しいレコードを要求します。
- 標準的な運用手順： デフォルトのTTLを3,600秒（1時間）から86,400秒（24時間）の範囲に設定します。これにより、サーバーの負荷とクエリのレイテンシのバランスが取れます。
- 移行前またはインシデント対応： インフラの変更を予定している場合、その少なくとも24～48時間前に、TTL値を300秒（5分）に下げておいてください。
事前にTTLを下げておけば、影響を受けたサーバーからトラフィックを迂回させる必要が生じた際に、世界中のリゾルバー全体でキャッシュが迅速に失効するようになります。変更が世界中のリゾルバーにどのように波及しているかは、リアルタイムの DNS伝播チェッカーを使用して、変更がグローバルリゾルバー全体にどのように波及しているかを監視できます。
9. クライアントからリゾルバーへの転送の暗号化 (DoH / DoT / DoQ)
標準的なDNSクエリは、UDPおよびTCPのポート53を介して平文で送信されるため、ユーザーはローカルネットワーク上の各ホップにおいて、地域的な監視、ISPによる追跡、盗聴、および経路上の改ざんのリスクにさらされることになる。
最新のプロトコルでは、実績のある暗号フレームワークを用いて、クライアントとリゾルバー間のトランスポート層を保護しています：
- DNS over HTTPS (DoH)： DNSリクエストをポート443上の標準的なHTTPSセッション内にカプセル化し、クエリトラフィックを通常のWebリクエストの中に隠蔽します。
- DNS over TLS (DoT)： DNSクエリをポート853上の専用の暗号化されたTLSトンネル経由で転送し、DNSトランザクションを隔離すると同時に、強力なエンドポイント認証を提供します。基盤となる暗号化プロトコルがトランスポートストリームをどのように保護しているかを理解するには、 SSLとTLSの違いに関する解説記事をご参照ください。
- DNS over QUIC (DoQ)： QUIC（UDPポート853）を介してクエリを転送し、接続確立のオーバーヘッドを最小限に抑えつつ、ヘッド・オブ・ライン・ブロッキングを解消します。
社内エンドポイント、オペレーティングシステム、およびローカルネットワークのフォワーダーを設定し、上流への解決処理を、DoH または DoT を強制するセキュアなリゾルバー経由でのみルーティングするようにします。
10. ローカルリゾルバーおよびネームサーバーソフトウェアのセキュリティ強化
組織内で内部の再帰的リゾルバーを運用している場合、またはBIND、Unbound、PowerDNS、Windows Server DNSを使用して専用の権威ネームサーバーインスタンスを管理している場合は、厳格なシステム強化対策を実施してください：
- オープン再帰の無効化： 再帰型リゾルバーが、信頼できる内部ネットワーク範囲から発信されたクエリのみを処理するようにしてください。リゾルバーを任意のインターネットクエリに対して開放したままにすると、オープンリゾルバーを介した増幅攻撃に対してインフラストラクチャがさらされることになります。
- 役割の分離： 権威サーバーのホスティングと再帰的解決を、同じサーバーソフトウェアのインスタンス上で決して実行しないでください。
- セキュリティ更新プログラムを速やかに適用する： ソフトウェアベンダーが提供するセキュリティアドバイザリの配信登録を行ってください。レガシーなDNSパッケージでは、キャッシュのバグ、バッファの欠陥、メモリリークなどの脆弱性が定期的に発見されています。パッチが適用されていないDNSソフトウェアを継続的に追跡し、修正を行ってください。
- ソフトウェアバージョンの非表示: 公開されているバージョン照会（BINDの「version.bind」CHAOS TXTクエリなど）を無効化し、偵察スキャナーが特定のソフトウェアビルドに関する情報を把握できないようにします。
- 応答レート制限（RRL）を有効にする： 権威サーバーにRRLを実装し、同一のドメインを標的とした急速かつ繰り返しのクエリの集中攻撃を抑制することで、リフレクション攻撃への関与を抑制します。
11. レスポンス・ポリシー・ゾーン（RPZ）を導入する
「レスポンス・ポリシー・ゾーン」（通称「DNSファイアウォール」）を利用することで、再帰的リゾルバーの管理者は、標準的な名前解決の上に、カスタマイズされた脅威インテリジェンス・フィードを重ね合わせることができます。
クライアントデバイスが、マルウェア、コマンド＆コントロール（C2）サーバー、またはフィッシングページをホストしていることが判明しているドメインの解決を試みると、RPZルールによってその検索が中断されます。リゾルバーは NXDOMAIN 応答を返すか、ユーザーを内部のブロックページにリダイレクトします。
12. 電子メール認証プロトコル（SPF、DKIM、DMARC）の適用
メール認証は、DNSゾーン内に公開された専用のTXTレコードを通じて直接行われます。適切なメールレコードが設定されていない場合、外部の送信者であれば誰でも、あなたのドメイン名から送信されたかのように装った詐欺メールを送信することが可能になります。
完全な電子メール防御体制を構築するには、相互に関連した3つの基準が必要です：
- SPF（Sender Policy Framework）： お客様のドメインに代わってメールを送信することが許可されている、サーバーのIPアドレスおよびサードパーティのリレープロバイダーの承認済みリストを公開します。SPF、DKIM、DMARCに関する基礎概念については、当社の SPF、DKIM、DMARCに関するガイドで基礎概念を確認してください。
- DKIM (DomainKeys Identified Mail)： 公開鍵暗号方式を用いて、送信メールのヘッダーにデジタル署名を付加します。DNSゾーンに公開鍵を登録することで、受信者はメッセージの内容が送信中に改ざんされていないことを確認できるようになります。
- DMARC（Domain-based Message Authentication, Reporting, and Conformance）： SPFとDKIMを、_dmarcに公開される一元化されたポリシーの下で統合します。DMARCは送信アクティビティの可視性を提供し、準拠していないメールをどのように扱うべきかを受信側のメールサーバーに指示します。
強制的な DMARCポリシー （p=quarantineまたは p=reject）に移行することで、受信側のメールサーバーが、あなたの身元を悪用した不正なメッセージを確実に拒否または隔離するようになります。当社の DMARCレコードチェッカーを使用して現在の設定を確認し、技術的な手順に従って DMARCレコードを公開。
DNSモニタリング：多くのチームが見落としがちな実践
セキュリティ対策の導入は、一度きりの作業ではありません。チームが一時的なマーケティングキャンペーンを展開したり、メールサービスプロバイダーを変更したり、ネームサーバーの委任先をローテーションさせたり、レガシーなインフラを廃止したりするにつれて、DNSレコードは時間の経過とともに変化していきます。自動化された可視化機能がない場合、不正な変更や意図しない設定ミスが、何ヶ月も発見されないまま放置されてしまう可能性があります。
適切なDNS監視手順では、以下の項目を継続的に追跡する必要があります：
- ネームサーバーおよび委任の変更： アカウントの不正アクセスを示唆する可能性のある、NSレコードまたは親ゾーンのグルーレコードへの変更を即座に検知します。
- MXおよびSPFのドリフト： 新たに公開されたメールエクスチェンジや、SPF送信者メカニズムの変更に関する可視性。
- DNSSEC 検証ステータス： 鍵の署名、RRSIGレコード、およびDSチェーンが有効期限切れにならず、引き続き有効であることを確認する自動チェック。
- ゾーン転送の悪用： 外部の不正なネットワークから繰り返し行われたAXFR転送要求のログ記録。
- 登録および証明書の有効期限： ドメインの更新日やパブリックSSL/TLS証明書の有効期間を積極的に追跡し、不慮の失効を防止します。
- 類似ドメインのアクティベーション： 貴社のブランドを装うために、アクティブなMXレコードを生成している、新規登録されたホモグリフドメインやタイポスクワットドメインを監視します。
マネージドDNSとDNSレイヤーでのフィルタリング：それぞれの適した場面
現代の企業では、運用を簡素化し、脅威の可視性を高めるために、マネージドDNSプラットフォームやDNS層でのセキュリティフィルタリングを導入することがよくあります。
信頼性の高いマネージドDNSプロバイダー
エンタープライズ向けマネージドDNSプロバイダーは、グローバルなアニキャストネットワークを運用しており、お客様の権威ゾーンファイルを数百カ所のエッジ拠点に分散させます。アニキャストインフラストラクチャにはDDoS対策機能が組み込まれており、大規模なトラフィック攻撃がお客様のコアネットワークに到達する前に吸収します。また、マネージドプラットフォームでは、DNSSEC鍵の管理やDNSレコードのメンテナンスも自動化されています。
再帰的DNS層フィルタリング（保護型DNS）
Protective DNS（PDNS）ソリューションは、再帰的リゾルバー層で動作します。PDNSソリューションは、単にクエリに応答するだけでなく、すべてのリクエストを動的な脅威インテリジェンスデータベースと照合します。
従業員が、新たに登録されたフィッシングドメインにつながるリンクをクリックした場合、あるいは感染したペイロードがC2サーバーへの接続を試みた場合、保護機能付きリゾルバーがネットワーク層でその解決をブロックします。
マネージドDNSもDNSフィルタリングも、ドメインレジストラの管理や適切なレコード設定に代わるものではありません。これらは、より広範なゼロトラストセキュリティアーキテクチャにおいて、補完的な層として機能するものです。
まず何を監査すべきか：優先順位付けされた行動計画
12項目のチェックリスト項目すべてにわたるドメインポートフォリオの是正作業は、気が遠くなるような作業に感じられるかもしれません。以下の優先順位に基づいたスケジュールに従い、まず重大な脆弱性に対処してください：
- 1日目：アカウントの所有権の確保
- ドメイン登録業者のポータルで、ハードウェアMFAを有効にしてください。
- 登録済みのすべてのドメインに対して「レジストラロック」を有効にしてください。
- 古くなった、割り当てられていない管理者アカウントを削除します。
- 2日目：主要なトラフィック経路の保護
- ゾーン転送（AXFR）を、検証済みのセカンダリネームサーバーに限定する。
- パブリックゾーンファイル内をスキャンし、未登録のクラウドサービスを指す、未接続のCNAME、A、またはNSレコードがないか確認してください。
- インターネットに公開されている企業のリゾルバにおいて、オープン再帰を無効にしてください。
- 第1週：暗号ベースのIDの導入
- 選択した認証局を指定するCAAレコードを公開してください。
- 最新のDNSSECアルゴリズムを使用して本番ゾーンを設定および署名し、DSレコードが親レジストリで検証されるようにします。
- 第2週：メール認証の実施
- 現在稼働中のSPF対策を見直し、使用されていないベンダーを削除してください。
- すべての送信メールゲートウェイにDKIMキーを展開してください。
- DMARCレコードを公開し、認証の一致状況を監視するためのレポート機能を設定します。
- 進行中：継続的なモニタリング体制の構築
- 実績の変更、証明書の有効期限、およびDNSSEC署名の健全性を自動的に追跡します。
ご自身の状況がわからない場合は、当社の無料 ドメインアナライザー で、ドメインの健全性スコアを評価してみてください。
よくあるご質問
DNSセキュリティにおいて最も重要な対策は何ですか？
ハードウェアベースの多要素認証やレジストラ／レジストリのロックなど、強力なレジストラへのアクセス制御を実施することが、何よりも重要な対策です。もし攻撃者がレジストラアカウントを乗っ取れば、権威ネームサーバーを完全に置き換えてしまい、下流のすべてのゾーン設定やDNSSECキーを無効にしてしまう可能性があります。
DNSが乗っ取られているかどうかはどうやって確認すればいいですか？
DNSハイジャックの兆候としては、正規のウェブサイトへのトラフィックが急激に減少すること、ユーザーに予期せぬSSL/TLS証明書の警告エラーが表示されること、レジストラの監査ログに不正な変更が見られること、原因不明のメール配信失敗が発生すること、あるいは外部リゾルバーがドメインに対して見慣れないIPアドレスを返すことなどが挙げられます。
DNSのセキュリティ対策は、大企業にのみ必要なものなのでしょうか？
いいえ。脅威アクターは、中小企業のレジストラポータルやDNSゾーンが監視されていないことが多いため、頻繁にこれらを標的にしています。攻撃者は、フィッシングキャンペーンの実施、悪意のあるリダイレクトチェーンのホスティング、企業幹部のなりすましを行うために、中小企業のドメインを日常的に乗っ取っています。
DNSSECはDNSクエリを暗号化しますか？
いいえ。DNSSECはデータの完全性と暗号による発信元認証を提供し、受信したDNSレコードが正当な所有者から送信されたものであり、伝送中に改ざんされていないことを証明します。ただし、DNSクエリを暗号化したり、機密性を確保したりするものではありません。クエリの通信を暗号化するには、DNS over HTTPS（DoH）やDNS over TLS（DoT）などのトランスポートプロトコルが必要です。
権威DNSと再帰DNSのセキュリティにはどのような違いがありますか？
権威DNSのセキュリティは、ドメインの公開レコード、ネームサーバーの稼働時間、およびゾーンファイルを保護することに重点を置いており、これにより、世界中のユーザーがサービスに関する正確な応答を受け取れるようになります。再帰DNSのセキュリティは、ネットワーク上のクライアントデバイスが改ざんされた応答を受け取らないように保護すること、悪意のあるドメインをブロックすること、および外部リゾルバーへの通信を暗号化することに重点を置いています。
組織はどのくらいの頻度でDNSレコードの監査を行うべきでしょうか？
組織は、少なくとも四半期に1回、パブリックゾーンファイルを監査し、使用されなくなったホスト名を整理し、ダングリングポインタを削除すべきです。ただし、不正なレコードの変更、ネームサーバーの変更、または有効期限が切れるDNSSECキーをリアルタイムで検出するためには、自動監視を毎日実行する必要があります。
1.1.1.1 の DNS は安全ですか？
はい。CloudflareのパブリックDNSリゾルバー「1.1.1.1」は安全であり、DNS over HTTPS（DoH）、DNS over TLS（DoT）、DNSSEC検証といった最新の暗号化通信プロトコルに対応しています。また、厳格なプライバシー保護措置を講じており、ユーザーのクエリログは24時間以内に消去することを約束しています。
DNSのセキュリティはVPNと同じものですか？
いいえ。VPN（仮想プライベートネットワーク）は、お使いのデバイスと遠隔地のプライベートネットワーク間のすべてのネットワークトラフィックに対して暗号化されたトンネルを構築し、宛先サーバーからIPアドレスを隠します。一方、DNSセキュリティは、ドメイン名からIPアドレスへの変換を特に保護し、クエリが真正であり、改ざん防止機能を備え、なりすましに対して耐性があることを保証します。
まとめ
ドメインネームシステム（DNS）のセキュリティ確保は、現代のサイバーセキュリティ対策において不可欠な要素です。DNSを適切に管理しないまま放置すると、広範な攻撃対象領域が生まれ、攻撃者が従来のエンドポイント、ファイアウォール、Webアプリケーションの防御を迂回できるようになってしまいます。
この12項目のセキュリティ強化チェックリストを体系的に適用し、レジストラアカウントのセキュリティを強化し、DNSSECを導入し、厳格な電子メール認証を実施することで、組織はトラフィックハイジャック、ブランドなりすまし、および多大な損失をもたらすサービス中断に対して、強靭な防御体制を構築することができます。
