TXT認証とは？TXTレコードの追加方法とdigでの確認手順

TXT認証が必要な理由

TXT認証は、対象ドメインの管理権限があることを確認する手順です。GitHub Docs も custom domain verification が takeover attack を避けるために役立つと明示しています。つまり TXT認証は『使うために必要な儀式』ではなく、ドメイン所有確認の安全装置です。

ASM診断 PRO では、TXT認証を通したドメインを Verified 管理へ載せることで、管理対象の正当性を保ちやすくしています。運用責任が曖昧なドメインを混ぜないためにも、認証フローは重要です。

TXT認証の前に確認する4点

追加前に必ず確認したいのは、`どのゾーンが権威 DNS か`, `既存 TXT と共存できるか`, `TTL が長すぎないか`, `challenge host と token が正しいか` の4点です。特に委託先やレジストラ経由で DNS を管理している環境では、見ている管理画面が権威 DNS ではないことがあります。

もうひとつ見落としやすいのが、既存 TXT の上書きです。SPF、DKIM、Google site verification などが混在していることは珍しくありません。反映確認に時間がかかる場合は、DNS 棚卸し でゾーン構成を先に整理しておくと切り分けが速くなります。

TXTレコードの追加手順

まず管理画面から challenge host と verification token を取得します。次に DNS 管理画面で TXT レコードを追加します。ここで大事なのは、既存の TXT を消さないことです。SPF や他サービスの検証レコードを壊すと、別の障害を起こします。

TTL は短めにすると確認が速くなります。Cloudflare は `Auto = 300 seconds` を示しており、認証作業中は 300 秒程度が扱いやすい目安です。ただし運用安定後は、環境に応じた標準TTLへ戻す判断も必要です。

dig / nslookup での確認

DNS 管理画面で設定しただけでは十分ではありません。外からどう見えているかを確認するため、`dig` や `nslookup` で TXT を引いてください。UI 上の保存完了と、外部リゾルバから見える状態の間にはタイムラグがあります。

15 分以上反映されない場合は、ホスト名の誤り、既存 TXT との上書き、権威 DNS の取り違えを疑ってください。複数リゾルバで同じ結果になるかを見ると、キャッシュ由来の誤判定を減らせます。

よくある失敗

TTL を見ていない

変更直後に未反映で失敗したと思い込み、同じレコードを何度も入れ直すケースがあります。TTL と伝播時間を見たうえで判断してください。

既存 TXT を消してしまう

SPF やメール認証の TXT を上書きすると、別の運用事故が起きます。必ず共存前提で設定してください。

権威 DNS を取り違える

代理店や外注先が DNS を持っている場合、見ている管理画面が違うことがあります。権威を持つ NS を先に確認してください。

TXT認証の反映後にやること

TXT認証が通ったら、まず Verified 運用へ進める対象ドメインかどうかを確認してください。認証済みでも、owner が曖昧なドメインや用途不明のサブドメインをそのまま運用対象へ載せるのは危険です。導入ガイド と 機能解説 を見ながら、誰が results を引き取るかまで決めると止まりにくくなります。

また、設定が通った後は、検証用に短くした TTL を標準値へ戻すかも判断してください。認証時だけの一時値を放置すると、運用ポリシーが崩れやすくなります。TXT認証は追加して終わりではなく、通常運用へ戻すまで が手順です。

よくある質問（FAQ）

TXT認証はどのくらいで反映されますか

TTL や権威 DNS の設定次第ですが、数分から数十分の差が出ます。15分以上見えない場合は、権威 DNS、ホスト名、値の入力を再確認してください。

dig と nslookup はどちらを使えばよいですか

どちらでも確認できますが、詳細に見たいなら `dig` が扱いやすいです。複数リゾルバで同じ結果になるかを確認すると、キャッシュ由来の見誤りを減らせます。

TXT認証の後に次にやるべきことは何ですか

Verified 運用へ進める対象を決め、継続監視とレポート運用へつなげることです。認証だけではセキュリティ運用は始まりません。

既存 TXT がある場合は上書きしてもよいですか

上書きは避けてください。SPF、DKIM、Google site verification など、他の運用に必要な TXT が共存していることは珍しくありません。新しい verification token は既存値を消さずに追加し、外から見える状態を確認してから次へ進めるのが安全です。

TXT認証が失敗したときは何を先に疑うべきですか

まずは権威 DNS の取り違え、challenge host の誤り、token の貼り付けミス、TTL と伝播待ち時間を疑ってください。管理画面の保存完了だけで判断せず、`dig` や `nslookup` で外から見える結果を確認すると切り分けが早くなります。

まとめ

TXT認証は、小さな設定作業に見えて、所有確認と運用責任の境界を支える重要な手順です。TTL、既存 TXT との共存、外からの確認まで含めて手順化すると、失敗しにくくなります。

ASM診断 PRO を使うなら、TXT認証を終えた後に Verified と継続監視へ進み、結果をレポートとレビューへ繋げてください。設定作業で終わらせず、運用開始までを一つの流れとして扱うのが重要です。