ドメインとDNSの基礎知識【法人サイト担当者向け】

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

法人サイト担当者が最初に覚えたいのは、レコードの暗記ではありません。ドメインを誰が保有し、どこがDNSを管理し、変更がWebとメールのどちらへ影響するかを追えることです。

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

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

同じ事業者が登録とDNSを提供する場合もありますが、必ず一体ではありません。さらにWebサーバーも別会社にできます。請求書にドメイン名があるだけでDNSの管理場所を判断せず、登録事業者と権威DNSの管理画面を分けて記録します。

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

ネームサーバーを変更すると、WebのAレコードだけでなくメール認証や外部サービス確認のTXTレコードも管理先が変わります。新しいDNSへ必要なレコードを移さず委任だけ変えると、一部の機能が止まります。変更前にゾーン全体を比較します。

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

レコードには同時に置けない組み合わせや、参照先に制約があります。値を見た目だけで転記せず、利用サービスの公式手順とDNS事業者の入力形式を照合します。Web移転であっても、メール用のMXとTXTを変更対象から外す判断が必要です。

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

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

変更作業では、対象ドメイン・権威DNS・変更レコード・変更前後の値・TTL・作業時刻を残します。画面のスクリーンショットだけでなく、文字としても保存します。自動で末尾のドットを補う画面などがあるため、表示値と実際の応答を分けて確認します。

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

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

ドメインとDNSの基礎を実務へつなげるには、現在の構成図を一枚作るのが近道です。登録・DNS・Web・メールの事業者と管理者を結び、変更予定の線だけを動かします。この図があれば、制作会社が替わっても影響範囲を説明できます。

調査結果には、確認に使ったDNSサーバーと時刻も残します。社内回線だけで異なる結果が出る場合は、端末のキャッシュや社内DNSを切り分けます。再起動だけで直ったことにせず、公開応答との違いを記録します。