DNSサーバーとは、ドメイン名とIPアドレスを結びつけるためのサーバーです。
私たちがWebサイトを見るときは、ブラウザに次のようなURLを入力します。
https://example.com
しかし、インターネット上のコンピューター同士は、「example.com」という文字列だけで通信しているわけではありません。
実際の通信では、接続先を識別するためにIPアドレスが使われます。
たとえば、IPアドレスには次のような形式があります。
192.0.2.1
このような数字の並びをWebサイトごとに覚えるのは大変です。
そこで、人間が覚えやすい「ドメイン名」と、コンピューターが通信に使う「IPアドレス」を対応させる仕組みとしてDNSが使われます。
DNSサーバーは、簡単にいうとインターネット上の住所録のような役割を持っています。
DNSサーバーの代表的な役割は、ドメイン名をIPアドレスに変換することです。
この変換処理を「名前解決」といいます。
たとえば、ユーザーがブラウザで「example.com」にアクセスしようとした場合、端末はDNSサーバーに対して次のような問い合わせを行います。
example.comの接続先を教えてください
DNSサーバーは、その問い合わせに対して、対応するIPアドレスを返します。
その後、ブラウザは取得したIPアドレスを使ってWebサーバーへ接続し、ページを表示します。
IPアドレスは、数字や記号で構成されています。
IPv4アドレスは、次のような形式です。
192.0.2.1
IPv6アドレスは、さらに長い形式になります。
2001:db8::1
このようなIPアドレスをユーザーが毎回入力するのは現実的ではありません。
一方で、ドメイン名であれば、
example.com
example.jp
example.co.jp
のように、比較的覚えやすくなります。
DNSサーバーは、人間にとって扱いやすいドメイン名と、コンピューターが通信に使うIPアドレスを橋渡しする存在です。
DNSがあることで、Webサイトのサーバーを変更した場合でも、同じドメイン名を使い続けることができます。
たとえば、サーバー移転によって接続先のIPアドレスが変わった場合でも、DNSの設定を変更すれば、ユーザーは今まで通り同じドメイン名でアクセスできます。
変更前:example.com → 古いサーバーのIPアドレス
変更後:example.com → 新しいサーバーのIPアドレス
ユーザー側は、接続先のIPアドレスが変わったことを意識する必要がありません。
このようにDNSは、Webサイトや各種サービスを安定して運用するためにも重要な仕組みです。
DNSは、Webサイトの表示だけでなく、メールの送受信にも使われます。
メールを送るとき、送信側のメールサーバーは、宛先メールアドレスのドメインを確認します。
たとえば、次のメールアドレスへ送信する場合を考えます。
user@example.com
この場合、送信側のメールサーバーは「example.com」のDNS情報を調べ、どのメールサーバーへ届ければよいかを確認します。
このとき使われるのが、MXレコードと呼ばれるDNSレコードです。
DNS設定が正しくないと、メールが届かなかったり、送受信に問題が起きたりすることがあります。
まず、ユーザーがブラウザにURLを入力します。
https://example.com
この時点では、ブラウザは「example.com」の接続先IPアドレスをまだ知りません。
そこで、端末はDNSを使って、ドメイン名に対応するIPアドレスを調べます。
最初に確認されるのは、端末やブラウザに保存されているDNS情報です。
過去に同じドメインへアクセスしたことがある場合、その情報が一時的に保存されていることがあります。
この一時保存された情報を「DNSキャッシュ」といいます。
キャッシュに有効な情報が残っていれば、DNSサーバーへ新たに問い合わせる前に、その情報を使って接続できます。
これにより、名前解決にかかる時間を短縮できます。
端末やブラウザのキャッシュに情報がない場合、次にDNSリゾルバーへ問い合わせます。
DNSリゾルバーとは、ユーザーの代わりにDNS情報を調べてくれるサーバーです。
一般的には、インターネット回線事業者が提供するDNSリゾルバーが使われます。
また、Google Public DNS、Cloudflareの1.1.1.1、Quad9などのパブリックDNSを利用することもあります。
DNSリゾルバーは、問い合わせられたドメインの情報をすでにキャッシュしていれば、その情報をすぐに返します。
キャッシュがない場合は、他のDNSサーバーへ順番に問い合わせて、必要な情報を探します。
DNSリゾルバーが情報を持っていない場合、まずルートDNSサーバーへ問い合わせます。
ルートDNSサーバーは、DNS階層の最上位にあるサーバーです。
ただし、ルートDNSサーバーがすべてのドメインのIPアドレスを管理しているわけではありません。
ルートDNSサーバーは、次に問い合わせるべきTLD DNSサーバーの情報を返します。
たとえば「example.com」であれば、次のような案内をします。
.comを管理しているDNSサーバーに問い合わせてください
次に、DNSリゾルバーはTLD DNSサーバーへ問い合わせます。
TLDとは「Top Level Domain」の略で、ドメイン名の最後にある部分を指します。
たとえば、次のようなものがTLDです。
.com
.jp
.net
.org
「example.com」であれば「.com」がTLDです。
「example.jp」であれば「.jp」がTLDです。
なお、「.co.jp」は厳密にはTLDではありません。
「.jp」の下にある属性型JPドメインの一種です。
TLD DNSサーバーは、対象ドメインのIPアドレスそのものではなく、そのドメインを管理している権威DNSサーバーの情報を返します。
最後に、DNSリゾルバーは対象ドメインの権威DNSサーバーへ問い合わせます。
権威DNSサーバーとは、そのドメインに関する正式なDNS情報を管理しているサーバーです。
たとえば「example.com」の権威DNSサーバーには、次のような情報が登録されています。
example.comの接続先IPアドレス
www.example.comの接続先
メールサーバーの情報
ドメイン確認用の情報
DNSリゾルバーは、権威DNSサーバーから必要な情報を受け取ります。
DNSリゾルバーは、取得したIPアドレスをユーザーの端末へ返します。
その後、ブラウザはそのIPアドレスを使ってWebサーバーへ接続します。
WebサーバーからHTML、CSS、画像、JavaScriptなどのデータを受け取り、ブラウザ上にページが表示されます。
DNSリゾルバーは、ユーザーの端末から問い合わせを受け取り、必要なDNS情報を探して返すサーバーです。
「再帰リゾルバー」や「キャッシュDNSサーバー」と呼ばれることもあります。
DNSリゾルバーの主な役割は、次の通りです。
| 役割 | 内容 |
|---|---|
| 問い合わせの受付 | ユーザー端末からDNS問い合わせを受け取る |
| 情報の探索 | 必要に応じて他のDNSサーバーへ問い合わせる |
| キャッシュ | 一度取得したDNS情報を一定期間保存する |
| 応答 | 取得したDNS情報をユーザー端末へ返す |
DNSリゾルバーは、ユーザーにとって最も身近なDNSサーバーです。
ルートDNSサーバーは、DNS階層の最上位にあるサーバーです。
DNSの問い合わせにおいて、目的の情報を探すための出発点になる存在です。
ただし、ルートDNSサーバーがすべてのドメイン情報を持っているわけではありません。
ルートDNSサーバーの役割は、対象のTLDを管理しているDNSサーバーを案内することです。
たとえば「example.com」について問い合わせがあった場合、ルートDNSサーバーは「.comを管理しているTLD DNSサーバーはこちらです」という情報を返します。
TLD DNSサーバーは、トップレベルドメインを管理するDNSサーバーです。
トップレベルドメインとは、ドメイン名の最後にある部分です。
example.com → .com
example.jp → .jp
TLD DNSサーバーは、そのTLDに属するドメインについて、どの権威DNSサーバーが情報を持っているかを案内します。
たとえば「example.com」の場合、.comのTLD DNSサーバーが「example.comを管理している権威DNSサーバー」を教えてくれます。
権威DNSサーバーは、特定のドメインに関する正式なDNS情報を管理するサーバーです。
ドメイン所有者や管理者が設定したDNSレコードは、権威DNSサーバーで管理されます。
権威DNSサーバーには、たとえば次のような情報が登録されます。
ドメイン名に対応するIPアドレス
サブドメインの接続先
メールサーバーの情報
認証用のテキスト情報
DNSリゾルバーが最終的に問い合わせる先が、この権威DNSサーバーです。
DNSレコードとは、DNSサーバーに登録されている設定情報のことです。
DNSサーバーは、DNSレコードをもとに、ドメイン名とIPアドレスの対応関係や、メールサーバーの情報などを返します。
代表的なDNSレコードには、次のようなものがあります。
Aレコード
AAAAレコード
CNAMEレコード
MXレコード
TXTレコード
NSレコード
それぞれ役割が異なるため、Webサイトやメールを正しく運用するには、基本的な違いを理解しておくことが大切です。
Aレコードは、ドメイン名をIPv4アドレスに紐づけるレコードです。
たとえば、次のような形で設定します。
example.com → 192.0.2.1
Webサイトを表示するために使われる代表的なDNSレコードです。
サーバー移転などでWebサイトの接続先IPアドレスが変わる場合、このAレコードを変更することがあります。
AAAAレコードは、ドメイン名をIPv6アドレスに紐づけるレコードです。
たとえば、次のような形で設定します。
example.com → 2001:db8::1
AレコードがIPv4用、AAAAレコードがIPv6用と考えるとわかりやすいです。
IPv6に対応したサーバーを利用する場合に使われます。
CNAMEレコードは、あるドメイン名を別のドメイン名に紐づけるレコードです。
たとえば、次のような設定です。
www.example.com → example.com
CNAMEは、別名を設定するようなイメージです。
ただし、CNAMEの参照先には、IPアドレスではなくドメイン名を指定します。
また、CNAMEを設定した同じ名前に、AレコードやMXレコード、TXTレコードなどを同時に設定できない場合があります。
そのため、他のDNSレコードと組み合わせるときは注意が必要です。
MXレコードは、メールサーバーを指定するためのレコードです。
メールを送信する側のサーバーは、宛先メールアドレスのドメインを見て、そのドメインのMXレコードを確認します。
たとえば、次のメールアドレスへ送る場合を考えます。
user@example.com
この場合、送信側のメールサーバーは「example.com」のMXレコードを調べます。
そして、MXレコードに指定されたメールサーバーへメールを配送します。
MXレコードが正しく設定されていないと、メールを受信できない原因になります。
TXTレコードは、テキスト情報を登録するためのDNSレコードです。
もともとは自由なテキスト情報を登録するためのレコードですが、現在では認証や確認のために使われることが多くあります。
代表的な用途は次の通りです。
| 用途 | 内容 |
|---|---|
| SPF | そのドメインからメール送信してよいサーバーを示す |
| DKIM | メールに電子署名を付け、改ざんを検証する |
| DMARC | SPFやDKIMの結果をもとに、受信側の処理方針を示す |
| ドメイン所有確認 | 外部サービスでドメインの管理者であることを確認する |
| サービス連携 | メール配信サービスやクラウドサービスなどの認証に使う |
TXTレコードは、メール関連の設定や外部サービスとの連携でよく使われます。
値を間違えると認証に失敗することがあるため、設定時には正確に入力する必要があります。
NSレコードは、そのドメインを管理するDNSサーバーを指定するレコードです。
たとえば、次のような情報を示します。
example.comのDNS情報は、ns1.example-dns.comが管理する
ドメインを取得した後、どのDNSサーバーでDNSレコードを管理するかを指定するときに重要です。
レンタルサーバーのDNSを使う場合や、外部のDNS管理サービスを使う場合には、NSレコードやネームサーバー設定を確認する必要があります。
DNSキャッシュとは、一度取得したDNS情報を一定期間保存しておく仕組みです。
毎回すべてのDNSサーバーへ問い合わせていると、名前解決に時間がかかります。
また、DNSサーバーへの負荷も大きくなります。
そこで、DNSリゾルバーや端末、ブラウザなどは、取得したDNS情報を一時的に保存します。
次に同じドメインへアクセスするときは、保存された情報を使うことで、より早く接続先を判断できます。
TTLとは「Time To Live」の略で、DNS情報をキャッシュしてよい時間を示す値です。
たとえば、TTLが3600秒に設定されている場合、そのDNS情報は最大で1時間キャッシュされます。
TTL 3600秒 = 1時間
TTLが長いと、DNS問い合わせの回数を減らせるため、負荷を抑えやすくなります。
一方で、DNS設定を変更したときに、古い情報が長く残りやすくなります。
TTLが短いと、DNS変更後に新しい情報へ切り替わりやすくなります。
ただし、DNS問い合わせの回数は増えやすくなります。
DNS設定を変更しても、すぐにすべての環境で新しい情報が使われるとは限りません。
一般的には「DNSが反映される」と表現されることがありますが、実際には世界中のDNSサーバーへ一斉に情報が配信されるわけではありません。
多くの場合、古いDNS情報を保持しているキャッシュが残っているため、環境によって見え方に差が出ます。
たとえば、サーバー移転直後には次のようなことが起こる場合があります。
あるユーザーには新しいサイトが表示される
別のユーザーには古いサイトが表示される
自分のPCでは見えるが、スマートフォンでは見えない
会社のネットワークでは古い接続先を見に行ってしまう
これはDNSの仕組み上、珍しいことではありません。
サーバー移転やDNS変更を予定している場合は、切り替え直前ではなく、事前にTTLを短くしておくと影響を抑えやすくなります。
ユーザーがWebサイトへアクセスするとき、ブラウザはまず接続先のIPアドレスを知る必要があります。
DNS設定が正しく行われていれば、ドメイン名から正しいIPアドレスを取得できます。
その結果、ブラウザは目的のWebサーバーへ接続し、Webページを表示できます。
DNS設定に誤りがあると、Webサイトが正常に表示されないことがあります。
代表的なトラブルは次の通りです。
Webサイトが表示されない
別のサーバーに接続される
古いサイトが表示される
SSL証明書のエラーが出る
サブドメインが使えない
メールが届かない
たとえば、Aレコードに間違ったIPアドレスを設定すると、目的のWebサーバーへ接続できません。
また、CNAMEレコードの向き先を誤ると、サブドメインが正しく機能しない場合があります。
SSL証明書の対象ドメインとDNS設定が合っていない場合、ブラウザに警告が表示されることもあります。
DNSがなければ、ユーザーは接続先をIPアドレスなどで直接指定する必要があります。
ただし、現在のWebサイトでは、IPアドレスを直接入力しても目的のサイトが正しく表示されるとは限りません。
理由は、同じIPアドレス上で複数のWebサイトを運用していたり、HTTPSやCDNを利用していたりするためです。
そのため、現在のWebサイト運用では、DNSによって正しいドメイン名と接続先を紐づけることが非常に重要です。
DNSは、メールの送受信にも深く関係しています。
メールを送信するとき、送信側のメールサーバーは、宛先メールアドレスのドメインを確認します。
たとえば、次のメールアドレスへ送る場合です。
user@example.com
この場合、送信側は「example.com」のMXレコードをDNSで調べます。
MXレコードには、そのドメイン宛てのメールを受け取るメールサーバーが指定されています。
MXレコードが正しく設定されていないと、メールを受信できない原因になります。
DNSは、メールのなりすまし対策にも使われます。
代表的な設定には、SPF、DKIM、DMARCがあります。
| 種類 | 役割 |
|---|---|
| SPF | そのドメインからメール送信してよいサーバーを示す |
| DKIM | メールに電子署名を付け、改ざんを検証する |
| DMARC | SPFやDKIMの認証結果をもとに、受信側の処理方針を示す |
これらの設定は、多くの場合TXTレコードとしてDNSに登録します。
会社のメール、問い合わせフォームの自動返信、メールマガジン、各種通知メールなどを運用する場合、DNSのメール関連設定はとても重要です。
設定が不十分だと、メールが迷惑メールとして扱われたり、なりすましメールへの対策が弱くなったりする可能性があります。
CDNとは、Webサイトのデータを複数の配信拠点から届けることで、表示速度や安定性を高める仕組みです。
代表的なCDNサービスには、Cloudflare、Akamai、Fastly、Amazon CloudFrontなどがあります。
CDNを導入するときは、DNSでドメインやサブドメインをCDN側へ向ける設定を行うことがあります。
たとえば、次のような設定です。
www.example.com → CDNサービスが指定する接続先
CDNサービスによっては、AレコードではなくCNAMEレコードを設定する場合があります。
CDN導入時のDNS設定を間違えると、次のような問題が起こることがあります。
CDNが有効にならない
サイトが表示されない
SSL証明書のエラーが出る
wwwあり・なしの片方だけ表示されない
古いサーバーへ接続される
CDNはWebサイトの表示速度や安定性を高めるために役立ちますが、DNS設定との関係が深いため、導入時には慎重に確認する必要があります。
DNSサーバーに障害が起きると、Webサーバー自体が正常に動いていても、サイトにアクセスできなくなることがあります。
これは、建物は存在しているのに、住所を調べられない状態に近いです。
ユーザーのブラウザがドメイン名からIPアドレスを取得できなければ、目的のWebサーバーへ接続できません。
DNS障害は、Webサイトだけでなくメールや外部サービス連携にも影響します。
たとえば、次のようなトラブルが起こる可能性があります。
Webサイトが表示されない
メールが届かない
サブドメインが使えない
API連携が失敗する
CDNが機能しない
ドメイン認証に失敗する
そのため、重要なWebサイトやメールを運用する場合は、信頼性の高いDNSサービスを利用することが大切です。
また、複数のネームサーバーを用意して、障害時の影響を抑える構成にすることも一般的です。
Aレコードに誤ったIPアドレスを設定すると、Webサイトが正しく表示されません。
サーバー移転時に特に起こりやすいミスです。
新しいサーバーのIPアドレスを正しく設定したか、設定後に実際の表示確認を行うことが重要です。
CNAMEレコードでは、参照先のドメイン名を正しく指定する必要があります。
指定先が存在しない場合や、サービス側が求めている値と違う場合、サブドメインが正常に動作しません。
また、CNAMEの参照先にはIPアドレスではなく、ドメイン名を指定する点にも注意が必要です。
メールを使う場合、MXレコードの設定は非常に重要です。
Google WorkspaceやMicrosoft 365などのメールサービスを利用する場合、サービス側が指定するMXレコードを正しく設定する必要があります。
MXレコードを削除したり、誤った値に変更したりすると、メールを受信できなくなる可能性があります。
TXTレコードは、ドメイン所有確認やメール認証などでよく使われます。
値の一部が抜けていたり、余計な記号が入っていたりすると、認証に失敗することがあります。
特にSPF、DKIM、DMARCの設定では、記述内容の間違いがメールの受信状況やなりすまし対策に影響する場合があります。
DNS設定を変更しても、キャッシュの影響ですぐに新しい情報が使われるとは限りません。
サーバー移転やDNS切り替えを行う場合は、事前にTTLを短くしておくと、切り替え時の混乱を抑えやすくなります。
ただし、すでに古い情報が長いTTLでキャッシュされている場合、その期限が切れるまでは古い接続先が使われることもあります。
Webサイトを別のレンタルサーバーへ移す場合、DNS設定を変更することがあります。
たとえば、Aレコードを新しいサーバーのIPアドレスへ変更したり、ネームサーバー自体を新しいサーバー会社のものへ変更したりします。
このとき設定を間違えると、Webサイトが表示されなくなる可能性があるため注意が必要です。
メールサービスを変更するときも、DNS設定が必要になることがあります。
たとえば、Google WorkspaceやMicrosoft 365などを利用する場合、指定されたMXレコードを設定します。
また、SPF、DKIM、DMARCなどのTXTレコードを設定することで、メールの信頼性を高めることもあります。
CDNを導入する場合、ドメインやサブドメインをCDN側へ向けるDNS設定を行うことがあります。
サービスによって設定内容は異なりますが、CNAMEレコードやAレコードを変更するケースが一般的です。
CDNの設定とDNS設定が一致していないと、サイトが正しく表示されないことがあります。
ドメイン管理会社やDNS管理サービスを変更するときも、DNSサーバーの設定が関係します。
たとえば、これまでドメイン取得サービス側でDNSを管理していたものを、別のDNS管理サービスへ移す場合があります。
このときは、Aレコード、MXレコード、TXTレコードなどの既存設定を漏れなく移行する必要があります。
特にメール関連のDNSレコードを移し忘れると、メールが届かなくなることがあるため注意が必要です。
DNS情報は、コマンドを使って確認できます。
WindowsやmacOSでよく使われるのが、nslookupです。
nslookup example.com
このコマンドを使うと、指定したドメインのDNS情報を確認できます。
メールサーバーの情報を確認したい場合は、MXレコードを指定して調べることもできます。
nslookup -type=mx example.com
LinuxやmacOSでは、digコマンドもよく使われます。
dig example.com
特定のDNSレコードを確認したい場合は、次のように指定します。
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS
digは表示される情報が詳しいため、DNS設定の確認やトラブル調査でよく使われます。
コマンド操作に慣れていない場合は、オンラインのDNS確認ツールを使う方法もあります。
オンラインツールでは、ドメイン名を入力するだけで、Aレコード、MXレコード、TXTレコード、NSレコードなどを確認できるものがあります。
また、複数地域からDNS情報を確認できるツールもあります。
DNS変更後に、環境によって表示が違う場合は、こうしたツールを使うと状況を把握しやすくなります。
DNSの基本は、ドメイン名とIPアドレスを対応させることです。
ユーザーは覚えやすいドメイン名を使い、コンピューターはIPアドレスを使って通信します。
DNSサーバーは、この2つをつなぐ役割を担っています。
DNSサーバーには、DNSリゾルバー、ルートDNSサーバー、TLD DNSサーバー、権威DNSサーバーなどがあります。
それぞれのサーバーが役割を分担することで、世界中の膨大なドメイン情報を効率的に管理しています。
DNSレコードには、Aレコード、AAAAレコード、CNAMEレコード、MXレコード、TXTレコード、NSレコードなどがあります。
Webサイトの接続先を指定するもの、メールサーバーを指定するもの、認証に使うものなど、種類によって役割が異なります。
DNS設定を行うときは、どのレコードが何のために使われるのかを理解することが大切です。
DNSにはキャッシュの仕組みがあります。
一度取得したDNS情報は、一定期間保存されることがあります。
その保存期間を決めるのがTTLです。
DNS設定を変更してもすぐにすべての環境で新しい情報が使われるとは限らないため、サーバー移転や設定変更の際はTTLを考慮する必要があります。
DNSサーバーとは、ドメイン名とIPアドレスを結びつけるためのサーバーです。
私たちが「example.com」のような覚えやすいドメイン名でWebサイトにアクセスできるのは、DNSサーバーが裏側で接続先のIPアドレスを調べてくれているからです。
DNSサーバーには、ユーザーの問い合わせを受けるDNSリゾルバー、DNS階層の最上位にあるルートDNSサーバー、トップレベルドメインを管理するTLD DNSサーバー、ドメインの正式な情報を管理する権威DNSサーバーなどがあります。
また、DNSではAレコード、AAAAレコード、CNAMEレコード、MXレコード、TXTレコード、NSレコードなどのDNSレコードを使って、Webサイトの接続先やメールサーバーの情報を管理します。
DNS設定に誤りがあると、Webサイトが表示されない、メールが届かない、SSL証明書のエラーが出る、サブドメインが使えないといった問題が起こることがあります。
そのため、DNSサーバーは普段あまり意識されない存在でありながら、Webサイトやメール、各種インターネットサービスを支える非常に重要な仕組みだといえます。
以上、DNSサーバーの役割についてでした。
最後までお読みいただき、ありがとうございました。