DNSの正引きについて

DNSの正引きとは、ドメイン名やホスト名から、対応するIPアドレスを調べる名前解決のことです。

たとえば、Webサイトへアクセスするとき、人間は次のようなドメイン名を使います。

www.example.com

しかし、インターネット上のコンピューター同士が通信するときは、基本的にIPアドレスを使って相手を識別します。

そのため、ブラウザでWebサイトを表示する前には、DNSを使って次のようにドメイン名をIPアドレスへ変換します。

www.example.com → IPアドレス

このように、ドメイン名からIPアドレスを調べる処理がDNSの正引きです。

DNSの正引きの基本イメージ

DNSの正引きは、簡単にいうと次のような流れで行われます。

URLを入力する
↓
URL内のホスト名を確認する
↓
DNSに問い合わせる
↓
対応するIPアドレスを取得する
↓
取得したIPアドレスのサーバーへ接続する

たとえば、ユーザーがブラウザに https://www.example.com/ と入力した場合、ブラウザやOSはURLの中から www.example.com というホスト名を取り出します。

そして、そのホスト名に対応するIPアドレスをDNSで調べます。

IPアドレスが分かると、ブラウザはそのIPアドレスのサーバーへ接続し、Webページのデータを取得します。

正引きと逆引きの違い

DNSには、代表的な名前解決として正引きと逆引きがあります。

種類	調べる方向	例
正引き	ドメイン名・ホスト名 → IPアドレス	www.example.com → IPアドレス
逆引き	IPアドレス → ドメイン名・ホスト名	IPアドレス → example.com など

正引きは、Webサイトの表示、メール配送、API通信、外部サービスとの接続など、インターネット利用の多くの場面で使われます。

一方、逆引きは、サーバー管理、アクセスログの確認、メールサーバーの信頼性確認、不審なアクセス元の調査などで使われることがあります。

ただし、正引きと逆引きは必ずしも1対1で対応するわけではありません。

たとえば、あるドメイン名を正引きして得られたIPアドレスを逆引きしても、同じドメイン名が返ってくるとは限りません。

逆引きにはPTRレコードが使われ、通常はIPアドレスを管理しているプロバイダ、クラウド事業者、ホスティング事業者などが設定に関わります。

そのため、正引きと逆引きは関連していますが、完全に対称の仕組みではありません。

正引きで使われる主なDNSレコード

DNSの正引きでは、主に以下のレコードが関係します。

Aレコード

Aレコードは、ドメイン名やホスト名をIPv4アドレスに対応させるDNSレコードです。

たとえば、次のようなイメージです。

www.example.com → 192.0.2.10

IPv4アドレスは、以下のような形式で表されます。

192.0.2.10

Webサイトの公開やサーバーへの接続では、Aレコードがよく使われます。

AAAAレコード

AAAAレコードは、ドメイン名やホスト名をIPv6アドレスに対応させるDNSレコードです。

たとえば、次のようなイメージです。

www.example.com → 2001:db8::1

IPv6アドレスは、以下のような形式で表されます。

2001:db8:abcd:0012::1

現在はIPv4だけでなくIPv6も利用されているため、1つのドメイン名にAレコードとAAAAレコードの両方が設定されていることもあります。

注意点として、AAAAレコードの設定が誤っていると、IPv6を利用する環境だけでWebサイトに接続できないことがあります。

そのため、Webサイトの表示トラブルを調査する場合は、AレコードだけでなくAAAAレコードも確認することが重要です。

CNAMEレコード

CNAMEレコードは、あるホスト名を別のホスト名の別名として扱うためのDNSレコードです。

たとえば、次のような設定です。

www.example.com → CNAME → example.com

この場合、www.example.com は example.com の別名として扱われます。

ただし、CNAMEレコード自体がIPアドレスを直接返すわけではありません。

最終的には、CNAMEの参照先に設定されているAレコードやAAAAレコードをたどって、IPアドレスを取得します。

流れとしては、次のようになります。

www.example.com
↓ CNAME
example.com
↓ AレコードまたはAAAAレコード
IPアドレス

CNAMEは、外部サービスやCDN、ブログサービス、ECサービスなどを独自ドメインで利用するときによく使われます。

たとえば、外部サービス側から以下のような設定を求められることがあります。

blog.example.com → CNAME → service.example.net

このようにしておくと、外部サービス側で接続先IPアドレスが変更された場合でも、利用者側はCNAMEの参照先をたどって正しい接続先に到達できます。

CNAMEを使うときの注意点

CNAMEには重要な注意点があります。

CNAMEを設定したホスト名には、原則としてAレコードやAAAAレコードなどの他のレコードを同時に設定できません。

たとえば、次のような設定は避けるべきです。

www.example.com CNAME example.com
www.example.com A     192.0.2.10

CNAMEは、その名前を「別名」として扱うためのレコードです。

そのため、同じ名前にAレコードやAAAAレコードなどを混在させると、DNS設定上の問題になることがあります。

CNAMEを使う場合は、対象のホスト名を別名として扱い、同じホスト名に別のDNSレコードを同時に置かないようにすることが大切です。

ルートドメインにCNAMEを設定できない理由

DNS設定でよく注意されるのが、ルートドメインには標準的なDNSではCNAMEを設定できないという点です。

ここでいうルートドメインとは、たとえば次のようなドメインです。

example.com

一方、以下のようなものはサブドメインです。

www.example.com
blog.example.com
shop.example.com

example.com のようなゾーンの頂点には、通常、SOAレコードやNSレコードなどの重要なDNSレコードが必要です。

しかし、CNAMEを設定した名前には、原則として他のレコードを同時に設定できません。

そのため、ゾーンの頂点にCNAMEを設定しようとすると、SOAレコードやNSレコードと衝突してしまいます。

そのため、標準的なDNSでは、example.com のようなルートドメインにCNAMEを設定することはできません。

外部サービスにルートドメインを向けたい場合は、次のような方法が使われることがあります。

Aレコード
AAAAレコード
ALIAS
ANAME
CNAME flattening

このうち、ALIAS、ANAME、CNAME flatteningは、DNS事業者が独自に提供している機能です。

標準的なDNSレコードそのものではないため、利用できるかどうかはDNSサービスによって異なります。

DNSの正引きの流れ

DNSの正引きでは、複数のDNSサーバーが関係します。

ユーザーが www.example.com にアクセスする場合を例にすると、主に次のような流れになります。

ブラウザやOSがキャッシュを確認する

最初に、ブラウザやOSは過去に取得したDNS情報が残っていないか確認します。

DNSの情報には、TTLという有効期限のような値があります。

TTLとは、DNS情報をどのくらいの時間キャッシュしてよいかを示す値です。

たとえば、TTLが3600秒の場合、そのDNS情報は通常、最大1時間程度キャッシュされます。

ただし、実際の反映タイミングは、利用しているDNSリゾルバ、OS、ブラウザ、アプリケーション、DNS事業者の仕様などによって前後することがあります。

そのため、DNSレコードを変更した直後に、すべての環境で一斉に新しい情報へ切り替わるとは限りません。

キャッシュが残っていれば、端末やブラウザはDNSサーバーへ再度問い合わせずに、キャッシュされたIPアドレスを使うことがあります。

フルリゾルバに問い合わせる

キャッシュに情報がない場合、端末はフルリゾルバに問い合わせます。

フルリゾルバとは、利用者の代わりにDNS情報を調べてくれるDNSサーバーです。

一般的には、以下のようなDNSサーバーがフルリゾルバとして使われます。

プロバイダが提供するDNSサーバー
Google Public DNS
Cloudflare DNS
Quad9
企業や学校のDNSサーバー
VPN経由のDNSサーバー

通常、ユーザーのPCやスマートフォンが直接ルートDNSサーバーや権威DNSサーバーへ問い合わせるわけではありません。

多くの場合、端末はフルリゾルバに問い合わせ、フルリゾルバが必要に応じて他のDNSサーバーへ問い合わせます。

ルートDNSサーバーに問い合わせる

フルリゾルバが答えを持っていない場合、まずルートDNSサーバーに問い合わせます。

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

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

代わりに、次に問い合わせるべきDNSサーバーの情報を返します。

たとえば、www.example.com であれば、ルートDNSサーバーは .com を管理するTLD DNSサーバーの情報を返します。

イメージとしては、次のような回答です。

.com については、このTLD DNSサーバーに問い合わせてください

TLD DNSサーバーに問い合わせる

次に、フルリゾルバは .com を管理するTLD DNSサーバーへ問い合わせます。

TLDとは、トップレベルドメインのことです。

代表的なTLDには、次のようなものがあります。

.com
.net
.org
.jp
.co.jp

TLD DNSサーバーも、通常は www.example.com のIPアドレスを直接返すわけではありません。

代わりに、example.com を管理している権威DNSサーバーの情報を返します。

イメージとしては、次のような回答です。

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

権威DNSサーバーに問い合わせる

最後に、フルリゾルバは example.com を管理している権威DNSサーバーに問い合わせます。

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

ここでようやく、目的のホスト名に対応するDNSレコードを取得できます。

たとえば、次のような回答が返ります。

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

または、IPv6の場合は次のような回答になることもあります。

www.example.com のAAAAレコードは 2001:db8::1 です

CNAMEが設定されている場合は、CNAMEの参照先をさらにたどって、最終的なAレコードやAAAAレコードを取得します。

フルリゾルバが端末へ結果を返す

権威DNSサーバーから回答を受け取ったフルリゾルバは、その結果をユーザーの端末へ返します。

端末は、取得したIPアドレスを使ってWebサーバーなどへ接続します。

同時に、フルリゾルバや端末は、そのDNS情報を一定時間キャッシュします。

これにより、次回以降のアクセスではDNS問い合わせの回数を減らせるため、通信の効率がよくなります。

正引きの具体例

www.example.com の正引きを例にすると、全体の流れは次のようになります。

ユーザーが https://www.example.com/ にアクセスする
↓
ブラウザがURL内のホスト名 www.example.com を確認する
↓
ブラウザやOSがDNSキャッシュを確認する
↓
キャッシュがなければフルリゾルバへ問い合わせる
↓
フルリゾルバがルートDNSサーバーへ問い合わせる
↓
.com のTLD DNSサーバーを教えてもらう
↓
.com のTLD DNSサーバーへ問い合わせる
↓
example.com の権威DNSサーバーを教えてもらう
↓
example.com の権威DNSサーバーへ問い合わせる
↓
www.example.com のAレコードやAAAAレコードを取得する
↓
端末が取得したIPアドレスのサーバーへ接続する

このように、DNSの正引きは階層構造をたどりながら行われます。

ただし、実際にはキャッシュが利用されることが多いため、毎回必ずルートDNSサーバーから順番に問い合わせるわけではありません。

正引きで返ってくるIPアドレスは1つとは限らない

正引きの結果として返ってくるIPアドレスは、必ずしも1つだけではありません。

大規模なWebサービスでは、1つのホスト名に複数のIPアドレスを設定することがあります。

たとえば、次のようなイメージです。

www.example.com → 192.0.2.10
www.example.com → 192.0.2.11
www.example.com → 192.0.2.12

これは、負荷分散や冗長化のために使われます。

また、CDNを利用している場合、アクセスする地域、ネットワーク環境、利用しているDNSリゾルバなどによって、返されるIPアドレスが変わることもあります。

たとえば、日本からアクセスした場合と海外からアクセスした場合で、異なるIPアドレスが返るケースがあります。

そのため、同じドメイン名を正引きしても、すべてのユーザーに常に同じIPアドレスが返るとは限りません。

正引きとWebサイト表示の関係

Webサイトを表示する際、DNSの正引きは非常に重要です。

ユーザーがブラウザにURLを入力すると、ブラウザはまずURL内のホスト名を確認します。

そして、DNSでそのホスト名を正引きし、接続先のIPアドレスを取得します。

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

URLを入力する
↓
ホスト名を確認する
↓
DNSで正引きする
↓
IPアドレスを取得する
↓
サーバーへ接続する
↓
Webページのデータを取得する
↓
ブラウザに表示する

正引きに失敗すると、ブラウザは接続先のサーバーを特定できません。

そのため、サーバー自体が正常に動作していても、DNSの正引きに問題があるとWebサイトは表示されません。

なお、HTTPS通信では、DNSで取得したIPアドレスへ接続したあと、TLS通信やHTTPリクエストが行われます。

現在のWebでは、1つのIPアドレスに複数のドメインが同居していることも多いため、DNSだけでなくWebサーバー側の設定も重要です。

正引きが失敗する主な原因

DNSの正引きが失敗すると、Webサイトにアクセスできなかったり、メールが届かなかったりすることがあります。

主な原因は以下のとおりです。

ドメイン名の入力ミス

もっとも基本的な原因は、ドメイン名の入力ミスです。

たとえば、次のような間違いです。

example.com
exampel.com

一見似ていますが、DNS上は別の名前として扱われます。

存在しないドメイン名を入力した場合、DNSは対応するIPアドレスを返せません。

DNSレコードが設定されていない

ドメイン自体は存在していても、AレコードやAAAAレコードが設定されていなければ、正引きできないことがあります。

たとえば、www.example.com というサブドメインを使いたいのに、そのホスト名にAレコードやCNAMEレコードを設定していない場合です。

www.example.com のAレコードがない
www.example.com のAAAAレコードがない
www.example.com のCNAMEレコードもない

この場合、ブラウザは接続先のIPアドレスを取得できません。

CNAMEの参照先に問題がある

CNAMEレコードを設定している場合、参照先のドメイン名に問題があると正引きに失敗します。

たとえば、次のような設定があるとします。

www.example.com → CNAME → app.example.net

このとき、app.example.net にAレコードやAAAAレコードが設定されていなければ、最終的なIPアドレスを取得できません。

また、参照先の外部サービスを解約したり、外部サービス側の設定が変更されたりした場合にも、名前解決に失敗することがあります。

権威DNSサーバーの設定ミス

ドメインのDNS情報を管理している権威DNSサーバーに問題があると、正引きが失敗することがあります。

たとえば、以下のようなケースです。

ネームサーバーの指定が間違っている
権威DNSサーバーが停止している
ゾーンファイルの設定に誤りがある
必要なDNSレコードが登録されていない
DNSSECの設定に問題がある

このような場合、特定のサブドメインだけでなく、ドメイン全体の名前解決に影響することがあります。

DNSキャッシュの影響

DNSレコードを変更した直後は、古い情報がキャッシュに残っていることがあります。

たとえば、サーバー移転のためにAレコードを変更したとしても、一部のユーザーには古いIPアドレスが返される場合があります。

これは、以前のDNS情報が以下のような場所にキャッシュされている可能性があるためです。

フルリゾルバ
OS
ブラウザ
アプリケーション
社内ネットワーク
プロキシ

そのため、DNS変更後すぐにすべての環境で新しいIPアドレスへ切り替わるとは限りません。

特にサーバー移転やCDN導入の前には、事前にTTLを短めにしておくことがあります。

DNSサーバーの障害

利用しているフルリゾルバや権威DNSサーバーに障害があると、正引きができないことがあります。

たとえば、プロバイダのDNSサーバーに障害が起きている場合、そのプロバイダを利用しているユーザーだけWebサイトにアクセスできないことがあります。

また、権威DNSサーバー側に障害がある場合は、より広い範囲で名前解決に失敗する可能性があります。

DNSはインターネットの基盤に近い仕組みなので、DNS障害が起きるとWebサイト、メール、アプリ、APIなど多くのサービスに影響します。

正引きを確認する方法

DNSの正引きは、コマンドを使って確認できます。

代表的なコマンドには、以下のようなものがあります。

nslookup
dig
host

ここでは、具体的なコマンドの書き方ではなく、それぞれで確認できる内容を説明します。

nslookupで確認できること

nslookup を使うと、指定したドメイン名に対応するIPアドレスを確認できます。

主に以下のようなことを調べられます。

Aレコードが設定されているか
AAAAレコードが設定されているか
どのIPアドレスが返ってくるか
どのDNSサーバーに問い合わせているか
特定のDNSサーバーで正引きした場合の結果

WindowsでもmacOSでも利用しやすいため、基本的なDNS確認によく使われます。

digで確認できること

dig は、DNSの詳細情報を確認するときによく使われるコマンドです。

以下のような情報を詳しく確認できます。

Aレコード
AAAAレコード
CNAMEレコード
MXレコード
NSレコード
TTL
問い合わせ先DNSサーバー
応答時間
権威情報

サーバー管理者やネットワーク担当者は、DNSの状態を詳しく調べるために dig を使うことが多いです。

hostで確認できること

host もDNSの名前解決を確認するためのコマンドです。

比較的シンプルな出力で、ドメイン名に対応するIPアドレスや、メールサーバー情報などを確認できます。

簡単に正引き結果を見たい場合に便利です。

正引きで確認すべきポイント

Webサイトが表示されないときや、DNS設定を変更したときは、正引きの結果を確認することが重要です。

特に以下の点を確認します。

Aレコードが正しいか

IPv4で接続させたい場合は、Aレコードが正しく設定されているか確認します。

たとえば、WebサーバーのIPv4アドレスが 192.0.2.10 であれば、対象のホスト名がそのIPアドレスを返す必要があります。

Aレコードが古いサーバーのIPアドレスを指していると、サーバー移転後も古いサーバーへアクセスされることがあります。

AAAAレコードが正しいか

IPv6を利用する場合は、AAAAレコードが正しく設定されているか確認します。

Aレコードが正しくても、AAAAレコードが誤っていると、IPv6を優先する環境で接続に失敗することがあります。

そのため、以下のようなトラブルではAAAAレコードも確認する必要があります。

一部のユーザーだけサイトが表示できない
スマートフォン回線では見られない
特定のネットワーク環境だけ接続できない
IPv4では問題ないがIPv6では失敗する

CNAMEの参照先が正しいか

CNAMEを設定している場合は、参照先のドメイン名が正しく名前解決できるか確認します。

確認すべきポイントは以下です。

CNAMEの参照先が正しいか
参照先のドメイン名が存在しているか
参照先にAレコードやAAAAレコードがあるか
外部サービス側の設定が有効か
同じホスト名にAレコードなどを重複設定していないか

CNAMEの参照先が間違っていると、最終的なIPアドレスまでたどり着けません。

TTLが適切か

TTLは、DNS情報をキャッシュしてよい時間を示す値です。

TTLが長いと、DNS問い合わせの回数を減らせる一方で、DNS変更後に古い情報が長く残りやすくなります。

一方、TTLが短いと、DNS変更時の切り替えはしやすくなりますが、DNSサーバーへの問い合わせが増えやすくなります。

サーバー移転やDNS切り替えを予定している場合は、事前にTTLを短めにしておくことがあります。

ただし、TTLを変更しても、すでにキャッシュされている古い情報にはすぐ反映されない場合があります。

そのため、DNS切り替えは余裕を持って準備することが重要です。

ネームサーバーの指定が正しいか

ドメインのDNS情報は、指定されたネームサーバーで管理されます。

そのため、レジストラ側で設定しているネームサーバーが間違っていると、DNSレコードを正しく設定していても反映されません。

たとえば、DNS管理画面ではAレコードを正しく設定しているのに、ドメイン側のネームサーバーが別のDNSサービスを向いている場合があります。

この場合、ユーザーが問い合わせる先は別の権威DNSサーバーになるため、意図したDNS設定が使われません。

ドメイン移管やDNSサービス変更の際には、ネームサーバーの指定も必ず確認する必要があります。

正引きとメールの関係

DNSの正引きは、Webサイトだけでなくメールの配送にも関係します。

メールを送信するときは、まず送信先ドメインのMXレコードを調べます。

MXレコードとは、そのドメイン宛のメールをどのメールサーバーが受け取るかを示すDNSレコードです。

たとえば、user@example.com にメールを送る場合、メールサーバーはまず example.com のMXレコードを確認します。

流れとしては、次のようになります。

user@example.com にメールを送る
↓
example.com のMXレコードを調べる
↓
mail.example.com がメールサーバーだと分かる
↓
mail.example.com をAレコードやAAAAレコードで正引きする
↓
メールサーバーのIPアドレスを取得する
↓
そのメールサーバーへメールを配送する

つまり、メール配送では、まずMXレコードでメールサーバー名を調べ、その後でそのメールサーバー名を正引きしてIPアドレスを取得します。

MXレコード自体は、直接IPアドレスを返すためのレコードではありません。

最終的にメールサーバーへ接続するために、AレコードやAAAAレコードによる正引きが必要になります。

正引き設定時の注意点

DNSの正引きを設定するときは、以下の点に注意しましょう。

サーバーのIPアドレスを正しく設定する

AレコードやAAAAレコードには、接続先サーバーのIPアドレスを正しく設定する必要があります。

IPアドレスを1文字でも間違えると、意図しないサーバーへ接続されたり、Webサイトが表示されなかったりします。

特に、サーバー移転時には、旧サーバーのIPアドレスと新サーバーのIPアドレスを取り違えないように注意が必要です。

wwwあり と wwwなし を分けて考える

DNSでは、example.com と www.example.com は別の名前として扱われます。

そのため、以下の2つは別々に設定を確認する必要があります。

example.com
www.example.com

example.com は表示できるのに www.example.com は表示できない、またはその逆のトラブルは珍しくありません。

Webサイトを公開するときは、wwwあり と wwwなし の両方について、DNS設定とWebサーバー側の設定を確認しましょう。

サブドメインごとに設定が必要

DNSでは、サブドメインごとに個別のレコードを設定できます。

たとえば、以下はそれぞれ別のホスト名です。

www.example.com
blog.example.com
shop.example.com
lp.example.com

www.example.com のAレコードが正しく設定されていても、blog.example.com が自動的に同じIPアドレスへ向くわけではありません。

サブドメインを追加する場合は、それぞれに必要なDNSレコードを設定する必要があります。

CNAMEとAレコードを適切に使い分ける

直接IPアドレスを指定したい場合は、AレコードやAAAAレコードを使います。

一方、別のホスト名を参照させたい場合は、CNAMEレコードを使います。

たとえば、自社で管理しているサーバーに直接向ける場合は、Aレコードを使うことが多いです。

www.example.com → 192.0.2.10

一方、外部サービスに独自ドメインを向ける場合は、CNAMEを使うことがあります。

blog.example.com → CNAME → service.example.net

ただし、CNAMEを設定するホスト名には、原則として他のレコードを同時に設定できません。

また、ルートドメインには標準的なDNSではCNAMEを設定できないため、DNSサービスが提供するALIASやANAMEなどの機能が必要になる場合があります。

DNS変更前にTTLを確認する

サーバー移転やDNS切り替えを行う場合は、事前にTTLを確認しておくことが重要です。

TTLが長いままだと、変更前のDNS情報が長くキャッシュされ、一部のユーザーが古いサーバーへ接続し続ける可能性があります。

移転作業の前には、余裕を持ってTTLを短めに設定しておくと、切り替え時の影響を軽減しやすくなります。

ただし、TTLを短くしたからといって、すでにキャッシュされている情報がすぐに消えるわけではありません。

そのため、DNS変更は直前に慌てて行うのではなく、計画的に進めることが大切です。

正引きに関するよくあるトラブル

DNS_PROBE_FINISHED_NXDOMAIN と表示される

Chromeなどのブラウザで DNS_PROBE_FINISHED_NXDOMAIN と表示される場合、DNS上で対象のドメイン名が存在しない、または名前解決できない状態を示している可能性があります。

主な原因は以下です。

ドメイン名の入力ミス
ドメインの有効期限切れ
DNSレコード未設定
ネームサーバー設定ミス
DNS反映中

まずは、ドメイン名が正しいか、ドメインが有効か、ネームサーバーが正しく設定されているかを確認しましょう。

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

DNS変更後に、一部のユーザーだけWebサイトが見られないことがあります。

これは、DNSキャッシュの影響で、ユーザーや利用しているDNSサーバーによって取得しているIPアドレスが異なるためです。

たとえば、あるユーザーは新しいIPアドレスを取得している一方で、別のユーザーは古いIPアドレスをキャッシュしている場合があります。

このような場合は、複数のDNSサーバーで正引き結果を確認すると原因を切り分けやすくなります。

サーバー移転後に古いサーバーへアクセスされる

サーバー移転でAレコードを変更した直後は、古いIPアドレスがキャッシュに残っていることがあります。

その結果、一部のアクセスが古いサーバーへ向いてしまうことがあります。

これを防ぐには、移転前からTTLを短めにしておく、旧サーバー側にも一定期間コンテンツを残しておく、リダイレクトやメンテナンス表示を準備しておくなどの対策が有効です。

IPv4では見られるがIPv6では見られない

Aレコードは正しいのに、AAAAレコードが誤っている場合、IPv4環境では問題なく表示できても、IPv6環境では接続に失敗することがあります。

このような場合は、AレコードだけでなくAAAAレコードも確認しましょう。

特に、過去にIPv6対応を試したあと、AAAAレコードだけが古い設定のまま残っているケースには注意が必要です。

wwwあり は表示できるが wwwなし は表示できない

www.example.com と example.com はDNS上では別の名前です。

そのため、wwwあり のレコードだけ設定していて、wwwなし のレコードを設定していない場合、片方だけ表示できないことがあります。

Webサイトを公開するときは、以下の両方を確認しましょう。

example.com
www.example.com

さらに、どちらを正規URLにするかを決め、必要に応じてリダイレクト設定も行います。

DNSの正引きのまとめ

DNSの正引きとは、ドメイン名やホスト名から対応するIPアドレスを調べる名前解決のことです。

Webサイトを表示するとき、メールを配送するとき、外部サービスへ接続するときなど、インターネット利用の多くの場面で使われています。

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

ポイント	内容
正引きの意味	ドメイン名・ホスト名からIPアドレスを調べること
主なレコード	Aレコード、AAAAレコード、CNAMEレコード
Aレコード	IPv4アドレスへ対応させる
AAAAレコード	IPv6アドレスへ対応させる
CNAMEレコード	別のホスト名への別名を設定する
フルリゾルバ	利用者の代わりにDNS問い合わせを行うDNSサーバー
権威DNSサーバー	ドメインの正式なDNS情報を持つDNSサーバー
TTL	DNS情報をキャッシュしてよい時間
注意点	CNAMEの併用制限、ルートドメインのCNAME制限、キャッシュの影響
よくある問題	レコード未設定、ネームサーバー設定ミス、TTL、IPv6設定ミス、CNAME参照先の問題

正引きが正常に行われてはじめて、ブラウザやメールサーバーは目的のサーバーへ接続できます。

そのため、Webサイト公開、サーバー移転、ドメイン移管、CDN導入、メール設定、LP公開などを行う際には、DNSの正引きが正しく機能しているかを必ず確認することが大切です。

以上、DNSの正引きについてでした。

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