DNS レコード設定の実践 — ドメインをサーバー・クラウドにつなぐ (A・CNAME・apex・TTL)

インフラ DNS Domain
読了 8分

ドメインを買ってサーバーも用意したのに、アドレスを入力してもサイトが出てきません。こうして詰まる地点は、ほとんど DNS の設定です。今回の記事では、ドメインを実際のサーバーやクラウドにつなぐ流れを、A・CNAME・apex・TTL を中心に段階を追って扱います。ドメイン・ネームサーバー・レコードとは何かから押さえたい方は、ドメインとは何で、なぜ必要なのかを先に読むことをおすすめします。

まず決めること：ネームサーバーをどこに置くか #

ドメインをつなぐ最初の決定は「このドメインの DNS を誰が運用するか」です。選択肢は大きく二つあります。

  • 登録業者のデフォルトネームサーバーを使う: ドメインを買った場所(例: お名前.com、GoDaddy、Cloudflare Registrar)が提供する DNS にレコードを直接書きます。単純なサイトならこれで十分です。
  • 外部 DNS に委任する: 登録業者でネームサーバーだけを外部サービス(Cloudflare、AWS Route 53 など)に変え、レコードはそちらで管理します。キャッシュ、プロキシ、ヘルスチェックといった機能が必要なときに選びます。

委任は、登録業者の画面でネームサーバーの項目を外部サービスが教えてくれた値に変えればできます。

# 例: Cloudflare に委任するなら、登録業者にこのネームサーバーを指定
ns1.cloudflare.com
ns2.cloudflare.com

ネームサーバーを変えた直後は、まだ古いネームサーバーを見ているところが残っているので、変更が完全に落ち着くまで時間がかかります。だからネームサーバーの委任は、サイトを本格的に移す数日前に済ませておくほうが安全です。

主要レコードと実際の値 #

接続によく使うレコードは五つで十分です。

レコード役割値の例
A名前 → IPv4 アドレス203.0.113.10
AAAA名前 → IPv6 アドレス2001:db8::1
CNAME名前 → 別の名前schoolofweb.net
MXメール受信サーバーの指定10 mail.example.com
TXT認証・所有確認のメモv=spf1 include:...

いちばん単純な形はこうです。サイトを固定 IP を持つサーバー一台に載せるなら、apex ドメインと www をそれぞれこう置きます。

# 名前            タイプ   値
@                A        203.0.113.10
www              CNAME    schoolofweb.net

ここで @ は www のような接頭語のない apex ドメイン、つまり schoolofweb.net 自体を指します。

apex ドメインの落とし穴 #

実務でいちばん詰まる地点が apex ドメインです。ルール上、apex(@)には CNAME を置けません。 CNAME はその名前の他のすべてのレコードと共存できないのに、apex には MX や TXT のように必ず一緒にあるべきレコードがあるからです。

問題は、最近のホスティングや CDN が固定 IP ではなく名前(例: myapp.vercel.app)を接続先として渡してくる点です。apex に CNAME を使えないので、その名前をそのまま付けられません。解法は DNS サービスが提供する次の機能のどれかです。

  • ALIAS または ANAME レコード: apex でも名前を指せるようにする特殊なレコードです。(Route 53 の Alias、一部 DNS の ANAME)
  • CNAME flattening: apex に CNAME のように書き、DNS サービスが応答時に実際の IP に変えて返します。(Cloudflare が代表的)

どちらもなければ、接続先の固定 IP を受け取って apex に A レコードで直接書くしかありません。この場合、対象の IP が変わったら自分で追って直す必要があります。

環境別の設定 #

Linux サーバーに直接載せる場合 #

固定のグローバル IP を持つ Linux サーバーに Nginx でサイトを立てるなら、接続は A レコード一行で終わります。

@                A        203.0.113.10
www              CNAME    schoolofweb.net

サーバー側の Nginx は、両方の名前を受けるように設定します。

server {
    listen 80;
    server_name schoolofweb.net www.schoolofweb.net;
    # ...
}

設定後は、名前が意図した IP に解決されるかを dig で確認します。

dig +short schoolofweb.net A
# 203.0.113.10

dig +short www.schoolofweb.net
# schoolofweb.net.
# 203.0.113.10

クラウド管理型に載せる場合 #

ロードバランサーや CDN の後ろに置く場合は、対象が固定 IP ではなく名前であることが多いです。

  • AWS (Route 53 + ALB/CloudFront): www は CNAME または Alias でロードバランサーの名前を指し、apex は Alias レコードで同じ対象を指します。Alias は AWS 内部のリソースを指すとき料金なしで動きます。
  • Cloudflare: apex と www の両方に CNAME のように対象名を書けば、CNAME flattening のおかげで apex でもそのまま動きます。オレンジの雲(プロキシ)を入れると Cloudflare を経由して入ってきます。
# Cloudflare の例 (プロキシ オン)
@                CNAME    myapp.example-host.com   (flattening 適用)
www              CNAME    myapp.example-host.com

TTL と伝播：移す前に TTL を下げる #

レコードには TTL(Time To Live)があります。ほかの場所がこのレコードをどれくらいの間キャッシュしてよいかを秒単位で決めた値です。TTL が 3600 なら、一時間は変わった値が見えないことがあります。

だからサーバー移転のように IP が変わる作業は、順序が重要です。

  1. 移す一日前に、対象レコードの TTL を 300(5分)以下に下げておきます。
  2. 下げた TTL が広まるまで(元の TTL の分だけ)待ちます。
  3. 実際の移転時にレコードの値を新しい IP に変えます。これで 5分以内にほぼ反映されます。
  4. 安定したら TTL を 3600 程度に戻します。

こうして変わったレコードが世界中のキャッシュに広がることを伝播(propagation)と呼び、TTL を前もって下げておくと伝播による空白を大きく減らせます。

確認ツール：dig の読み方 #

設定が意図どおり解決されるかは、推測せず dig で確認します。dig(Domain Information Groper)は DNS に直接問い合わせて応答をそのまま見せるツールで、Linux と macOS にはたいてい標準で入っています。

基本の問い合わせと出力の読み方 #

オプションなしで問い合わせると、応答の全体が出ます。

$ dig schoolofweb.net A
; <<>> DiG 9.18.18 <<>> schoolofweb.net A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;schoolofweb.net.		IN	A

;; ANSWER SECTION:
schoolofweb.net.	300	IN	A	203.0.113.10

;; Query time: 31 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jul 28 10:12:04 KST 2026
;; MSG SIZE  rcvd: 71

読むところは二か所です。

  • status: NOERROR なら正常な応答です。NXDOMAIN はドメイン自体が存在しないという意味で、NOERROR なのに ANSWER: 0 ならドメインはあるがそのタイプのレコードがないという意味です。
  • ANSWER SECTION: 実際の答えです。一行は 名前 / TTL / クラス(IN) / タイプ / 値 の順で、上では 300 が TTL(秒)、203.0.113.10 がつながった IP です。

値だけ簡単に見る：+short #

値を素早く見るには +short を付けます。

$ dig +short schoolofweb.net A
203.0.113.10

www のように CNAME がかかった名前は、連鎖がそのまま見えます。いちばん上が CNAME の対象、その下が最終的な IP です。

$ dig +short www.schoolofweb.net
schoolofweb.net.
203.0.113.10

レコードのタイプ別の問い合わせ #

タイプを変えながら同じやり方で確認します。

$ dig +short schoolofweb.net MX
10 mail.schoolofweb.net.

$ dig +short schoolofweb.net TXT
"v=spf1 include:_spf.example.com ~all"

$ dig +short schoolofweb.net NS
ns1.cloudflare.com.
ns2.cloudflare.com.

特定のサーバーに直接尋ねる：@ #

@ で問い合わせるサーバーを指定します。権威ネームサーバーに直接尋ねれば伝播と無関係に元の値を見られ、公開リゾルバー(例: 1.1.1.1)に尋ねれば一般ユーザーが受け取るキャッシュ済みの値を見られます。

# 権威ネームサーバーに直接 (伝播前でも元の値を確認)
$ dig @ns1.cloudflare.com schoolofweb.net A +short
203.0.113.10

# 公開リゾルバー経由 (ユーザーが実際に受け取る値)
$ dig @1.1.1.1 schoolofweb.net A +short
203.0.113.10

二つの値が違えば、まだ伝播が終わっていない合図です。

TTL で伝播の状態を読む #

キャッシュされた応答では、TTL が 0 に向かって減っていきます。+noall +answer で答えだけ抜き出して少し後にもう一度問い合わせると、数字が小さくなっているのが見えます。

$ dig +noall +answer schoolofweb.net A
schoolofweb.net.	287	IN	A	203.0.113.10

287 は元の TTL 300 から 13秒が過ぎたという意味です。0 になるとリゾルバーが権威サーバーに尋ね直して新しい値を受け取るので、移す前に TTL を下げておくと新しい値がそのぶん早く反映されます。

ルートから段階を追う：+trace #

応答がおかしいときは、+trace でルートから権威サーバーまで、誰が何を答えるかを段階を追ってたどれます。

$ dig +trace schoolofweb.net
.			518400	IN	NS	a.root-servers.net.
...
net.			172800	IN	NS	a.gtld-servers.net.
...
schoolofweb.net.	86400	IN	NS	ns1.cloudflare.com.
schoolofweb.net.	300	IN	A	203.0.113.10

上から下へ、委任がルート → net → ドメインの権威ネームサーバーの順につながります。途中で切れたり、見当違いのサーバーが出たりしたら、その段階の委任が間違っているという意味です。

dig がないとき #

dig がない環境(一部の Windows など)では、nslookup で基本的な問い合わせができます。

$ nslookup schoolofweb.net
$ nslookup -type=MX schoolofweb.net

よくあるミスのチェックリスト #

  • apex に CNAME を入れようとして詰まる: ALIAS/ANAME か CNAME flattening を使うか、固定 IP に A レコードで置きます。
  • www だけ動いて apex が動かない: apex(@)レコードを抜かした場合です。両方の名前を設定したか確認します。
  • 古い A レコードが残っている: 新しいレコードを追加するだけで古い値を消さないと、一部の訪問者が古いサーバーへ行きます。
  • TTL が高くて変更が見えない: すぐ変わらないからと値を何度も直さず、まず TTL と伝播の時間を確認します。
  • メールが切れる: ネームサーバーを委任しながら MX・TXT(SPF/DKIM)を新しい DNS に移していない場合です。メール配送のしくみはメールはどうやって相手に届くのかを参考にしてください。

まとめ #

ドメインの接続は結局「どのネームサーバーが答え、そこにどんなレコードを書くか」に整理されます。鍵は、apex ドメインの CNAME 制約を知って ALIAS・flattening・A レコードのうち合う解法を選ぶこと、そして移す前に TTL を下げて伝播の空白を減らすことです。

ドメインがつながったら、次は HTTPS 証明書です。実際に証明書を発行して自動で更新する方法は、HTTPS 証明書の実践へ続きます。

X