ドメインの契約とサーバーの契約は別物
サーバーを借りただけでは、独自ドメインでアクセスできるようにはならない。ドメインはレジストラ(ドメイン登録事業者)から別途取得し、その名前をどのサーバーに結びつけるかを設定して初めてつながる。サーバー事業者がドメイン登録も扱っていれば同じ管理画面で完結するが、二つの契約であることに変わりはない。
設定する場所は二段階に分かれる。第一段階はレジストラでのネームサーバーの指定で、このドメインについては誰に問い合わせればよいかを決める。第二段階は、指定したネームサーバー上でのDNSレコードの登録で、wwwはどのIPアドレスか、メールはどこへ配送するかといった中身を書く。設定が思ったとおりに動かないとき、原因の多くはこの二段階のどちらを触っているのかを取り違えていることにある。
ネームサーバーは問い合わせ先、レコードは回答内容
ブラウザがexample.comのアドレスを知りたいとき、問い合わせはルートサーバーから始まる。ルートは「.comのことは.comのサーバーに聞け」と答え、.comのサーバーは「example.comのことはns1.example-dns.jpに聞け」と答える。この最後に名指しされたサーバーが権威ネームサーバーで、ここに登録されたレコードが実際の回答になる。上位から下位へ担当を引き渡すこの仕組みを委任と呼ぶ。
レジストラの管理画面でネームサーバーを変更する操作は、.comのサーバーが返す委任先を書き換えることを意味する。ここで重要なのは、切り替えた瞬間から有効になるのは新しいネームサーバーに登録されたレコードだけだという点だ。旧ネームサーバーに残したレコードは参照されなくなる。サーバー移転にあたってWebサイト用のAレコードだけを移し、メール用のMXレコードやドメイン認証用のTXTレコードを写し忘れると、Webは表示されるのにメールだけ止まる。ネームサーバーを変える前に、旧環境に登録されている全レコードを一覧で控えておく。
逆に、ネームサーバーを変えずにレコードだけ書き換えるなら、影響範囲はそのレコードに限られる。サーバー移転でIPアドレスだけが変わる場合は、ネームサーバーはそのままにAレコードを書き換えるほうが安全だ。
よく使う5種類のレコード
| 種類 | 登録する値 | 主な用途 |
|---|---|---|
| A | IPv4アドレス | ドメインをサーバーに向ける |
| AAAA | IPv6アドレス | IPv6で接続させる |
| CNAME | 別のホスト名 | 他の名前の別名にする |
| MX | メールサーバーのホスト名と優先度 | メールの配送先を指定する |
| TXT | 任意の文字列 | 所有権確認、SPF・DKIM・DMARC |
AとAAAA:サーバーのIPアドレスを書く
AレコードにはIPv4アドレスを、AAAAレコードにはIPv6アドレスを書く。両方登録すれば、クライアントが使えるほうを選ぶ。VPSがIPv6アドレスも配布しているなら両方登録してよいが、その場合はWebサーバーがIPv6でも待ち受けているか、ファイアウォールがIPv6を通しているかを合わせて確認する。AAAAだけ登録してサーバー側が未対応だと、IPv6環境の利用者からのみ接続できないという再現しにくい障害になる。
CNAME:別名を張るが、置ける場所に制限がある
CNAMEは「この名前は別のホスト名と同じ扱いにする」という指定で、参照先のIPアドレスが変わっても追随する。外部サービスが指定するホスト名に向ける用途で使う。CDN、独自ドメインを設定できるSaaS、静的サイトホスティングなどが典型だ。
制約が二つある。第一に、CNAMEを設定した名前には他のレコードを共存させられない。第二に、example.comそのもの(ゾーン頂点、管理画面では@や空欄で表される)にはCNAMEを置けない。頂点にはSOAレコードとNSレコードが必ず存在するため、共存できないという第一の制約に反するからだ。頂点を外部サービスに向けたい場合は、DNS事業者が提供するALIASやANAMEといった独自機能を使うか、頂点にはAレコードを置き、wwwなどのサブドメインだけをCNAMEにする。
MX:優先度は小さいほうが優先
MXレコードはそのドメイン宛のメールをどのサーバーが受け取るかを示す。値はホスト名と優先度の組で、優先度は数値が小さいほど優先される。10と20を登録すれば通常は10のほうに配送され、応答しないときに20が使われる。
MXの値にIPアドレスを直接書くことはできず、ホスト名を書く。またMXが指すホスト名はCNAMEであってはならず、Aレコードで直接IPアドレスに解決される必要がある。メール配信サービスを使う場合は、提供元が指定するMXとTXTを指示どおりに登録する。
TXT:所有権確認とメール認証
TXTレコードは任意の文字列を置ける枠で、実際には二つの目的で使う。ひとつは所有権の確認だ。外部サービスが指定した文字列をTXTに登録すると、そのドメインを管理していることの証明になる。もうひとつがメールの送信元認証で、SPF・DKIM・DMARCの3つがすべてTXTとして登録される。SPFは送信を許可するサーバーの一覧、DKIMは電子署名の検証鍵、DMARCは認証に失敗したメールの扱い方針を示す。
SPFで注意が要るのは、1つのドメインに有効なSPFレコードを2つ以上置けない点だ。メール配信サービスを追加するたびに新しいTXTを増やすのではなく、既存のSPFレコードの中に追記して1行にまとめる。
TTLはキャッシュの有効期限
各レコードにはTTL(Time To Live)が秒数で設定されている。3600なら1時間だ。世界中のキャッシュDNSサーバーは、一度受け取った回答をこの秒数のあいだ保持し、その間は権威ネームサーバーに問い合わせ直さない。レコードを書き換えても即座に切り替わらないのはこのためで、変更が広まるのを待っているのではなく、古いキャッシュの期限切れを待っている。
ここから作業手順が決まる。IPアドレスの変更を予定しているなら、変更の前日にTTLを300秒程度へ下げておく。ただしTTLを下げた設定自体が行き渡るのにも、変更前のTTLぶんの時間がかかる。元が3600秒なら1時間以上、86400秒なら1日以上の余裕を見る。切り替えが完了して安定したら、TTLを元の値に戻す。TTLを短いままにすると問い合わせが増え、権威ネームサーバーが停止したときの影響が早く出る。
存在しない名前を引いた結果もキャッシュされる。この期限はゾーンのSOAレコードで決まる。設定をタイプミスした状態で一度アクセスしてしまうと、修正後もしばらく失敗が続くことがある。設定直後にうまくいかない場合、数分待ってから再確認する価値がある。
反映されないときは上流から順に切り分ける
調査は必ずルート側から下流へ向かって進める。どの段階まで正しく届いているかがわかれば、直すべき場所が一箇所に定まる。Linuxではdig、Windowsではnslookupを使う。
1. 委任先が正しいか。dig NS example.com @8.8.8.8 で、返ってくるネームサーバー名がレジストラで指定したものと一致するか確認する。一致しないなら、レジストラ側の設定がまだ反映されていないか、そもそも保存できていない。ネームサーバーの変更は上位ゾーンの更新を伴うため、レコードの変更より時間がかかり、数時間から1日程度みておく。
2. 権威ネームサーバーが正しい値を返すか。dig www.example.com A @ns1.example-dns.jp のように、権威サーバーを直接指定して問い合わせる。ここで期待した値が返らなければ、原因はキャッシュではなくレコードの登録内容にある。管理画面の入力を見直す。
3. 公開リゾルバが古い値を返していないか。権威サーバーは正しいのに dig www.example.com A @8.8.8.8 が古い値を返すなら、TTLの期限切れを待つ以外にできることはない。
4. 手元の端末のキャッシュ。外からは正しく見えるのに自分の環境だけ古い場合は、OSやブラウザのキャッシュを疑う。systemd-resolvedを使うLinuxなら resolvectl flush-caches、Windowsなら ipconfig /flushdns で消去する。動作確認のために hosts ファイルへ書いた行が残っていないかも確認する。
5. 名前は引けるのにつながらない場合。ここまでで正しいIPアドレスが返っているなら、DNSの問題ではない。サーバーのファイアウォール、Webサーバーが該当ドメイン名を受け付ける設定になっているか、TLS証明書がそのドメインで発行されているかを順に確認する。
委任のどこで途切れているか把握したいときは dig +trace example.com が使える。ルートから順に問い合わせる過程が表示されるため、どの階層で想定と違う回答が返っているかが一目でわかる。
設定でつまずきやすい書式
ホスト名の書き方は事業者ごとに異なる。管理画面によっては www とだけ書く相対指定を求め、別の画面では www.example.com. と末尾のドットまで含めた絶対指定を求める。相対指定の欄に www.example.com と入力すると、末尾にドメイン名が補われて www.example.com.example.com という別の名前になる。値が保存できているのに解決されないときは、まずこの補完を疑う。
ゾーン頂点の書き方も揃っていない。@、空欄、ドメイン名そのものなど表記が分かれるため、管理画面の説明を確認してから入力する。
移行時の順序と、公開前の確認
稼働中のサイトを別のサーバーへ移すなら、順序を守れば無停止に近づけられる。まず新サーバーに環境を構築し、手元の hosts ファイルへ新サーバーのIPアドレスを書いてDNSを変えずに動作を確認する。次に前日までにTTLを短くする。そのうえでAレコードを書き換え、旧サーバーは1週間ほど停止せずに残しておく。キャッシュの残った利用者が旧サーバーへ到達しても、正常な応答が返る状態を保つためだ。
公開前に見るべき点は四つに絞れる。ネームサーバーの委任先が意図したものになっていること。頂点とwwwの両方で名前が引けること。メールを使うならMXとSPFが旧環境から漏れなく移っていること。そしてTTLが用途に見合った値に戻っていること。この四つを dig の出力で確認できていれば、DNS側の準備は終わっている。以降の不具合はサーバー設定側を見ればよい。