DNSプロトコルとはなんなのか

DNSプロトコルとは、インターネット上でドメイン名に対応する情報を問い合わせるための通信ルールです。

DNSは Domain Name System の略で、日本語では「ドメインネームシステム」と呼ばれます。

一般的には、

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

として説明されることが多いです。

たとえば、ブラウザに以下のようなURLを入力したとします。

https://www.example.com/

人間にとっては www.example.com のようなドメイン名は覚えやすいですが、コンピューターが通信相手を特定するには、実際にはIPアドレスが必要です。

そこでDNSが、

www.example.com のIPアドレスは何ですか？

と問い合わせ、

このIPアドレスです

と答えを返します。

このように、DNSはインターネット上で「名前」から「住所」を調べるための重要な仕組みです。

ただし、厳密にいうとDNSが扱うのはIPアドレスだけではありません。

メールサーバー情報、ドメイン所有権確認、メール認証、証明書発行に関する情報など、さまざまなデータも扱います。

そのため、より正確には次のように説明できます。

DNSは、ドメイン名に対応するIPアドレスやメールサーバーなどの情報を問い合わせるための、分散型の名前解決システムです。

DNSが必要な理由

インターネット上の通信では、サーバーや端末を識別するためにIPアドレスが使われます。

しかし、人間がWebサイトにアクセスするたびにIPアドレスを覚えるのは現実的ではありません。

たとえば、以下のような数字の並びを毎回入力するのは不便です。

192.0.2.10
203.0.113.25
2001:db8::1

そこで、人間には覚えやすいドメイン名を使います。

example.com
google.com
yahoo.co.jp

そして、コンピューター側ではDNSを使って、そのドメイン名に対応するIPアドレスを調べます。

この変換処理を名前解決といいます。

DNSは「電話帳」にたとえられる

DNSはよく「インターネットの電話帳」とたとえられます。

電話をかけるとき、人間は相手の名前を覚えます。

山田さん
佐藤さん
株式会社〇〇

しかし、実際に電話をかけるには電話番号が必要です。

DNSも同じです。

人間は、

example.com

という名前を覚えます。

しかし、コンピューターが通信するには、

192.0.2.10

のようなIPアドレスが必要です。

DNSは、

example.com という名前の相手は、どのIPアドレスですか？

を調べる仕組みです。

ただし、DNSは単なる一覧表ではありません。

世界中に分散された、階層型のデータベースとして動いています。

DNSプロトコルとDNSシステムの違い

DNSという言葉は、文脈によって少し意味が変わります。

DNSシステム

DNSシステムとは、ドメイン名を階層的・分散的に管理する仕組み全体のことです。

たとえば、次のような要素が含まれます。

ルートDNSサーバー
TLD DNSサーバー
権威DNSサーバー
リゾルバDNSサーバー
DNSレコード
DNSキャッシュ

DNSプロトコル

DNSプロトコルとは、DNSクライアントとDNSサーバー、またはDNSサーバー同士が問い合わせ・応答を行うための通信ルールです。

つまり、

このドメインのAレコードを教えてください
このドメインのMXレコードを教えてください
このドメインのTXTレコードを教えてください

といった問い合わせと応答の形式を定めているのがDNSプロトコルです。

DNSレコード

DNSレコードとは、ドメイン名に紐づく具体的な情報です。

代表的なものには、Aレコード、AAAAレコード、CNAMEレコード、MXレコード、TXTレコードなどがあります。

DNSの基本的な名前解決の流れ

ユーザーがWebサイトにアクセスするとき、DNSではおおまかに次のような処理が行われます。

ユーザーがURLを入力
↓
ブラウザがホスト名を確認
↓
端末やブラウザのDNSキャッシュを確認
↓
リゾルバDNSサーバーへ問い合わせ
↓
必要に応じてルートDNSサーバーへ問い合わせ
↓
TLD DNSサーバーへ問い合わせ
↓
権威DNSサーバーへ問い合わせ
↓
IPアドレスを取得
↓
Webサーバーへ接続

ただし、実際には毎回すべてのDNSサーバーをたどるわけではありません。

過去に取得した情報がキャッシュされていれば、途中の問い合わせは省略されます。

DNSに登場する主なサーバー

DNSを理解するには、いくつかのサーバーの役割を知っておく必要があります。

リゾルバDNSサーバー

リゾルバDNSサーバーは、ユーザーの代わりにDNS問い合わせを行うサーバーです。

「再帰DNSサーバー」「フルサービスリゾルバ」と呼ばれることもあります。

ユーザーのPCやスマートフォンは、通常、まずリゾルバDNSサーバーに問い合わせます。

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

するとリゾルバDNSサーバーは、自分のキャッシュを確認します。

キャッシュがあれば、その情報を返します。

キャッシュがなければ、ルートDNSサーバーやTLD DNSサーバー、権威DNSサーバーに問い合わせて、最終的な答えを取得します。

家庭や会社のネットワークでは、以下のようなDNSサーバーが使われることがあります。

プロバイダのDNSサーバー
Google Public DNS
Cloudflare DNS
企業内DNSサーバー
ルーターに設定されたDNS

ルートDNSサーバー

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

ルートDNSサーバーは、世界中のすべてのドメインのIPアドレスを直接知っているわけではありません。

代わりに、

.com については、このTLD DNSサーバーへ
.jp については、このTLD DNSサーバーへ
.org については、このTLD DNSサーバーへ

というように、次に問い合わせるべきサーバーを教えてくれます。

TLD DNSサーバー

TLDは Top Level Domain の略です。

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

.com
.jp
.net
.org
.info

TLD DNSサーバーは、そのTLD配下のドメインについて、どの権威DNSサーバーに問い合わせればよいかを教えてくれます。

たとえば、example.com について問い合わせたい場合、.com のTLD DNSサーバーは、

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

と案内します。

なお、co.jp は厳密にはTLDではありません。TLDは .jp であり、co.jp は .jp 配下の属性型JPドメインの分類です。

階層としては、次のようになります。

.          ルート
jp         TLD
co         jp配下の分類
example    登録名
www        ホスト名・サブドメイン

権威DNSサーバー

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

たとえば、example.com の権威DNSサーバーには、以下のような情報が登録されています。

example.com のAレコード
www.example.com のCNAMEレコード
example.com のMXレコード
example.com のTXTレコード
example.com のNSレコード

最終的な答えを持っているのが、この権威DNSサーバーです。

Webサイト運営者やドメイン管理者がDNS設定を変更するとき、多くの場合、この権威DNSサーバー上のDNSレコードを編集しています。

DNSの名前解決の具体例

ここでは、ユーザーが www.example.com にアクセスする場合を例に説明します。

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

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

すでにキャッシュがあれば、DNSサーバーに問い合わせずに、そのIPアドレスを使います。

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

キャッシュがなければ、端末は設定済みのリゾルバDNSサーバーに問い合わせます。

www.example.com のAレコードを教えてください

Aレコードとは、ドメイン名をIPv4アドレスに対応づけるDNSレコードです。

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

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

ルートDNSサーバーは、

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

と返します。

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

次に、リゾルバは .com のTLD DNSサーバーに問い合わせます。

TLD DNSサーバーは、

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

と返します。

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

最後に、リゾルバは example.com の権威DNSサーバーに問い合わせます。

権威DNSサーバーは、

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

のように答えを返します。

ここで示したIPアドレスは説明用の例です。

実際のIPアドレスは、ドメインや環境、時期によって異なります。

ブラウザがWebサーバーへ接続する

IPアドレスを取得した端末は、そのIPアドレスに対して通信を開始します。

Webサイトの場合、その後にHTTPやHTTPSを使ってWebページのデータを取得します。

つまり、DNSはWebページそのものを取得する仕組みではありません。

DNSの役割は、あくまで次の部分です。

ドメイン名から接続先を調べる

その後のWebページ取得には、HTTPやHTTPSが使われます。

DNSの問い合わせ方式

DNSの問い合わせには、大きく分けて「再帰問い合わせ」と「反復問い合わせ」があります。

再帰問い合わせ

再帰問い合わせとは、クライアントがリゾルバDNSサーバーに対して、

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

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

一般的なPCやスマートフォンは、リゾルバDNSサーバーに対して再帰問い合わせを行います。

反復問い合わせ

反復問い合わせとは、問い合わせ先のDNSサーバーが、

私は最終的な答えを知りませんが、次はこのサーバーに聞いてください

と返す方式です。

リゾルバDNSサーバーが、ルートDNSサーバー、TLD DNSサーバー、権威DNSサーバーをたどるときに使われます。

DNSプロトコルが使うポート番号

DNSでは、伝統的に以下のポートが使われます。

UDP 53番ポート
TCP 53番ポート

UDP 53番ポート

DNSでは、通常の問い合わせにUDP 53番ポートがよく使われます。

UDPは接続確立の手間が少なく、軽量で高速です。

DNSの問い合わせと応答は小さなデータで済むことが多いため、UDPと相性が良いとされています。

TCP 53番ポート

DNSでは、TCP 53番ポートも正式に使われます。

かつては「DNSは基本UDPで、TCPは例外的」という説明がよくされていました。

実務的には今でもUDPが多く使われますが、現代のDNSではTCPも重要なトランスポートです。

TCPが使われるケースには、以下があります。

DNS応答が大きい場合
UDP応答が切り詰められた場合
DNSSECによって応答サイズが大きくなる場合
ゾーン転送を行う場合
実装や運用方針でTCPを使う場合

そのため、DNSを正確に理解するなら、

DNSはUDP 53番だけでなく、TCP 53番も使う

と覚えておくとよいです。

DNSメッセージの構造

DNSの問い合わせや応答のメッセージには、いくつかのセクションがあります。

ヘッダー

ヘッダーには、問い合わせIDや各種フラグ、応答コードなどが含まれます。

問い合わせIDは、どの問い合わせに対する応答なのかを識別するために使われます。

質問セクション

質問セクションには、問い合わせたい名前とレコード種別が入ります。

例：

名前：www.example.com
種別：A

これは、

www.example.com のAレコードを教えてください

という意味です。

回答セクション

回答セクションには、問い合わせに対する実際の答えが入ります。

例：

www.example.com A 192.0.2.10

権威セクション

権威セクションには、対象ドメインを管理する権威DNSサーバーに関する情報が含まれることがあります。

追加情報セクション

追加情報セクションには、問い合わせ結果を補助する情報が含まれることがあります。

たとえば、NSレコードで示されたネームサーバーのIPアドレスが追加情報として含まれる場合があります。

DNSレコードとは

DNSレコードとは、ドメイン名に紐づく情報のことです。

DNSでは、目的に応じてさまざまな種類のレコードを使います。

主なDNSレコードの種類

Aレコード

Aレコードは、ドメイン名をIPv4アドレスに対応づけるレコードです。

例：

example.com A 192.0.2.10

Webサイトの表示でよく使われる基本的なレコードです。

AAAAレコード

AAAAレコードは、ドメイン名をIPv6アドレスに対応づけるレコードです。

例：

example.com AAAA 2001:db8::1

IPv6に対応した環境では、AAAAレコードが使われます。

AレコードとAAAAレコードの違いは次の通りです。

Aレコード     → IPv4アドレス
AAAAレコード  → IPv6アドレス

CNAMEレコード

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

例：

www.example.com CNAME example.com

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

CNAMEは、外部サービスやCDN、LP作成ツールなどと独自ドメインを接続するときによく使われます。

たとえば、次のような場面です。

lp.example.com をLP作成ツールに向ける
blog.example.com を外部CMSに向ける
track.example.com をメール配信ツールに向ける
cdn.example.com をCDNサービスに向ける

ただし、CNAMEには重要な制約があります。

CNAMEが設定された名前には、原則としてA、AAAA、MX、TXTなどの他の通常レコードを同居させられません。

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

www.example.com CNAME service.example.net
www.example.com A 192.0.2.10

CNAMEは「この名前は別名である」という意味を持つため、同じ名前に別のレコードを混在させると矛盾が生じます。

MXレコード

MXレコードは、メールを受信するサーバーを指定するレコードです。

MXは Mail Exchange の略です。

例：

example.com MX 10 mail.example.com

この場合、example.com 宛のメールは mail.example.com で受け取る、という意味になります。

MXレコードでは、通常、IPアドレスではなくメールサーバーのホスト名を指定します。

そのホスト名は、さらにAレコードやAAAAレコードによってIPアドレスに名前解決されます。

TXTレコード

TXTレコードは、任意のテキスト情報をDNSに登録するためのレコードです。

現在では、メール認証やドメイン所有権確認によく使われます。

代表的な用途は以下です。

SPF
DKIM
DMARC
Google Search Consoleの所有権確認
Microsoft 365のドメイン確認
Google Workspaceのドメイン確認
広告ツールのドメイン認証
MAツールの送信ドメイン認証

Webマーケティングの現場では、TXTレコードは非常によく使われます。

特にメール配信や広告運用、アクセス解析、Search Console設定などに関係します。

NSレコード

NSレコードは、そのドメインのDNS情報を管理するネームサーバーを指定するレコードです。

例：

example.com NS ns1.example-dns.com
example.com NS ns2.example-dns.com

NSレコードは、DNSの階層構造における委任にも関係します。

たとえば、.com 側では、

example.com については、このネームサーバーに聞いてください

という情報を持っています。

これにより、DNSの問い合わせは、親のゾーンから子のゾーンへと正しくたどれるようになります。

SOAレコード

SOAレコードは、そのDNSゾーンの基本情報を持つレコードです。

SOAは Start of Authority の略です。

SOAレコードには、主に以下のような情報が含まれます。

プライマリネームサーバー
管理者情報
シリアル番号
リフレッシュ間隔
リトライ間隔
有効期限
最小TTL関連の値

通常のWebサイト運用では直接編集する機会は少ないですが、DNSゾーンの管理において重要なレコードです。

PTRレコード

PTRレコードは、IPアドレスからドメイン名を調べるためのレコードです。

通常のDNSが、

ドメイン名 → IPアドレス

を調べるのに対し、PTRレコードは、

IPアドレス → ドメイン名

を調べるために使われます。

これを逆引きDNSといいます。

メールサーバーの信頼性確認などで使われることがあります。

なお、PTRレコードは通常、ドメイン所有者が自由に設定するというより、IPアドレスを管理しているプロバイダやクラウド事業者、ホスティング事業者側で設定することが多いです。

CAAレコード

CAAレコードは、SSL/TLS証明書を発行できる認証局を指定するためのレコードです。

たとえば、

example.com の証明書は、この認証局だけが発行できる

という制御に使われます。

Webサイトのセキュリティ運用では、CAAレコードも重要になる場合があります。

DNSの階層構造

DNSは階層構造になっています。

たとえば、以下のドメインを考えます。

www.example.co.jp

これを右から左へ分解すると、次のようになります。

.          ルート
jp         TLD
co         jp配下の分類
example    登録名
www        ホスト名・サブドメイン

DNSの名前解決では、基本的に右側の上位階層から左側の下位階層へとたどっていきます。

.
↓
jp
↓
co.jp
↓
example.co.jp
↓
www.example.co.jp

この階層構造によって、DNSは世界中のドメイン情報を1か所で集中管理せず、分散して管理できます。

DNSキャッシュとは

DNSキャッシュとは、一度取得したDNS情報を一定時間保存しておく仕組みです。

DNSでは、毎回すべてのサーバーに問い合わせるわけではありません。

キャッシュがあることで、問い合わせ回数を減らし、Webサイトへのアクセスを高速化できます。

DNSキャッシュは、以下のような場所に保存されることがあります。

ブラウザ
OS
ルーター
リゾルバDNSサーバー
企業内DNSサーバー

たとえば、すでに www.example.com のIPアドレスを取得している場合、同じ情報を再度ルートDNSサーバーからたどる必要はありません。

TTLとは

TTLは Time To Live の略で、DNSレコードのキャッシュ有効時間を表します。

たとえば、TTLが 3600 に設定されている場合、そのDNS情報は3600秒、つまり1時間キャッシュされます。

TTL 300    → 5分
TTL 3600   → 1時間
TTL 86400  → 24時間

TTLが長いと、DNS問い合わせの回数が減り、効率的です。

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

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

DNS変更がすぐ反映されない理由

DNS設定を変更したあと、すぐに新しい設定が反映されないことがあります。

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

DNSを変更したのに、まだ古いサイトが表示される
一部の人だけ新しいサイトが見える
メール設定を変えたのに、まだ旧設定の影響が残る

この主な原因はDNSキャッシュです。

権威DNSサーバー上の設定を変更しても、リゾルバDNSサーバーや端末側に古い情報がキャッシュされている場合、そのキャッシュが期限切れになるまでは古い情報が使われることがあります。

この現象は、実務上「DNS浸透」と呼ばれることがあります。

ただし、技術的には、DNS情報が世界中にじわじわ配布されているというより、各所に残っているキャッシュがTTL切れになるのを待っている状態です。

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

DNSとHTTP/HTTPSの違い

DNSとHTTP/HTTPSは混同されやすいですが、役割が異なります。

DNSの役割

DNSは、ドメイン名に対応するIPアドレスなどを調べる仕組みです。

example.com → 192.0.2.10

HTTP/HTTPSの役割

HTTP/HTTPSは、Webページのデータをやり取りするためのプロトコルです。

やり取りされるデータには、たとえば以下があります。

HTML
CSS
JavaScript
画像
動画
APIレスポンス

Webサイトにアクセスするときの流れは、おおまかに次のようになります。

1. URLからホスト名を取り出す
2. DNSでホスト名を名前解決する
3. 取得したIPアドレスへ接続する
4. HTTPSの場合は暗号化通信を確立する
5. HTTPリクエストを送る
6. Webページのデータを受け取る
7. ブラウザがページを表示する

DNSは「住所を調べる仕組み」、HTTP/HTTPSは「その住所に行ってデータを受け取る仕組み」と考えるとわかりやすいです。

DNSとURLの関係

URLは、Web上の場所を表す文字列です。

たとえば、以下のURLを見てみます。

https://www.example.com/page/index.html

このうちDNSが主に関係するのは、ホスト名の部分です。

www.example.com

URLを分解すると、次のようになります。

https://                  スキーム
www.example.com            ホスト名
/page/index.html           パス

DNSはURL全体を名前解決するわけではありません。

DNSが扱うのは、基本的にホスト名・ドメイン名の部分です。

DNSSECとは

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

DNSはインターネットの基盤技術ですが、もともと強いセキュリティ機能を前提に設計されたものではありません。

そのため、攻撃者が偽のDNS応答を返すと、ユーザーを本来とは異なるサーバーへ誘導できる可能性があります。

DNSSECでは、電子署名を使ってDNS応答の正当性を検証します。

重要なのは、DNSSECはDNS通信を暗号化する仕組みではないという点です。

DNSSECの役割は、以下です。

DNS応答が本物かどうかを検証する
DNSデータが改ざんされていないか確認する

一方で、DNS問い合わせの内容を隠すものではありません。

DNS over HTTPSとDNS over TLS

従来のDNS問い合わせは、平文で送られることが多く、通信経路上でどのドメインに問い合わせているか見える可能性がありました。

そこで、DNS問い合わせのプライバシーを保護するために、以下のような仕組みが使われます。

DNS over HTTPS
DNS over TLS

DNS over HTTPS

DNS over HTTPSは、DNS問い合わせをHTTPS通信の中で行う仕組みです。

略して DoH と呼ばれます。

通常のWeb通信と同じHTTPSを使うため、DNS問い合わせの内容を暗号化できます。

DNS over TLS

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

略して DoT と呼ばれます。

DoTでは、通常TCP 853番ポートが使われます。

DNSSEC、DoH、DoTの違いを整理すると、以下のようになります。

DNSSEC  → DNS応答が正当かどうかを検証する
DoH     → DNS通信をHTTPSで暗号化する
DoT     → DNS通信をTLSで暗号化する

DNSで起きやすいトラブル

DNSはWebサイトやメールの運用に深く関わるため、設定ミスがあると大きな影響が出ます。

Aレコードの設定ミス

AレコードのIPアドレスを間違えると、Webサイトが正しく表示されません。

たとえば、古いサーバーのIPアドレスを指定したままだと、ユーザーが旧サーバーへアクセスしてしまうことがあります。

CNAMEレコードの設定ミス

外部サービスに独自ドメインを接続するとき、CNAMEレコードを使うことがあります。

この設定を間違えると、LP作成ツール、CMS、CDN、メール配信ツールなどでドメイン認証に失敗することがあります。

MXレコードの設定ミス

MXレコードを間違えると、メールが届かなくなる可能性があります。

Google WorkspaceやMicrosoft 365へメール環境を移行する際は、特に注意が必要です。

TXTレコードの設定ミス

TXTレコードの設定ミスは、メール認証やドメイン認証に影響します。

特に、以下の設定を間違えると、メール到達率やなりすまし対策に悪影響が出ます。

SPF
DKIM
DMARC

メールマーケティングや営業メール、会員向け通知メールを運用する場合、TXTレコードの設定は非常に重要です。

NSレコードの設定ミス

NSレコードを誤って変更すると、そのドメイン全体のDNS管理先が変わってしまうことがあります。

新しいDNS管理先に必要なレコードが移行されていない場合、Webサイトやメールが停止する可能性があります。

TTLが長すぎる

TTLが長いと、DNS変更後も古い情報が長くキャッシュされます。

サーバー移転やメール移行の前には、あらかじめTTLを短くしておくと、切り替え時の影響を抑えやすくなります。

DNS設定でよく見る項目

DNS管理画面では、以下のような項目がよく表示されます。

ホスト名
タイプ
値
TTL
優先度

ホスト名

ホスト名は、対象となる名前です。

管理画面では、以下のように表示されることがあります。

@
www
mail
lp
blog

@ は、多くのDNS管理画面でルートドメイン、つまり example.com そのものを表します。

www は、www.example.com を意味します。

タイプ

タイプは、DNSレコードの種類です。

例：

A
AAAA
CNAME
MX
TXT
NS
CAA

値

値は、設定する内容です。

例：

192.0.2.10
example.com
mail.example.com
v=spf1 include:_spf.example.com ~all

TTL

TTLは、DNSキャッシュの有効時間です。

例：

300
3600
86400

優先度

優先度は、主にMXレコードで使われます。

数値が小さいほど優先度が高くなります。

例：

10 mail1.example.com
20 mail2.example.com

この場合、通常は mail1.example.com が優先されます。

apexドメインにCNAMEを設定できない理由

example.com のようなルートドメイン部分は、apexドメインまたはゾーンapexと呼ばれます。

通常、apexドメインにはCNAMEレコードを設定できません。

理由は、apexドメインにはSOAレコードやNSレコードなど、DNSゾーンに必要なレコードが存在するためです。

一方で、CNAMEが設定された名前には、原則として他の通常レコードを同居させられません。

そのため、apexドメインにCNAMEを設定すると、SOAやNSと衝突してしまいます。

この問題を解決するために、DNS事業者によっては以下のような独自機能を提供している場合があります。

ALIAS
ANAME
CNAME flattening

これらは、見かけ上CNAMEのように使いながら、実際にはAレコードやAAAAレコードのように応答する仕組みです。

外部サービスにルートドメインを接続する場合によく関係します。

DNSとWebマーケティングの関係

DNSは技術寄りの分野ですが、Webマーケティングの実務にも深く関係します。

特に、独自ドメイン、LP、メール配信、広告計測、Search Console、CDN、MAツールなどを扱う場合、DNS設定が必要になることが多いです。

独自ドメインのWebサイト公開

コーポレートサイト、オウンドメディア、ECサイト、LPなどを公開するとき、ドメインをWebサーバーへ向ける必要があります。

このとき、AレコードやCNAMEレコードを設定します。

LP作成ツールとの接続

外部のLP作成ツールやノーコードツールを使う場合、サブドメインをCNAMEで接続することがあります。

例：

lp.example.com
campaign.example.com
seminar.example.com

この設定を誤ると、LPが表示されなかったり、サービス側のドメイン認証に失敗したりします。

メール配信の認証

メールマーケティングでは、DNS設定が非常に重要です。

特に以下の設定が関係します。

SPF
DKIM
DMARC
MX
Return-Path
カスタムトラッキングドメイン

これらの設定が不十分だと、メールが迷惑メールに入りやすくなったり、なりすまし対策が弱くなったりします。

Google Search Consoleの所有権確認

Google Search Consoleでドメインプロパティを設定する場合、TXTレコードによる所有権確認が必要になることがあります。

DNSに指定されたTXTレコードを追加することで、

このドメインを管理しているのは自分です

と証明します。

広告・計測ツールのドメイン認証

広告配信ツール、MAツール、CDP、メール配信ツールなどでも、ドメイン認証のためにDNS設定を求められることがあります。

よく使われるのはTXTレコードやCNAMEレコードです。

CDNやWAFの導入

サイト高速化やセキュリティ強化のために、CDNやWAFを導入する場合もDNS設定が関係します。

たとえば、以下のようなサービスを使う際に、DNSレコードの変更が必要になることがあります。

Cloudflare
AWS CloudFront
Fastly
Akamai
各種WAFサービス

DNS設定を誤ると、サイトが表示されない、SSL証明書が正しく発行されない、一部ページだけ不安定になる、といった問題が起きることがあります。

DNSをコマンドで確認する方法

DNS設定は、コマンドでも確認できます。

nslookup

nslookup は、WindowsやmacOSで使いやすい基本的なDNS確認コマンドです。

nslookup example.com

Aレコードを確認する場合は、次のようにします。

nslookup -type=A example.com

MXレコードを確認する場合は、次のようにします。

nslookup -type=MX example.com

TXTレコードを確認する場合は、次のようにします。

nslookup -type=TXT example.com

dig

dig は、LinuxやmacOSでよく使われるDNS確認コマンドです。

dig example.com

Aレコードを確認する場合は、次のようにします。

dig example.com A

MXレコードを確認する場合は、次のようにします。

dig example.com MX

TXTレコードを確認する場合は、次のようにします。

dig example.com TXT

NSレコードを確認する場合は、次のようにします。

dig example.com NS

権威DNSサーバーまでたどる様子を確認したい場合は、次のようなコマンドも使えます。

dig +trace example.com

host

host は、シンプルにDNS情報を確認できるコマンドです。

host example.com

MXレコードを確認する場合は、次のようにします。

host -t MX example.com

DNS設定を変更するときの注意点

DNS設定は、Webサイトやメールに直接影響します。

変更する前には、必ず現在の設定を確認しておくことが重要です。

変更前のレコードを控える

DNS設定を変更する前に、現在のレコードを控えておきましょう。

特に以下は重要です。

Aレコード
AAAAレコード
CNAMEレコード
MXレコード
TXTレコード
NSレコード
TTL

設定ミスがあった場合でも、元に戻しやすくなります。

メール関連レコードを削除しない

Webサイトの設定だけを変えるつもりで、誤ってMXレコードやTXTレコードを削除すると、メールに影響が出ることがあります。

特に以下は注意が必要です。

MX
SPF
DKIM
DMARC

メール配信や問い合わせフォーム、会員向け通知に影響する可能性があります。

CNAMEと他のレコードを同じ名前に置かない

CNAMEを設定した名前には、原則として他の通常レコードを同居させられません。

たとえば、以下のような設定は避ける必要があります。

www.example.com CNAME service.example.net
www.example.com A 192.0.2.10

TTLを事前に短くしておく

サーバー移転やメール移行など、大きなDNS変更を行う場合は、事前にTTLを短くしておくと切り替えがスムーズです。

たとえば、変更前にTTLを以下のように短くしておくことがあります。

300秒
600秒

ただし、TTLを短くする前に古いTTLでキャッシュされている情報がある場合、そのキャッシュが切れるまでは影響が残ることがあります。

そのため、重要な移行では、変更直前ではなく前日や数日前から準備するのが安全です。

NS変更時は全レコードの移行を確認する

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

このとき、旧DNSに登録されていたレコードを新DNSに正しく移行していないと、Webサイトやメールが停止する可能性があります。

特に以下は必ず確認しましょう。

Webサイト用のA/AAAA/CNAME
メール用のMX
SPF/DKIM/DMARCなどのTXT
Search Consoleなどの所有権確認TXT
外部サービス連携用のCNAME

DNSプロトコルのまとめ

DNSプロトコルは、ドメイン名に対応する情報を問い合わせるための通信ルールです。

一般的には、ドメイン名をIPアドレスに変換する仕組みとして理解されますが、実際にはメールサーバー情報や認証情報など、さまざまなDNSレコードを扱います。

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

DNSは Domain Name System の略
DNSは分散型・階層型の名前解決システム
DNSプロトコルは問い合わせと応答の通信ルール
ドメイン名からIPアドレスを調べる用途が代表的
AレコードはIPv4アドレスを示す
AAAAレコードはIPv6アドレスを示す
CNAMEレコードは別名を示す
MXレコードはメール受信サーバーを示す
TXTレコードはメール認証や所有権確認などに使われる
NSレコードはネームサーバーを示す
SOAレコードはゾーンの基本情報を示す
PTRレコードは逆引きDNSに使われる
DNSは主にUDP 53番とTCP 53番を使う
DNSキャッシュにより問い合わせ回数を減らしている
TTLはDNSキャッシュの有効時間を示す
DNS変更がすぐ反映されない主な理由はキャッシュ
DNSSECはDNS応答の正当性を検証する
DoHやDoTはDNS通信を暗号化する

DNSは、Webサイト表示、メール送受信、広告計測、Search Console、CDN、SSL証明書、MAツール、メールマーケティングなど、さまざまな仕組みの土台になっています。

普段は目立たない技術ですが、DNS設定を誤るとWebサイトやメールが止まることもあります。

そのため、Web担当者やマーケターであっても、DNSの基本的な仕組みと主要レコードの意味を理解しておくことは非常に重要です。

以上、DNSプロトコルとはなんなのかについてでした。

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