【初心者向け】ドメイン レコード 種類を完全解説｜A・AAAA・CNAME・MX・TXT・NS・SOAの役割と使い分け

Webサイトの公開やサーバー移転、いざ作業を始めようとドメインの管理画面を開いて「うわっ、難しそう……」と手が止まってしまったことはありませんか？

管理画面に並ぶ「A」「CNAME」「MX」といったアルファベットの羅列。なんとなく設定を進めて「もし間違えてクライアントのメールが止まったら……」「サイトが表示されなくなったら……」と不安になることも。実は、DNSレコードの仕組みはポイントさえ押さえてしまえば、決して怖いものではありません。

本記事では、ドメインレコードの基礎知識から、実務でそのまま使える具体的な書き方、さらには「設定したのに反映されない！」といったトラブル時の対処法まで分かりやすく解説します。

この記事を読み終える頃には、ドメイン管理画面への苦手意識がなくなり、自信を持って設定作業を進められるようになっているはずです。それでは、一緒に見ていきましょう！

DNSレコードの種類一覧（A / CNAME / MX / TXT / NS / SOA）と違い

DNSレコードとは「ドメイン名と各種サーバー情報を紐づける設定データ」であり、種類ごとに役割が明確に分かれています。まず全体像を把握することが、DNS設定ミスを防ぐ最短ルートです。

ドメインを取得してサーバーに接続しようとしたとき、「どのレコードを設定すればいいのか分からない」と感じたことはないでしょうか。A、CNAME、MX……記号の羅列に見えるかもしれませんが、それぞれに明確な役割があります。

まず、DNS（Domain Name System）とは何かを一言で説明します。インターネット上のサーバーは「IPアドレス（例：203.0.113.1）」という数字の住所で識別されていますが、人間がこれを覚えるのは困難です。そこでDNSが「example.com → 203.0.113.1」のように、ドメイン名をIPアドレスへ変換（名前解決）する仕組みを提供しています。

そしてDNSレコードとは、その変換ルールを定義したデータの1行1行のことです。

主要DNSレコードの種類一覧

実務でよく使うのは A・CNAME・MX・TXT・NS の5種類です。SOAは意識せずとも自動で設定されているケースがほとんどなので、まずこの5種類の理解が重要です。

A・AAAA・CNAMEレコードの違いと使い分け【Webサイト表示】

Webサイトを表示させるには「Aレコード」が基本です。CNAMEはIPアドレスが頻繁に変わるサービス（CDNやSaaSなど）への接続に使います。AAAAはIPv6対応が必要な場面で追加します。

Aレコード（Address Record）

AレコードはDNSレコードの中で最も基本的な種類で、ドメイン名をIPv4アドレスに直接紐づけます。

# Aレコードの記述例（ゾーンファイル形式）
example.com.     3600  IN  A  203.0.113.1
www.example.com. 3600  IN  A  203.0.113.1

上記の設定により、example.comとwww.example.comの両方が同じサーバー（203.0.113.1）に向きます。お名前.comやXserverの管理画面では以下のように入力します。

AAAAレコード（Quad-A Record）

AAAAレコードはAレコードのIPv6版です。IPv6アドレス（例：2001:db8::1）を指定します。

example.com.  3600  IN  AAAA  2001:db8::1

現状、多くのレンタルサーバーやVPSはIPv4が主流ですが、クラウドサービスやCDNでIPv6が使われるケースが増えています。サーバー側がIPv6に対応しているなら、AレコードとAAAAレコードの両方を設定しておくと接続の安定性が向上します。

CNAMEレコード（Canonical Name Record）

CNAMEは「正式なドメイン名（別名）」を定義するレコードで、あるドメイン名を別のドメイン名にエイリアス（別名参照）させます。

# www.example.com を example.com へエイリアス
www.example.com.  3600  IN  CNAME  example.com.

# CloudflareでShopifyストアに接続する例
shop.example.com.  3600  IN  CNAME  shops.myshopify.com.

CNAMEが特に威力を発揮するのはSaaSサービスや CDNとの連携時です。たとえばShopify・Netlify・Vercelなどのサービスは、IPアドレスが変わることがあります。もしAレコードでIPアドレスを直接指定していたら、サービス側がIPを変更するたびに自分でDNS設定を更新しなければなりません。CNAMEでサービス側のドメイン名を指定しておけば、IPアドレスの変更はサービス側が管理してくれるため、自分の設定を変える必要がなくなります。

MX・TXT（SPF / DKIM / DMARC）の役割【メール送受信・認証】

MXレコードはメールの「受信先」を指定するレコードです。TXTレコードはSPF・DKIM・DMARCという「送信元の正当性を証明する仕組み」の設定に使います。メール設定ではこの両方が必須です。

MXレコード（Mail Exchanger Record）

MXレコードはメールを受け取るサーバー（メールサーバー）を指定するレコードです。誰かがinfo@example.comにメールを送ると、送信側のメールサーバーはDNSのMXレコードを参照して「このドメインのメールはどのサーバーが受け取るのか」を確認します。

# Google Workspace（旧G Suite）のMXレコード設定例
example.com.  3600  IN  MX  1   aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt4.aspmx.l.google.com.

数字（1、5、10）はPriority（優先度）です。数値が小さいほど優先順位が高く、メールは最初に優先度1のサーバーに配送されます。優先サーバーが応答しない場合にのみ、次の優先度のサーバーが使われます。これがメールの冗長化（耐障害性）を担保する仕組みです。

TXTレコードとSPF・DKIM・DMARC

TXTレコードは任意のテキストデータを格納できる汎用レコードです。用途は多岐にわたりますが、実務で最重要なのがメール認証（SPF・DKIM・DMARC）です。

近年、迷惑メール対策やなりすましメール対策として、これらの認証が設定されていないとメールが届かない、または迷惑メールフォルダに振り分けられるケースが急増しています。

① SPF（Sender Policy Framework）

「このドメインからのメールは、これらのサーバーだけが送信を許可されている」と宣言するレコードです。

# SPFレコードの例（Google Workspaceを使用している場合）
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

# 複数のサービスを使う場合（XserverのSMTPとGoogle Workspaceを併用）
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:xserver.jp ~all"

~allは「上記以外のサーバーからの送信はソフトフェイル（疑わしいが拒否はしない）」を意味します。-allにするとハードフェイル（拒否）になりますが、設定に自信がない初期段階では~allが安全です。

SPFレコードは1ドメインに1つだけ設定します。複数設定するとエラーになるので注意してください。

② DKIM（DomainKeys Identified Mail）

メールに電子署名を付加し、送信途中で改ざんされていないことを受信側が検証できる仕組みです。Google WorkspaceやSendGridなどのサービス側が公開鍵を提供するため、それをTXTレコードに登録します。

# Google WorkspaceのDKIMレコード例（セレクタ名：google）
google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

ホスト名の形式がセレクタ名._domainkey.ドメイン名という点がポイントです。セレクタ名はサービスによって異なります（Google Workspaceならgoogle）。

③ DMARC（Domain-based Message Authentication, Reporting & Conformance）

SPFやDKIMの認証に失敗したメールをどう扱うかのポリシーを定義し、レポートを受け取る仕組みです。

# DMARCレコードの例（まずはモニタリングモードで開始）
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"

p=noneはモニタリングのみで何もしない設定です。運用が安定したらp=quarantine（迷惑メールへ）→p=reject（拒否）と段階的に強化するのがベストプラクティスです。

NS・SOAレコードの役割と編集の注意点【ネームサーバー管理】

NSレコードはDNSの管理権限がどこにあるかを示す最重要レコードです。SOAレコードはゾーンの管理情報を持つ特殊なレコードで、基本的に手動で編集することはありません。

NSレコード（Name Server Record）

NSレコードは「このドメインのDNS情報は、このネームサーバーが管理している」と宣言するレコードです。

# お名前.comのNSレコード例
example.com.  86400  IN  NS  dns1.onamae.com.
example.com.  86400  IN  NS  dns2.onamae.com.

# CloudflareへNSを移管した場合
example.com.  86400  IN  NS  alice.ns.cloudflare.com.
example.com.  86400  IN  NS  bob.ns.cloudflare.com.

NSレコードのTTLは86400（24時間）など長めに設定されていることが多いです。これはネームサーバーの変更が頻繁に起きないことを前提としているためです。

NSレコードの変更は「引越し届け」と同じです。お名前.comで取得したドメインをCloudflareで管理したい場合、お名前.com側の管理画面でNSレコードをCloudflareのものに変更します。この変更が反映されると、以降のDNSクエリはCloudflareのネームサーバーが回答するようになります。

SOAレコード（Start of Authority Record）

SOAレコードはDNSゾーンの管理情報（メタデータ）を持つレコードで、すべてのDNSゾーンに必ず1つ存在します。

# SOAレコードの例
example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
    2024010101  ; シリアル番号（更新のたびに増加）
    3600        ; リフレッシュ間隔（秒）
    900         ; リトライ間隔（秒）
    604800      ; 有効期限（秒）
    300         ; ネガティブキャッシュTTL（秒）
)

含まれる情報は「プライマリネームサーバー名」「管理者のメールアドレス（@をドットに変換）」「シリアル番号」「各種タイマー値」です。

DNSレコードはそれぞれ担当領域が明確です。「Webサイトを表示させたい → Aレコード」「メールを使いたい → MXレコード + TXTレコード（SPF/DKIM/DMARC）」「DNS管理先を変えたい → NSレコード」という対応関係を覚えておくだけで対応が楽になります。

DNSレコードの正しい書き方と設定ルール（ホスト名・値・TTL・Priority）

DNSレコードの設定ミスの大半は「ホスト名の書き方」と「TTLの意味を知らないこと」から発生します。各入力項目の意味を正確に理解すれば、管理画面の種類が変わっても迷わず設定できるようになります。

DNSレコードを設定する管理画面はサービスによってUIが異なりますが、入力する項目の本質はどこも同じです。主な項目は以下の4つです。

この5項目を正確に入力できれば、どのサービスの管理画面でも対応できます。順番に解説します。

ホスト名欄の「@」「www」「*（ワイルドカード）」が持つそれぞれの意味

ホスト名欄は「どのドメイン・サブドメインに対してこのレコードを適用するか」を指定する項目です。「@」はルートドメイン、「www」はwwwサブドメイン、「*」はすべてのサブドメインを意味します。

ホスト名欄の入力を間違えると「設定したはずなのにサイトが表示されない」という典型的なトラブルになります。それぞれの意味を正確に把握しましょう。

「@」：ルートドメインそのもの

@はゾーンの起点（ルートドメイン）を表す記号です。example.comというドメインを取得している場合、@はexample.comそのものを指します。

# 「@」を使ったAレコードの設定イメージ
ホスト名 : @
タイプ   : A
値       : 203.0.113.1
TTL      : 3600

# これは以下と同じ意味
example.com.  3600  IN  A  203.0.113.1

https://example.com（wwwなし）にアクセスしたときにサイトを表示させたいなら、@に対してAレコードを設定します。なお、サービスによっては@の代わりに空欄のままにする、またはドメイン名をそのまま入力する仕様のものもあります（Cloudflareなど）。

「www」：wwwサブドメイン

wwwと入力すると、www.example.comに対する設定になります。

# 「www」を使ったAレコードの設定
ホスト名 : www
タイプ   : A
値       : 203.0.113.1
TTL      : 3600

# または CNAMEでルートドメインへ転送する場合
ホスト名 : www
タイプ   : CNAME
値       : example.com.
TTL      : 3600

サブドメイン名（blog・shop・mailなど）

任意のサブドメインを作りたい場合は、サブドメイン名をそのまま入力します。

# blog.example.com を別サーバーに向ける例
ホスト名 : blog
タイプ   : A
値       : 203.0.113.50
TTL      : 3600

# shop.example.com をShopifyに向ける例
ホスト名 : shop
タイプ   : CNAME
値       : shops.myshopify.com.
TTL      : 3600

「*」（ワイルドカード）：すべてのサブドメイン

（アスタリスク）はワイルドカードと呼ばれ、存在しないサブドメインすべてに一致する設定です。

# ワイルドカードAレコード
ホスト名 : *
タイプ   : A
値       : 203.0.113.1
TTL      : 3600

この設定があると、anything.example.comのように存在しないサブドメインへのアクセスも、指定したIPアドレスに向きます。マルチテナントSaaS（ユーザーごとにサブドメインを発行するサービス）などで使われますが、意図せず設定するとセキュリティリスクになるため、必要な場合のみ使用してください。

反映時間に直結する「TTL（Time To Live）」の仕組みと推奨される「3600」の意味

TTLはDNSの「キャッシュ保持時間（秒）」です。値が大きいほど反映が遅く、小さいほど素早く反映されます。通常運用では「3600（1時間）」、変更作業前は「300（5分）」に下げておくのがプロの作法です。

TTLとは何か

DNSの名前解決は、世界中のDNSサーバーが連携して行われています。毎回ルートDNSまで問い合わせに行くと時間がかかるため、各DNSサーバーは一度調べた結果を一定時間キャッシュ（保存）します。

このキャッシュの有効期限がTTL（Time To Live）です。単位は「秒」です。

# TTLの具体的な数値と時間の対応
300   = 5分
600   = 10分
1800  = 30分
3600  = 1時間（推奨値）
86400 = 24時間

たとえばTTLを86400（24時間）に設定した場合、DNSレコードを変更しても世界中のDNSキャッシュが更新されるまで最大24時間かかります。その間は古いIPアドレスに向いたままになる可能性があります。

なぜ「3600」が推奨なのか

3600（1時間）は「キャッシュ効率」と「変更の反映速度」のバランスが取れた値として、業界標準的に使われています。

• 大きすぎる（86400など）： DNSの問い合わせ負荷は減るが、設定変更時の反映が遅い
• 小さすぎる（60など）： 変更はすぐ反映されるが、DNSサーバーへの問い合わせが頻発してパフォーマンスに影響する場合がある
• 3600（1時間）： 日常運用には十分な反映速度と負荷のバランス

サーバー移転・DNS変更前のプロの対処法

サーバー移転やDNS設定の大幅変更を予定している場合、作業の24〜48時間前にTTLを300（5分）に下げておくことを強く推奨します。

# 作業前の準備（24〜48時間前）
TTL : 300  ← まずこれに変更して待つ

# 作業当日：DNSレコードを変更
値（IPアドレスなど）を新しいものに変更

# 作業後・移転完了後
TTL : 3600  ← 元に戻す

こうすることで、万が一設定ミスがあっても5分後には修正が反映されます。TTLを下げずに移転作業をして「サイトが丸一日見られなくなった」というトラブルは現場でよく起きます。

お名前.comやムームードメイン等の管理画面で迷わない入力手順

管理画面のUIはサービスによって異なりますが、入力する内容は同じです。各サービスの「表記のクセ」を把握すれば、どの画面でも迷わず設定できます。

お名前.com での設定手順

お名前.comはDNSレコード設定画面で「ホスト名」「TYPE」「VALUE」「TTL」を入力します。

【お名前.com DNS設定 入力例：Aレコード】
ホスト名 : （空白 = @と同じ意味）
TYPE     : A
VALUE    : 203.0.113.1
TTL      : 3600

【お名前.com DNS設定 入力例：CNAMEレコード】
ホスト名 : www
TYPE     : CNAME
VALUE    : example.com.   ← 末尾のドット（.）は不要な場合が多い
TTL      : 3600

ムームードメイン での設定手順

ムームードメインはロリポップ！と連携しているケースが多く、「ムームーDNS」を使う場合と「カスタム設定」を使う場合があります。

【ムームードメイン カスタム設定 入力例：Aレコード】
サブドメイン : （空白）
種別         : A
内容         : 203.0.113.1

【ムームードメイン カスタム設定 入力例：TXTレコード（SPF）】
サブドメイン : （空白）
種別         : TXT
内容         : v=spf1 include:_spf.google.com ~all

Xserver（エックスサーバー）での設定手順

XserverはサーバーパネルとドメインパネルでDNS設定の場所が異なります。ドメインをXserverのネームサーバーで管理している場合は、サーバーパネルの「DNSレコード設定」から行います。

【Xserver DNS設定 入力例：Aレコード】
ホスト名 : @
種別     : A
内容     : 203.0.113.1
TTL      : 3600（デフォルト）

【Xserver DNS設定 入力例：TXTレコード（DMARC）】
ホスト名 : _dmarc
種別     : TXT
内容     : v=DMARC1; p=none; rua=mailto:report@example.com
TTL      : 3600

Cloudflare での設定手順

CloudflareはUIが英語ですが、非常に直感的です。また、Cloudflare独自の「プロキシ（オレンジ雲）」機能があります。

【Cloudflare DNS設定 入力例：Aレコード】
Type    : A
Name    : example.com（または @ と入力）
IPv4    : 203.0.113.1
TTL     : Auto（プロキシON時は自動）
Proxy   : Proxied（CDN・DDoS保護を使う場合）
         DNS only（DNSのみの場合）

【Cloudflare DNS設定 入力例：CNAMEレコード】
Type    : CNAME
Name    : www
Target  : example.com
TTL     : Auto

各サービスの入力項目対応表

DNSレコードの書き方で覚えておくべき核心は3点です。

1. ホスト名の@はルートドメインを指す、
2. TTLは通常3600・変更前は300に下げる、
3. 管理画面の表記は違っても入力内容は同じ。

この3点を押さえるだけで、どのサービスの管理画面でも迷わず設定できるようになります。次のセクションでは、混同されやすいNSレコード・CNAMEレコード・SOAレコードの違いを徹底的に整理します。

ネームサーバー（NS）とCNAME・SOAレコードの決定的な違い

NS・CNAME・SOAは「どれもドメインに関するレコード」という共通点から混同されがちですが、役割のレイヤーがまったく異なります。NSは「DNS管理の権限ごと委譲する」、CNAMEは「特定ホスト名の参照先を別名で指定する」、SOAは「ゾーン全体のメタ情報を管理する」という、それぞれ独立した役割を持っています。

この3つの混同は、DNS設定トラブルの中でも特に根深いものです。「NSを変えればCNAMEも変わる」「CNAMEを設定すればNSも変わる」といった誤解を持ったまま作業すると、サイト全体が表示されなくなる・メールが届かなくなるといった重大インシデントに発展します。本セクションでは、この3つの違いを「役割の階層」という視点で徹底的に整理します。

管理権限を委譲する「NSレコード」と特定ホストを転送する「CNAME」の混同回避

NSレコードは「DNS管理の本部をどこに置くか」を決める組織レベルの設定です。CNAMEは「特定の部屋の案内板」に過ぎません。影響範囲がまったく異なるため、絶対に混同してはいけません。

NSレコードの本質：「管理権限の委譲」

NSレコード（Name Server Record）が担うのは、ドメインのDNSゾーン全体の管理権限をどのネームサーバーに委ねるかの宣言です。

わかりやすく言えば、「example.comに関するDNSの質問は、すべてこのサーバーに聞いてください」という公式の管理者登録です。

# お名前.comからCloudflareへNSを移管した場合
example.com.  86400  IN  NS  alice.ns.cloudflare.com.
example.com.  86400  IN  NS  bob.ns.cloudflare.com.

このNSレコードが変更されると、example.comのすべてのDNSレコード（A・MX・TXT・CNAMEなど）の回答権限が、新しいネームサーバーに移ります。つまりNSレコードの変更は「DNS設定の引越し」であり、影響範囲はドメイン全体です。

NSレコードが影響する範囲のイメージ

【NSレコードの影響範囲】

 example.com（ドメイン全体）
 └── NSレコード → alice.ns.cloudflare.com  ← ここが変わると…
      ├── Aレコード（すべて）
      ├── MXレコード（すべて）
      ├── TXTレコード（すべて）
      ├── CNAMEレコード（すべて）
      └── その他すべてのDNSレコード
           ↑ すべての管理権限が移管先に移る

これに対してCNAMEレコードは、影響範囲が設定した1つのホスト名のみです。

CNAMEレコードの本質：「特定ホストの別名参照」

CNAMEレコードは、あるホスト名を別のホスト名の「別名（エイリアス）」として定義するだけです。NSレコードのようにゾーン全体の管理権限を動かすことはありません。

# CNAMEの影響範囲：shop.example.comのみ
shop.example.com.  3600  IN  CNAME  shops.myshopify.com.

# これが影響するのはshop.example.comだけ
# example.comのAレコードにもMXレコードにも一切影響しない

shop.example.comにアクセスしたユーザーのDNS解決の流れは以下のようになります。

【CNAMEの名前解決フロー】

1. ユーザーが shop.example.com にアクセス
         ↓
2. DNSが shop.example.com のCNAMEを確認
   → shops.myshopify.com という別名を発見
         ↓
3. 今度は shops.myshopify.com のAレコードを確認
   → 203.0.113.99 というIPアドレスを取得
         ↓
4. ユーザーのブラウザが 203.0.113.99 に接続

このようにCNAMEは「最終的にAレコードで解決されるまでの中継点」に過ぎません。NSレコードのように管理権限を動かす力はありません。

NS vs CNAME：決定的な違いの対比表

よくある混同ケースと正しい対処

ケース①：「CloudflareでCNAMEを設定したのにNSも変わってしまった」

これはCloudflareへの移管手順を踏んだ際に起きる誤解です。CloudflareでCNAMEを設定したのではなく、Cloudflareへの移管時にNSレコードを変更したのが原因です。CNAMEの設定自体にNSを変える力はありません。

ケース②：「NSをお名前.comに戻したらCNAMEの設定も消えた」

NSレコードを変更すると、管理権限ごと移動するため、移管前のゾーンで設定していたCNAMEなどのレコードは新しい管理先には引き継がれません。NSを変更する前に必ずすべてのDNSレコードをメモ・エクスポートしてから作業してください。

# 作業前に現在のDNSレコードを確認・記録する方法（macOS/Linux）
dig example.com ANY
dig example.com A
dig example.com MX
dig example.com TXT
dig example.com NS

ケース③：「ルートドメインにCNAMEを設定しようとしたらエラーになった」

これはDNS仕様上の正常な挙動です。ルートドメイン（@）にはNSレコードとSOAレコードが必須で存在しているため、CNAMEを同じ名前に設定することはRFC上禁止されています。ルートドメインをSaaS等に向けたい場合は、CloudflareのCNAME Flatteningや、対象サービスが提供するAレコード用IPアドレスを使用してください。

「SOAレコード」の役割とは？ゾーン情報の管理と基本的に編集不要な理由

結論：SOAレコードはDNSゾーンの「戸籍謄本」のようなものです。ゾーンの管理者・更新履歴・キャッシュルールなどのメタ情報を記録していますが、マネージドDNSサービスを使っている限り手動で触る必要はほぼありません。

SOAレコードの構造と各フィールドの意味

# SOAレコードの完全な構造
example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
    2024011501  ; ① シリアル番号
    3600        ; ② リフレッシュ間隔（秒）
    900         ; ③ リトライ間隔（秒）
    604800      ; ④ 有効期限（秒）
    300         ; ⑤ ネガティブキャッシュTTL（秒）
)

各フィールドの意味を整理します。

なぜ「基本的に編集不要」なのか

お名前.com・ムームードメイン・Xserver・CloudflareなどのマネージドDNSサービスはSOAレコードを自動管理しています。特に以下の2点が自動化されているため、ユーザーが手動で介入する必要がありません。

① シリアル番号の自動インクリメント

ゾーンのDNSレコードを変更するたびに、サービス側がシリアル番号を自動で増加させます。シリアル番号が増加することで、セカンダリネームサーバーが「ゾーンが更新された」と認識して同期を開始します。

② タイマー値の最適化

リフレッシュ間隔・リトライ間隔・有効期限はサービスのインフラ構成に合わせた最適値がデフォルトで設定されています。

SOAレコードを手動で編集するのは、BINDやPowerDNSなどを使って自前でDNSサーバーを構築・運用しているケースに限られます。一般的なWeb制作・サイト運用の業務でSOAレコードを意識する機会はほぼないと思って構いません。

レジストラ側DNSとサーバー側DNS、どちらを使うべきかの判断基準

「設定の自由度・管理のしやすさ」を重視するならCloudflare等の専用DNSサービスを使い、「シンプルさ・管理画面の一元化」を重視するならレンタルサーバーのDNSを使うのが実務的な正解です。プロジェクトの規模と要件で使い分けましょう。

「レジストラ側DNS」と「サーバー側DNS」の違い

まず用語を整理します。

レジストラ側DNS（ドメイン登録会社のDNS） お名前.com・ムームードメインなどのドメイン登録会社が提供するDNSサービスです。ドメイン取得と同じ管理画面でDNSが設定できます。

サーバー側DNS（ホスティング会社のDNS） Xserverやロリポップなどのレンタルサーバーがサーバーと一体で提供するDNSサービスです。NSレコードをサーバー会社のネームサーバーに向けることで使用できます。

専用DNSサービス CloudflareやAWS Route 53など、DNS管理に特化したサービスです。

3つの管理形態の比較

実務的な判断フローチャート

【どのDNS管理を使うべきか？判断フロー】

スタート
  ↓
Q1. CDN・DDoS対策・高度なセキュリティが必要か？
  → YES → Cloudflare（または AWS Route 53）を使う
  → NO  → 次の質問へ
  ↓
Q2. 複数サービス（Webサーバー・メール・SaaS）を組み合わせるか？
  → YES → Cloudflareまたはレジストラ側DNSで一元管理
  → NO  → 次の質問へ
  ↓
Q3. レンタルサーバー1台にドメインを紐づけるだけか？
  → YES → サーバー側DNS（最もシンプル）
  → NO  → レジストラ側DNSで管理

実務でよく使う構成パターン

パターン①：中小規模サイト（Xserver + お名前.comドメイン）

最もよくある構成です。NSレコードをXserverのネームサーバーに向け、Xserverのサーバーパネルでまとめてレコード管理します。

# お名前.com側のネームサーバー設定
ネームサーバー1: ns1.xserver.jp
ネームサーバー2: ns2.xserver.jp
# → 以降のDNS設定はXserverのサーバーパネルで行う

パターン②：高速・高セキュリティ構成（Cloudflare + 任意ドメイン）

CDN・DDoS対策・WAFが必要な場合や、複数のSaaSを組み合わせる場合に有効です。NSをCloudflareに向け、Cloudflareのダッシュボードで一元管理します。

# お名前.com側のネームサーバー設定（Cloudflare移管後）
ネームサーバー1: alice.ns.cloudflare.com
ネームサーバー2: bob.ns.cloudflare.com
# → 以降のDNS設定はCloudflareのダッシュボードで行う

パターン③：メールをGoogle Workspace、WebをXserverで運用

Webサーバーのレコードはサーバー側、MXレコードはGoogle Workspaceのものを追加、という混在構成です。この場合はCloudflareまたはレジストラ側DNSで一元管理するのが最もスッキリします。

# Cloudflare管理画面での設定例（混在構成）
# WebサイトはXserverへ
example.com.      3600  IN  A     123.456.789.1  # XserverのIP
www.example.com.  3600  IN  CNAME example.com.

# メールはGoogle Workspaceへ
example.com.  3600  IN  MX  1  aspmx.l.google.com.
example.com.  3600  IN  TXT "v=spf1 include:_spf.google.com ~all"

NS・CNAME・SOAの違いを整理すると、「NSはゾーン全体の管理権限」「CNAMEは1ホストの別名参照」「SOAはゾーンの自動管理情報」という明確な階層関係があります。NSレコードを変更するときは全体影響を、CNAMEを設定するときはルートドメイン制約を、SOAは基本触らないことをそれぞれ意識してください。また、DNS管理の場所（レジストラ・サーバー・Cloudflare）は「プロジェクト要件と管理のしやすさ」で選ぶのが実務的な正解です。次のセクションでは、実際にDNSレコードを確認・トラブルシュートする具体的な方法を解説します。

DNSレコードの確認・設定・トラブル対策

DNSのトラブルは「設定ミス」と「反映待ちの誤解」の2つが原因の大半を占めます。dig・nslookupコマンドや各種オンラインツールで現在の状態を正確に把握し、原因を切り分ける手順を身につけることが、最速のトラブル解決につながります。

「設定したはずなのにサイトが表示されない」「メールが届かない」——DNS関連のトラブルは原因の特定が難しく、焦って設定を変更しているうちに状況が悪化するケースが後を絶ちません。本セクションでは、まず現状を正確に確認する→原因を切り分ける→対処するという手順で体系的に解説します。

dig・nslookup・お名前.com・ムームードメインでの確認方法

DNSレコードの確認には、コマンドライン（dig/nslookup）とオンラインツールの両方を使いましょう。コマンドラインは詳細情報が得られ、オンラインツールは「世界中からどう見えているか」を確認するのに優れています。

digコマンド（macOS・Linux）

digはDNS確認の最強ツールです。ターミナルから実行でき、DNSレコードの詳細な情報を取得できます。

# 基本的な使い方：Aレコードを確認
dig example.com A

# MXレコードを確認
dig example.com MX

# TXTレコードを確認（SPF・DKIMなど）
dig example.com TXT

# NSレコードを確認
dig example.com NS

# CNAMEレコードを確認
dig www.example.com CNAME

# すべてのレコードを一括確認
dig example.com ANY

# 特定のネームサーバーに直接問い合わせる（@で指定）
dig @8.8.8.8 example.com A       # Google DNSに問い合わせ
dig @1.1.1.1 example.com A       # Cloudflare DNSに問い合わせ
dig @alice.ns.cloudflare.com example.com A  # 権威NSに直接問い合わせ

# TTLの残り時間を確認する（+ttlidの指定）
dig example.com A +ttlid

# シンプルな出力のみ表示（+shortオプション）
dig example.com A +short
# → 203.0.113.1（IPアドレスのみ返ってくる）

digの出力結果の読み方：

# dig example.com A の出力例
; <<>> DiG 9.10.6 <<>> example.com A
;; QUESTION SECTION:
;example.com.           IN  A         ← 質問：example.comのAレコードは？

;; ANSWER SECTION:
example.com.  3600  IN  A  203.0.113.1  ← 回答：IP・TTL・レコード種別

;; AUTHORITY SECTION:
example.com.  86400  IN  NS  alice.ns.cloudflare.com.  ← 権威NS

;; Query time: 12 msec                ← 応答時間
;; SERVER: 192.168.1.1#53            ← 問い合わせ先DNSサーバー
;; WHEN: Thu Jan 15 10:00:00 JST 2024
;; MSG SIZE  rcvd: 56

注目すべきポイントはANSWER SECTIONのIPアドレスとTTLです。設定した値と一致しているか、TTLが想定通りかを確認します。ANSWER SECTIONが空の場合はレコードが存在しないか、まだ反映されていません。

DKIMレコードの確認方法（セレクタ名が必要）

# Google WorkspaceのDKIMを確認（セレクタ名：google）
dig google._domainkey.example.com TXT

# SendGridのDKIMを確認（セレクタ名はサービスにより異なる）
dig s1._domainkey.example.com TXT +short

nslookupコマンド（Windows・macOS・Linux共通）

Windowsユーザーはコマンドプロンプトでnslookupが使えます。

# Aレコードを確認
nslookup example.com

# MXレコードを確認
nslookup -type=MX example.com

# TXTレコードを確認
nslookup -type=TXT example.com

# NSレコードを確認
nslookup -type=NS example.com

# 特定のDNSサーバーに問い合わせる
nslookup example.com 8.8.8.8

# nslookup example.com の出力例
Server:  dns.example.local
Address: 192.168.1.1

Non-authoritative answer:      ← キャッシュから回答（権威NSではない）
Name:    example.com
Address: 203.0.113.1           ← 取得したIPアドレス

「Non-authoritative answer」と表示されるのは、ローカルDNSキャッシュから回答が返ってきているためです。権威NSに直接問い合わせたい場合は、特定のDNSサーバーを指定してください。

オンラインDNS確認ツール

コマンドラインが使えない環境、またはグローバルな反映状況を確認したい場合はオンラインツールが便利です。

実務での使い分け：

【確認ツールの使い分けフロー】

設定変更直後
  → dig +short で値が反映されているか即確認
  ↓
「自分の環境では見えるが他の人には見えない」
  → DNSChecker / WhatsMyDNS でグローバル伝播状況を確認
  ↓
「メールが届かない・迷惑メールになる」
  → MXToolbox でMX・SPF・DKIM・DMARCを一括診断
  ↓
「Google Workspaceのメール設定を確認したい」
  → Google Admin Toolbox を使用

お名前.com・ムームードメインの管理画面での確認方法

コマンドやオンラインツールに加え、各サービスの管理画面でも現在の設定値を確認できます。

管理画面の表示とdigの結果が違う場合 管理画面は「設定値」を表示しており、世界中のDNSキャッシュへの反映状況は反映されていません。「管理画面では設定されているのにdigで返ってこない」場合は、TTLの時間内でまだキャッシュが更新されていない可能性が高いです。

ホスト名・TTL・優先度の正しい書き方と反映時間

設定値の書き方のミスと、反映時間の誤解が混在すると「設定したのに動かない」という状態が長引きます。書き方のルールと反映時間の現実を正確に把握することで、不要な再設定を防げます。

よくある書き方ミスとその正解

実務でよく見かける入力ミスをパターン別に整理します。

【ホスト名の書き方ミス】

❌ NG: example.com           （ルートドメインをそのまま入力）
✅ OK: @                     （または空欄）

❌ NG: www.example.com       （フルドメインで入力）
✅ OK: www                   （サブドメイン部分のみ）

❌ NG: _dmarc.example.com    （フルドメインで入力）
✅ OK: _dmarc                （サブドメイン部分のみ）

❌ NG: google._domainkey.example.com （フルドメインで入力）
✅ OK: google._domainkey             （サブドメイン部分のみ）

【値（Value）の書き方ミス】

# Aレコード
❌ NG: <http://203.0.113.1>    （httpをつけてしまう）
❌ NG: 203.0.113.1/          （スラッシュをつけてしまう）
✅ OK: 203.0.113.1           （IPアドレスのみ）

# CNAMEレコード
❌ NG: <https://shops.myshopify.com>  （httpsをつけてしまう）
❌ NG: shops.myshopify.com/         （スラッシュをつけてしまう）
✅ OK: shops.myshopify.com.         （ドメイン名のみ・末尾ドットはあっても可）

# MXレコード
❌ NG: 203.0.113.50          （IPアドレスを指定してしまう）
✅ OK: aspmx.l.google.com.   （ドメイン名で指定）

# TXTレコード（SPF）
❌ NG: v=spf1 include:_spf.google.com ~all（ダブルクォーテーションを自分でつける）
✅ OK: v=spf1 include:_spf.google.com ~all（管理画面が自動付与）
※ サービスによっては "" が必要な場合もあるため、エラーが出たら試す

【MXレコードのPriority（優先度）ミス】

❌ NG: Priority欄に「aspmx.l.google.com」（ドメイン名を入力してしまう）
✅ OK: Priority欄に「1」（数値のみ）

❌ NG: Priority欄を空欄のまま
✅ OK: 数値を入力（Google Workspaceなら 1, 5, 5, 10, 10）

DNS反映時間の現実

「設定したのに反映されない」という問い合わせで最も多い原因が、反映時間への誤解です。

【反映時間の目安】

設定直後          : 権威NSには即時反映
〜5分             : TTL=300の場合のキャッシュ更新
〜1時間           : TTL=3600（標準）の場合のキャッシュ更新
〜24時間          : NSレコード変更後の世界的な伝播
〜72時間          : 最悪ケース（古いキャッシュが残っている環境）

「自分のPCでは表示されるのにスマホでは表示されない」という現象の原因

これはDNSキャッシュがデバイスや回線ごとに異なるためです。自分のPCのDNSキャッシュが既に更新されていても、スマホが接続しているモバイル回線のDNSキャッシュはまだ古い値を持っている可能性があります。

# ローカルDNSキャッシュをクリアする方法

# macOS（Monterey以降）
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux（systemd-resolved使用時）
sudo systemd-resolve --flush-caches

ただしローカルキャッシュをクリアしても、ISP（インターネットプロバイダ）のDNSキャッシュまではクリアできません。確実に最新の状態を確認したいときは、dig @8.8.8.8でGoogle DNSに直接問い合わせるか、オンラインツール（DNSChecker等）でグローバルな反映状況を確認してください。

設定ミスでサイトが表示されない・メールが届かない原因と対処法

トラブルの原因特定は「切り分け」が命です。「サイトが表示されない」「メールが届かない」という症状に対し、DNS起因なのかサーバー起因なのかを最初に判別することで、無駄な設定変更を防げます。

トラブル①：サイトが表示されない

【診断フロー：サイトが表示されない場合】

Step 1: DNSが正しく解決されているか確認
  $ dig example.com A +short
  → IPアドレスが返ってくる？

  ✅ 正しいIPが返ってくる → DNS設定はOK。サーバー側の問題
  ❌ 違うIPが返ってくる  → AレコードのIPアドレスを修正
  ❌ 何も返ってこない    → Aレコードが未設定 or まだ反映中
  ❌ CNAMEが返ってくる   → ルートドメインのCNAME設定ミス

Step 2: DNSが解決されているのにサイトが表示されない場合
  → サーバーのApache/Nginx設定確認
  → SSL証明書の有効期限確認
  → サーバーのファイアウォール設定確認

よくある原因と対処法

原因①：AレコードのIPアドレスが古いまま（サーバー移転後など）
対処：新サーバーのIPアドレスをAレコードに設定し直す
確認：$ dig example.com A +short → 新しいIPアドレスが返るか確認

原因②：wwwありとwwwなしで片方しか設定していない
対処：@とwwwの両方にAレコード（またはCNAME）を設定する
確認：$ dig example.com A +short
     $ dig www.example.com A +short
     → 両方から正しいIPが返るか確認

原因③：NSレコードを変更したが、新しい管理先でAレコードを設定していない
対処：移管先のDNS管理画面（Cloudflareなど）でAレコードを新規設定する
確認：$ dig @alice.ns.cloudflare.com example.com A
     → 権威NSに直接問い合わせてレコードの有無を確認

原因④：CNAMEをルートドメインに設定してしまった
対処：ルートドメインのCNAMEを削除し、Aレコードに変更する
確認：$ dig example.com CNAME +short → 何も返らないことを確認
     $ dig example.com A +short     → IPアドレスが返ることを確認

トラブル②：メールが届かない・迷惑メールになる

【診断フロー：メールが届かない場合】

Step 1: MXレコードが設定されているか確認
  $ dig example.com MX +short
  → メールサーバーのドメインが返ってくるか？

  ✅ 正しいMXサーバーが返る → Step 2へ
  ❌ 返ってこない           → MXレコードを設定する
  ❌ 違うサーバーが返る     → MXレコードの値を修正

Step 2: SPFレコードが設定されているか確認
  $ dig example.com TXT +short | grep spf
  → "v=spf1 ..." が返ってくるか？

  ✅ 正しいSPFが返る → Step 3へ
  ❌ 返ってこない   → SPFのTXTレコードを設定する
  ❌ 複数返ってくる → SPFレコードが重複している（1つに統合する）

Step 3: MXToolboxでSPF・DKIM・DMARCを一括診断
  → <https://mxtoolbox.com/SuperTool.aspx>
  → 「Email Health」でドメインを検索
  → ERRORとWARNINGを確認して対処

よくある原因と対処法

原因①：MXレコードの値にIPアドレスを指定している
対処：MXレコードの値はドメイン名（FQDN）に変更する
❌ NG: example.com. MX 1 203.0.113.50
✅ OK: example.com. MX 1 mail.example.com.

原因②：SPFレコードが複数設定されている
対処：SPFレコードは必ず1つに統合する
❌ NG:
  example.com. TXT "v=spf1 include:_spf.google.com ~all"
  example.com. TXT "v=spf1 include:sendgrid.net ~all"
✅ OK:
  example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

原因③：DKIMレコードのホスト名にフルドメインを入力している
対処：ホスト名はサブドメイン部分のみ入力する
❌ NG: ホスト名 = google._domainkey.example.com
✅ OK: ホスト名 = google._domainkey

原因④：Google Workspaceでメール認証が完了していない
対処：Google管理コンソール→「アプリ」→「Google Workspace」
     →「Gmail」→「メールの認証」でDKIM署名を有効化する
     ※ DKIMレコードをDNSに設定してもGoogleコンソール側で
       「認証を開始」しないと機能しない点に注意

トラブル③：NSレコード変更後にサイトとメールが両方停止した

これはNSレコード移管時の「設定引き継ぎ漏れ」が原因です。

【NSレコード移管後の復旧手順】

Step 1: 移管先DNSで現在のレコードを確認
  $ dig @alice.ns.cloudflare.com example.com ANY
  → どのレコードが存在するか確認

Step 2: 不足しているレコードを特定して追加
  以下を移管先管理画面で設定：
  - Aレコード（Webサイト用）
  - MXレコード（メール受信用）
  - TXTレコード（SPF・DKIM・DMARC）
  - その他のサブドメイン設定

Step 3: 反映確認（TTL経過後）
  $ dig example.com A +short        → WebサーバーのIP
  $ dig example.com MX +short       → メールサーバーのFQDN
  $ dig example.com TXT +short      → SPFレコード

DNS設定トラブル対策チェックリスト

実務での設定作業前後に使えるチェックリストです。

【作業前チェックリスト】
□ 現在のDNSレコードをすべてdump・メモした
□ TTLを300に下げて24〜48時間待った
□ 作業内容と切り戻し手順を文書化した
□ 作業時間帯は深夜〜早朝（アクセスが少ない時間帯）

【作業後チェックリスト】
□ dig +short でAレコードのIPアドレスを確認した
□ dig MX でメールサーバーのFQDNを確認した
□ dig TXT でSPFレコードを確認した
□ DNSCheckerでグローバル反映状況を確認した
□ 実際にブラウザでサイト表示を確認した
□ テストメール送受信を確認した
□ 問題なければTTLを3600に戻した

DNSトラブルの解決は「正確な現状把握→原因の切り分け→最小限の修正」という手順が鉄則です。digコマンドとオンラインツールを組み合わせれば、ほとんどの問題は原因まで特定できます。設定変更前のTTL引き下げ・レコードのバックアップ・切り戻し手順の準備を習慣化するだけで、重大なインシデントの大半は防げます。次のセクションでは、読者からよくある質問に回答します。

よくある質問（FAQ）

DNS設定に関して、現場のエンジニアや制作担当者からよく寄せられる疑問をまとめました。「なんとなく設定はできたけど、これで合っているのか不安」という疑問の解消にお役立てください。

まとめ

ここまでDNSレコードの種類から書き方・確認方法・トラブル対策まで、実務で必要な知識を一通り解説してきました。最初は記号の羅列に見えたDNSレコードも、それぞれの役割を理解してしまえば、設定作業で迷うことはぐっと減るはずです。

DNSレコードは「ドメインとサーバーをつなぐ翻訳辞書」のようなものです。A・CNAME・MX・TXT・NS——それぞれが担う役割は明確で、「何をしたいか」が決まれば、使うレコードも自然と決まってきます。

DNS設定で一番やってはいけないのは、「なんとなく設定して、なんとなく動いた」で終わらせることです。理解のないまま進めると、次に問題が起きたときに原因の見当がつかず、無駄な設定変更を重ねて状況を悪化させてしまいます。

この記事で紹介したdigコマンドやMXToolboxを使いこなせるようになると、DNSのトラブル対応がぐっとスムーズになります。「設定したら必ず確認する」習慣をつけるだけで、現場での信頼感は大きく変わってくるはずです。

DNSの理解は、インフラへの苦手意識を取り除く最初の一歩でもあります。ぜひこの記事を手元に置きながら、実際の設定作業で活用してみてください。

あわせて読みたい

【初心者向け】Apacheアクセスログの見方完全ガイド｜保存場所・エラー原因・不正アクセス検知まで徹底解説

Apacheのアクセスログの見方を初心者にも分かりやすく解説。保存場所の確認方法から、IP・日時・リクエスト・ステータスコードの読み方、CombinedとCommonフォーマットの違いまで丁寧に紹介。さらに可視化ツール活用、404・500エラー原因の特定や不正アクセス検知など、実践的なログ解析テクニックも解説します。

watashi.xyz

2025.08.30

簡単にできる！特定のサイトのIPアドレスの調べ方【コマンド・WEBツール】

Webサイトのアドレスを簡単に調べる方法をご紹介します。Windows、Mac、スマホ別の確認手順や「nslookup」「ping」コマンドの使い方、便利な無料ツールまで完全網羅。IPアドレスの基礎知識からプロ級テクニックまで、初心者でもすぐに実践できる内容です。接続トラブル解決やセキュリティ確認に役立つ情報満載！

watashi.xyz

2025.04.11