DNS

DNSとは？仕組み・レコード・設定・浸透を初心者向けに解説

著者: FreeHostBox Web Academy 編集部 公開日: 2026-09-07 最終更新: 2026-09-09

DNSとは一言でいうと

DNS（Domain Name System）とは、ドメイン名（example.com）とIPアドレス（数字の住所）を結びつけるインターネットの電話帳です。ブラウザはドメイン名のままでは接続先が分からないため、DNSでIPアドレスを調べてからサーバーへ接続します。ドメイン解説記事の住所看板に実際の番地を対応付けるのがDNSであり、HTTP解説記事の往復はDNS解決の後に始まります。私たちの無料プランでも無料サブドメインと独自ドメイン持ち込みをご利用いただけますので、ぜひ無料プランでお試しください。

身近な例でいえば、スマートフォンの連絡先がDNSです。名前（example.com）をタップすると裏側で電話番号（IPアドレス）が引かれ、発信（接続）されます。番号が変わっても名前が同じなら連絡先からたどれるように、サーバー移転でもDNSを書き換えれば同じドメインで到達できます。この分離があるからこそ、引っ越し・冗長化・負荷分散が成り立ちます。

本記事はIETF RFCのDNS関連仕様の考え方、各レジストラのDNS・ネームサーバー設定に関する一般解説、ICANNのドメイン名管理に関する解説、MDN Web DocsのDNS・HTTP関連解説を参考にしています。私たちでは無料サブドメイン、独自ドメイン持ち込み対応、無料SSL対応をご用意しています。まずは無料プランで実際に触って確かめてみてください。

名前解決の流れ：リゾルバーと権威サーバーの往復

名前解決は登場人物を3者に分けると理解できます。ブラウザ（質問者）、リゾルバー（利用者側の案内係）、権威サーバー（正しい対応表を持つ原本）です。

1. ブラウザがリゾルバーへ「example.comはどこ？」と問い合わせる
2. リゾルバーがルートからTLD、権威サーバーへと順にたどって正しい答えを探す
3. 得られたIPアドレスへブラウザが接続し、HTTPの往復が始まる
4. 答えは各層でTTLの間だけ控え（キャッシュ）として保存される

このうち2の「順にたどる」部分が初心者には見えにくい要点です。リゾルバーはいきなり正解を知っているわけではなく、.（ルート）→com の管理者→example.com の権威サーバーという順に問い合わせます。各段階の答えもキャッシュされるため、2回目以降は速くなります。速さの裏側で「古い控えが残ると新しい設定が見えない」という浸透の時間差が生まれます。キャッシュは高速化のための善意の仕組みであり、変更時だけ一時的に古さとして現れると理解すると混乱しません。

権威サーバーとリゾルバーの混同も頻出します。権威サーバーは「このドメインの正解は私が持つ」と宣言する側であり、ネームサーバー変更で指定する対象です。リゾルバーは利用者の通信事業者や公共DNS等が提供する「調べる側」であり、利用者が直接書き換える対象ではありません。表示されないときに触るべきは権威側の設定とキャッシュの切り分けであり、リゾルバーを疑うのは後の段階です。切り分けの記録には、確認日時・確認手段（コマンド・別端末・別回線）・返った値・期待値・次の一手の5項目を残します。記録を時系列で並べると浸透の進行が可視化でき、無駄な再変更の抑止になります。記録様式を固定しておくと、複数人での作業分担時にも情報共有が円滑になり、引き継ぎ漏れの防止になります。公共DNSへの切り替えは診断の補助手段にはなりますが、恒久対策ではなく、まずは権威側の値と浸透の確認が先です。

最低限のレコード用語：A・AAAA・CNAME・MX・TXT・NS

DNS設定の実体はレコードと呼ばれる対応表の行です。1行ごとに種別・ホスト名・値・TTLを持ちます。入門で必須の6種を次の表に整理します。

入門ではA・CNAME・NSの3つで十分です。MX・TXTはメールや認証で必要になってから足します。CNAMEの制約として、ルート直下（example.com自体）へのCNAME設定が慣例上避けられる点は押さえておきます。ルートにはMXやNS等の行が同居するため、別名定義との重複が問題になります。ルートの向き先はAまたはAAAAで直指定し、www等の枝番にCNAMEを使うのが定石です。管理画面によってはルートへのCNAME入力を制限している場合があり、その場合は案内に従ってA指定にします。AAAAはIPv6対応時にAと対で整えます。片方だけ古い向き先のままだと、利用者の回線種別によって挙動が割れるため、対応時は両方の整合を確認します。ただし後からメールを使う可能性がある場合は、最初から「Web用の行とメール用の行は別物」という意識を持ち、ネームサーバー変更時にメール行を消さない段取りが重要です。独自ドメイン設定手順記事でも触れる通り、Web公開の変更でメール不通を招く例が後を絶ちません。AAAAはIPv6対応時にAと対で整えます。片方だけ古い向き先のままだと、利用者の回線種別によって挙動が割れるため、対応時は両方の整合を確認します。

; レコード記述の考え方（一般例・値をそのまま使わないこと）
; 注意: ホスト名・IP・TTL・優先度は必ず利用中のサーバー案内と
; レジストラ管理画面の指示に従ってください。以下は書式理解の例示です。
example.com.       3600  IN  A      192.0.2.10
www.example.com.   3600  IN  CNAME  example.com.
example.com.       3600  IN  MX  10 mail.example.com.
example.com.       3600  IN  TXT    "v=spf1 include:_spf.example ~all"

上記はゾーンファイル風の読み物であり、コピー用の完成値ではありません。3600 はTTL（秒）、10 はMX優先度（小さいほど優先）を示します。管理画面によってはホスト名欄に @ や空欄でルートを表す等の慣例差があるため、画面の凡例を優先してください。特にTXTは引用符・空白の扱いが厳密であり、手打ちより案内値のコピーと再確認が安全です。所有確認用のTXTは指定文字列を一文字も変えずに登録し、ホスト名欄（@ か指定サブドメインか）を取り違えないことが合格の鍵です。

浸透・TTL・キャッシュ：待ち時間の正体と管理方法

浸透とは、設定変更が世界中のキャッシュに行き渡るまでの時間差です。原因は3層のキャッシュです。第一に権威サーバーの公開遅延、第二にリゾルバーやOSの控え、第三にブラウザの控えです。TTLはこのうち「控えを何秒信じてよいか」の有効期限であり、短いほど早く行き渡りますが問い合わせが増えます。変更前のTTLが長い（例: 86400秒＝24時間）と、変更後も古い控えが長く残るため、作業の数時間〜前日からTTLを短くしておく段取りが紹介されることもあります。既定のままでも進行はできるため、無理に触る必要はありません。

実務の目安として、変更後は数分〜数時間を見込みます。「最大72時間」という古い目安が残る場合もありますが、現代の一般的なTTL運用ではそこまでかからないことが多く、焦って何度も変更する方が混乱を招きます。1回変更したら変更内容をメモし、TTL分の時間を置いて再確認する姿勢が近道です。変更時刻・変更内容・確認結果を時系列で記録すると、浸透の進行か入力誤りかの判断が付きやすくなります。深夜の切り替えは確認手段が限られるため、日中の時間帯に作業し、関係者への周知も添えるのが安全です。

キャッシュの切り分け手順を示します。まず nslookup あなたのドメイン や dig あなたのドメイン A +short の考え方で「今見えている答え」を確認します。返るIPがサーバー案内と一致すればDNS側は到達しており、表示されない原因はサーバー側追加やSSL・キャッシュに移ります。一致しなければ入力誤りか浸透途中であり、綴り・種別・値を突合せて時間を置きます。ブラウザ要因を切り分けるため、強制再読込、シークレットウィンドウ、別端末・別回線での確認を組み合わせます。1台・1回だけ見て断定しないことが鉄則です。スマートフォンのモバイル回線と自宅回線で結果が割れる場合は、リゾルバー層の控え差であり、時間経過で収束する見込みが高いと判断できます。

# 確認コマンドの考え方（環境により利用可否が異なる）
# 注意: 結果はキャッシュの影響を受けるため、時間を置いて複数回確認すること。
nslookup example.com
nslookup www.example.com
dig example.com A +short
dig www.example.com CNAME +short

Windowsでは nslookup、macOS・Linuxでは nslookup と dig が使える場合が多いですが、利用できない環境もあります。その場合はオンラインのDNS確認道具や別回線での表示確認が代替手段になります。コマンド結果の読み方として、ANSWER欄の値が案内値と一致するかに注目し、権威欄・追加欄の細部に深入りしすぎないのが入門のコツです。wwwあり・なしの両方を確認する習慣が、片側だけ見えない事故の早期発見につながります。

設定手順の要点：独自ドメイン向けの通し手順

詳しい通し手順は独自ドメイン設定手順記事でご紹介しています。ここではDNS担当分の要点のみ示します。

1. 方式を決める（ネームサーバー変更かレコード直接編集か、サーバー案内に従う）
2. レジストラ側でNSまたはA/CNAMEをサーバー案内の値へ変更する
3. wwwあり・なしの両ホスト名を整える（片方だけ直して終わりにしない）
4. サーバー側へドメインを追加する（DNSだけでは表示されない）
5. 浸透待ち（数分〜数時間）を見込んで nslookup の考え方で確認する
6. SSL化して https:// で確認する（SSL設定手順記事で詳説）

方式選びの目安は、初心者・一括移行ならネームサーバー変更、メール等の外部併用があるならレコード直接編集です。どちらを選んでも、変更前の値を控えることが必須です。控えがないと切り戻しができず、復旧に時間がかかります。管理画面のスクリーンショットやメモで「いつ・何を・何から何へ」を残します。作業は閑散時間帯に行い、公開中サイトの切り替えでは事前に告知とバックアップを済ませます。切り替え計画書の雛形は、目的・対象ドメイン・変更内容・変更前値・作業時刻・確認方法・切り戻し条件の7項目で十分です。計画書があると、作業中の迷いが減り、万一の際も切り戻し条件に従って機械的に復旧できます。公開中サイトでは関係者への周知文（作業時間・影響範囲・問い合わせ先）も添えると信頼を保てます。

設定時のチェックリストを示します。

• 変更前のNS・A・CNAME・MX・TXT値を控えたか
• サーバー案内の値と管理画面の入力値が一文字まで一致しているか
• ホスト名のtypo（www有無、末尾、綴り）がないか
• 種別（A/CNAME/NS/MX）の取り違えがないか
• TTLを極端に長く・短くしすぎていないか
• サーバー側追加を忘れていないか（片側だけでは表示されない）
• 浸透待ち時間を確保し連打変更していないか
• キャッシュ切り分け（別端末・シークレット）を試したか

トラブル対処フローとエラー早見表

対処は「仮説→確認→1回修正→待ち→再確認」の順に進めます。同時に複数箇所を変えると原因が分からなくなります。フローは次の通りです。

1. 綴り・ホスト名を確認する（www有無、末尾ドット、余分な空白）
2. 種別と値を確認する（Aにホスト名を入れていないか、CNAMEの向き先は正しいか）
3. サーバー側追加を確認する（既定ページなら未追加の可能性が高い）
4. 浸透とTTLを確認する（変更時刻から十分置いたか）
5. キャッシュを切り分ける（別端末・別回線・シークレット）
6. メール・外部連携を確認する（MX・TXTを消していないか）

エラー早見表を示します。

特に所有確認（サーチコンソールや外部サービスのドメイン認証）では、指定されたTXT値やHTMLファイル配置を正確に行い、浸透後に認証ボタンを押す順番が重要です。浸透前に連打すると失敗履歴だけが増えます。認証用と公開用の行を取り違えないよう、作業メモに目的を添えて残します。外部サービス連携（メール配信・サイト認証・CDN等）を併用する場合は、連携ごとに必要な行を一覧化してからDNS作業に入ると、行の消し忘れ・上書きを防げます。診断の補助として、公共DNS（通信事業者以外の第三者が提供する名前解決サービス）での見え方比べも有効です。自回線のリゾルバーでは古い控えが残っていても、公共DNS側では新しい答えが返る場合があり、浸透の進行中であることが分かります。切り替えはOSやブラウザの設定で一時的に行い、診断後は元に戻すのが安全です。オンラインの伝播確認道具（世界各地の地点から名前解決結果を並べて見せる道具）を使うと、浸透の地理的な広がりが可視化でき、待つべきか直すべきかの判断材料になります。いずれの道具も結果は一時点の記録であり、最終判断は時間を置いた再確認で行います。

次に読む記事

• 独自ドメイン設定手順 — 取得からサーバー追加・SSLまでの実践手順
• SSLとは — HTTPS化の必要性と無料SSLの考え方
• SSL設定手順 — 発行から転送・混在解消までの手順
• ドメインとは — 種類・選び方の基礎固め

出典

参考にした資料

• IETF RFCのDNS関連仕様の考え方、各レジストラのDNS・ネームサーバー設定に関する一般解説、ICANNのドメイン名管理に関する解説、MDN Web DocsのDNS・HTTP関連解説を参考にしました。私たちでは無料サブドメイン、独自ドメイン持ち込み対応、無料SSL対応をご用意しています。まずは無料プランで実際に触って確かめてみてください。仕様・画面は公式ページをご覧ください。