DNSセキュリティチェックリストとは？設定ミス・放置レコード・優先修正順の見方

DNSセキュリティチェックとは何か

DNS棚卸しと何が違うのか

DNS棚卸しは、ある時点でどのドメインにどんな 「A」、 「AAAA」、 「CNAME」、 「MX」、 「TXT」、 「NS」 があるかを一覧化する作業です。これはとても重要ですが、主役は現状把握です。

一方の DNS セキュリティチェックは、同じレコード一覧を見ても、「この設定は何が危険か」「どれから直すべきか」を判断する工程です。たとえば CNAME が残っていること自体が問題なのではなく、その向き先がもう存在しないのに DNS だけ残っている状態が危険です。つまり、棚卸しが何があるかを作る工程なら、セキュリティチェックは何が危ないかを決める工程です。

この違いを曖昧にすると、一覧はあるのに優先修正順が決まらない状態になります。現場で必要なのは、「全部点検した感」ではなく、「今週どれを止めるべきか」が分かることです。DNS セキュリティチェックは、その優先順位をつくるためにあります。

どこからを危険な設定ミスとみなすのか

実務では、すべての設定揺れを同じ重さで扱うと運用が止まります。危険判定の起点にしやすいのは、少なくとも所有確認が崩れている、削除順が逆転している、権限委譲の境界が曖昧、想定外の公開範囲が生まれているの 4 条件です。

ここでいう 「authoritative DNS」 は、そのゾーンに対して最終的な正解を返す権威 DNS のことです。 「verification record」 は、ドメイン所有を証明するための TXT などの記録です。 「CAA」 はどの証明書発行局が証明書を発行してよいかを制御するレコード、 「DNSSEC」 は DNS 応答が改ざんされていないかを検証する仕組みです。専門用語は多いですが、どれも誰が正しい情報を返し、誰がその名前を使ってよいかを支える要素です。

なぜDNS設定ミスは見逃されやすいのか

事故は攻撃より先に運用分断から起きる

DNS の事故は、必ずしも高度な攻撃から始まるわけではありません。むしろ多いのは、マーケティング部門が追加した LP 用サブドメイン、制作会社が設定した CNAME、クラウド移行時の向き先変更、証明書更新、M&A 後の旧ブランドドメインなどが、別々のチームで動くうちに責任分界が崩れることです。

Microsoft Learn の Azure App Service 向け防止策↗も、DNS が残ったままリソースだけ削除されると subdomain takeover の条件が生まれると説明しています。ここで本質なのは、侵入の巧妙さより先に、 「DNS は残っているのに実体がない」 状態を組織側が作ってしまうことです。つまり事故の入口は、攻撃より前にあるライフサイクル管理の不整合です。

CNAME、NS、TXT、CAA、DNSSEC が別担当で切れやすい

DNS 監査が難しい理由は、レコードごとに意味と担当が違うことです。 「CNAME」 は SaaS や CDN、ホスティング基盤への接続で使われやすく、Web チームや委託先が触ります。 「NS」 は委任境界そのものなので基盤チームや旧ベンダーが握ることがあります。 「TXT」 は所有確認、SPF、DKIM、DMARC などに関わり、メール担当や認証担当が入ります。 「CAA」 と 「DNSSEC」 は証明書やレジストラ運用に近く、さらに別担当になることもあります。

こうして担当が切れると、各チームは「自分の範囲では問題ない」と考えがちです。しかし攻撃者や事故は、その境界の外側から起きます。Let's Encrypt の CAA 解説↗が説明するように、CAA はサブドメインごとに上書きでき、しかも 「CNAME」 先まで追って評価されます。つまり証明書発行の可否は、証明書担当だけの話ではなく DNS 全体設計の問題です。DNS セキュリティチェックは、この分断を埋めるためにあります。

最初に確認する5つの重要チェック

dangling CNAME と削除済みクラウド参照

最優先は 「dangling CNAME」 です。これは CNAME が残っているのに、向き先のクラウド資源やホスティング実体がすでに消えている状態を指します。MDN の Subdomain takeover 解説↗は、CNAME がある一方でコンテンツを返すホストが存在しないと、攻撃者がその向き先を取り直してサブドメインを乗っ取れると整理しています。

危険なのは、この状態が特別な障害ではなく、LP 終了、SaaS 解約、ステージング削除、CDN 移行など日常作業の延長で普通に発生することです。だからこそ、DNS セキュリティチェックでは「今動いているか」より前に「削除順が守られたか」を見ます。

NS 委任とレジストラ / 権威DNS の不整合

次に危険なのが 「NS」 です。NS はそのゾーンを誰が 「authoritative」 に管理しているかを示します。ここが曖昧だと、中央側では「もう存在しない」と思っているサブドメインが、子ゾーン側ではまだ普通に公開されている、ということが起きます。

レジストラ設定、親ゾーン、委任先 DNS provider の状態が一致していないと、どこが正規の管理面なのか分かりにくくなります。これは派手に見えませんが、個別レコード以前に誰が正解を返すかが壊れている状態なので、非常に危険です。

MX / TXT / 所有確認レコードの置き去り

「MX」 はメール配送先、 「TXT」 は所有確認、SPF、DKIM、DMARC、検証トークンなど多目的に使われます。ここでいう 「SPF」 は送信元サーバーの許可範囲、 「DKIM」 は電子署名、 「DMARC」 は受信側の扱い方針を示すメール認証です。見た目はただの文字列でも、実際には誰がそのドメインを使えるかの土台になっています。

Cloudflare の TXT-based DCV 解説↗でも、証明書発行前の 「DCV」 （Domain Control Validation） で authoritative DNS に正しく TXT を置く重要性が説明されています。問題は、TXT があることではなく、その存在理由を説明できるかです。意味が説明できない verification record は、残しても危険、消しても危険です。

wildcard DNS と不要な公開範囲

「*.example.com」 のような 「wildcard DNS」 は便利ですが、守るべき名前の範囲を一気に広げます。GitHub Docs↗は、wildcard DNS が即時の takeover リスクを高めると明確に警告しています。理由は単純で、想定外の深い階層まで応答対象になり得るからです。

wildcard を完全禁止するかは組織次第ですが、少なくとも「便利だから残す」は危険です。使うなら、対象範囲、管理責任者、利用目的、除外ルール、監視方法を明文化したうえで、通常より強い差分監視が必要です。

CAA / DNSSEC / 証明書発行まわり

「CAA」 と 「DNSSEC」 は、後回しにされやすいわりに、信頼の境界へ直接関わる設定です。Let's Encrypt は、CAA がどの CA がそのドメイン向け証明書を発行してよいかを制御し、サブドメイン側で override できること、さらに CNAME 先まで追って判断されることを説明しています。

一方Cloudflare の DNSSEC 解説↗は、DNSSEC が spoofed domain への誘導を防ぐ追加の認証層であることに加え、移管時に古い DNSSEC が残ると connectivity error が起きると説明しています。つまり CAA と DNSSEC は「入れているか」だけでなく、「今の運用と整合しているか」を見る必要があります。

レコード種別ごとにどこを見るべきか

A / AAAA / CNAME

「A」 と 「AAAA」 は名前を IP アドレスへ結びつけるレコードです。ここで重要なのは、IP が通るかどうかより、その IP が今も想定どおりの資産かです。移管や廃止のあとに古い IP を向いたまま残っていると、意図しない環境へ流れていることがあります。

「CNAME」 はさらに厄介です。SaaS、CDN、Pages、App Service など外部サービスへ名前を渡していることが多く、向き先の状態確認が不可欠です。CNAME を見るときは、向き先が現役か、所有確認 があるか、削除時の手順が存在するかの 3 点まで確認してください。

NS / MX / TXT

NS は「どの nameserver が authoritative か」だけでなく、「その委任が今も誰の責任か」を確認します。子会社、委託先、旧ベンダー、買収先に委任されているなら、中央の台帳と必ず突き合わせるべきです。「この子ゾーンは誰の責任か分からない」状態は、そのまま高リスクです。

MX はメール配送先そのものなので、古いサービスや意図しない委託先へ向いていないかを確認します。TXT は所有確認、SPF、DKIM、DMARC、検証トークンなどが混在するため、値より前に存在理由を点検します。存在理由が説明できない TXT は、危険な残置か、誤削除で事故になるかのどちらかです。

CAA / DNSSEC / verification records

CAA は「あるかないか」だけでは不十分です。どこにあり、どの CA を許可していて、その設計が今の運用と一致しているかが重要です。サブドメイン側で override できる以上、親ドメインだけ見て安心するのは危険です。

DNSSEC は、 「DS record」 をレジストラ側へ正しく設定できているか、nameserver 変更時に古い署名や設定が残っていないかがポイントです。verification record も同様で、「追加したら終わり」ではなく、継続的に維持すべき境界設定として扱う必要があります。

すぐ使えるDNSセキュリティチェックの進め方

初回 30 分でやる監査

初回チェックで完璧を目指す必要はありません。むしろ重要なのは、最初の 30 分で危険な順に止めることです。おすすめは、 「CNAME」 の向き先確認、 「NS」 の委任先確認、 「TXT / verification」 の存在理由確認、 「wildcard」 の有無確認、 「CAA / DNSSEC」 の状態確認の順です。

ここで大事なのは「全部直す」ではなく、「今すぐ危ないものだけ拾う」ことです。GitHub Pages や App Service の custom domain で 所有確認 がない、削除済みサービスへ CNAME が残っている、旧委託先の NS 委任が戻っていない、といったものは高優先で止めるべきです。

週次の差分確認で止めるべきもの

DNS の危険は、ある日ゼロから生まれるというより、前回と比べて少し変わったことで発生します。週次レビューでは、新規 CNAME / NS / TXT、既存 CNAME の向き先変更、verification record の追加や削除、wildcard の追加、CAA と DNSSEC の状態変更を固定項目にすると回しやすくなります。

ポイントは一覧ではなく差分を見ることです。差分ベースにすると、「先週までなかったもの」「先週までは安全だったもの」が見えるようになり、監査が運用に変わります。差分起点の監視設計は、サブドメイン監視の記事とも相性が良いです。

月次レビューで管理責任者未確定項目を潰す

月次レビューでは、技術差分そのものより、 「説明できない状態」 を減らします。管理責任者未確定のサブドメイン、用途不明の verification record、旧委託先のまま残る NS 委任、期限や更新責任が曖昧な CAA / DNSSEC、wildcard の例外運用などが残っていれば、翌月へ持ち越さない方針が必要です。

見落としやすい危険シナリオ

サブドメイン takeover と disabled service の放置

最も典型的なのは、サービスを止めたのに DNS を消していない状態です。GitHub Docs↗は、GitHub Pages site が disabled なのに custom domain が DNS provider 側に残っていると、その subdomain が takeover リスクに晒されると説明しています。Microsoft Learn も、site deletion 前に DNS records を先に更新しないと bad actor に奪われる窓が生まれると説明しています。

2025 年 12 月に公開されたInfoblox の Hazy Hawk 解説↗は、放置された dangling CNAME と削除済み cloud resource を足場に、高信頼ドメイン配下のサブドメインが現実に hijack されたことを示しました。悪用先が defacement ではなく悪性 URL の中継や配布だった点は、読者にとって重要な発見です。

NS / MX の不整合が信頼悪用につながるケース

NS や MX の不整合は、CNAME takeover ほど話題になりませんが、信頼を壊すという意味では同じくらい危険です。委任先が旧ベンダーのまま残る、意図しない mail route が生きている、所有確認が別組織のまま残る、といった状態は、ユーザーから見れば「その会社の名前なのに中身が違う」状況を作ります。

DNS は Web ページだけの話ではありません。NS の境界が曖昧なら、正解を返す主体そのものが曖昧になります。MX や関連 TXT が曖昧なら、メールの trust 境界が揺れます。だから DNS セキュリティチェックは、Web チームだけで閉じてはいけません。

移管時の DNSSEC / DS record 事故

DNSSEC は「入れるか入れないか」の二択に見えがちですが、実務で事故になりやすいのは切り替え時です。Cloudflare は、既存ドメインを onboarding する際にレジストラ側で古い DNSSEC を無効化しないまま nameserver を切り替えると connectivity error が起きると明記しています。

つまり DNSSEC は security feature があるから安心、ではありません。 「今の nameserver」、 「DS record」、 「レジストラ設定」 が揃っているかを確認しないと、可用性の事故になります。高度な設定ほど、運用の引き継ぎミスや移管ミスで壊れやすいのです。

チェック結果を台帳と運用へ戻す方法

change 管理票に追加すべき項目

DNS の事故を減らすには、発見した問題を一時的なメモで終わらせず、change 管理と台帳へ戻す必要があります。最低限ほしいのは、対象 「FQDN」、 レコード種別、現在の値と向き先、管理責任者、利用中サービス名、停止時に先に消すべきもの、verification record の有無、CAA / DNSSEC の関係有無、最終確認日です。

この情報がそろうと、DNS セキュリティチェックの結果を「誰かの気づき」で終わらせず、次の是正と再確認へつなげられます。逆に、この情報が残らないと、同じ問題が担当者交代のたびに再発します。

子会社 /委託先/ M&A ドメインをどう含めるか

複数ブランドや子会社がある企業では、DNS の危険は中央より周辺で起きやすいです。M&A 後の旧ブランドドメイン、委託先が作った LP サブドメイン、子会社独自のメール配送用ドメインなどが、後から監査範囲へ入ってくることがよくあります。

ここではドメイン単位だけでなく責任単位で見るのが有効です。つまり、どのブランドか、どの子会社か、どの委託先か、誰が停止判断を持つかを台帳へ入れることです。DNS セキュリティチェックは、技術資産の監査であると同時に、責任の監査でもあります。

削除前に確認すべき順序

DNS まわりで最も危険なのは、削除を雑に進めることです。推奨順序は、利用中サービスか確認する、管理責任者と用途を確認する、verification / certificate / mail auth の影響を確認する、DNS を先に更新する、最後にサービス本体を止めるです。

この順序を変えると、表面上は停止済みなのに DNS だけ残る、verification を消してから再発行が必要になる、メール配送だけ壊れる、といった事故が起きます。削除は片付けではなく、最も危険な change だと考えた方が安全です。

DNSセキュリティチェックなら ASM診断 PRO

外部観点で危険な DNS 差分を優先確認しやすい

ここまで見てきたように、DNS セキュリティチェックで難しいのは、レコードを読むことより何が危険で、誰が直すべきかを決めることです。DNS だけを見ていても、実際に何が公開されているか、どのホストが再公開されたか、どの向き先が危険かは判断しきれません。

ASM診断 PRO は、その点で外部観点の見え方から入れるのが強みです。まず Public 診断で外から見える公開資産の全体像を掴み、その後、会員登録とTXT 認証を通じて Verified 側の継続監視へつなげると、「DNS に何かある」ではなく「今その設定が何を露出させているか」を判断しやすくなります。

特に、複数ドメイン、子会社、委託先、旧キャンペーンサイトが混ざる組織では、DNS 監査の難しさは設定数より責任分界の複雑さにあります。ASM診断 PRO は、Public と Verified の導線を使いながら、差分を管理責任者と用途へ戻しやすいので、「見つけたけれど誰も引き取らない」状態を減らしやすいです。

手作業 / DNS棚卸し / ASM診断 PRO の比較表で訴求する

運用チームが比較表から判断すべきこと

DNS セキュリティチェックで本当に難しいのは、検知そのものより 「検知結果を放置しないこと」 です。手作業は初回監査に向きますが、差分運用まで続けると属人化しやすくなります。棚卸しは母集団作成に向いていますが、危険な変更を追い続けるには追加の運用設計が必要です。

ASM診断 PRO は、単発の確認を継続運用へ移しやすいのが利点です。もちろん、脆弱性診断やペンテストの代わりではありません。ただし、何が増えたか、何が危ないか、誰に戻すべきかを外部観点で見える化するという意味では、DNS セキュリティチェックの土台と相性が良いです。

よくある質問（FAQ）

DNS 棚卸しと DNS セキュリティチェックは別々にやるべきですか

はい。棚卸しは「何があるか」を整理する作業、セキュリティチェックは「どれが危険か」を判断する作業です。実務では密接に関係しますが、目的は別です。棚卸しだけだと優先修正順が決まらず、セキュリティチェックだけだと母集団の把握が粗くなります。

CAA や DNSSEC は全ドメインで必須ですか

一律に必須と断定するより、どのドメインが証明書発行や信頼境界の中心かで優先度を決めるのが現実的です。ただし、CAA と DNSSEC を「難しいから後回し」にすると、後から設計と運用の食い違いが大きくなります。少なくともコーポレートや重要サービスのドメインでは監査項目へ入れるべきです。

wildcard DNS はどの条件なら許容できますか

使うなら、対象範囲、管理責任者、利用目的、差分監視方法が明確であることが前提です。GitHub Docs が警告しているように、wildcard は意図しない深い階層まで危険領域を広げます。便利だから使う、ではなく、管理できる条件がそろっているから使う、と考えるべきです。

子会社や委託先の DNS まで中央で見た方がよいですか

はい。ただし中央がすべてを直接管理する必要はありません。重要なのは、中央で差分を見つけることと、各現場へ責任を戻すことを分けることです。中央が完全に見えていない状態が最も危険です。

脆弱性診断だけでは DNS の問題は見つかりませんか

見つかるものもありますが、不十分です。脆弱性診断は、存在している公開面の弱点を見るのが得意です。一方で DNS セキュリティチェックは、「そもそもその公開面が正しく管理されているか」「所有確認や削除順に問題がないか」を見る作業です。両者は代替関係ではありません。

まとめ

DNS セキュリティチェックは、DNS をきれいに見せるための作業ではなく、事故に直結する 「misconfiguration」 を危険な順に止めるための作業です。特に重要なのは、 「dangling CNAME」、 「NS 委任の曖昧さ」、 「TXT / verification の置き去り」、 「wildcard DNS」、 「CAA / DNSSEC」 の 5 領域です。

今日から始めるなら、まずCNAME の向き先が現役か、NS の委任先と管理責任者が説明できるか、TXT verification と wildcard DNS の存在理由が説明できるかの 3 点だけでも確認してください。DNS の事故は、派手な侵入より前に、運用の分断から始まります。だからこそ、「設定がある」ことより「設定の意味が説明できる」ことを基準に監査を始めるのが有効です。