0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@gtakairo

NSレコードを登録してもらわないとALBは使えない？——DNS委譲からRoute 53 Aliasまでの一本道

0
Last updated at Posted at 2026-08-31

はじめに

ALB を作った。ターゲットグループも healthy。ブラウザに ALB の DNS 名を貼れば、ちゃんとアプリが出る。

http://my-alb-1234567890.ap-northeast-1.elb.amazonaws.com/   → 表示される
http://www.example.com/                                      → 繋がらない

ドメインの管理は別の部署、あるいは社外の業者が握っている。事情を説明したら、こう返ってきた。

「NSレコードを登録してもらわないと ALB は使えないらしいです」

ここで混乱する。ALB は AWS のリソースなのに、なぜ他人が持っているドメインのレコードが要るのか。ALB は NS レコードに依存して動いているのか。

結論から書く。

❌ ALB を使うには NS レコードの登録が必要

👉 ALB は NS レコードと無関係に動いている。動かないのは www.example.com という問い合わせが Route 53 に届いていないから

ALB は最初から動いている。壊れているのは「名前からアドレスを引く経路」のほうだ。そして NS レコードは、その経路を作るための部品にすぎない。

この記事では、ルートから ALB まで一本道で辿る：

  • DNS は「委譲」でできている（NS レコードの正体）
  • NS の登録は誰がどこにするのか（レジストラ側とホストゾーン側）
  • Route 53 のホストゾーン（作った瞬間に何が払い出されるか）
  • Alias レコード（なぜ ALB は CNAME ではなく Alias なのか）
  • ACM の証明書（HTTPS にする段で DNS がもう一度出てくる）
  • dig で切り分ける（どこで委譲が切れているかを目で見る）
  • サブドメインだけ委譲してもらう（親ドメインを渡してもらえないときの逃げ道）
  • 詰まった時に見るところ（症状から疑うところへの早見表）

前提：DNSは「委譲」でできている

DNS には「全部のドメインを知っている台帳」は存在しない。あるのは**「その先は、あっちに聞いてくれ」の連鎖**だけだ。

www.example.com を引くとき、リゾルバ（キャッシュDNSサーバー）はこう歩く。

リゾルバ →「www.example.com のアドレスは？」→ ルートサーバー（ . ）
リゾルバ ←「知らない。com は下のサーバーに聞いて」← ルートサーバー
                                                    NS: com のネームサーバー

リゾルバ →「www.example.com のアドレスは？」→ com のネームサーバー
リゾルバ ←「知らない。example.com は下に聞いて」← com のネームサーバー
                                                    NS: ns-123.awsdns-12.com.
                                                    NS: ns-456.awsdns-45.net.
                                                    NS: ns-789.awsdns-78.org.
                                                    NS: ns-1012.awsdns-01.co.uk.

リゾルバ →「www.example.com のアドレスは？」→ ns-123.awsdns-12.com.（Route 53）
リゾルバ ←「それは私の担当だ。答えはこれ」    ← ns-123.awsdns-12.com.

どの段も、自分より下のことは知らない。知っているのは**「下の担当者の名前」**だけだ。

👉 この「下の担当者はこいつだ」を書き留めたレコードが NS レコードである。NS レコードの正体は、上のゾーンから下のゾーンへ引かれた委譲の矢印そのものだ。

だから NS レコードが存在しないということは、矢印が引かれていないということで、リゾルバは 2 段目で足止めを食う。example.com の担当者が誰なのか、誰にも聞けない。

委譲の矢印は 2 箇所にある

ここが後で効いてくるので、先に押さえておく。example.com の NS レコードは、2 つの別々のゾーンに、それぞれ独立して存在する。

[ com ゾーン ]  ← レジストラ経由で登録する側（親）
example.com.   NS   ns-123.awsdns-12.com.
example.com.   NS   ns-456.awsdns-45.net.
example.com.   NS   ns-789.awsdns-78.org.
example.com.   NS   ns-1012.awsdns-01.co.uk.

[ example.com ゾーン ]  ← Route 53 のホストゾーンが持つ側（権威）
example.com.   NS   ns-123.awsdns-12.com.
example.com.   NS   ns-456.awsdns-45.net.
example.com.   NS   ns-789.awsdns-78.org.
example.com.   NS   ns-1012.awsdns-01.co.uk.
  • 親（com ゾーン）が持つ NS — 委譲する側が書く矢印。リゾルバが上から降りてくるとき、最初に辿るのはこちら
  • 委譲先（example.com ゾーン）自身が持つ NS — 委譲される側が自分で名乗る宣言。ゾーンの頂点（apex）に置かれる

なお、ゾーン頂点のこの 4 台は 4 本の NS レコード（同じ名前・同じ型のレコードの集合）だ。Route 53 のコンソールが 1 行にまとめて表示するのは画面上の都合であり、DNS のプロトコル上は 4 本である。

内容が一致しているのが正常な状態だが、両者は別物なので食い違うことがある。ホストゾーンを作り直して 4 台の名前が変わったのに、レジストラ側を直し忘れた——という事故がまさにこれで、権威側だけを見ていると何も問題が無いように見える。

👉 後の dig の章で「親に聞く」と「権威に聞く」を分けて実行するのは、この 2 箇所を別々に確かめるためだ。片方だけ見ても、委譲が繋がっているかは判定できない。

NSレコードを登録するとは何をしているのか

前提章で見た、com ゾーンが持つ側の NS 4 行を思い出してほしい。

レジストラの管理画面にある「ネームサーバーを変更」「NSレコードの設定」といった項目は、突き詰めればこの 4 行を com ゾーンに書き込む依頼にすぎない。画面の見た目はレジストラごとに違っても、やっていることは同じで、Route 53 が払い出した 4 台のネームサーバー名を、親ゾーンの委譲情報として登録している。

なぜ AWS 側で代行できないのか

com ゾーンを管理しているのは AWS ではない。レジストリ（.com の場合は Verisign）と契約しているのは、レジストラ経由でドメインを登録した側だけだ。AWS 側にできるのは、委譲先である Route 53 のホストゾーンに 4 台のネームサーバーを用意することまでで、その名前を親ゾーンに書き込む権限は持っていない。

だから「NSレコードを登録してもらう」という一手間は、ドメインを持っている側にしか押せないボタンを、代わりに押してもらう作業になる。冒頭で「ALB は AWS のリソースなのに、なぜ他人が持っているドメインのレコードが要るのか」と感じたところの答えはここにある。ALB 自体は NS レコードと無関係に動くが、www.example.com という問い合わせをそもそも Route 53 まで届けるには、この一手間が要る。

反映が遅い理由

登録してすぐに切り替わるとは限らない。AWS のドキュメントは、ネームサーバー（やグルーレコード）の変更を誤ると最大 2 日程度サイトが使えなくなり得ると明記している。理由は、DNS リゾルバが上位から得たネームサーバー名を通常 2 日間キャッシュするからだ。

👉 リゾルバは一度「example.com の担当はここ」と覚えると、そのキャッシュが切れるまで聞き直しに行かない。親ゾーンの登録を書き換えても、すでにキャッシュを持っているリゾルバには、キャッシュが切れるまで新しい委譲が見えない。

ホストゾーンを作る

ここまで「NSレコードを登録する」を主語に説明してきたが、実際の作業順は逆だ。登録するには、まず親ゾーンに渡す 4 台のネームサーバー名が要る。それを手に入れる場所がホストゾーンだ。

$ aws route53 create-hosted-zone \
    --name example.com \
    --caller-reference $(date +%s)

レスポンスには、払い出された 4 台のネームサーバーが DelegationSet.NameServers に入って返ってくる。

{
  "HostedZone": {
    "Id": "/hostedzone/Z0123456789ABCDEFGHIJ",
    "Name": "example.com.",
    "CallerReference": "1788134400",
    "Config": {
      "Comment": "",
      "PrivateZone": false
    },
    "ResourceRecordSetCount": 2
  },
  "ChangeInfo": {
    "Id": "/change/C0123456789ABCDEFGHIJ",
    "Status": "PENDING",
    "SubmittedAt": "2026-08-31T00:00:00.000Z"
  },
  "DelegationSet": {
    "Id": "/delegationset/N0123456789ABCDEFGHIJ",
    "CallerReference": "1788134400",
    "NameServers": [
      "ns-123.awsdns-12.com",
      "ns-456.awsdns-45.net",
      "ns-789.awsdns-78.org",
      "ns-1012.awsdns-01.co.uk"
    ]
  },
  "Location": "https://route53.amazonaws.com/2013-04-01/hostedzone/Z0123456789ABCDEFGHIJ"
}

この NameServers の 4 本が、前章でレジストラに渡した 4 行の正体だ。ホストゾーンを作った時点で、Route 53 は「この 4 台が example.com の担当です」と自分自身のゾーンに 4 本の NS レコードを書く。あとはこの 4 台の名前を、親（com ゾーン）側にも同じ内容で登録してもらえば、委譲の矢印が両側でつながる。

👉 章の並びは「NS登録 → ホストゾーン」で書いたが、手を動かす順番は逆になる。ホストゾーンを先に作らないと、レジストラに渡す 4 台の名前がそもそも手元にない。記事の説明順は「委譲される側が何を用意しているか」を先に理解してもらうための都合で、実際の作業はホストゾーン作成が最初の一歩になる。

ALB を指す：Alias レコード

前章までで、委譲の矢印は両側でつながった。リゾルバは「example.com の担当は Route 53 のあの 4 台だ」と知っていて、問い合わせは確かに Route 53 まで届く。

残る問題はひとつ。Route 53 は何を返せばいいのか——www.example.com への問い合わせに対して答えを返すレコードを、ホストゾーンに置く番だ。

ALB は固定の IP アドレスを持たない。だから A レコードに IP を直接書く方法は使えない（理由は次章で見る）。代わりに使うのが Alias レコードだ。

$ aws route53 change-resource-record-sets \
    --hosted-zone-id Z0123456789ABCDEFGHIJ \
    --change-batch file://alias-change.json

alias-change.json の中身。

{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z14GRHDCWA56QT",
          "DNSName": "my-alb-1234567890.ap-northeast-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

AliasTarget の 3 フィールド:

  • DNSName — 指す先。ALB の DNS 名そのもの
  • EvaluateTargetHealth — ALB のヘルスチェック結果を Route 53 の応答に反映するかどうか
  • HostedZoneId — ここが罠

👉 AliasTarget.HostedZoneId は、このレコード自体が属する Route 53 のホストゾーン ID（Z0123456789ABCDEFGHIJ、コマンドの --hosted-zone-id に渡した値）ではない。 ELB がリージョンごとに持つ、固定のゾーン ID だ。ap-northeast-1 の ALB/CLB の場合は Z14GRHDCWA56QT（NLB はまた別の値になる）。

同じ JSON の中に、似て非なる 2 つの「ゾーン ID」が同居している。--hosted-zone-id（コマンド引数）は「このレコードをどのホストゾーンに書き込むか」、AliasTarget.HostedZoneId（JSON の中身）は「指す先の ALB がどのゾーン ID の世界に属しているか」——名前は似ているが、指しているものはまったくの別物だ。

値を暗記する必要はない。取得方法は2通り。

$ aws elbv2 describe-load-balancers \
    --names my-alb \
    --query 'LoadBalancers[0].CanonicalHostedZoneId'

もしくは Route 53 コンソールでレコードを作るとき、「エイリアス」を ON にしてリストから対象の ALB を選べば、HostedZoneId は自動で入る。どちらの方法でも、値を暗記して手で打つ必要はない。

Alias / CNAME / A の使い分け

なぜ A でも CNAME でもなく Alias なのか。3 つのレコード種別を並べる。

レコード種別 ALB を指せるか apex に置けるか クエリ課金
A ✕ IP を直書きするしかない ✓ 課金される
CNAME ✓ 名前で指せる ✕ 課金される
Alias ✓ 名前で指せる ✓ ELB・CloudFront・S3 静的サイト等の対象 AWS リソースを指す場合は無課金

ALB の IP は変わる

❌ ALB の IP アドレスを調べて、A レコードに直接書く

ALB は複数の AZ にまたがる複数の IP アドレスを持ち、スケーリングやメンテナンスのタイミングで入れ替わる。ある時点で引けた IP を A レコードに固定してしまうと、その IP が差し替わった瞬間に繋がらなくなる。ALB の DNS 名（my-alb-1234567890.ap-northeast-1.elb.amazonaws.com）を名前として指す方法でなければ、IP の変動に追従できない。

Zone Apex に CNAME は置けない

www.example.com のようなサブドメインなら CNAME で ALB の DNS 名を指せる。だが example.com 自体（ゾーンの頂点 = apex）には CNAME を置けない。

根拠は 2 つの RFC にある。

  • RFC 1034 §3.6.2: 「あるノードに CNAME レコードが存在する場合、他のデータは存在すべきでない」
  • RFC 2181 §10.1: あるドメイン名について「CNAME レコードが 1 つだけ存在する」か「CNAME でないレコードが 1 つ以上存在する」かのどちらか一方でなければならず、両者は共存できない

一方で、ゾーン apex には SOA レコードと NS レコードが必ず存在する（前々章で見た「4 本の NS レコード」がまさにこれだ）。この 2 つの事実を組み合わせると——apex にはすでに SOA と NS が存在しているので、そこへ CNAME を追加で置くことはできない、と説明できる。AWS 公式ドキュメントも「example.com に CNAME レコードは作成できない」と明記している。

👉 だから example.com 自体を ALB に向けたい場合、CNAME という選択肢はそもそも存在しない。Alias レコードは A レコードとして登録されるため、SOA・NS と同じ apex に共存できる。

Alias は Route 53 内部で解決される

Alias レコードへの問い合わせは、Route 53 が自分の中で ALB の実体を引いて返す。CNAME のように別名を経由してもう一段問い合わせをやり直す、という動きはしない。

そして課金面では、ALB を指す Alias レコードへのクエリは Route 53 の課金対象外になる。

👉 ただし「Alias なら常に無課金」ではない。無課金になるのは、Alias のターゲットが ELB・CloudFront・S3 の静的サイトホスティング用バケットなど、特定の AWS リソースを指す場合に限られる。同じホストゾーン内の別のレコードを指す Alias や、対象外のリソースを指す Alias は、通常どおり課金される。

HTTPS：ACM のDNS検証も同じ道を通る

ここまでで www.example.com は ALB を指すようになった。だが今の状態は HTTP だけだ。HTTPS で終端するには、ALB にアタッチする証明書が要る。

ACM（AWS Certificate Manager）で証明書をリクエストすると、検証方法に「DNS 検証」を選べる。選ぶと、ACM がこういう CNAME レコードを追加してくれと言ってくる。

レコード名: _ダミーハッシュ1234.example.com.
種別:       CNAME
値:         _ダミーハッシュ5678.acm-validations.aws.

これを example.com のホストゾーンに置く。ここで気づく人がいるかもしれない。これも DNS のレコードを 1 本追加するだけの作業だ。ALB の Alias レコードを置いたときと、何も変わらない。

ACM コンソール上のステータスは、レコードを置いた直後は Pending validation（検証待ち）のままだ。72 時間以内に検証できないと Validation timed out になる。

👉 委譲が終わっていないと、このステータスは Pending validation から先に進まない。 ACM は自分の手元にある情報だけで検証しているわけではない。_ダミーハッシュ1234.example.com を実際に引きに行き、値が _ダミーハッシュ5678.acm-validations.aws. と一致するかを確認する——「DNS 検証」とは、その名の通り外部から見える DNS の記録を確認する仕組みだ。委譲の矢印が繋がっていなければ、ACM の問い合わせも Route 53 まで届かず、レコードを正しく置いていても検証は進まない。

ステータスは CLI でも確認できる。

$ aws acm describe-certificate \
    --certificate-arn <ARN> \
    --query 'Certificate.DomainValidationOptions[0].ValidationStatus'

👉 CLI が返す値はコンソールの表記と違い、PENDING_VALIDATION のようにアンダースコア区切りの大文字になる。表記が違うだけで意味は同じだ。

👉 なお、ワイルドカード証明書（*.example.com）とベースドメイン（example.com）を同時にリクエストした場合、検証レコードは両者で共有される。2 本用意する必要はない。

NS の登録は、ここまで「ALB に繋ぐため」の前提として説明してきた。だが実際には「HTTPS 化のため」の前提でもある。ACM の検証も、ALB への到達も、どちらも同じ一本道——委譲が繋がっているかどうか——の上に乗っている。

dig で答え合わせ

委譲がどこまで繋がっているかを、憶測ではなく dig で確かめる。目的が違えば、引き方も変える。

コマンド 何を確かめるか
dig +trace www.example.com ルートから順に、矢印が繋がっているか
dig NS example.com @a.gtld-servers.net 親（.com）が Route 53 を指しているか
dig www.example.com @ns-123.awsdns-12.com 権威（Route 53）自体は正しく答えるか

+trace はルートから順番に辿ってくれるので、まず全体を通しで見るのに向く。ただし途中のどこで止まっているかまでは、出力を読み込まないと分からない。

@a.gtld-servers.net（.com の TLD サーバーの 1 つ）を指定して NS だけを聞くのは、前章で見た「親（com ゾーン）が持つ NS」を直接確認する方法だ。ここに ns-123.awsdns-12.com などが並んでいなければ、レジストラ側の登録がまだ終わっていない。

@ns-123.awsdns-12.com（Route 53 が払い出した 4 台のうちの 1 つ）を指定するのは、「委譲先ゾーン自身が持つ NS」＝権威サーバーに直接聞く方法だ。ここで正しい答えが返るなら、Route 53 側の設定は問題ない。

example.com は RFC 2606 の予約ドメインで実際には引けないので、ここから先は実在ドメインで引いた生の出力を載せる。自分のドメインに読み替えてほしい。

A. dig +trace で通しで辿る

$ dig +trace www.example.net | head -60

; <<>> DiG 9.18.39-0ubuntu0.24.04.6-Ubuntu <<>> +trace www.example.net
;; global options: +cmd
.			6615	IN	NS	e.root-servers.net.
.			6615	IN	NS	g.root-servers.net.
.			6615	IN	NS	h.root-servers.net.
.			6615	IN	NS	d.root-servers.net.
.			6615	IN	NS	a.root-servers.net.
.			6615	IN	NS	k.root-servers.net.
.			6615	IN	NS	l.root-servers.net.
.			6615	IN	NS	b.root-servers.net.
.			6615	IN	NS	m.root-servers.net.
.			6615	IN	NS	j.root-servers.net.
.			6615	IN	NS	f.root-servers.net.
.			6615	IN	NS	i.root-servers.net.
.			6615	IN	NS	c.root-servers.net.
;; Received 503 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

net.			172800	IN	NS	a.gtld-servers.net.
net.			172800	IN	NS	m.gtld-servers.net.
net.			172800	IN	NS	g.gtld-servers.net.
net.			172800	IN	NS	i.gtld-servers.net.
net.			172800	IN	NS	c.gtld-servers.net.
net.			172800	IN	NS	d.gtld-servers.net.
net.			172800	IN	NS	f.gtld-servers.net.
net.			172800	IN	NS	b.gtld-servers.net.
net.			172800	IN	NS	e.gtld-servers.net.
net.			172800	IN	NS	h.gtld-servers.net.
net.			172800	IN	NS	j.gtld-servers.net.
net.			172800	IN	NS	k.gtld-servers.net.
net.			172800	IN	NS	l.gtld-servers.net.
net.			86400	IN	DS	37331 13 2 2F0BEC2D6F79DFBD1D08FD21A3AF92D0E39A4B9EF1E3F4111FFF2824 90DA453B
net.			86400	IN	RRSIG	DS 8 1 86400 20260913050000 20260831040000 57780 . ZDyB2edh4TU0poGCB+MPIEFxKKIC2i3tiOEVjrrb0jKBqi2pYivUmOwa uEx6yoMw8k9dX1tTyBfXasYC25agpq57xN98FBB9SLACdqBkraYMx+eZ GKPknfXtjnZK95zdkfdJd42IOmXNiJgKiMpf6pHIUEm4paFSmpQo7EV7 /Iw7/MLTgvneLXwKJXT9AiPkU4gOSNKOazlmykDPdzKb4L/xg0ZhFB1V cU7h84E5XfbtgO/+omIZ8WiQM8B2SDYehH2fs36ELxAKrQlfBpRwwtH9 up4SKldrw6Z1XHTu7aZ76fBntIbTHlypZr8V11jrBHWIJjp34RMVLfhZ Tu4row==
;; Received 1200 bytes from 192.112.36.4#53(g.root-servers.net) in 780 ms

;; UDP setup with 2001:501:b1f9::30#53(2001:501:b1f9::30) for www.example.net failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:501:b1f9::30#53(2001:501:b1f9::30) for www.example.net failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:501:b1f9::30#53(2001:501:b1f9::30) for www.example.net failed: network unreachable.
;; UDP setup with 2001:500:d937::30#53(2001:500:d937::30) for www.example.net failed: network unreachable.
example.net.		172800	IN	NS	hugh.ns.cloudflare.com.
example.net.		172800	IN	NS	betty.ns.cloudflare.com.
example.net.		86400	IN	DS	2371 13 2 6EBDD24B59EBB0A642D07F2D8EF3CB65AAF1124FA5507FB2F2101D53 B45FE666
example.net.		86400	IN	RRSIG	DS 13 2 86400 20260907033827 20260831022827 7272 net. fGQOh8I5n628qVM27IlJh+02IOw40XbtCCmHMf24v3P6X3o9EzEypkx9 U/5Q4GIES2JtEspYEqzJQzq2P9aw+A==
;; Received 247 bytes from 192.35.51.30#53(f.gtld-servers.net) in 206 ms

www.example.net.	300	IN	A	104.20.21.8
www.example.net.	300	IN	A	172.66.175.59
www.example.net.	300	IN	RRSIG	A 13 3 300 20260901122653 20260830102653 34505 example.net. 25IwjQGENO613+2ma5GcDzUxhpvy4xsqNP2IDcbWijzhzGLqh9wgT3FQ WftkR32wBduJTburNHEWaGtJy1gRVA==
;; Received 183 bytes from 173.245.59.117#53(hugh.ns.cloudflare.com) in 71 ms

これはローカルリゾルバ（127.0.0.53）から始めて、ルートサーバー →.net の TLD サーバー → example.net の権威サーバー（Cloudflare の hugh.ns.cloudflare.com / betty.ns.cloudflare.com）と、委譲を 1 段ずつ辿った記録だ。;; Received ... bytes from <server> の行が、直前にどのサーバーから答えが返ったかを示している。最後の段で hugh.ns.cloudflare.com から www.example.net の A レコードが 2 件そのまま返り、そこで止まっている。

途中の network unreachable / no servers could be reached は、採取した環境に IPv6 の疎通が無く、dig が IPv6 のサーバーを飛ばして IPv4 にフォールバックした跡だ。委譲が切れているサインではない。

👉 これが自分のドメインなら、最後の段の相手は hugh.ns.cloudflare.com ではなく ns-123.awsdns-12.com（Route 53 が払い出した 4 台のうちの 1 つ）になる。途中の段のどこかで詰まっていれば、そこが委譲の切れ目だ。

B. 親（TLD サーバー）に NS を聞く

ここから先は別の実ドメインの出力になる。A の example.net から amazon.com に切り替わるが、見ているコマンドの意味は変わらない——親（TLD サーバー）に NS だけを聞く。

$ dig NS amazon.com @a.gtld-servers.net

; <<>> DiG 9.18.39-0ubuntu0.24.04.6-Ubuntu <<>> NS amazon.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33637
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;amazon.com.			IN	NS

;; AUTHORITY SECTION:
amazon.com.		172800	IN	NS	ns-521.awsdns-01.net.
amazon.com.		172800	IN	NS	ns-264.awsdns-33.com.
amazon.com.		172800	IN	NS	ns-1707.awsdns-21.co.uk.
amazon.com.		172800	IN	NS	ns-1447.awsdns-52.org.

;; ADDITIONAL SECTION:
ns-264.awsdns-33.com.	172800	IN	A	205.251.193.8
ns-264.awsdns-33.com.	172800	IN	AAAA	2600:9000:5301:800::1

;; Query time: 184 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net) (UDP)
;; WHEN: Mon Aug 31 19:17:10 CST 2026
;; MSG SIZE  rcvd: 220

この応答では ANSWER SECTION が存在せず（ヘッダーの ANSWER: 0）、AUTHORITY SECTION に amazon.com の NS が 4 件並んでいる。TLD サーバーは amazon.com の中身を知っているわけではなく、「この先はこの 4 台に聞いてくれ」という委譲情報だけを返している。これが委譲応答の形だ。

ここで改めて「権威」という言葉をきちんと定義しておく。権威サーバーとは、あるゾーンについて「自分が正式な答えを持っている」と宣言して応答するサーバーのことだ。AUTHORITY SECTION に並んでいるのは、権威サーバーそのものの応答ではなく、「権威サーバーはこの 4 台だ」という又聞き情報にすぎない。実際にその 4 台のどれかに聞きに行って初めて、権威に聞いたことになる。

👉 これが自分のドメインなら、AUTHORITY SECTION に並ぶのは ns-123.awsdns-12.com などの 4 台になる。

C. 権威サーバーに直接聞く

A の最後の段に出てきた example.net の権威サーバー hugh.ns.cloudflare.com に、今度は直接聞く（ドメインは A の example.net に戻る）。

$ dig www.example.net @hugh.ns.cloudflare.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.6-Ubuntu <<>> www.example.net @hugh.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20445
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.example.net.		IN	A

;; ANSWER SECTION:
www.example.net.	300	IN	A	172.66.175.59
www.example.net.	300	IN	A	104.20.21.8

;; Query time: 13 msec
;; SERVER: 108.162.193.117#53(hugh.ns.cloudflare.com) (UDP)
;; WHEN: Mon Aug 31 19:24:44 CST 2026
;; MSG SIZE  rcvd: 76

ヘッダーの ;; flags: qr aa rd に aa（authoritative answer）が立っている。これは、この応答がキャッシュ経由の又聞きではなく、example.net の権威サーバー自身が返した正式な回答であることを示す。ANSWER SECTION には CNAME を挟まず A レコードが 2 件そのまま入っている——Route 53 の Alias レコードが ALB を指す場合と同じ、CNAME を経由しない形だ。

👉 これが自分のドメインなら dig www.example.com @ns-123.awsdns-12.com に相当する。aa が立った応答が返れば、Route 53 側の設定そのものは正しい。

D. 存在しない名前を引いた場合（権威的な否定応答）

$ dig this-subdomain-does-not-exist.amazon.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.6-Ubuntu <<>> this-subdomain-does-not-exist.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58474
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;this-subdomain-does-not-exist.amazon.com. IN A

;; AUTHORITY SECTION:
amazon.com.		3600	IN	SOA	dns-external-route53.us-east-1.amazonaws.com. root.amazon.com. 201 3600 900 604800 60

;; Query time: 16 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Aug 31 19:17:16 CST 2026
;; MSG SIZE  rcvd: 151

status: NXDOMAIN が返っている。この問い合わせには @サーバー名 の指定がなく、;; SERVER: 127.0.0.53#53(127.0.0.53) の通りローカルの再帰リゾルバに聞いた結果だ。;; flags: qr rd ra に aa は立っていない——この応答自体は権威サーバーからの直接の回答ではない。それでも AUTHORITY SECTION に SOA レコードが 1 件入っているのは、リゾルバが裏で権威サーバー（Route 53）まで辿り着き、そこで「そのような名前は存在しない」という否定応答を受け取って、それをそのまま中継しているからだ。

👉 判定の要点はここ。B や C のように権威サーバーに直接聞けば筋の通った応答（委譲応答、または aa 付きの正式な回答）が返るのに、dig www.example.com を素朴に引くと同じ答えが返ってこない——これが「委譲が切れている」ときの見え方だ。委譲前は A の 2 段目（親から先）で答えが途切れるか、そもそも example.com の NS 自体を親が知らない。委譲後は A が最後まで通しで辿れて、権威に直接聞いた C と同じ答えに行き着く。権威サーバー自体は最初から正しく設定されている場合が多く、壊れているのはたいてい権威サーバーへの「たどり着き方」のほうだ。

応用：サブドメインだけ委譲する

「NS の登録をお願いする」がどうしても通らない場合もある。example.com 自体は他チーム、あるいは社外ベンダーの管理下にあり、そのゾーンにレコードを足す権限はこちらには無い——これは冒頭で立てた前提そのものだ。

ここまでの一本道は、example.com 全体を委譲してもらえる前提で書いてきた。だが実際に必要なのは api.example.com だけかもしれない。その場合、example.com ごと委譲してもらう必要はない。api.example.com のようなサブドメインだけを、自分の Route 53 に切り出して委譲してもらうという手がある。

委譲は「どのゾーンからどのゾーンへ矢印を引くか」の話でしかない。矢印の起点が .com から example.com に変わるだけで、やることは変わらない。

手順

  1. api.example.com のホストゾーンを作る
$ aws route53 create-hosted-zone \
    --name api.example.com \
    --caller-reference $(date +%s)

  1. レスポンスから、そのゾーンの NS 4 本を得る（「ホストゾーンを作る」章で見た DelegationSet.NameServers と同じ形で返ってくる）

  2. 親ゾーン（example.com）に NS レコードを 4 本足してもらう

api.example.com.   NS   ns-123.awsdns-12.com.
api.example.com.   NS   ns-456.awsdns-45.net.
api.example.com.   NS   ns-789.awsdns-78.org.
api.example.com.   NS   ns-1012.awsdns-01.co.uk.

👉 実際には api.example.com 用のホストゾーンは example.com のホストゾーンとは別に払い出されるので、この 4 台は example.com が持つ 4 台とは異なる値になる。ここでは説明のために同じダミー値を使っているだけで、値が一致するという意味ではない。

依頼文の形

相手に渡すのは、example.com ゾーン全体の管理権限ではない。api.example.com という 1 つのサブドメインの担当者情報、レコード名・種別・値・TTL の 4 点だけだ。

以下の NS レコードを example.com のゾーンに追加してください。

レコード名: api.example.com
種別:       NS
値（4件）:
  ns-123.awsdns-12.com.
  ns-456.awsdns-45.net.
  ns-789.awsdns-78.org.
  ns-1012.awsdns-01.co.uk.
TTL:        既存の NS レコードに合わせてください

これだけで委譲は成立する。渡すのは 4 行のテキストであって、example.com の管理権限そのものではない。

👉 委譲さえ済めば、その先——api.example.com のホストゾーンに Alias レコードを置いて ALB を指す話も、ACM の DNS 検証を通す話も——前の章とまったく同じ手順になる。委譲の起点が .com から example.com に変わっただけで、やることは何一つ変わらない。

もっと軽い頼み方：CNAME を 1 本もらう

委譲そのものが通らないこともある。「ゾーンに NS を足すのは前例がない」「委譲は運用ポリシー上できない」——よくある返事だ。

その場合でも、www.example.com を ALB に向けるだけなら、頼む量はもっと減らせる。親ゾーンに CNAME を 1 本入れてもらえばいい。

レコード名: www.example.com
種別:       CNAME
値:         my-alb-1234567890.ap-northeast-1.elb.amazonaws.com

この形では Route 53 は登場しない。www.example.com の権威は example.com のゾーン（＝相手側）のままで、こちらが渡すのは ALB の DNS 名 1 行だけだ。「使い分け」の章で見たとおり、サブドメインなら CNAME で ALB を指せる。

ただし失うものがある。

  • apex には使えない。 example.com 自体を ALB に向けたいなら CNAME という選択肢は無く、Alias が要る。そして Alias を置くには自分の Route 53 に委譲されている必要がある。
  • ACM の検証レコードも頼むことになる。 HTTPS 化するなら _ダミーハッシュ1234.www.example.com の CNAME も example.com ゾーンの側に入れてもらう必要がある。頼みは 1 回では済まない。
  • 名前が増えるたびに頼む。 委譲は一度通してしまえば、その先のレコードは自分で足せる。CNAME 方式は api を足すときも admin を足すときも、相手を経由する。

👉 一度きりなら CNAME、これから増えるなら委譲。相手の負担は CNAME のほうが軽く、こちらの自由度は委譲のほうが高い。頼みが通らなかったときの落とし所として、この二段構えを持っておくといい。

詰まった時に見るところ

症状から、どこを疑ってどう確かめるかの早見表。確認コマンドは前章で使った形をそのまま使う。

症状 疑うところ 確認コマンド
NXDOMAIN レコード未作成、またはゾーンが別 dig www.example.com @ns-123.awsdns-12.com
SERVFAIL 委譲先の NS が応答しない／委譲設定の不整合 dig NS example.com @a.gtld-servers.net
古い IP が返る キャッシュ（TTL）、または A レコード直書きの残骸 dig +trace www.example.com
ACM が検証待ちのまま 委譲未完了、または検証 CNAME の置き場所違い dig CNAME _ダミーハッシュ1234.example.com @ns-123.awsdns-12.com
apex だけ引けない apex に CNAME を置こうとしている aws route53 list-resource-record-sets --hosted-zone-id Z0123456789ABCDEFGHIJ

各行、前章の語彙で読み解く。

NXDOMAIN

権威（Route 53）に直接聞いて status: NXDOMAIN が返るなら、Route 53 側にそのレコードが存在しない。前章 D で見た「権威的な否定応答」と同じ形だ。作ったつもりのレコードが違うホストゾーンに入っている、あるいはそもそも作られていない可能性を疑う。

SERVFAIL

dig NS example.com @a.gtld-servers.net を引いて、AUTHORITY SECTION に並ぶ NS が実際に生きている 4 台と食い違っていないか確認する。「前提」章で触れた「親と権威で内容が食い違う」事故がこれに当たる。委譲先のホストゾーンを作り直して 4 台の名前が変わったのに、親側の登録を直し忘れていると、ここで詰まる。

古い IP が返る

dig +trace で通しで辿り、どの段の答えが古いのかを見る。最後の段（権威からの応答）自体が古ければ Route 53 側のレコードが残っている。途中の段で止まっていれば、リゾルバのキャッシュが古い委譲情報を握ったままの可能性がある。

ACM が検証待ちのまま

ACM が引きに行くのは CNAME レコードだ。同じ権威サーバーに、その CNAME を直接聞く。返る値が ACM コンソールに表示された値と一致しているか、レコード名がベースドメインの手前に正しく付いているかを確認する。

apex だけ引けない

ホストゾーンの中身を一覧して、apex（example.com そのもの）に CNAME が置かれていないか探す。「使い分け」章で見た通り、apex には CNAME を置けない。Alias なら共存できる。

まとめ

www.example.com から ALB までの一本道を、もう一度並べる。

  • レジストラで example.com の NS レコードを登録する（親ゾーンに委譲の矢印を引く）
  • Route 53 にホストゾーンを作る（権威側の矢印を立てる。4 台のネームサーバーが払い出される）
  • ホストゾーンに Alias レコードを置いて ALB を指す（IP の変動に追従でき、apex にも置ける形で）
  • ACM で DNS 検証の CNAME を追加する（HTTPS 化も同じ委譲の上に乗っている）

途中で詰まったら、dig で「親に聞く」か「権威に聞く」かを切り分ける。それだけで、どちら側の設定が壊れているかが分かる。

冒頭に立てた問いに戻る。

「NSレコードを登録してもらわないと ALB は使えないらしいです」

❌ ALB を使うには NS レコードの登録が必要

これは半分だけ正しい。ALB 自体は NS レコードの有無に関わらず、最初から正しく動いている。ターゲットグループのヘルスチェックも通っている。壊れているのは ALB ではない。

👉 ALB が使えないのではなく、質問が Route 53 に届いていない。

NS レコードは、www.example.com という問い合わせを Route 53 まで届けるための「委譲の矢印」だ。矢印が引かれていなければ、リゾルバは example.com の担当者を誰にも聞けず、Route 53 に問い合わせが届く前に迷子になる。矢印さえ両側で繋がれば、あとは Alias レコードが答えを返すだけで、ALB はずっとそこにいる。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?