ドメインは会社のWebサイトとメールで使う名前です。DNSは、その名前からWebサーバーやメールサーバーなどの接続先を調べられるようにする仕組みです。似た言葉ですが、契約と設定の役割は分かれています。

たとえば、同じ会社のドメインでホームページはレンタルサーバー、メールは別のメールサービスを使えます。それぞれの行き先をDNSが案内するためです。名前と接続先を分けて考えると、サーバーを変えてもURLやメールアドレスを維持できる理由が分かります。

ドメイン登録とDNS運用は別の仕事になる

ドメインを登録した組織や人を登録者と呼び、登録はレジストラなどの事業者を通じて維持します。更新、移管、登録情報の管理はこの契約に関わります。一方のDNS運用は、ドメインに対する問い合わせへ接続先の情報を返す仕事です。

同じ事業者が登録とDNSを提供する場合もありますが、必ず一体ではありません。さらにWebサーバーも別会社にできます。そのため、ドメインの請求元へログインしても、Webの接続先を変更する欄がないことがあります。設定する場所は、現在使っているDNSの管理画面です。

DNSは階層と委任で問い合わせ先をたどる

DNSは一か所の巨大な名簿ではなく、階層ごとに管理を分けています。上位側は対象ドメインの情報を持つネームサーバーを案内し、その権威DNSがWebやメールに必要なレコードを返します。この管理の受け渡しを委任と考えると整理しやすくなります。

ネームサーバーを変更すると、WebのAレコードだけでなくメール認証や外部サービス確認のTXTレコードも管理先が変わります。新しいDNSへ必要なレコードを移さず委任だけ変えると、一部の機能が止まります。Webだけを移す場合にも、DNSの管理先を変えるならメールなど既存の設定を引き継ぐ必要があります。

Webとメールは同じ名前から別の接続先へ進む

WebサイトではAやAAAAがIPアドレスを示し、CNAMEが別の名前を参照させます。メールではMXが受信先を案内します。TXTは送信認証やサービス所有確認などに使われます。同じドメインでも用途ごとに別の事業者へ向けられます。

レコードには同時に置けない組み合わせや、参照先に制約があります。たとえばWebの接続先を示すAレコードだけを変え、メール用のMXはそのままにする構成が可能です。ただし、そのMXが変更するAレコードの名前を配送先にしている場合は、メールの行き先も変わります。サービスが指定する値は用途が異なるため、似た名前の欄へ入れ替えて入力できるものではありません。

TTLは変更が反映される期限ではない

TTLは、問い合わせ結果をキャッシュしてよい時間を示します。変更前の値がキャッシュに残っている間は、新旧の回答が利用者ごとに分かれる場合があります。ただしTTLを短くすれば、すべての環境がその時刻に一斉に変わるという意味ではありません。

切り替え前にTTLを調整するなら、現在のTTLが期限切れになるだけの時間を先に確保します。変更後すぐ元の長さへ戻すと調査が難しくなるため、新旧サーバーのアクセスとメール配送を確認してから戻します。値は事業者の許容範囲に従います。

設定の変更で影響する範囲

DNSを実際に変更するときは、元の値を保存しておくと、誤入力を見つけたときに戻す基準になります。ただし、値を戻してもキャッシュが残るため、全利用者の接続先がすぐ元に戻るとは限りません。変更前の値と、外部から取得できる応答は分けて見る必要があります。

DNSSECを利用している場合は、署名と委任側の情報も変更に関係します。ネームサーバーだけを先に変えると検証に失敗することがあるため、対応手順を登録事業者とDNS事業者へ確認します。DNSSECを無効にする前提で進めません。

障害時は契約画面と応答結果を分けて見る

サイトが見えないときは、まずドメイン登録が有効かを見ます。次に委任先と権威DNSの応答を確認し、最後にWebサーバーの応答を調べます。管理画面に正しい値があっても、公開されたDNS応答が同じとは限りません。

サイトが表示されない原因は、サーバー停止だけではありません。ドメインの期限切れなら登録会社、接続先の誤りならDNS、接続後のエラーならWeb側と、問題のある場所によって対応先が変わります。

社内だけ古いサイトが表示される場合は、社内DNSや端末のキャッシュが残っている可能性もあります。同じURLなのに見え方が違うこと自体は、DNSの仕組みで説明できます。レコードごとの具体例はA・CNAME・MX・TXTの違いで扱っています。