DNSとは？ドメインとIPアドレスを結ぶ仕組みをやさしく解説

DNS（Domain Name System）とは、ブラウザに入力したドメイン名を、通信先を示すIPアドレスなどの情報へ変換する仕組みです。人が覚えやすい名前と、コンピューターが通信に使うアドレスを結び付けるため、「インターネットの電話帳」にたとえられます。

ただし、DNSは単純な一覧表ではありません。世界中のサーバーが階層的に役割を分担し、Webサイトだけでなくメールの配送先やドメイン所有確認なども扱います。本記事では、2026年9月28日時点の公式情報を基に、DNSの仕組み、ドメイン・IPアドレスとの違い、確認方法、設定変更、トラブル時の切り分けまで初心者向けに解説します。

DNSはドメイン名を何に変換しているのか？

DNSの代表的な仕事は、「www.example.jp」のようなホスト名に対応するIPアドレスを調べることです。ICANNのDNS解説でも、端末がDNSを利用してドメイン名に対応するIPアドレスを見つける仕組みが説明されています。

Webサイトへ接続するとき、ブラウザは文字列のドメイン名だけを使って通信先へ到達するわけではありません。まずDNSからIPv4用のAレコードやIPv6用のAAAAレコードを取得し、その結果を手掛かりにWebサーバーへ接続します。DNSは接続先を調べる段階を担当し、ページのHTMLや動画を配信するのはWebサーバーです。

ここで区別したいのが、「ドメイン名」「URL」「IPアドレス」です。URLが「https://www.example.jp/products/index.html」なら、httpsは通信方式、www.example.jpは接続先のホスト名、/products/index.htmlはサーバー内の場所を表します。example.jpが登録されたドメイン名で、wwwはその配下に設けられたホスト名です。IPアドレスは、そのホストへ通信するためにDNSから得られる値です。

一つのドメイン名に複数のIPアドレスが登録される場合も、複数の名前が同じ接続先を指す場合もあります。負荷分散、障害対策、CDNの利用、IPv4とIPv6の併用などがあるため、「ドメイン名とIPアドレスは常に一対一」と覚えるのは正確ではありません。

また、ブラウザへIPアドレスを直接入力しても、目的のサイトが表示されるとは限りません。同じIPアドレス上で複数のサイトを運用しているサーバーは、接続時に示されたホスト名を見て表示内容や証明書を選びます。DNSを使わずIPアドレスだけで接続すると、別ページや証明書エラーになることがあります。

DNSはページを配信する装置ではなく、最初に接続先の情報を案内する仕組みだと分けて考えましょう。

ブラウザにURLを入力してから名前解決はどう進むのか？

利用者がURLを入力すると、端末内のスタブリゾルバーが、あらかじめ設定されたキャッシュDNSサーバーへ問い合わせます。一般家庭では、ルーターや回線事業者からDHCPでDNSサーバーの情報を受け取る構成が一般的です。パブリックDNSを手動設定している場合は、その事業者のサーバーへ問い合わせます。

キャッシュに有効な結果がなければ、キャッシュDNSサーバーはDNSの階層をたどります。JPRS「DNSの仕組みと動作原理」によると、フルリゾルバーはルートヒントを手掛かりにルートサーバーへ問い合わせ、各ゾーンを管理する権威DNSサーバーへ反復問い合わせを行います。

1. 端末がキャッシュDNSサーバーへ「www.example.jpのIPアドレス」を尋ねる
2. キャッシュがなければルートサーバーから「.jp」の問い合わせ先を得る
3. JPのDNSサーバーから「example.jp」の問い合わせ先を得る
4. example.jpの権威DNSサーバーからwwwのAまたはAAAAレコードを得る
5. キャッシュDNSサーバーが結果を端末へ返す
6. ブラウザが得られたIPアドレスへ接続し、HTTPS通信を開始する

ルートサーバーが全ドメインのIPアドレスを保持しているわけではありません。ルートはトップレベルドメインの案内役、JP DNSはJP配下の委任先を示す案内役、対象ドメインの権威DNSサーバーはそのドメインの具体的なレコードを回答する役です。この分担によって、巨大な名前空間を分散管理できます。

同じサイトを続けて開くと、毎回ルートから問い合わせるとは限りません。ブラウザ、OS、ルーター、キャッシュDNSサーバーなどに利用可能な結果が残っていれば再利用されます。JPRS用語辞典の「キャッシュ」では、結果を一時保持することで応答時間、問い合わせ回数、サーバー負荷、ネットワークトラフィックを減らせると説明されています。

名前解決後は、ブラウザがTCPやQUICなどで接続し、HTTPSなら証明書の確認や暗号化通信を行います。「DNSでIPアドレスが返った」ことは接続先情報を得られたという意味であり、Webサーバーの稼働やHTTPSの正常性まで保証するものではありません。

障害を調べるときは、名前解決と、その後のWeb接続を別工程として確認すると原因を絞れます。

ドメイン名・IPアドレス・ネームサーバーはどう違うのか？

ドメイン名は、人や組織がインターネット上の名前として登録・利用する文字列です。IPアドレスは、IP通信で送信先や送信元を識別するためのアドレスです。ネームサーバーは、ドメイン名に関するDNS情報を提供するサーバーを指します。

表中のIPアドレスは文書用として予約された例示値であり、実在サイトの接続先を示すものではありません。IPv4はドット区切りの10進数、IPv6はコロン区切りの16進数で表されます。両者の違いや端末での判定方法は、LUFTMEDIAのIPv4とIPv6の違いとIPv6接続の確認方法でも確認できます。

ドメインを取得しただけでは、Webサイトの接続先は決まりません。ドメイン管理事業者で権威DNSサーバーを指定し、そのDNSサービス上でA、AAAA、CNAMEなどのレコードを登録します。さらにWebサーバー側でも、そのドメインを受け入れる設定が必要です。詳しい接続手順はドメインとは？URL・DNSとの関係と取得後に行う設定を参照してください。

「DNSサーバーを変更する」という表現にも注意が必要です。ドメイン運営者が権威DNSの委任先を変更する操作と、利用者が端末の名前解決先を変更する操作は別物です。前者はサイトやメールの公開情報に影響し、後者は原則として変更した端末やネットワークからの問い合わせ先に影響します。

設定前に、変更対象が「ドメイン側の権威DNS」か「端末側の問い合わせ先」かを確認してください。

A・AAAA・CNAME・MX・TXT・NSレコードは何を示すのか？

DNSにはIPアドレス以外の情報も保存されます。情報の種類を示すものがリソースレコードです。管理画面では、2026年9月28日時点で「DNS設定」「DNSレコード設定」「ゾーン編集」などの名称が使われますが、実際の画面名、入力形式、利用可能なレコードは事業者によって異なります。

AやAAAAを調べる操作は「正引き」です。IPアドレスからPTRレコードを調べる操作は「逆引き」ですが、正引き結果と逆引き結果が常に一対一で一致するとは限りません。また、WebサイトのURLをCNAMEへ直接登録することはできません。CNAMEの値には「https://」や「/path」を付けず、事業者から指定されたホスト名を入力します。

ルートドメインの「example.jp」と「www.example.jp」は別の名前です。wwwだけにレコードを登録しても、ルートドメインが自動的に同じ接続先になるわけではありません。両方を利用する場合は、DNSレコード、Webサーバーのドメイン追加、HTTPS証明書、正規URLへのリダイレクトをそれぞれ確認します。

MXを変更する場合は、Web表示だけでなくメール受信へ影響します。ネームサーバーを一括変更するなら、新しいDNSへ既存のA、AAAA、MX、TXT、CNAMEなどを先に移してから委任先を切り替えます。Web用レコードだけを移すと、サイトは表示できてもメールや所有確認が失敗する可能性があります。

LUFTのnslookupオンライン無料ツールでは、A、AAAA、NS、CNAME、SOA、PTR、MX、TXTを選んで確認できます。管理画面の登録値だけで判断せず、外部からどの値が取得できるかも照合すると設定漏れを見つけやすくなります。

DNSを変更する前に現在の全レコードを控え、Web用だけでなくMXやTXTも移行対象に含めましょう。

権威DNSサーバーとキャッシュDNSサーバーは何を分担するのか？

権威DNSサーバーは、担当するゾーンの情報を正式な回答として提供します。キャッシュDNSサーバーは、端末から依頼を受けてDNS階層を検索し、得た回答を利用者へ返します。JPRSのDNS安全性・安定性に関する解説でも、両者は機能、サービス対象、提供範囲が異なると示されています。

一般利用者がWi-Fiへ接続すると、端末はDHCPやルーター広告などを通じてDNSサーバー情報を受け取ります。端末から見えているDNSサーバーが家庭用ルーターのアドレスでも、ルーターがさらに回線事業者のキャッシュDNSへ問い合わせる場合があります。一方、Google Public DNSなどを端末へ手動指定すると、その接続について問い合わせ先を変更できます。

キャッシュされたレコードにはTTL（Time To Live）があり、その期間内は保存済みの回答を再利用できます。TTLが残っている間は、権威DNS側でレコードを変更しても、一部の利用者に旧情報が返ることがあります。「DNSの反映待ち」と呼ばれる現象の多くは、世界中のデータが同時に複製される待ち時間というより、各所に保存された旧キャッシュが期限を迎えるまでの差です。

一方で、TTLが切れても直らない場合は、単なる待ち時間ではありません。委任先NSの誤り、新旧DNS間のレコード差、ホスト名の入力間違い、サーバー側のドメイン未登録、証明書の未発行などを調べます。設定値を繰り返し変更すると、どの変更が有効だったのか判断しにくくなるため、変更時刻、変更前後の値、確認に使ったDNSサーバーを記録します。

権威DNSとキャッシュDNSは運用上も分離が推奨されています。一般利用者が自宅でDNSサーバーを公開する必要は通常ありません。ルーターのWAN側からDNS問い合わせを受け付ける設定や、外部利用者へ無制限に再帰検索を提供するオープンリゾルバーは、攻撃の踏み台になる危険があります。

「しばらく待つ」だけで終えず、TTL、権威DNSの回答、サーバー設定を分けて記録しましょう。

WindowsとmacOSでDNSの回答をどう確認するのか？

Windowsでは、2026年9月28日時点のWindows 10・11で「コマンド プロンプト」またはPowerShellを開き、nslookupを利用できます。スタートメニューの検索欄へ「コマンド プロンプト」と入力して起動し、次を実行します。

nslookup example.jp
nslookup -type=AAAA example.jp
nslookup -type=MX example.jp
nslookup -type=NS example.jp

Microsoft Learnのnslookup公式資料によると、問い合わせ先を省略した非対話モードでは既定のDNSサーバーが使われ、第2引数にDNSサーバーを指定できます。既定の結果と特定サーバーの結果を比べる場合は、管理対象ではない例示ドメインを置き換えて次のように実行します。

nslookup example.jp
nslookup example.jp 8.8.8.8

出力の「Server」または「サーバー」は問い合わせ先で、「Address」欄のうち回答部分が対象名に対応する値です。「Non-authoritative answer」は異常を意味するとは限らず、キャッシュDNSサーバーから得た回答であることを示します。「Nonexistent domain」は名前が存在しない、「timed out」は時間内に応答がなかった、「No records」は名前は存在しても指定種類のレコードがない状態を示します。

macOSでは、2026年9月28日時点で「Finder」→「アプリケーション」→「ユーティリティ」→「ターミナル」を開き、digを利用できます。

dig example.jp A
dig example.jp AAAA
dig example.jp MX
dig example.jp NS

digの「ANSWER SECTION」に回答が表示されます。「status: NXDOMAIN」なら対象名が存在しないという回答、「status: NOERROR」でANSWERが0件なら、名前は存在しても指定種類の回答がない可能性があります。「SERVER」では実際に問い合わせたDNSサーバーも確認できます。iPhoneやAndroidにはWindowsのnslookupやmacOSのdigに相当する標準画面がないため、同じWi-Fiに接続したPCで確認するか、信頼できる管理用ツールを使います。

結果のIPアドレスがサーバー事業者の指定値と異なれば、DNSレコード、CNAMEの接続先、参照中のキャッシュを調べます。IPアドレスが正しいのにサイトを表示できなければ、Webサーバーのドメイン設定、公開先、ファイアウォール、HTTPS証明書を確認します。なお、複数IPを返す構成では、回答順が毎回同じとは限りません。

確認結果には、実行時刻、問い合わせた名前、レコード種類、使用したDNSサーバーを一緒に残してください。

Windows・Mac・AndroidでDNSサーバーを変更するには？

DNSサーバーの変更は、名前解決の問い合わせ先を切り替える操作です。通信回線そのものやWebサイトの権威DNSを変更する操作ではありません。作業前に現在の設定を記録し、会社・学校の端末では管理者の指示を優先してください。社内名、接続制限、ペアレンタルコントロール、VPNの名前解決が使えなくなる場合があります。

2026年9月28日時点のWindows 11では、一般に「設定」→「ネットワークとインターネット」→使用中の「Wi-Fi」または「イーサネット」→「DNS サーバーの割り当て」の「編集」と進みます。「手動」を選ぶ場合はIPv4またはIPv6を有効にし、優先DNSと代替DNSを入力して保存します。機種、管理ポリシー、Windowsの更新状態によって表示名や配置が異なる場合は、ネットワークアダプターのプロパティから「インターネット プロトコル バージョン4（TCP/IPv4）」または「バージョン6（TCP/IPv6）」を開きます。

macOSでは、2026年9月28日時点で「Appleメニュー」→「システム設定」→「ネットワーク」→利用中の接続→「詳細」→「DNS」と進み、DNSサーバーを追加します。macOSの版によっては「システム環境設定」→「ネットワーク」→接続→「詳細」→「DNS」と表示されます。保存後、対象接続をいったん切断・再接続して確認します。

Android 9以降の「プライベートDNS」は、通常のDNSサーバーIPではなく、DNS-over-TLS対応事業者が指定するプロバイダーのホスト名を入力する方式です。2026年9月28日時点の一般的な順路は「設定」→「ネットワークとインターネット」または「接続」→「プライベートDNS」ですが、端末メーカーにより名称が異なります。Google Public DNSを利用する場合のホスト名は「dns.google」です。Google Public DNSの公式設定資料では、Android 9以降の順路、Windows・macOS・Linuxなどの一般的な設定方法、変更前の値を控える注意点が示されています。

iPhoneやiPadでWi-Fiごとに変更する場合は、2026年9月28日時点で「設定」→「Wi-Fi」→接続中SSIDの情報ボタン→「DNSを構成」と進みます。モバイル回線を含む端末全体の暗号化DNSは、対応アプリや構成プロファイルによって提供される場合があるため、Appleおよび提供事業者の対象OS向け説明を確認してください。

ルーターで変更すると家庭内の複数端末へ配布できますが、画面名はメーカーごとに異なります。「インターネット」「WAN」「DHCPサーバー」「DNSサーバー」などを探し、型番とファームウェア版に一致する公式マニュアルを確認します。IPv4だけを変更してもIPv6側で別のDNSが配布される場合があるため、変更後は「ipconfig /all」や「dig」のSERVER欄で実際の問い合わせ先を確かめます。

変更後に接続できなければ、記録した「自動取得」または元のアドレスへ戻します。VPN、セキュリティソフト、ブラウザのセキュアDNS機能がOS設定を上書きする場合もあるため、期待したサーバーへ問い合わせていないときは、それらを一つずつ確認します。

DNS変更後はWeb表示だけで判断せず、実際の問い合わせ先と元へ戻せることまで確認しましょう。

DNSエラーや変更後の未反映をどう切り分けるのか？

最初に、影響範囲を確認します。「一つのサイトだけか」「すべてのサイトか」「自分の端末だけか」「同じWi-Fiの全端末か」「Webだけか、メールも止まったか」を分けます。Wi-Fiでは失敗してモバイル回線では成功するなら、端末よりルーター、回線、利用中DNSの影響を疑えます。複数回線で同じドメインだけ失敗するなら、対象ドメインのDNSやサーバー側を優先して調べます。

WindowsでローカルDNSキャッシュを消去する場合は、2026年9月28日時点で管理者として「コマンド プロンプト」またはPowerShellを開き、次を実行します。

ipconfig /flushdns

ただし、端末のキャッシュを消しても、キャッシュDNSサーバーに旧回答が残っていれば結果は変わりません。先に既定DNSと別のDNSへnslookupを実行し、回答差があるか調べる方が切り分けに役立ちます。macOSのキャッシュ操作はOSバージョンによってコマンドや挙動が異なるため、まずネットワーク再接続とブラウザ再起動を試し、対象バージョンのApple公式情報を確認します。

「DNS_PROBE_FINISHED_NXDOMAIN」のようなブラウザ表示だけで、原因を断定しないことも重要です。存在しない名前、検索サフィックス、VPN、フィルタリング、DNSSEC検証失敗、一時的な権威DNS障害などでも名前解決は失敗します。設定変更直後なら、権威DNSへ直接問い合わせた結果、複数のキャッシュDNSの結果、登録したTTLを比較します。

DNSSECはDNS応答が正しい発信元から来たことや途中で改変されていないことを検証する仕組みですが、通信内容そのものを暗号化する機能ではありません。端末とキャッシュDNS間の盗み見を抑えるDNS-over-HTTPSやDNS-over-TLSとは役割が異なります。また、暗号化DNSを使っても、接続先サービス、端末、ブラウザ、VPNなどに関するすべてのプライバシー問題が解消するわけではありません。

復旧できない場合は、ドメイン名、発生時刻、利用回線、端末とOS、Wi-Fiか有線か、nslookupまたはdigの全文、変更前後のレコード、利用中のDNSサーバー、Webとメールの影響範囲をまとめて問い合わせます。レコードを連続して上書きするより、観測結果を残した方が管理事業者やサーバー会社が原因を判断しやすくなります。

参照した公式情報

• ICANN「The Domain Name System」
• JPRS「DNSの仕組みと動作原理」
• JPRS「DNSの安全性・安定性向上のためのキホン」
• JPRS用語辞典「キャッシュ」
• Microsoft Learn「nslookup」
• Google for Developers「Public DNSを使い始める」

不具合時は影響範囲を確認し、名前解決、Web接続、メール、HTTPSの順に工程を分けて調べましょう。