DNS完全理解 ― レコード種別・TTL・伝播をVPS運用者目線でマスターする

「ドメインを設定したのに繋がらない」「メールが届かない」「切り替えたのに古いサーバーが表示される」── VPS運用のトラブルの多くは，実はDNSに起因する．そして原因の大半は，DNSの仕組みへの誤解から来ている．

DNSは「ドメイン名をIPアドレスに変換する電話帳」だが，その裏では再帰問い合わせ・キャッシュ・TTL・複数のレコード種別が絡み合っている．ここを理解すれば，「繋がらない」の原因を即座に切り分けられる．

この記事は，独自ドメインをVPSに向けて運用する個人開発者，DNS設定で何度もつまずいたエンジニアに向けている．レコード種別の使い分けから，TTL・伝播の正しい理解，digでのデバッグまでを体系的に解説する．

読み終えたとき，あなたはDNSレコードを的確に設定し，切り替え時のダウンタイムを最小化し，「繋がらない」を自力で診断できるようになっている．

なぜDNSの理解がVPS運用に必須なのか

ドメインをVPSに向ける，メールを設定する，サブドメインを増やす，サーバーを移行する── これらはすべてDNSの操作だ．DNSを理解せずにVPSを運用することはできない．

そしてDNSトラブルは独特の「分かりにくさ」を持つ．設定変更が即座には反映されず(伝播)，自分の環境では古いキャッシュが残り，「正しく設定したはずなのに繋がらない」という混乱を生む．

TTLや伝播の仕組みを知っていれば，「これはまだ伝播中だから待てばよい」「これは設定ミスだから直すべき」を切り分けられる．この切り分けができないと，正しい設定を何度も無駄に変更してしまう．

DNSは一見地味だが，Web・メール・各種認証のすべての入り口だ．ここを押さえることが，安定運用の基礎になる．

名前解決の流れ ― ドメインがIPになるまで

ブラウザにexample.comと入れてからIPが分かるまで，複数のDNSサーバーへの問い合わせ(再帰問い合わせ)が起きている．大まかには，ルート→TLD(.com)→権威サーバー(あなたのドメインのDNS)とたどる．

重要なのは，この結果が各所でキャッシュされることだ．一度引いた結果はTTLの間保持される．これが「変更がすぐ反映されない」現象の正体だ．

レコード種別 ― 何をどう使うか

DNSには用途別のレコード種別がある．VPS運用で使う主要なものを押さえれば，大半の設定はできる．

VPSにWebサイトを向けるなら，まずAレコードをサーバーのグローバルIPに設定するのが基本だ．www付きはwwwのCNAMEをapex(example.com)に向けるか，同じAレコードを設定する．

TTLと伝播 ― 「すぐ反映されない」を制御する

TTL(Time To Live)は，「この結果を何秒間キャッシュしてよいか」を示す値だ．TTLが3600なら，変更しても最大1時間は古い結果が各所に残りうる．これが「伝播(propagation)」の待ち時間の正体だ．

重要なのは，サーバー移行やIP変更を予定しているなら，事前にTTLを短くしておくことだ．切り替えの数日前にTTLを300秒などに下げておけば，本番の切り替え時にほぼ即座に新IPへ移れる．

現在のTTLとレコードを確認

dig example.com A +noall +answer
# 出力例: example.com. 3600 IN A 203.0.113.10
#                      ^^^^ これがTTL(秒)

# 特定のDNSサーバーに直接問い合わせ(伝播確認)
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

切り替えの基本手順は，(1)数日前にTTLを短く(例: 300秒)→(2)切り替え当日にレコードを変更→(3)安定後にTTLを戻す，だ．これを知らずにTTL3600のまま切り替えると，一部ユーザーに最大1時間古いサーバーが表示され続ける．

CNAMEの落とし穴 ― apexには使えない

CNAMEは「別名」を作る便利なレコードだが，重大な制約がある．知らないとハマる定番ポイントだ．

1. apex(ルートドメイン)にCNAMEは使えない：example.com自体にはCNAMEを設定できない(RFC上の制約)．apexはAレコードで指定する．多くのDNSサービスは代替の「ALIAS/ANAME」を提供する．
2. CNAMEと他レコードは共存できない：CNAMEを設定した名前には，MXやTXTなど他のレコードを同居させられない．
3. 多段CNAMEは遅延の元：CNAMEがCNAMEを指す多段構成は，解決に余計な問い合わせが増える．

実践設定 ― VPSに向ける・メール・SPF

代表的な設定をまとめる．WebをVPSに向け，メールを設定し，なりすましを防ぐSPFまでが基本セットだ(メールの詳細は別記事で扱う)．

典型的なDNSレコード構成

; Web をVPSに向ける
example.com.      A      203.0.113.10
www.example.com.  CNAME  example.com.

; メール(例: 外部メールサービス)
example.com.      MX     10 mx.mailservice.example.
example.com.      TXT    "v=spf1 include:mailservice.example ~all"

; 証明書発行をLet's Encryptに限定
example.com.      CAA    0 issue "letsencrypt.org"

SPFレコード(TXT)は，「このドメインのメールを送ってよいサーバー」を宣言し，なりすましメールを防ぐ．CAAレコードは，証明書を発行できる認証局を限定し，不正な証明書発行を防ぐ．どちらも地味だが，ドメインの信頼を守る重要な設定だ．

digでデバッグする ― 「繋がらない」を切り分ける

DNSトラブルの調査はdigが基本だ．「設定が正しいか」「伝播したか」「キャッシュが古いだけか」を切り分けられる．

digによるDNS診断

dig example.com A +short          # 今返ってくるIP
dig @1.1.1.1 example.com +short   # 外部DNSでの解決(伝播確認)
dig example.com MX +short         # メール設定の確認
dig example.com TXT +short        # SPF等の確認
dig +trace example.com            # ルートから辿って解決過程を表示

切り分けの定石は，まずdig @1.1.1.1など外部DNSで引いてみることだ．外部では正しく，自分の環境だけ古いならローカルキャッシュの問題(待てば解決)．外部でも古い/誤りなら設定ミスか伝播待ち．dig +traceは権威サーバーまでの経路を見せ，NS設定の問題を発見できる．

DNSのセキュリティ ― CAA・DNSSECの概要

DNSは攻撃の標的にもなる．ドメイン乗っ取りやDNS応答の改ざんは深刻な被害を生む．基本的な防御を知っておこう．

CAAレコードで証明書を発行できるCAを限定すれば，不正な証明書発行のリスクを下げられる．より高度にはDNSSEC(DNS応答に署名して改ざんを検知する仕組み)があり，対応するDNSサービスなら有効化を検討する価値がある．

加えて重要なのが，ドメイン管理アカウント自体の保護だ．DNSを管理するレジストラ/サービスのアカウントが乗っ取られれば，すべてのレコードを書き換えられる．二段階認証を必ず有効にし，ドメインの有効期限切れにも注意する(期限切れは最悪のドメイン喪失事故になる)．

補論：DNSは「分かりやすい管理画面」と「VPSの固定IP」で扱いやすくなる

DNSの設定ミスは，管理画面の分かりにくさから生まれることが多い．レコード種別・TTL・値を直感的に編集でき，変更履歴を追える管理画面なら，事故は大きく減る．

向ける先のVPSは固定のグローバルIPを持つことが前提だ．高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ は固定IPが付き，NVMe SSDで安定稼働するため，Aレコードを向ける先として信頼できる．スナップショットがあれば，DNS切り替えと並行したサーバー移行も安全に進められる．

ドメイン側は，DNS編集が分かりやすく，WHOIS代理公開や二段階認証に対応したサービスが安心だ．取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ で取得すれば，管理画面からAレコード・MX・TXTを直接編集でき，「ドメイン取得→VPSに向ける→公開」の流れが一本道で繋がる．

よくある質問(FAQ)

Q1．設定したのに反映されないのはなぜ？

TTLによるキャッシュ(伝播待ち)が大半だ．TTLの秒数だけ古い結果が各所に残る．dig @1.1.1.1など外部DNSで引き，そこで正しければあとは時間の問題．外部でも誤りなら設定ミスを疑う．

Q2．サーバー移行で古いサーバーが表示される

切り替え前にTTLを短くしておくのが対策だ．数日前にTTLを300秒等に下げ，当日レコードを変更すれば，ほぼ即座に新サーバーへ移れる．これを怠るとTTLの時間だけ古い表示が残る．

Q3．ルートドメインにCNAMEを設定できない

仕様上の制約だ．apex(example.com)にはCNAMEを使えず，Aレコードで指定する．多くのDNSサービスは代替の「ALIAS/ANAME」を提供しているので，それを使う．

Q4．wwwあり・なしはどう設定する？

apex(example.com)をAレコードでVPSに向け，wwwをapexへのCNAMEにするのが定番だ．そのうえでどちらかに301リダイレクトで正規化する(別記事のwww正規化を参照)．

Q5．メールが届かない原因は？

MXレコードの設定漏れ・誤り，またはSPF/DKIM/DMARCの不備が典型だ．dig ドメイン MX +shortとdig ドメイン TXT +shortで確認する．送信側の認証(SPF等)が無いと迷惑メール扱いされやすい．

Q6．DNSのセキュリティで最優先は？

ドメイン管理アカウントの二段階認証と，有効期限の管理だ．アカウント乗っ取りや期限切れは，全レコード書き換え・ドメイン喪失という最悪の事故になる．CAAレコードでの証明書発行制限も有効だ．

まとめ ― DNSを理解すれば「繋がらない」は怖くない

DNSは，名前解決の流れ・レコード種別・TTLと伝播を理解すれば，トラブルの大半を自力で切り分けられる．特にTTLと伝播の理解は，無駄な設定変更の繰り返しから解放してくれる．

今日やるべきことは，digで自分のドメインのA・MX・TXTレコードを確認し，意図通りか，TTLは適切かを見ること．移行予定があるなら，事前にTTLを下げておく．

DNSはWeb・メール・認証すべての入り口だ．分かりやすい管理画面のドメインと固定IPのVPSがあれば，設定も切り替えも怖くない．