DNSリゾルバとはなんなのかについて

Webサイトを見るとき、私たちは普段、

https://www.example.com

のようなURLを入力します。

しかし、インターネット上のコンピューター同士は、基本的に example.com のようなドメイン名ではなく、IPアドレスを使って通信しています。

たとえば、Webサーバーには次のようなIPアドレスが割り当てられています。

203.0.113.10

つまり、ブラウザがWebサイトにアクセスするためには、

www.example.com は、どのIPアドレスに対応しているのか？

を調べる必要があります。

このように、ドメイン名に対応する情報を調べる仕組みが DNS です。

そして、そのDNS問い合わせをユーザーやアプリケーションの代わりに行ってくれる仕組みが DNSリゾルバ です。

DNSリゾルバとは

DNSリゾルバとは、ユーザーの端末やアプリケーションからDNS問い合わせを受け取り、必要に応じて他のDNSサーバーへ問い合わせながら、目的のDNSレコードを取得して返す仕組みです。

Webサイトにアクセスする場面では、主に Aレコード や AAAAレコード を取得し、ドメイン名に対応するIPアドレスを調べます。

簡単にいうと、DNSリゾルバは、

ドメイン名から必要なDNS情報を調べてくれる案内役

です。

たとえば、ユーザーがブラウザに

www.example.com

と入力した場合、ブラウザやOSはDNSリゾルバに対して、

www.example.com のIPアドレスを教えてください

と問い合わせます。

DNSリゾルバは、その情報を持っていればすぐに返します。

持っていなければ、ルートDNSサーバー、TLDのDNSサーバー、権威DNSサーバーなどへ順番に問い合わせ、最終的に必要なDNS情報を取得します。

DNSリゾルバを一言でいうと

DNSリゾルバは、ドメイン名に対応する情報を調べるための「調査係」のような存在です。

人間にとっては、

google.com
example.com
openai.com

のようなドメイン名のほうが覚えやすいです。

しかし、コンピューターが通信するときには、多くの場合IPアドレスが必要です。

そこでDNSリゾルバが、ドメイン名とIPアドレスなどの対応関係を調べてくれます。

イメージとしては、次のようになります。

ユーザー：example.com を見たい
↓
ブラウザ：example.com のIPアドレスが必要
↓
DNSリゾルバ：DNS情報を調べる
↓
ブラウザ：取得したIPアドレスへ接続する

DNSリゾルバが必要な理由

DNSリゾルバが必要な理由は、インターネット上の通信では、ドメイン名だけでは目的のサーバーに接続できないためです。

たとえば、ユーザーはWebサイトにアクセスするときに、

example.com

と入力します。

しかし、実際に通信するためには、そのドメイン名に対応するIPアドレスが必要です。

もしDNSがなければ、ユーザーはWebサイトにアクセスするたびに、IPアドレスを直接入力しなければなりません。

203.0.113.10

のような数字を大量に覚えるのは現実的ではありません。

そこで、ドメイン名を使いやすい住所のように扱い、その裏側でDNSリゾルバが必要な情報を調べる仕組みになっています。

DNSリゾルバの主な役割

DNSリゾルバには、主に次の役割があります。

ドメイン名に対応するDNSレコードを調べる

DNSリゾルバの基本的な役割は、ドメイン名に対応するDNSレコードを調べることです。

Webサイトへのアクセスでは、特に次のレコードがよく使われます。

レコード	内容
Aレコード	ドメイン名をIPv4アドレスに対応させる
AAAAレコード	ドメイン名をIPv6アドレスに対応させる

たとえば、ブラウザが www.example.com にアクセスする場合、DNSリゾルバはAレコードやAAAAレコードを問い合わせ、対応するIPアドレスを取得します。

ただし、DNSリゾルバが扱うのはIPアドレスだけではありません。

DNSには、メールサーバーを指定するMXレコードや、SPF・DKIM・DMARCなどで使われるTXTレコード、ネームサーバーを指定するNSレコードなどもあります。

つまり、DNSリゾルバは正確には、

ドメイン名をIPアドレスに変換するだけの仕組み

ではなく、

ドメイン名に対応するDNSレコードを調べる仕組み

と理解するとよいです。

ユーザーの代わりにDNS問い合わせを行う

DNSの仕組みは階層構造になっています。

代表的なDNSサーバーには、次のようなものがあります。

種類	役割
ルートDNSサーバー	DNS階層の最上位にあるサーバー群
TLDの権威DNSサーバー	.com や .jp などのTLDを管理するサーバー
権威DNSサーバー	特定のドメインやゾーンの正式なDNS情報を持つサーバー

ユーザーの端末が、これらすべてに直接問い合わせるわけではありません。

多くの場合、ユーザーの端末はまずDNSリゾルバに問い合わせます。

その後、DNSリゾルバが必要に応じて複数のDNSサーバーに問い合わせ、最終的な答えを取得します。

つまり、DNSリゾルバは、ユーザーの代わりにDNS情報を探しに行く役割を持っています。

DNSの問い合わせ結果をキャッシュする

DNSリゾルバは、一度取得したDNS情報を一定時間保存します。

これを キャッシュ といいます。

たとえば、あるDNSリゾルバが一度、

www.example.com のAレコード

を取得したとします。

その後、別のユーザーが同じDNSリゾルバに対して www.example.com を問い合わせた場合、DNSリゾルバは毎回ルートDNSサーバーから順に問い合わせる必要はありません。

保存していたキャッシュを使って、すばやく答えを返すことができます。

DNSリゾルバがキャッシュを持つことで、次のようなメリットがあります。

メリット	内容
名前解決が速くなる	毎回すべてのDNSサーバーに問い合わせる必要がなくなる
DNSサーバーの負荷が減る	同じ問い合わせの繰り返しを減らせる
ネットワーク通信量が減る	不要なDNS通信を抑えられる

このキャッシュ機能は、Web表示速度やインターネット全体の安定性にも関係しています。

DNSリゾルバの動作の流れ

ここでは、ユーザーがブラウザで

www.example.com

にアクセスする場合を例に、DNSリゾルバの動作を見ていきます。

大まかな流れは次の通りです。

1. ユーザーがブラウザに www.example.com と入力する
2. ブラウザやOSがDNSリゾルバに問い合わせる
3. DNSリゾルバがキャッシュを確認する
4. キャッシュがあれば、その情報を返す
5. キャッシュがなければ、DNS階層をたどって問い合わせる
6. 権威DNSサーバーからDNSレコードを取得する
7. DNSリゾルバがブラウザやOSに結果を返す
8. ブラウザが取得したIPアドレスのサーバーへ接続する

図にすると、次のようなイメージです。

ユーザー
  ↓
ブラウザ / OS
  ↓
DNSリゾルバ
  ↓
ルートDNSサーバー
  ↓
TLDの権威DNSサーバー
  ↓
対象ドメインの権威DNSサーバー
  ↓
DNSリゾルバ
  ↓
ブラウザ / OS
  ↓
Webサーバーへ接続

DNSリゾルバは、ユーザー側から見ると「1回問い合わせれば答えを返してくれる存在」です。

しかし裏側では、複数のDNSサーバーに問い合わせて情報を探している場合があります。

DNSリゾルバが問い合わせるDNSサーバー

DNSリゾルバは、キャッシュに情報がない場合、DNSの階層構造をたどって問い合わせを行います。

ここで重要なのが、次の3種類のDNSサーバーです。

ルートDNSサーバー

ルートDNSサーバーは、DNS階層の最上位にあるサーバー群です。

たとえばDNSリゾルバが、

www.example.com の情報を知りたい

と思った場合、まずルートDNSサーバーに問い合わせます。

ただし、ルートDNSサーバーが www.example.com のIPアドレスを直接知っているわけではありません。

ルートDNSサーバーは、次のように案内します。

.com については、このTLDのDNSサーバーに聞いてください

つまり、ルートDNSサーバーは最終的な答えを返すというより、次に問い合わせるべきサーバーを案内する役割を持っています。

なお、ルートDNSサーバーは1台だけではありません。

A〜Mまでのルートサーバー識別名があり、実際には世界中に多数のサーバーが分散配置されています。

TLDの権威DNSサーバー

TLDとは、Top Level Domainの略です。

たとえば、以下のようなものがTLDです。

.com
.jp
.net
.org

www.example.com の場合、TLDは .com です。

DNSリゾルバは、ルートDNSサーバーから案内された .com の権威DNSサーバーに問い合わせます。

すると、.com の権威DNSサーバーは次のように答えます。

example.com については、この権威DNSサーバーに聞いてください

ここでも、必ずしも最終的なIPアドレスが返るわけではありません。

対象ドメインを管理している権威DNSサーバーの情報が返されます。

対象ドメインの権威DNSサーバー

権威DNSサーバーとは、特定のドメインやゾーンについて、正式なDNS情報を持っているDNSサーバーです。

たとえば example.com の権威DNSサーバーは、example.com に関する正式なDNSレコードを持っています。

DNSリゾルバがこの権威DNSサーバーに問い合わせると、要求されたDNSレコードが返されます。

たとえば、Aレコードを問い合わせた場合は、

www.example.com のAレコードは 203.0.113.10 です

のような応答が返ります。

ただし、必ずしも直接IPアドレスが返るとは限りません。

たとえば、www.example.com が別のホスト名の別名として設定されている場合は、CNAMEレコードが返ることがあります。

www.example.com は example-cdn.example.net の別名です

この場合、DNSリゾルバはさらに example-cdn.example.net のAレコードやAAAAレコードを問い合わせて、最終的なIPアドレスを調べます。

DNSリゾルバと権威DNSサーバーの違い

DNSリゾルバと権威DNSサーバーは、どちらもDNSに関係するサーバーですが、役割が異なります。

項目	DNSリゾルバ	権威DNSサーバー
主な役割	ユーザーの代わりにDNS情報を調べる	ドメインやゾーンの正式なDNS情報を返す
立場	問い合わせる側	答える側
代表例	ISPのDNS、Google Public DNS、Cloudflare DNSなど	ドメイン管理会社、DNSホスティング、クラウドDNSなど
キャッシュ	通常、問い合わせ結果をキャッシュする	基本的には正式なゾーン情報を保持する
ユーザーとの関係	ユーザー端末から直接問い合わせられることが多い	DNSリゾルバから問い合わせられることが多い

簡単にいうと、

DNSリゾルバ = 答えを探しに行く側
権威DNSサーバー = 正式な答えを持っている側

です。

たとえるなら、DNSリゾルバは「調査員」、権威DNSサーバーは「正式な台帳」のようなものです。

ユーザーは調査員に質問し、調査員が正式な台帳を確認して答えを返してくれる、というイメージです。

DNSリゾルバの種類

DNSリゾルバには、いくつかの種類があります。

文脈によって「リゾルバ」という言葉が指す範囲が変わるため、整理して理解しておくとわかりやすくなります。

スタブリゾルバ

スタブリゾルバは、PCやスマートフォンなどの端末側にある簡易的なDNS問い合わせ機能です。

通常、端末自身がルートDNSサーバーやTLDのDNSサーバーをたどって、完全な名前解決を行うわけではありません。

端末側のスタブリゾルバは、設定されているDNSリゾルバに対して、

このドメイン名の情報を調べてください

と問い合わせます。

つまり、スタブリゾルバはDNS問い合わせの入口となる存在です。

再帰リゾルバ

再帰リゾルバは、ユーザーや端末の代わりにDNS階層をたどり、最終的な答えを取得して返すDNSリゾルバです。

一般的に「DNSリゾルバ」といった場合、多くはこの再帰リゾルバを指します。

たとえば、再帰リゾルバは次のような問い合わせを行います。

ルートDNSサーバーに問い合わせる
↓
TLDの権威DNSサーバーに問い合わせる
↓
対象ドメインの権威DNSサーバーに問い合わせる
↓
結果をユーザー側へ返す

ユーザー側から見ると、再帰リゾルバに1回問い合わせるだけで、最終的な結果が返ってきます。

フォワーディングリゾルバ

フォワーディングリゾルバは、自分自身で完全な再帰問い合わせを行わず、別のDNSリゾルバへ問い合わせを転送するリゾルバです。

家庭用ルーターや社内ネットワークのDNSサーバーでは、このような構成が使われることがあります。

たとえば、端末からのDNS問い合わせをルーターが受け取り、ルーターがISPのDNSリゾルバやパブリックDNSへ転送するケースです。

端末
  ↓
ルーターのDNS機能
  ↓
ISPやパブリックDNSのリゾルバ

このように、DNSリゾルバは必ずしもすべての問い合わせを自力で完結させるとは限りません。

パブリックDNSリゾルバ

パブリックDNSリゾルバは、一般ユーザーが利用できる公開DNSリゾルバです。

代表的なものには、次のようなサービスがあります。

サービス	代表的なIPv4アドレス
Google Public DNS	8.8.8.8 / 8.8.4.4
Cloudflare DNS	1.1.1.1 / 1.0.0.1
Quad9	9.9.9.9

通常、家庭や会社ではISPが提供するDNSリゾルバを自動的に使っていることが多いです。

一方で、ユーザーが手動でパブリックDNSリゾルバを設定することもできます。

パブリックDNSを利用する理由には、次のようなものがあります。

名前解決を速くしたい
DNS障害時の回避策にしたい
セキュリティ機能を使いたい
プライバシー方針を重視したい
DNSSEC検証対応を重視したい
DoHやDoTを使いたい

ただし、どのDNSリゾルバが最適かは、地域、回線、利用環境、セキュリティ要件によって異なります。

再帰問い合わせと反復問い合わせの違い

DNSリゾルバの仕組みを理解するうえで、再帰問い合わせと反復問い合わせの違いも重要です。

再帰問い合わせ

再帰問い合わせとは、問い合わせ先に対して、

最終的な答えまで調べて返してください

と依頼する問い合わせです。

ユーザー端末からDNSリゾルバへの問い合わせは、多くの場合この形です。

端末：
www.example.com のIPアドレスを調べてください

DNSリゾルバ：
わかりました。必要なDNSサーバーに問い合わせて、最終的な答えを返します

反復問い合わせ

反復問い合わせとは、問い合わせ先が最終的な答えを持っていない場合に、

次はこのDNSサーバーに聞いてください

と案内する形の問い合わせです。

DNSリゾルバがルートDNSサーバーやTLDのDNSサーバーへ問い合わせるときは、典型的にこの流れになります。

DNSリゾルバ：
www.example.com を知っていますか？

ルートDNSサーバー：
直接は知りません。.com のDNSサーバーに聞いてください

つまり、ユーザー端末から見ればDNSリゾルバが再帰的に解決してくれます。

一方で、DNSリゾルバ自身はDNS階層を反復的にたどって情報を集めます。

DNSキャッシュとTTL

DNSリゾルバの重要な機能のひとつがキャッシュです。

DNSリゾルバは、一度取得したDNS情報を一定時間保存し、同じ問い合わせが来たときに再利用します。

このキャッシュ時間に関係するのが TTL です。

TTLとは

TTLは、Time To Liveの略です。

DNSにおけるTTLは、

そのDNS情報をどれくらいの時間キャッシュしてよいか

を示す値です。

たとえば、あるAレコードのTTLが 3600 に設定されている場合、DNSリゾルバはその応答を最大で3600秒、つまり1時間程度キャッシュできます。

TTL 3600 = 3600秒 = 1時間

TTLが長いほどキャッシュが効きやすくなり、DNS問い合わせの回数を減らせます。

一方で、DNS設定を変更したときに、古い情報が残りやすくなります。

TTLが短いほどDNS変更は反映されやすくなりますが、DNS問い合わせの回数は増えやすくなります。

TTLは絶対ではない

TTLはDNSキャッシュの重要な目安ですが、実際の挙動はDNSリゾルバの実装や設定によって異なる場合があります。

たとえば、リゾルバによっては次のような制御を行うことがあります。

TTLより短くキャッシュする
最大TTLを設定する
最小TTLを設定する
短時間だけ独自にキャッシュする
存在しないという結果をキャッシュする

特に注意したいのが、ネガティブキャッシュです。

ネガティブキャッシュとは、

そのドメイン名は存在しない
そのレコードは存在しない

といった否定的な応答を一定時間保存する仕組みです。

たとえば、DNS設定を間違えて一時的にレコードが存在しない状態になった場合、その「存在しない」という結果がキャッシュされることがあります。

その後、正しいレコードを設定しても、一部の環境ではしばらくエラーが続く場合があります。

DNSキャッシュは複数の場所に存在する

DNSキャッシュは、DNSリゾルバだけに存在するわけではありません。

実際には、さまざまな場所でDNSキャッシュが行われます。

ブラウザのDNSキャッシュ
OSのDNSキャッシュ
ルーターのDNSキャッシュ
社内DNSサーバーのキャッシュ
ISPのDNSリゾルバのキャッシュ
パブリックDNSのキャッシュ

そのため、DNS設定を変更したあとに古い情報が残る場合、原因がDNSリゾルバだけとは限りません。

ブラウザ、OS、ルーター、社内ネットワーク、ISPのDNSなど、複数の箇所を確認する必要があります。

DNSリゾルバで扱われる主なDNSレコード

DNSリゾルバは、さまざまなDNSレコードを問い合わせます。

代表的なDNSレコードは次の通りです。

レコード	役割
A	ドメイン名をIPv4アドレスに対応させる
AAAA	ドメイン名をIPv6アドレスに対応させる
CNAME	あるドメイン名を別のドメイン名の別名として指定する
MX	メールサーバーを指定する
TXT	任意のテキスト情報を持たせる。SPF、DKIM、DMARCなどで使われる
NS	そのゾーンを管理するネームサーバーを指定する
SOA	ゾーンの基本情報を示す
CAA	SSL/TLS証明書を発行できる認証局を制限する

Webサイト表示では、主にAレコードやAAAAレコードが関係します。

一方、メール配信ではMXレコード、TXTレコード、SPF、DKIM、DMARCなどが重要になります。

DNSリゾルバとWeb表示速度の関係

DNSリゾルバは、Webサイトの表示速度にも関係します。

Webページを表示する前には、まずアクセス先ドメインの名前解決が必要です。

DNSリゾルバの応答が遅い場合、ブラウザがWebサーバーへ接続を開始するまでに時間がかかります。

特に、以下のようなサイトではDNS問い合わせが多くなりがちです。

外部広告タグを多く使っているサイト
アクセス解析ツールを複数導入しているサイト
外部フォントを読み込んでいるサイト
複数のCDNを利用しているサイト
外部APIを多く呼び出しているサイト
画像や動画を別ドメインから配信しているサイト

DNS名前解決に時間がかかると、初回アクセス時の表示開始が遅れる可能性があります。

ただし、一度DNS情報がキャッシュされると、同じドメインへの再アクセスでは名前解決が速くなることがあります。

Webサイト運営やSEOの観点では、DNSだけで表示速度が決まるわけではありません。

しかし、DNSはページ表示の最初に関係する処理のひとつであり、無視できない要素です。

DNSリゾルバとCDNの関係

CDNを使っているWebサイトでは、DNSリゾルバが返す結果が配信先に影響することがあります。

CDNとは、ユーザーに近い配信拠点からコンテンツを届ける仕組みです。

たとえば、日本のユーザーには日本国内や近隣地域の配信拠点を、海外のユーザーにはその地域に近い配信拠点を使わせることで、表示速度や安定性を高めます。

このとき、DNS応答によって接続先のIPアドレスが変わることがあります。

DNSベースのCDNでは、次のような情報が配信先の判断に関係する場合があります。

DNSリゾルバのIPアドレス
EDNS Client Subnet
ユーザーのネットワーク
地域情報
CDN側の負荷状況
障害状況

ただし、現在のCDNではDNSだけで配信先が決まるとは限りません。

Anycast、HTTPレベルの制御、アプリケーション側のルーティングなども併用されることがあります。

そのため、DNSリゾルバはCDNの動作に影響する要素のひとつですが、唯一の要因ではありません。

DNSリゾルバとセキュリティ

DNSリゾルバは、セキュリティ面でも重要な役割を持ちます。

なぜなら、DNSはWebアクセスやメール通信の入口に近い部分だからです。

危険なドメインへのアクセスを防ぐ

一部のDNSリゾルバは、マルウェア配布サイトやフィッシングサイトなど、危険なドメインへのアクセスをブロックする機能を持っています。

たとえば、ユーザーが危険なドメインへアクセスしようとした場合、DNSリゾルバがIPアドレスを返さなかったり、警告ページへ誘導したりすることがあります。

このようなDNSフィルタリングは、企業ネットワークやセキュリティ重視のパブリックDNSで使われることがあります。

DNSキャッシュポイズニング対策

DNSには、DNSキャッシュポイズニングという攻撃があります。

これは、DNSリゾルバのキャッシュに偽のDNS情報を保存させ、ユーザーを不正なサイトへ誘導する攻撃です。

たとえば、本来は正規サイトのIPアドレスが返るべきところで、攻撃者が用意した偽サイトのIPアドレスが返ってしまうと、ユーザーが偽サイトへ誘導される可能性があります。

このような攻撃への対策として、DNSSECなどの仕組みがあります。

DNSSEC

DNSSECは、DNS応答が改ざんされていないかを検証するための仕組みです。

DNSSECを使うと、DNSリゾルバは受け取ったDNS応答が正当なものかどうかを暗号学的に確認できます。

ただし、DNSSECはDNS通信を暗号化する仕組みではありません。

主な目的は、

DNS応答の真正性を確認すること
DNS応答の改ざんを検出すること

です。

DNS over HTTPS / DNS over TLS

DNS over HTTPS、DNS over TLSは、DNS問い合わせを暗号化するための仕組みです。

それぞれ、次のように略されます。

DNS over HTTPS = DoH
DNS over TLS = DoT

DoHやDoTを使うと、端末とDNSリゾルバの間のDNS通信を暗号化できます。

これにより、通信経路上でDNS問い合わせの内容を盗み見られたり、改ざんされたりするリスクを減らせます。

ただし、DoHやDoTとDNSSECは役割が異なります。

仕組み	主な役割
DoH	DNS問い合わせをHTTPSで暗号化する
DoT	DNS問い合わせをTLSで暗号化する
DNSSEC	DNS応答が改ざんされていないか検証する

つまり、DoHやDoTは主に通信経路の保護、DNSSECはDNS応答内容の検証に関係します。

DNSリゾルバを変更すると何が変わるのか

PCやスマートフォン、ルーターの設定を変更することで、利用するDNSリゾルバを変えることができます。

DNSリゾルバを変更すると、次のような点が変わる可能性があります。

名前解決速度

DNSリゾルバによって、名前解決の応答速度が異なる場合があります。

ただし、どのDNSリゾルバが速いかは、利用している地域、回線、時間帯、キャッシュ状況によって変わります。

ある環境では速いDNSリゾルバでも、別の環境ではそれほど速くないことがあります。

セキュリティ機能

DNSリゾルバによっては、悪意あるドメインやフィッシングサイトへのアクセスをブロックする機能があります。

セキュリティを重視する場合、こうしたフィルタリング機能を持つDNSリゾルバを選ぶことがあります。

プライバシー

DNSリゾルバには、ユーザーがどのドメインを問い合わせたかが見える場合があります。

つまり、DNSリゾルバの運営者は、ユーザーのアクセス傾向に関する情報を扱う立場になります。

そのため、DNSリゾルバを選ぶ際には、ログ保存方針やプライバシーポリシーも重要です。

CDNの接続先

CDNを利用しているサービスでは、DNSリゾルバによって返されるIPアドレスが変わる場合があります。

その結果、接続先の配信拠点が変わり、表示速度や安定性に差が出ることがあります。

ただし、CDNのルーティングはDNSだけで決まるわけではないため、DNSリゾルバを変えれば必ず速くなるとは限りません。

フィルタリングや社内向け名前解決

企業や学校のネットワークでは、独自のDNSリゾルバを使っていることがあります。

この場合、社内システム向けのドメイン名を解決したり、特定のサイトへのアクセスを制御したりすることがあります。

たとえば、社内ネットワークでは、

intranet.example.local

のような内部向けの名前を解決できる場合があります。

このような環境で勝手に外部のパブリックDNSへ変更すると、社内システムにアクセスできなくなることがあります。

DNSリゾルバ関連でよくあるトラブル

DNSリゾルバやDNS設定に関係するトラブルには、いくつか代表的なものがあります。

DNS_PROBE_FINISHED_NXDOMAIN

Chromeなどのブラウザで、

DNS_PROBE_FINISHED_NXDOMAIN

というエラーが表示されることがあります。

これは、指定したドメイン名をDNSで解決できなかった場合に発生することがあります。

主な原因には、次のようなものがあります。

ドメイン名の入力ミス
ドメインが存在しない
DNSレコードが設定されていない
権威DNSサーバーの設定ミス
ネームサーバーの設定ミス
DNSSECの設定ミス
DNSリゾルバのキャッシュ

単に「DNSリゾルバが悪い」とは限らず、ドメイン側の設定に問題がある場合もあります。

DNS設定を変更したのに反映されない

Webサーバー移転やCDN導入の際に、DNSレコードを変更してもすぐに反映されないことがあります。

よくある原因はキャッシュです。

DNSリゾルバ、OS、ブラウザ、ルーターなどに古いDNS情報が残っていると、しばらく古いIPアドレスへ接続される場合があります。

また、原因はTTLだけとは限りません。

次のような要因も考えられます。

権威DNSサーバー側の設定ミス
NSレコード変更の反映待ち
親ゾーンへの委任設定ミス
DNSSECのDSレコード不整合
CNAME設定の誤り
AAAAレコードの設定ミス
CDN側の設定未完了

DNS変更後に問題が起きた場合は、キャッシュだけでなく、権威DNS側の設定やCDN側の設定も確認する必要があります。

一部の環境だけWebサイトが見られない

「自分の環境では見られるが、他の人は見られない」

「スマホ回線では見られるが、会社のWi-Fiでは見られない」

このようなケースでは、使っているDNSリゾルバやネットワークごとに名前解決結果が異なっている可能性があります。

原因としては、次のようなものが考えられます。

DNSキャッシュの新旧が異なる
一部のDNSリゾルバだけ古い情報を返している
社内DNSで独自の設定がされている
DNSフィルタリングでブロックされている
IPv6側の設定に問題がある
CDNの地域制御や障害の影響を受けている

このような場合は、複数のDNSリゾルバで名前解決結果を比較すると原因を絞り込みやすくなります。

Webサイト運営者がDNSリゾルバについて知っておくべきこと

Webサイト運営者やマーケティング担当者がDNSリゾルバそのものを直接管理することは多くありません。

しかし、DNSの仕組みを理解しておくと、サイト移転、CDN導入、メール配信、障害対応などで役立ちます。

DNS変更前にはTTLを確認する

サーバー移転やCDN導入の前には、DNSレコードのTTLを確認しておくことが重要です。

たとえば、現在のAレコードのTTLが次のように設定されているとします。

86400秒

これは24時間です。

この状態でIPアドレスを変更すると、一部のDNSリゾルバでは古い情報が長く残る可能性があります。

そのため、サーバー移転やDNS切り替えの前には、事前にTTLを短くしておくことがあります。

たとえば、

300秒

のように短くしておけば、切り替え後の反映を早めやすくなります。

ただし、TTLを短くしても、すべての環境で即時反映されるとは限りません。

OS、ブラウザ、ルーター、DNSリゾルバ、CDNなどのキャッシュも関係するためです。

ネームサーバー変更は慎重に行う

ドメインのネームサーバーを変更すると、DNSの管理先が変わります。

この作業を誤ると、Webサイトやメールが利用できなくなる可能性があります。

特に注意したいのは、次のようなケースです。

ドメイン移管
DNSホスティングの変更
サーバー移転
CDN導入
メールサービスの切り替え

ネームサーバー変更前には、新しいDNS側に必要なレコードがすべて設定されているか確認する必要があります。

Aレコード、AAAAレコード、CNAME、MX、TXT、SPF、DKIM、DMARCなどを漏れなく確認することが重要です。

メール配信にもDNSが関係する

DNSはWebサイトだけでなく、メール配信にも深く関係します。

メールでは、主に次のDNSレコードが使われます。

レコード	用途
MX	受信メールサーバーを指定する
SPF	送信元メールサーバーの正当性を示す
DKIM	メールに電子署名を付け、改ざんを検証する
DMARC	SPFやDKIMの認証結果に基づく扱いを指定する

これらのDNS設定が不適切だと、メールが届きにくくなったり、迷惑メール判定されやすくなったりします。

そのため、Webマーケティングでメール配信を行う場合も、DNS設定は重要です。

CDN導入時はDNSの挙動も確認する

CDNを導入する場合、多くのケースでCNAMEレコードやAレコードの変更が発生します。

たとえば、

www.example.com CNAME example.cdn-provider.net

のように、Webサイトのホスト名をCDN側のホスト名に向けることがあります。

このとき、DNSリゾルバがCNAMEの先をさらに解決し、最終的な配信先IPアドレスを取得します。

CDN導入時には、次の点を確認しておくと安心です。

CNAMEが正しく設定されているか
ルートドメインでCNAMEを使えない場合の対応
AレコードやALIAS/ANAMEの扱い
AAAAレコードの有無
TTLの設定
CDN側のSSL/TLS証明書設定
オリジンサーバー設定

DNS自体が正しくても、CDN側の設定が未完了だとWebサイトが表示されないことがあります。

DNSリゾルバの設定はどこで行うのか

DNSリゾルバの設定は、主に次の場所で行われます。

ルーターのネットワーク設定
PCのネットワーク設定
スマートフォンのWi-Fi設定
ブラウザのセキュアDNS設定
企業ネットワークの管理設定

家庭用回線では、多くの場合、ルーターがISPからDNSリゾルバの情報を自動取得し、それを端末へ配布しています。

そのため、ユーザーが特に設定しなくても、通常はISPのDNSリゾルバが使われます。

一方で、手動でGoogle Public DNSやCloudflare DNSなどに変更することもできます。

ただし、企業や学校のネットワークでは、DNSリゾルバを変更すると内部システムにアクセスできなくなる場合があります。

管理されたネットワークでは、勝手にDNS設定を変更しないほうが安全です。

DNSリゾルバの例え

DNSリゾルバは、電話番号案内に例えるとわかりやすいです。

あなたがある会社に電話したいとします。

しかし、会社名だけでは電話をかけることはできません。電話番号が必要です。

そこで電話番号案内に、

株式会社○○の電話番号を教えてください

と問い合わせます。

電話番号案内は、正式な情報を調べて電話番号を教えてくれます。

DNSの場合は、次のように考えるとわかりやすいです。

電話の世界	DNSの世界
会社名	ドメイン名
電話番号	IPアドレス
電話番号案内	DNSリゾルバ
正式な電話帳	権威DNSサーバー

ユーザーはドメイン名を入力し、DNSリゾルバが対応するDNS情報を調べ、最終的にWebサーバーへ接続できるようになります。

まとめ

DNSリゾルバとは、ユーザーの端末やアプリケーションからDNS問い合わせを受け取り、必要なDNSレコードを調べて返す仕組みです。

Webサイトにアクセスするときには、主にAレコードやAAAAレコードを取得し、ドメイン名に対応するIPアドレスを調べます。

重要なポイントをまとめると、次の通りです。

ポイント	内容
DNSリゾルバの役割	ドメイン名に対応するDNSレコードを調べる
Webアクセスでの役割	AレコードやAAAAレコードを取得し、IPアドレスを調べる
よく指すもの	ISPやパブリックDNSが提供する再帰リゾルバ
関係するDNSサーバー	ルートDNS、TLDの権威DNS、対象ドメインの権威DNS
キャッシュ	一度取得したDNS情報を一定時間保存する
TTL	DNS情報をキャッシュしてよい時間の目安
セキュリティ	DNSSEC、DoH、DoT、DNSフィルタリングなどが関係する
Web運営での重要性	サーバー移転、CDN導入、メール配信、障害対応に関係する

最もシンプルにいうと、DNSリゾルバは、

ドメイン名に対応するDNS情報を、ユーザーの代わりに調べてくれる仕組み

です。

私たちが普段、IPアドレスを意識せずにWebサイトへアクセスできるのは、DNSリゾルバが裏側で名前解決を行ってくれているからです。

以上、DNSリゾルバとはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。