IT
🌐

DNS設定完全ガイド:AレコードとCNAMEの違いから実践的な設定まで

「DNS設定完全ガイド:AレコードとCNAMEの違いから実践的な設定まで」の実践ガイド。明確なチェックリスト、注意すべき主なリスク、実行前に選択肢を比較したい読者のための次のステップを紹介します。

DNS設定完全ガイド:AレコードとCNAMEの違いから実践的な設定まで

要点まとめ

  • A record: ドメインをIPアドレスに直接接続する(最も基本的な種類)
  • CNAME: ドメインを別のドメインの別名として接続する(主にサブドメインで使用)
  • MX record: メールを受信するメールサーバーを指定する
DNS設定完全ガイド AレコードとCNAMEの違いから実践的な設定まで guide reference image visual reference 1
  • TTL: レコードがキャッシュに保持される時間(短いほど変更が早く反映される)

短い答え: A recordはドメインをIPアドレスに接続し、CNAMEはドメインを別のドメインに接続します。

DNSを一言で説明すると

DNS設定完全ガイド:A RecordsとCNAMEの違いからPra visual 2まで
項目内容
A recordドメインをIPアドレスに直接接続する
CNAMEドメインを別のドメインの別名として接続する
MX recordメールを受信するメールサーバーを指定する
TTLレコードがキャッシュに保持される時間

DNS(Domain Name System)は、インターネットの電話帳です。millionscode.comのような人間が読みやすいドメイン名を、104.21.32.55のようなコンピューターが理解できるIPアドレスに変換します。

ブラウザにURLを入力すると、ブラウザはDNSサーバーに「このドメインのIPアドレスは何ですか?」と問い合わせます。その後、受け取ったIPアドレスを使って実際のサーバーに接続します。この処理は通常、数十ミリ秒以内に完了します。

DNSレコード種類の完全解説

DNS設定完全ガイド:A RecordsとCNAMEの違いからPra visual 3まで

A Record: ドメインをIPアドレスに直接接続する

A recordは最も基本的なDNSレコードです。ドメイン名を、4つの数字で構成されるアドレスであるIPv4アドレスに直接対応付けます。

例:

millionscode.com → 104.21.32.55

どのような場合に使うべきですか?

  • ドメインをVPSや専用サーバーに接続する場合
  • ルートドメイン(example.com)をサーバーに接続する場合
  • Cloudflare Pagesを使わず、IPアドレスを直接指定する場合

Cloudflareでの設定方法:

  1. 1Cloudflare dashboard → DNS → Add record
  2. 2Type: A
  3. 3Name: @(ルートドメイン)または目的のサブドメイン
  4. 4IPv4 address: サーバーIPを入力
  5. 5Proxy status: Proxied(オレンジ色の雲)を推奨
  6. 6TTL: Auto(Proxiedの場合は自動管理)

CNAME Record: ドメインを別のドメインの別名として設定する

CNAME は、あるドメインを別のドメインに向けるエイリアスレコードです。IP アドレスではなく、別のドメイン名を指します。

例:

www.millionscode.com → millionscode.com
blog.millionscode.com → millionscode.pages.dev

どのような場合に使うべきですか?

  • www サブドメインをルートドメインに接続する場合
  • カスタムドメインを Cloudflare Pages、Vercel、Netlify などの PaaS に接続する場合
  • サブドメインを CDN サービスに接続する場合

重要なルール: 標準的な DNS では、ルートドメイン(@)に CNAME を使用できません。Cloudflare は CNAME Flattening によってこの制限を回避しています。

MX Record: メールを受信するメールサーバーを指定する

MX(Mail Exchange)レコードは、ドメイン宛てに届いたメールをどのメールサーバーが処理するかを指定します。

例:

millionscode.com MX → mx1.emailprovider.com (priority: 10)
millionscode.com MX → mx2.emailprovider.com (priority: 20)

優先度の数値が低いほど、そのサーバーが先に使用されます。最初のサーバーが停止した場合、トラフィックは自動的に 2 番目のサーバーへ切り替わります。

TXT Record: テキストベースの検証と設定

TXT レコードは、ドメインにテキスト情報を追加する汎用レコードです。主に所有権の確認、SPF、DKIM などに使用されます。

一般的な用途:

  • Google Search Console verification: google-site-verification=XXXXX
  • Naver Search Advisor verification: naver-site-verification=XXXXX
  • SPF record: メールスパムの防止を助けるため、送信サーバーを認証します
  • DKIM: メールの改ざんやなりすましを防ぐのに役立つデジタル署名

Practical Guide: Cloudflare で DNS を段階的に設定する方法

Complete DNS Setup Guide: From the Difference Between A Records and CNAME to Pra visual 4

Step 1: ネームサーバーを変更する

Gabia や Whois など、ドメインを購入したレジストラでネームサーバーを Cloudflare に変更します。

existing nameserver → Cloudflare replace with the nameserver
ns1.cloudflare.com (example — check in the Cloudflare dashboard)
ns2.cloudflare.com

ネームサーバーを変更した後、反映には最大 24 時間かかることがあります。通常は 1〜2 時間以内に完了します。

Step 2: DNS レコードを追加する

Cloudflare ダッシュボードで必要なレコードを追加します。ドメインの現在の DNS 設定は、DNS Lookup tool で確認できます。

Step 3: SSL/TLS を設定する

Cloudflare → SSL/TLS で、モードを Full (Strict) に設定すると HTTPS が自動的に適用されます。別途 SSL 証明書を購入する必要はありません。

TTL Setup Guide

TTL(Time To Live)は、DNS レコードがキャッシュに保持される時間です。

TTL値意味推奨される用途
300秒(5分)非常に短いDNS変更の直前または直後
3600秒(1時間)標準通常の運用状態
86400秒(24時間)長い予定された変更がない安定した状態
AutoCloudflare自動設定Proxiedレコードに推奨

ヒント: DNS設定を変更する予定がある場合は、24時間前にTTLを300秒へ下げておきましょう。 これにより、その後の変更がすばやく反映されやすくなります。

よくあるミスと対処法

ミス1: wwwが接続できない

これは、ルートドメイン(@)だけが設定されていて、wwwのCNAMEがない場合に起こります。必ず www → @ のCNAMEレコードを追加してください。

ミス2: メールが届かない

最も一般的な原因はMXレコードの不足です。利用しているメールサービスプロバイダーのMXレコード設定ガイドに正確に従ってください。

ミス3: SSL証明書エラー

Cloudflare Proxy(オレンジ色の雲)が有効になっている一方で、オリジンサーバーにSSLがない場合に発生することがあります。一時的にSSL/TLSモードを Full (Strict) から Flexible に変更するか、オリジンサーバーにSSLをインストールしてください。


よくある質問(FAQ)

Q1. AレコードとCNAMEのどちらを使うべきですか?

A: サーバーのIPアドレスが固定されている場合はAレコードを使います。VercelやCF PagesなどのPaaSに接続する場合、またはIPアドレスが変わる可能性がある場合はCNAMEを使います。ほとんどのサブドメインではCNAMEレコードが便利です。

Q2. DNSを変更した後、どのくらい待つ必要がありますか?

A: TTL設定によりますが、通常は5分から24時間です。事前にTTLを300秒へ下げておけば、5分以内に反映されることがあります。

Q3. Cloudflare Proxy(オレンジ色の雲)は有効にする必要がありますか?

A: 必須ではありませんが、推奨されます。Proxyを有効にすると、DDoS保護、CDNキャッシュ、自動SSLなどのメリットがあります。

Q4. ルートドメインにCNAMEを設定できますか?

A: 標準のDNSではできませんが、CloudflareではCNAME Flatteningにより、ルートドメインでも同じ効果を提供しています。

Q5. 間違ったDNSレコードでサイトが停止することはありますか?

A: はい。Aレコードを誤ったIPに変更したり、CNAMEを存在しないターゲットに向けたりすると、訪問者はサイトにアクセスできなくなります。変更前には必ず既存の設定をスクリーンショットでバックアップしてください。

Q6. ドメインの現在のDNS設定を確認するにはどうすればよいですか?

A: 当社の DNS Lookup tool にドメインを入力すると、現在のA/CNAME/MX/TXTレコードをすぐに確認できます。

💡 実践的な知見

ほかのブログ記事では「A は IP、CNAME は別名」という一般的な説明で終わっていることが多いのですが、実際の運用でサイトが落ちる本当の原因は別にあります。私自身が Cloudflare Pages で millionscode.com を運用してきた経験では、韓国のユーザーが最もよく犯すミスは、Gabia や Whois でネームサーバーを変更したのに、24時間たっても反映されないというものです。これはほぼ必ずレジストラ側のキャッシュ問題です。Gabia の場合、平均的には 1〜2時間程度が普通で、遅延が 6時間を超えるなら、1対1の問い合わせでレジストラに連絡するほうがたいてい早く解決します。次によく見落とされる点は、ルートドメインで CNAME を使うことは、Cloudflare CNAME Flattening を除けばどこでも標準的な DNS 違反になるということです。AWS Route 53 の Alias レコードや Vercel の ANAME など、各ベンダーにはそれぞれ回避策があります。以前、Cloudflare から別の DNS プロバイダーへ移行した際に Flattening が外れ、ルートドメインが 30分間停止したことがありました。事前に TTL を 300秒へ下げていたため、すぐに復旧できました。一般的なガイドでは TTL の変更に触れないことが多いですが、実運用では DNS 変更の 24〜48時間前に TTL を下げておくことは、ほぼ必須の保険です。最後に、韓国でサイトを運営する場合、Naver のボットは meta タグより TXT 認証を信頼する傾向があるため、Search Console と Naver Search Advisor の両方を TXT records で登録することが、インデックス漏れを減らす重要な方法です。


Reference: Bank of Korea Economic Statistics

2026 DNS Records チェックリスト

基本的な A record と CNAME を設定した後は、AAAA、TXT、MX records も確認してください。これらのレコードは、IPv6 アクセス、メール配信、ドメイン所有権の確認、移行時の信頼性に影響します。

AAAA

AAAA はドメインを IPv6 アドレスに向けるためのものです。オリジンサーバーまたは CDN が IPv6 を正しく処理できる場合にのみ追加し、デプロイ後に実際のアクセスをテストしてください。

SPF、DKIM、DMARC 用の TXT

TXT records は、所有権確認やメールの信頼性確保によく使われます。SPF は承認済みの送信サーバーを列挙し、DKIM はメッセージ署名を検証し、DMARC は認証に失敗したメールを受信側がどう扱うべきかを定義します。

MX

MX records は受信メールをルーティングします。置き換える前に、そのドメインが現在 Google Workspace、Microsoft 365、Cafe24、または別のプロバイダー経由でメールを受信していないか確認してください。

Gabia、Cafe24、Cloudflare、Route53 に関するメモ

Gabia と Cafe24 では、同じ項目が host、name、record name といったラベルで表示されることがあります。ルートドメインは通常 @ または空のホストで、wwwwww.example.com のみを対象にします。

Cloudflare は DNS と CDN プロキシ制御を組み合わせているため、プロキシされたレコードは DNS-only records とは異なる挙動をします。Route53 は AWS リソースと密接に統合されており、CloudFront、S3、ロードバランサー向けの ALIAS 形式のルーティングをサポートしています。

TTL と伝播のトラブルシューティング

移行前にTTLを短くし、新しい参照先が安定したら再び長くします。伝播が想定どおりに見えない場合は、ローカルDNSキャッシュをクリアし、公開リゾルバで結果を比較し、重複レコードがないか確認し、権威ネームサーバーが変更されていることを確認します。

関連するDNSとSEOガイド

2026-06-03更新: AAAA、SPFを含むTXT、DKIM、DMARC、MX、GabiaとCafe24のUIに関する注記、CloudflareとRoute53の違い、TTL伝播のトラブルシューティング、2026年DNSチェックリストを追加しました。

🔧 関連する無料ツール

次に役立つステップ

このガイドから続ける

関連