ドメインとDNS設定の完全ガイド｜A・CNAME・MXレコードの基本を解説

「独自ドメインでWebサイトを公開したいが、DNSの設定がわからない」「ドメインを取得したのにサイトが表示されない」——ドメインとDNSの仕組みは、Web開発やインフラ管理の基礎でありながら、初心者にとってつまずきやすいポイントです。

本記事では、ドメインの基本的な仕組みから各種DNSレコードの役割、実際のWebサイト公開やメール設定までを体系的に解説します。このガイドを読めば、ドメインとDNSの設定を自信を持って行えるようになります。

ドメインとDNSの基本的な仕組み

まずは、ドメインとDNSがどのような役割を果たしているのかを理解しましょう。

ドメインとは何か

ドメインとは、インターネット上の住所に当たるものです。たとえば example.com というドメインは、人間が覚えやすい文字列でWebサイトやメールサーバーの場所を示しています。

コンピューター同士の通信ではIPアドレス（例：203.0.113.50）が使われますが、数字の羅列は人間にとって覚えにくいものです。ドメインは、このIPアドレスに人間が理解しやすい名前を付ける仕組みです。

ドメインには階層構造があります。

トップレベルドメイン（TLD）
.com、.jp、.orgなどの最上位の階層です。.co.jpのように国コードTLDとカテゴリが組み合わされたものもあります。

セカンドレベルドメイン（SLD）
example.com の example 部分です。ドメイン取得時に自由に選択できます。

サブドメイン
www.example.com や blog.example.com のように、ドメインの先頭に付加する文字列です。自由に作成でき、追加費用はかかりません。

DNS（Domain Name System）の仕組み

DNSは、ドメイン名をIPアドレスに変換（名前解決）するシステムです。ブラウザに example.com と入力したとき、裏側では以下のプロセスが実行されています。

ステップ1：ブラウザのキャッシュ確認
まずブラウザは自身のDNSキャッシュを確認します。最近アクセスしたドメインの情報がキャッシュに残っていれば、そのIPアドレスを即座に使用します。

ステップ2：OSのキャッシュ確認
ブラウザにキャッシュがなければ、OSのDNSリゾルバ（キャッシュ）を確認します。

ステップ3：再帰的DNSリゾルバへの問い合わせ
OSにもキャッシュがなければ、ISP（プロバイダー）やパブリックDNS（Google Public DNS：8.8.8.8 など）の再帰的リゾルバに問い合わせます。

ステップ4：ルートDNSサーバーへの問い合わせ
再帰的リゾルバは、まずルートDNSサーバーに問い合わせ、.com のTLDネームサーバーの情報を取得します。

ステップ5：TLDネームサーバーへの問い合わせ
.com のTLDネームサーバーに問い合わせ、example.com の権威ネームサーバーの情報を取得します。

ステップ6：権威ネームサーバーへの問い合わせ
最終的に example.com の権威ネームサーバーから、該当するDNSレコード（IPアドレスなど）を取得します。

この一連のプロセスは通常数十ミリ秒で完了し、キャッシュがあればさらに高速です。

ネームサーバー（NS）とは

ネームサーバーは、特定のドメインのDNSレコード情報を保持しているサーバーです。ドメインを取得すると、「このドメインのDNS情報はどのネームサーバーに問い合わせればよいか」を設定する必要があります。

ドメインレジストラ（お名前.com、ムームードメインなど）でドメインを取得した場合、初期設定ではレジストラのネームサーバーが設定されています。AWS Route 53やCloudflare DNSを使う場合は、ネームサーバーをそれらのサービスのものに変更します。

主要なDNSレコードの種類と役割

DNSレコードにはさまざまな種類があり、それぞれ異なる目的で使用されます。ここでは実務でよく使うレコードを解説します。

Aレコード（Address Record）

最も基本的なDNSレコードで、ドメイン名をIPv4アドレスに対応付けます。

# Aレコードの設定例
example.com.        IN  A   203.0.113.50
www.example.com.    IN  A   203.0.113.50

上記の設定は「example.com にアクセスしたら、IPアドレス 203.0.113.50 のサーバーに接続する」という意味です。Webサーバーやアプリケーションサーバーを指す際に使用します。

AAAAレコードはIPv6アドレスを対応付けるレコードで、Aレコードのipv6版です。IPv6対応を行う場合はAレコードとAAAAレコードの両方を設定します。

CNAMEレコード（Canonical Name Record）

ドメイン名を別のドメイン名に対応付けるレコードです。エイリアス（別名）を作成する際に使います。

# CNAMEレコードの設定例
www.example.com.    IN  CNAME  example.com.
blog.example.com.   IN  CNAME  my-blog.netlify.app.
app.example.com.    IN  CNAME  d1234567.cloudfront.net.

CNAMEは、CDN（CloudFront、Cloudflareなど）やPaaS（Heroku、Netlify、Vercelなど）を利用する際によく使います。これらのサービスではIPアドレスが動的に変わる可能性があるため、Aレコードではなく、サービスが提供するドメイン名にCNAMEで向けるのが一般的です。

注意点：CNAMEレコードはルートドメイン（ネイキッドドメイン：example.com）には設定できません。これはDNSの仕様上の制約です。ルートドメインにはAレコードを使うか、ALIASレコード（Route 53）やFlattenedCNAME（Cloudflare）などの独自機能を利用します。

MXレコード（Mail Exchange Record）

メールの送信先サーバーを指定するレコードです。独自ドメインでメールを受信するために必須の設定です。

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

数字は優先度を示し、小さいほど優先されます。優先度1のサーバーに接続できない場合、次の優先度のサーバーに試行します。複数のMXレコードを設定することで、メール受信の冗長性を確保できます。

TXTレコード（Text Record）

テキスト情報を格納するレコードで、主にドメインの所有権確認やメールセキュリティに使用されます。

# SPFレコード（メール送信元の認証）
example.com.    IN  TXT  "v=spf1 include:_spf.google.com ~all"

# DKIMレコード（メール署名の検証）
google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANB..."

# DMARCレコード（SPF/DKIMの総合ポリシー）
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

# ドメイン所有権の確認（Google Search Console など）
example.com.    IN  TXT  "google-site-verification=XXXXXXXXXXXXX"

メールセキュリティのSPF、DKIM、DMARCの設定は、独自ドメインでメールを送信する場合に非常に重要です。これらが正しく設定されていないと、送信したメールが迷惑メールに分類されるリスクが高まります。

その他のレコード

NSレコード
ドメインの権威ネームサーバーを指定します。通常はドメインレジストラまたはDNSサービスプロバイダーの管理画面で設定します。

SRVレコード
特定のサービスのホスト名とポート番号を指定します。Microsoft 365やSIPサーバーの設定で使われます。

CAAレコード
どの認証局（CA）がこのドメインのSSL/TLS証明書を発行できるかを指定します。意図しない認証局による証明書発行を防ぐセキュリティ対策です。

# CAAレコードの設定例（Let's Encrypt のみ許可）
example.com.    IN  CAA  0 issue "letsencrypt.org"
example.com.    IN  CAA  0 issuewild "letsencrypt.org"

TTL（Time To Live）の設定と管理

TTLは、DNSレコードのキャッシュ保持時間を秒数で指定する設定です。適切なTTL設定は、DNS運用の重要なポイントです。

TTLの基本

# TTL 3600秒（1時間）の例
example.com.    3600  IN  A   203.0.113.50

TTLが3600秒の場合、DNSリゾルバは1時間このレコードをキャッシュします。次の問い合わせはキャッシュから回答されるため、権威ネームサーバーへの問い合わせが減り、名前解決が高速化します。

TTL設定のベストプラクティス

通常時は長めに設定（3600〜86400秒）
頻繁に変更しないレコードは、1時間〜24時間のTTLを設定します。キャッシュが効くため、名前解決のパフォーマンスが向上します。

変更予定がある場合は事前に短縮する
サーバー移行やCDN切り替えなど、DNSレコードの変更を予定している場合は、変更の24〜48時間前にTTLを短く（300秒程度）しておきます。これにより、変更後の新しいレコードが速やかに反映されます。

変更完了後に元に戻す
DNS変更が完了し、問題がないことを確認したら、TTLを通常の値に戻します。短いTTLのままだとDNSサーバーへの問い合わせが増加し、名前解決のレイテンシが増える可能性があります。

# サーバー移行のTTL管理手順

# ステップ1：変更48時間前 - TTLを短縮
example.com.    300  IN  A   203.0.113.50  # 旧サーバー

# ステップ2：変更実施 - IPアドレスを変更
example.com.    300  IN  A   198.51.100.25  # 新サーバー

# ステップ3：変更後24時間 - 問題ないことを確認しTTLを戻す
example.com.    3600  IN  A   198.51.100.25  # 新サーバー

実践：Webサイト公開のためのDNS設定

実際のWebサイト公開に必要なDNS設定を、ユースケース別に解説します。

VPSやクラウドサーバーを使う場合

AWSのEC2やVPS（さくらVPS、ConoHaなど）にWebサーバーを立てている場合は、Aレコードを設定します。

# ルートドメインとwwwサブドメインの両方を設定
example.com.      IN  A   203.0.113.50
www.example.com.  IN  A   203.0.113.50

静的IPアドレスが割り当てられていることが前提です。AWSのEC2を使う場合は、Elastic IPを割り当ててからAレコードを設定しましょう。Elastic IPなしではインスタンス再起動時にIPアドレスが変わる可能性があります。

CDNやPaaSサービスを使う場合

Netlify、Vercel、CloudFrontなどのサービスを使う場合は、CNAMEレコードを使います。

# Vercelを使う場合
www.example.com.  IN  CNAME  cname.vercel-dns.com.

# Netlifyを使う場合
www.example.com.  IN  CNAME  my-site.netlify.app.

# CloudFrontを使う場合
www.example.com.  IN  CNAME  d1234567.cloudfront.net.

前述のとおり、ルートドメインにはCNAMEを設定できないため、以下のいずれかの方法で対応します。

方法1：wwwへのリダイレクト
example.com へのアクセスを www.example.com にリダイレクトする設定をWebサーバーやDNSサービスで行います。

方法2：ALIASレコード / FlattenedCNAME
Route 53のALIASレコードやCloudflareのFlattenedCNAMEなど、DNSサービス独自の機能を使って、ルートドメインをCNAMEのように動作させます。

# Route 53のALIASレコード（ルートドメインでも使用可能）
example.com.  IN  A  ALIAS d1234567.cloudfront.net.

SSL/TLS証明書とDNS検証

HTTPS通信のためのSSL/TLS証明書取得時にも、DNSレコードが必要になることがあります。

DNS-01チャレンジ（Let's Encrypt）
Let's Encryptの無料SSL証明書を取得する際に、ドメインの所有権をTXTレコードで証明する方法です。

# Let's EncryptのDNS-01チャレンジ
_acme-challenge.example.com.  IN  TXT  "ランダムな文字列"

AWS Certificate Manager（ACM）
ACMで証明書を発行する際も、CNAMEレコードによるドメイン検証が必要です。

# ACMのドメイン検証用CNAMEレコード
_abc123.example.com.  IN  CNAME  _def456.acm-validations.aws.

メール設定に必要なDNSレコード

独自ドメインでメールを送受信するためのDNS設定を解説します。メールのDNS設定は、送信したメールが迷惑メールに分類されないために非常に重要です。

メール受信の設定（MXレコード）

使用するメールサービスに応じたMXレコードを設定します。

# Google Workspaceの場合
example.com.  IN  MX  1   aspmx.l.google.com.
example.com.  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  IN  MX  5   alt2.aspmx.l.google.com.

# Microsoft 365の場合
example.com.  IN  MX  0   example-com.mail.protection.outlook.com.

メール認証の3点セット（SPF・DKIM・DMARC）

メールの信頼性を確保するために、以下の3つの認証を設定します。

SPF（Sender Policy Framework）
「このドメインからメールを送信できるサーバーはどれか」を宣言します。

# SPFレコードの設定例
# Google Workspace + SendGridを使用する場合
example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

include:で許可するメールサービスを列挙し、末尾の~allは「リストにないサーバーからのメールはソフトフェイル（疑わしい）とする」という意味です。

DKIM（DomainKeys Identified Mail）
メールに電子署名を付与し、送信元の正当性と内容の改ざんがないことを証明します。メールサービス側が提供するDKIMレコードをDNSに設定します。

# DKIMレコードの設定例（Google Workspace）
google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DMARC（Domain-based Message Authentication, Reporting, and Conformance）
SPFとDKIMの検証結果に基づいて、認証に失敗したメールの取り扱いポリシーを指定します。

# DMARCレコードの設定例
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com"

p=quarantine は認証に失敗したメールを迷惑メールフォルダに振り分ける指定です。最終的には p=reject（拒否）に強化することを推奨します。ただし、最初は p=none（監視のみ）から始めて、レポートを確認しながら段階的に強化するのが安全です。

DNSの確認とトラブルシューティング

DNS設定後の確認方法と、よくあるトラブルの解決方法を紹介します。

DNS設定の確認コマンド

digコマンドやnslookupコマンドを使って、DNSレコードが正しく設定されているか確認できます。

# Aレコードの確認
dig example.com A

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

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

# TXTレコードの確認
dig example.com TXT

# 特定のDNSサーバーに問い合わせ
dig @8.8.8.8 example.com A

# 名前解決の全過程を表示
dig +trace example.com

# nslookupを使う場合
nslookup example.com
nslookup -type=MX example.com

よくあるトラブルと対処法

設定変更が反映されない
DNSの変更は即座には反映されません。TTLの値に応じたキャッシュが残っているため、反映には数分〜数時間（TTLが長い場合は最大48時間）かかることがあります。TTLを事前に短縮しておくことで、反映時間を短縮できます。

ドメインにアクセスしてもサイトが表示されない
Aレコードの設定、Webサーバーの起動状態、ファイアウォールの設定を順番に確認します。まずdigコマンドでDNSが正しく解決されているか確認し、次にcurlコマンドでIPアドレス直接アクセスを試みます。

# DNSの解決を確認
dig example.com A +short
# 出力例: 203.0.113.50

# IPアドレスで直接アクセス
curl -I http://203.0.113.50

# ドメインでアクセス
curl -I http://example.com

メールが届かない・迷惑メールに分類される
MXレコードの設定が正しいか確認するとともに、SPF・DKIM・DMARCの設定を見直します。MXToolboxなどのオンラインツールで各レコードの設定状況を一括チェックできます。

CNAME設定のエラー
CNAMEレコードと他のレコード（AレコードやMXレコード）を同じ名前で併用することはできません。これはDNSの仕様上の制約です。CNAMEを設定する名前には、CNAME以外のレコードを設定しないようにしましょう。

主要なDNSサービスの選び方

DNSサービスの選択も重要なポイントです。主要なサービスを比較します。

各サービスの特徴

AWS Route 53
AWSが提供するDNSサービスです。ALIASレコード、ヘルスチェック、ルーティングポリシー（加重、レイテンシベース、フェイルオーバーなど）といった高度な機能を備えています。AWSの他サービスとの統合がシームレスで、AWS中心の環境では最適な選択です。

Cloudflare DNS
高速な名前解決とDDoS防御機能を備えた無料のDNSサービスです。CDNやWAFなどのセキュリティ機能も統合されており、小規模なサイトから大規模サイトまで幅広く利用されています。FlattenedCNAMEによりルートドメインのCNAME的な設定も可能です。

Google Cloud DNS
Google Cloudが提供するDNSサービスです。100%のSLAを提供しており、Googleのインフラによる高い信頼性が特徴です。

レジストラ付属のDNS
ドメインレジストラ（お名前.com、ムームードメインなど）が提供するDNSサービスです。追加費用なしで利用でき、シンプルな設定には十分ですが、高度な機能（ヘルスチェック、加重ルーティングなど）は提供されない場合が多いです。

選定のポイント

個人のWebサイトやブログ程度であれば、Cloudflare DNSが無料で高機能なためおすすめです。ビジネス用途でAWSを利用している場合はRoute 53が統合性の面で優れています。GCP中心の環境ではGoogle Cloud DNSが適しています。

まとめ

ドメインとDNSの設定は、Webサイト公開やメール運用の土台となる重要なスキルです。本記事のポイントを振り返りましょう。

DNSの基本
DNSはドメイン名をIPアドレスに変換するシステムです。階層的な問い合わせとキャッシュにより、効率的な名前解決を実現しています。

主要なDNSレコード
Aレコード（IPアドレスの指定）、CNAME（別名の指定）、MX（メールサーバーの指定）、TXT（テキスト情報）の4つが最も重要です。

メールセキュリティ
SPF、DKIM、DMARCの3つの認証設定は、独自ドメインでメールを運用する際に必須です。

TTLの管理
DNSレコードの変更前にTTLを短縮し、変更後に元に戻すという運用が、スムーズな切り替えの鍵です。

トラブルシューティング
digコマンドでDNSの状態を確認し、問題の切り分けを行うスキルは、インフラ管理者にとって必須です。

まずは自分のドメインに対してdigコマンドを実行し、現在のDNS設定がどのようになっているかを確認してみてください。実際のレコードを見ることで、本記事で解説した内容がより深く理解できるはずです。