DNS棚卸しの手順：レコード確認、CNAME整理、TTL見直しの実務

DNS 棚卸しで見るべきレコード

DNS 棚卸しの基本は、A / AAAA / CNAME / TXT / NS の役割を分けて見ることです。A や AAAA は直結先、CNAME は委譲先、TXT は所有確認やメール認証、NS は委任境界を示します。公開面の事故は、目立つAレコードだけでなく、古いCNAME や忘れられた TXT から起きやすくなります。

棚卸しでは、レコード値より先に用途を確認してください。用途不明のまま残っているレコードは、それだけでリスク候補です。用途、担当、関連サービス、変更日が台帳やチケットで追えないなら、棚卸し対象として優先順位を上げるべきです。

DNS 棚卸しを始める前に揃える情報

DNS 棚卸しの前に揃えるべき情報は、「残す / 要確認 / 削除候補」を判断するための前提条件です。まずは次の 5 点が揃っているかを確認してください。

特に NS の委任先と委託先情報は重要です。中央管理から外れたサブゾーンが残っていると、レコードの意味を現場へ戻せません。もしゾーン構成が曖昧なら、先に サブドメイン棚卸し で外から見える名前を洗っておく方が前に進みやすくなります。

CNAME / NS / TXT をどう点検するか

CNAME

CNAME は SaaS 連携や CDNs、LP 作成サービスで多用されます。もっとも危ないのは、サービスを消したあとに CNAME だけ残るケースです。ダングリングDNS に直結するため、委譲先が現役か、所有者が明確か、TXT verification があるかを合わせて確認してください。

NS

NS は委任境界を示します。社内ではメインゾーンを把握していても、委任先で何が公開されているかを把握していないことがあります。委託先や子会社が管理するサブゾーンを含めて見ないと、中央の DNS 棚卸しは不完全になります。

TXT

TXT は SPF / DKIM / verification token など多目的に使われるため、消してよいものと残すべきものが混在しやすいです。TXT は『文字列だから軽い』のではなく、メールや所有確認の境界を支えるレコードです。既存値との共存ルールを理解しないまま整理すると、副作用が大きくなります。

TTL を見直すべき場面

TTL はキャッシュ保持時間なので、短ければ良いわけではありません。変更頻度が高いレコードや、検証作業中の TXT verification では短めが有効ですが、安定運用フェーズでは不必要に短い TTL が問い合わせ負荷を増やします。Cloudflare も TTL を『変更がエンドユーザーに届くまでの時間に直結する設定』として扱っています。

見直しが必要なのは、移行直前、カットオーバー前、認証作業中、障害復旧時などです。逆に、常時すべて 300 秒にすれば安全というわけではありません。用途ごとに TTL 方針を決め、レコードの種類と更新頻度に応じて使い分けてください。

DNS 設定ミスの危険サイン

危険サインは、レコード種別ごとに見ると判断しやすくなります。次のような状態が見えたら、単なる棚卸し漏れではなく事故の起点候補として扱ってください。

とくに「このレコードは消してよいか分からない」状態は、そのまま未管理状態を意味します。TXT verification やサービス連携が関わる場合は、TXT認証 の考え方とセットで見直してください。

用途不明レコードをどう整理するか

重要なのは、「分からないから残す」を常態化させないことです。削除できなくても「要確認」のまま期限を切って戻し、monthly見直しで必ず再判定してください。

棚卸し後の運用ルール

DNS 棚卸しは、一覧を作った時点では終わりません。追加、変更、削除のフローへ『用途・担当・関連サービス・廃止時確認』を入れてはじめて再発が減ります。特に CNAME と TXT は、変更依頼票に「既存値との共存確認」「委譲先サービスの現役確認」を追加するだけでも品質が上がります。

また、DNS 棚卸しは サブドメイン棚卸し と分けて考えすぎない方が実務的です。DNS はサブドメイン棚卸しの基礎データであり、サブドメイン棚卸しは DNS の実害評価にあたります。両方を往復しながら整理するのが自然です。

ASM診断 PRO を使えば、外部観点で見える DNS 情報を定期的に確認し、用途不明レコードや古い委譲先の気づきを monthly見直しに乗せやすくなります。手元の台帳と現実の公開面の差分を見る、という DNS 棚卸しの基本と相性が良いです。

よくある質問（FAQ）

DNS 棚卸しはどのレコードから始めるべきですか

まずは A / AAAA で直結先を押さえ、そのうえで CNAME、NS、TXT を見ていくのが進めやすいです。実害に繋がりやすいのは、目立つ A レコードよりも用途不明の CNAME や委任先不明の NS、整理ミスを起こしやすい TXT です。

CNAME と NS はなぜ優先して点検するのですか

CNAME は廃止済み SaaS や LP サービスへの参照が残りやすく、NS は中央管理から外れた子ゾーンを生みやすいからです。どちらも管理責任者が曖昧だと、気づかないまま公開面が増えたり、ダングリングDNSの入口になったりします。

TTL は短いほど安全ですか

そうとは限りません。移行や verification の最中は短い TTL が便利ですが、平常運用で常時短くすると問い合わせ負荷だけが残ります。変更頻度と反映速度の要件に合わせて設計するのが基本です。

用途不明の TXT はすぐ削除してもよいですか

すぐ削除するのは危険です。TXT は SPF、DKIM、verification token など用途が広く、見た目以上に影響範囲があります。まずは関連サービスと管理責任者を確認し、「残す / 要確認 / 削除候補」に分けてから change 管理へ乗せてください。

DNS 棚卸しとサブドメイン棚卸しは別々に行うべきですか

完全に分けるより、往復しながら進める方が実務的です。DNS 棚卸しは設定と委任の整理、サブドメイン棚卸しは外から見える公開面の実害評価なので、片方だけでは判断材料が足りません。

まとめ

DNS 棚卸しは、レコード一覧を眺める作業ではなく、公開面の意味を説明できる状態へ戻す作業です。A / AAAA だけでなく、CNAME、NS、TXT、TTL を役割ごとに見直し、用途不明や廃止漏れを「要確認」のまま放置しないことが重要です。

まずは対象ドメインと委任先を揃え、CNAME と NS の整理から始めてください。DNS 棚卸しを月次レビューへ組み込めば、サブドメイン監視や TXT認証、ダングリングDNS対策まで一つの運用として回しやすくなります。

DNS 棚卸しの月次点検ルール

月次点検では、「新規レコード」、「用途不明レコード」、「委任先変更」、「短TTLのまま残る設定」、「廃止予定サービスへの参照」を固定項目にすると運用しやすくなります。変更依頼の件数より、意味が説明できないレコードの有無を見る方が事故を減らしやすくなります。

点検結果は台帳と change 管理へ戻し、月次レビューで管理責任者未確定項目を潰してください。DNS 棚卸しは設定作業ではなく、公開面の統治活動です。