DNSセキュリティのベストプラクティス：包括的なセキュリティ強化チェックリスト

ドメインネームシステム（DNS）のインフラは、企業ネットワークにおいて最も信頼されているコンポーネントであることが多いにもかかわらず、依然として監視が最も不十分なコンポーネントの一つです。システム管理者がドメインレコードの設定を終えると、通常はファイアウォールやエンドポイントセキュリティ、あるいはID管理などの作業に移ります。攻撃者はこのギャップの存在を熟知しており、それを最大限に悪用しています。

攻撃者がドメイン名解決の制御権を掌握した場合、Webトラフィックを気付かれずに迂回させたり、社内の電子メールを傍受したり、貴社の名義で有効なTLS（Transport Layer Security）証明書を生成したりすることが可能になります。攻撃者は、社内ネットワーク内のサーバーを1台も侵害することなく、これらすべてを実行してしまうのです。

現代のインフラにおいて、堅牢なDNSセキュリティの導入は必須です。このガイドでは、よくある問題やミスを回避するための、DNSセキュリティに関するベストプラクティスを網羅して紹介します。

DNSセキュリティとは何ですか？

DNSセキュリティとは、ドメイン名解決サービスの完全性、可用性、および機密性を保護するために設計された、技術的制御、暗号プロトコル、および管理方針からなるシステムである。

効果的なDNSセキュリティを実現するには、単一のツールに頼るのではなく、4つの異なる層にわたる防御策が必要です：

1. レジストラおよびアカウント層：これには、不正なドメイン移管や認証情報の盗難を防ぐために、ドメインレジストラ側で実施される管理上の保護措置が含まれます。
2. 権威ネームサーバー層：これらは、公式のゾーンファイルが常に利用可能で、改ざんされず、分散型サービス拒否（DDoS）攻撃に対して耐性を維持できるようにするインフラストラクチャ制御です。
3. 解決層およびトランスポート層：この層には、エンドユーザークライアント、再帰的リゾルバ、および権威サーバー間の転送中にDNSクエリを保護するプロトコルが含まれます。
4. リソースレコードおよび識別レイヤー：ゾーンファイル内に公開される、ドメイン名システム（DNS）セキュリティ拡張や電子メール認証レコードなどの暗号化レコードであり、ドメインデータの真正性を検証するものです。

DNSが標的となる理由：攻撃対象領域

DNSは信頼できるバックグラウンドの基盤として機能しているため、レガシーな設定では、攻撃者がさまざまな攻撃を実行できてしまう。

DNSハイジャックとレジストラへの不正アクセス

ドメインハイジャック攻撃では、攻撃者がドメインレジストラのアカウントに不正アクセスしたり、レジストラの脆弱な手続きを悪用したりして、ネームサーバーの委任設定を変更します。攻撃者がNSレコードを変更して自身の不正なサーバーを指すようにすると、そのドメインへのすべての着信トラフィックを攻撃者が制御できるようになります。

最近の攻撃では、クレデンシャルスタッフィングや標的型ソーシャルエンジニアリングを用いて、ドメイン登録業者を標的にしています。攻撃者がDNSハイジャックに成功すると、自動化された認証局（CA）の検証プロトコルを利用して、標的のルートドメインに対して即座に有効な証明書を発行することが可能になります。

DNSスプーフィングとキャッシュポイズニング

従来のDNSクエリは、ポート53の暗号化されていないUDPを介して送信されます。標準的なクエリにはトランザクション認証機能が組み込まれていないため、ネットワーク経路上の攻撃者は、正当な権威サーバーが応答する前に、応答パケットを偽造して再帰的リゾルバーに送信することが可能です。

「DNSスプーフィング」として知られるこの手法は、再帰サーバーに対し、標的となったホスト名に対する偽のIPアドレスを受け入れるよう強制します。リゾルバーがこれらの偽造された応答をローカルメモリに保存すると、DNSキャッシュポイズニングが発生します。そのリゾルバーを利用しているすべてのユーザーは、キャッシュされたエントリの有効期限が切れるまで、悪意のあるサイトへ誘導されてしまいます。一般的なDNS攻撃の種類を分析する際には、こうした攻撃経路を理解することが非常に重要です。

DNS増幅攻撃とDDoS

権威ネームサーバーは、トラフィック量を利用したDDoS攻撃の主要な標的となっています。攻撃者は、開放されている再帰型リゾルバーを悪用して、DNS増幅攻撃を仕掛けることがよくあります。

被害者の偽造された送信元IPアドレスを使用して、脆弱性のあるリゾルバーに対して小さな偽装リクエスト（ANY やTXTクエリなど）を送信すると、リゾルバーは被害者に対して膨大な量の応答ペイロードを返します。このトラフィックの洪水により、ネットワークの帯域幅が飽和し、広範囲にわたるサービス停止を引き起こします。

danglingレコードとサブドメインの乗っ取り

組織がクラウドプロバイダー間でサービスを移行する際、システムエンジニアは、Amazon S3バケット、GitHub Pages、Azure App Servicesなどのクラウドリソースを削除する一方で、DNSゾーン内の対応するCNAMEレコードを削除し忘れることがよくあります。
この見落としにより、未処理のDNSレコードが生じます。外部の攻撃者は、クラウドプロバイダーのプラットフォーム上で放棄されたバケットやアプリインスタンスを乗っ取り、即座にサブドメインの制御権を獲得することができます。サブドメインの乗っ取りにより、攻撃者はフィッシングフォームをホストしたり、クロスサイトスクリプティング（XSS）を実行したり、セッションクッキーを盗んだりすることが可能になります。

脆弱なDNSレコードを悪用したメールのなりすまし

電子メールの配信は、DNSに大きく依存しています。組織が適切に設定された認証レコードを公開していない場合、サイバー犯罪者は、あたかもそのメールが貴社のドメインから送信されたかのように偽装したメールを送信することが可能になります。これにより、ビジネスパートナー、顧客、従業員が、直接的なフィッシング攻撃の標的となるリスクにさらされます。

DNSセキュリティのベストプラクティス：セキュリティ強化チェックリスト

この段階的なチェックリストを活用して、ドメインインフラストラクチャを傍受や悪用から体系的に保護してください。

1. レジストラレベルでドメインをロックする

認証されていない転送リクエストは、重要なドメイン資産にとって最大の脆弱性となります。ドメインに対して「clientTransferProhibited」および「clientUpdateProhibited」のステータスコードを適用してください。

価値の高い企業ドメインについては、レジストラにレジストリロックの申請を行ってください。レジストリロックが設定されている場合、ネームサーバーの委任設定やWHOISの管理担当者情報の変更を行う前に、指定された担当者との電話確認など、オフラインでの本人確認が必要となります。

2. レジストラにおいて、多要素認証（MFA）と役割ベースのアクセス制御を実施する

ドメイン登録業者およびDNSホスティングプロバイダーの管理アカウントについては、パスワードのみに依存しないようにしてください。FIDO2／WebAuthnセキュリティキーを使用したハードウェアベースの多要素認証（MFA）を義務付けてください。

レジストラのログイン認証情報は、チームの共有受信箱には保管しないでください。厳格なロールベースのアクセス制御（RBAC）を導入し、一般のITスタッフには読み取り専用アクセス権限のみを付与し、ドメイン管理権限は指定されたドメイン管理者に限定してください。

3. ゾーン転送の制限 (AXFR)

権威DNSサーバーは、プライマリサーバーとセカンダリサーバー間でDNSデータを複製するために、フルゾーン転送（AXFR）を使用します。ネームサーバーが任意のIPアドレスからのAXFRリクエストを無制限に許可している場合、攻撃者はゾーンファイル全体をダウンロードできてしまいます。これにより、内部のホスト名構造、ステージングサーバー、および隠されたネットワークインフラが露見してしまいます。

プライマリネームサーバーの設定を行い、承認済みのセカンダリネームサーバーの明示的なIPアドレスへのAXFR転送のみを許可するようにしてください。設定内容は、ターミナルプロンプトから確認できます：

なし
dig AXFR yourdomain.com @ns1.yourdomain.com

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）レコードを公開する

CAAレコードとは、DNSのTXTレコード形式のレコードであり、特定のドメイン名に対して公開用TLS証明書を発行する権限を持つ認証局（CA）を明示的に指定するものです。

攻撃者が自動化されたCAに対して、あなたのドメインの無許可の証明書の発行を要求しようとした場合、CAは発行前にあなたの公開CAAレコードを確認しなければなりません。CAがリストにない場合、発行はブロックされます。

証明書の発行を特定のプロバイダーに限定するには、ルートドメインにCAAレコードを追加してください：

なし
yourdomain.com. IN CAA 0 issue “letsencrypt.org”
yourdomain.com. IN CAA 0 issue “digicert.com”
yourdomain.com. IN CAA 0 iodef “mailto:[email protected]”

iodef パラメータは、誰かが許可されていない証明書の申請を試みた場合、準拠している認証局（CA）がセキュリティチームにリアルタイムで通知メールを送信するよう指示するものです。

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)

UDPポート53での標準的な平文DNSクエリは、クライアントの閲覧履歴を、ローカルの盗聴者、不正なWi-Fi運営者、およびトランジットISPにさらしてしまいます。クエリ経路を暗号化することで、エンドユーザーのプライバシーを保護し、ローカルネットワーク上での改ざんを防ぐことができます。

現代の企業ネットワークでは、主に以下の 3 つの暗号化トランスポート規格がサポートされています：

• DNS over TLS (DoT)– 専用のTCPポート853上で動作します。DoTは、内部エンドポイント、ローカルの再帰的リゾルバー、およびアップストリームサーバー間の通信を保護するために広く利用されています。
• DNS over HTTPS (DoH)– DNSクエリをポート443のHTTPSトラフィック内にカプセル化することで、クエリトラフィックを通常のWebトラフィックと見分けがつかないようにします。
• DNS over QUIC (DoQ)– QUICトランスポートを採用し、不安定なネットワーク接続環境においても遅延を低減し、パフォーマンスを向上させます。

企業環境内で暗号化DNSを展開する際は、モバイルデバイス管理（MDM）ツールを使用して、ローカルのクライアントエンドポイントが指定された内部の暗号化リゾルバーを利用するよう設定してください。また、ネットワークファイアウォールで、許可されていない外部へのDoT（ポート853）およびパブリックDoHエンドポイントへの通信をブロックし、アプリケーションがローカルのセキュリティログ記録を迂回することを防止してください。

10. ローカルリゾルバーおよびネームサーバーソフトウェアのセキュリティ強化

組織内で自己ホスト型の再帰的リゾルバーや、内部用のBIND、Unbound、PowerDNSインスタンスを運用している場合は、厳格なサーバーのセキュリティ強化対策を実施してください：

• 再帰的解決を、許可された内部IPアドレス範囲に限定してください。パブリックインターネット上のオープンリゾルバーは、DDoS増幅攻撃に急速に悪用されています。
• QNAMEの最小化を実施し、リゾルバーがアップストリームの権威サーバーに対して、必要最小限のドメインラベルのみを送信するように設定する（RFC 7816）。これにより、権威あるルートサーバーが完全なターゲットホスト名を把握することを防ぐことができる。
• 権威あるプライマリサーバーは、パブリックなNSレコードセットに記載されていない非公開のIPアドレスの背後に配置します。パブリックなセカンダリサーバーは、この非公開のプライマリサーバーからゾーンの更新情報を取得します。

11. レスポンス・ポリシー・ゾーン（RPZ）を導入する

「レスポンス・ポリシー・ゾーン」（通称「DNSファイアウォール」）を利用することで、再帰的リゾルバーの管理者は、標準的な名前解決の上に、カスタマイズされた脅威インテリジェンス・フィードを重ね合わせることができます。

クライアントデバイスが、マルウェア、コマンドアンドコントロール（C2）サーバー、またはフィッシングページをホストしていることが判明しているドメインの解決を試みた場合、RPZルールによってその解決処理が中断されます。リゾルバーはNXDOMAIN応答を返すか、ユーザーを内部のブロックページにリダイレクトします。

12. 電子メール認証プロトコル（SPF、DKIM、DMARC）の適用

メール認証プロトコルはDNSレコードです。SPF、DKIM、DMARCを適用していなければ、たとえレジストラやネームサーバーのセキュリティ対策が万全であっても、攻撃者はフィッシングメールでドメインの身元を偽装することが可能です。

DNSモニタリング：多くのチームが見落としがちな実践

セキュリティチームは、顧客サポートからサイトのダウンやメール配信の障害が報告されて初めて、DNSの改ざんに気づくことがよくあります。受動的な設定では、大きな死角が生じてしまいます。

効果的なDNS監視には、以下の3つの能動的な管理措置が必要です：

1. ゾーンファイルの整合性に関する自動監視：権威あるゾーンファイルを24時間365日追跡する自動ポーラーを設定します。重要なレコード（NS、MX、A、またはルートTXTレコードなど）に予期せぬ変更があった場合、チームには即座にアラートが送信されるようにします。
2. MXレコードおよびNSレコードの変更に関するアラート：MXレコードを変更されると、攻撃者は受信メールを自身のサーバー経由でルーティングし、機密性の高いパスワードリセットトークンを収集することが可能になります。MXレコードおよびNSレコードの変更に関するアラートが発生した場合は、直ちに優先度の高いインシデント対応ワークフローを起動する必要があります。
3. DNSクエリログの分析：Protective DNS（PDNS）のログをセキュリティ情報イベント管理（SIEM）プラットフォームに統合します。DNSクエリログとDHCPリース履歴を照合することで、アナリストは悪意のあるドメイン検索を、侵害された内部デバイスまで直接追跡することができます。

DNS制御としての電子メール認証

DNSセキュリティにおけるよくある間違いは、Webトラフィックの制御とメールの制御を分離してしまうことです。SPF、DKIM、DMARCは、公開鍵や送信者ポリシーを公開するために、完全にDNSのTXTレコードに依存しています。

• SPF：お客様のドメインに代わって送信メールを送信することが許可されているIPアドレスおよびメールサーバーの許可リストを公開します。
• DKIM：送信メールのヘッダーに暗号署名を付与します。受信者は、ドメインのDNSから対応する公開鍵を取得し、メッセージが転送中に改ざんされていないことを確認します。
• DMARC： SPFとDKIMを統合したものです。DMARCは、認証に失敗したメールをどのように処理すべきかを、受信メールサーバーに指示します。

ポリシーを「p=reject」に設定すると、受信メールサーバーに対して、認証されていないメッセージを自動的に破棄するよう指示されます。現在のDMARCポリシーを理解しておくことは、世界中の受信ネットワークにおいて、ブランドの評判を守ることに繋がります。

オンラインのDMARCレコードチェッカーを使えば、現在のメール認証の状態を即座に確認することができます。

DMARCは電子メールにおけるドメインのなりすましを防ぐことができますが、キャッシュポイズニングやサブドメインの乗っ取りに対しては防ぐことができない点に留意してください。完全な防御戦略を構築するには、ネットワークのDNS解決と電子メールのDNSレコードの両方を強化する必要があります。

マネージドDNSとDNSレイヤーでのフィルタリング：それぞれの適した場面

現代の企業では、運用を簡素化し、脅威の可視性を高めるために、マネージドDNSプラットフォームやDNS層でのセキュリティフィルタリングを導入することがよくあります。

信頼性の高いマネージドDNSプロバイダー

エンタープライズ向けマネージドDNSプロバイダーは、グローバルなアニキャストネットワークを運用しており、お客様の権威ゾーンファイルを数百カ所のエッジ拠点に分散させます。アニキャストインフラストラクチャにはDDoS対策機能が組み込まれており、大規模なトラフィック攻撃がお客様のコアネットワークに到達する前に吸収します。また、マネージドプラットフォームでは、DNSSEC鍵の管理やDNSレコードのメンテナンスも自動化されています。

再帰的DNS層フィルタリング（保護型DNS）

Protective DNS（PDNS）ソリューションは、再帰的リゾルバー層で動作します。PDNSソリューションは、単にクエリに応答するだけでなく、すべてのリクエストを動的な脅威インテリジェンスデータベースと照合します。

従業員が、新たに登録されたフィッシングドメインにつながるリンクをクリックした場合、あるいは感染したペイロードがC2サーバーへの接続を試みた場合、保護機能付きリゾルバーがネットワーク層でその解決をブロックします。

マネージドDNSもDNSフィルタリングも、ドメインレジストラの管理や適切なレコード設定に代わるものではありません。これらは、より広範なゼロトラストセキュリティアーキテクチャにおいて、補完的な層として機能するものです。

まず何を監査すべきか：優先順位付けされた行動計画

今四半期、セキュリティチームがチェックリストの12項目すべてを実施できない場合は、まず影響力の大きい成果に注力してください。以下の5つのタスクを順に実行してください：

1. すべてのプライマリドメインで「clientTransferProhibited」およびレジストリロックを有効にします。アカウント乗っ取りのリスクを排除するため、すべてのレジストラアカウントユーザーに対し、FIDO2ハードウェアキーの使用を義務付けます。
2. 権威ネームサーバーを監査することでAXFRゾーン転送を制限し、無制限のゾーン転送を直ちにブロックします。
3. 公開されているすべてのCNAMEレコードを一覧化し、稼働中のクラウドリソースと照合して、孤立したエントリを削除します。
4. ルートゾーンレコードの継続的な監視を設定し、MXおよびNSレコードに関する自動アラートを構成することで、不正な変更があった場合にチームに即座に通知が届くようにします。
5. アクティブなメール送信元を監査し、整合性の不一致を解消した上で、DMARCポリシーを更新して、なりすましメールをブロックしてください。

よくあるご質問

DNSセキュリティとは、簡単に言うとどのようなものですか？

DNSセキュリティとは、ドメイン名解決システムを保護するために用いられる技術的なプロトコル、アクセス制御、および管理上の慣行を総称するものです。これにより、ユーザーがブラウザにドメイン名を入力した際、攻撃者によって作成された悪意のあるサイトではなく、実際のサーバーに確実に接続されるようになります。

DNSSECはDNSトラフィックを暗号化しますか？

いいえ、DNSSECはDNSクエリや応答を暗号化しません。標準的なDNSSECクエリは平文で送信されます。DNSSECはデジタル署名を使用して、受信したDNSデータが本物であり、転送中に改ざんされていないことを検証します。DNSトラフィックのクエリを暗号化するには、DNS over HTTPS (DoH)、DNS over TLS (DoT)、またはDNS over QUIC (DoQ) を導入する必要があります。

DNSSECとDNS over HTTPS（DoH）の違いは何ですか？

DNSSECはゾーンレベルでデータの完全性を認証し、応答が本来のドメイン所有者から改ざんされることなく送信されたことを証明します。DoHは、エンドユーザー端末と再帰的リゾルバー間の通信経路を暗号化します。

DNSハイジャックとDNSスプーフィングは同じものですか？

いいえ。DNSハイジャックとは、ドメインレジストラやネームサーバーホストの管理権限を乗っ取り、公式のDNS設定を変更することを指します。一方、DNSスプーフィング（またはキャッシュポイズニング）は、公式のレジストラ設定を変更することなく、再帰的リゾルバーを騙して、偽のIPアドレスをキャッシュに保存させる手口です。

自分のドメインのDNSが侵害されているかどうか、どうすればわかりますか？

一般的な兆候としては、予期せぬWebサイトのリダイレクト、メール配信率の急激な低下、ドメインに対して不正に発行されたTLS証明書、あるいは定期的な監査中にNSレコード、Aレコード、MXレコードに予期せぬ変更が加えられていることなどが挙げられます。

SPF、DKIM、DMARCはDNSセキュリティに含まれますか？

はい。SPF、DKIM、およびDMARCレコードは、ドメインのパブリックDNSゾーン内に直接公開されます。受信メールサーバーは、メッセージの送信者の真正性を検証するためにDNSにクエリを送信するため、正確なメール認証レコードは、ドメインのDNSセキュリティ強化において不可欠な要素となります。

結論

DNSセキュリティは、単一の製品を購入して導入するだけのものではありません。これは、ドメイン登録機関の管理、権威ネームサーバーのセキュリティ強化、クエリ転送の暗号化、レコードの整合性チェックなど、多層的な取り組みです。

どのレイヤーでも監視を怠ると、脅威アクターがトラフィックを乗っ取ったり、中間者攻撃を実行したり、企業内の通信を偽装したりする機会を与えてしまうことになります。

今すぐ、アクティブなゾーンファイルの完全なインベントリを作成し、ドメインインフラのセキュリティ強化に取り組みましょう。無料のDNSレコード検索ツールを使用して公開されているレコードを監査し、DMARCレコードチェッカーでドメインをテストして、ブランドが確実に保護されていることを確認してください。

• について
• 最新記事

ミレーナ・バグダサリャン

コンテンツスペシャリスト（勤務先： PowerDMARCの

ミレーナは、IT、サイバーセキュリティ、バーチャルイベントなどに関する魅力的なコンテンツ制作に7年以上の経験を持つ、熟練したライター兼コンテンツ制作者です。ニューヨーク大学アブダビ校、UWCチャイナ校、カレッジ・オブ・ヨーロッパなどの名門校を卒業。

最新記事 by Milena Baghdasaryan(全て見る)

• インシデント対応計画を一から策定する - 2026年9月8日
• ハッカーが金融AIアシスタントを騙す新たな手口 - 2026年9月7日
• DNSセキュリティのベストプラクティス：包括的なセキュリティ強化チェックリスト - 2026年9月7日