3-3 電話帳を管理する（DNS）
第 1 章では、お客さんが電話帳を引いて窓口を探す様子を見ました。この章では、その電話帳を自分で書きます。
いま読んでいるこのサイト（Cloudflare Lab）の店名を登録すると、電話帳が 1 冊できます。ここに何を書くかで、お客さんがどこへ向かうかが決まります。
ここでは、電話帳 1 冊の単位、預かり先、1 行の構成、受付を通す印、封印の順に見ます。
Learning goals
この節でできるようになること
- zone と nameserver の関係を自分の言葉で説明できる
- DNS レコード 1 行の五つの要素を言える
- proxied と DNS-only で何が変わるかを説明できる
- DNSSEC が何を守るかを説明できる
1. 電話帳 1 冊と、その預かり先（zone と nameserver）
Section titled “1. 電話帳 1 冊と、その預かり先（zone と nameserver）”店名ごとに電話帳が 1 冊あり、どこが預かっているかが決まっています。お客さんは「この店名の電話帳はどこ？」と聞いてから中身を引きます。
Cloudflare では、電話帳 1 冊を zone と呼びます。預かり先が nameserver で、Cloudflare が預かる形が primary setup（full setup）です。公式は、これが最も一般的な形だと書いています。
実物では、Registrar で登録したドメインは最初から Cloudflare の nameserver を使います。他社で登録したドメインなら、登録先で nameserver を Cloudflare のものに書き換え、認証されて初めて zone が active になります。
Cloudflare の棚に、店名ごとの電話帳が並んでいます。その電話帳をどこが預かっているかを案内するのが nameserver です。
つまり、zone は店名 1 つぶんの電話帳で、nameserver はその預かり先の案内です。
2. 電話帳の 1 行（DNS レコード）
Section titled “2. 電話帳の 1 行（DNS レコード）”電話帳の 1 行には、名前と番号だけでなく、種類や有効期間も書いてあります。
Cloudflare では、この 1 行を DNS record と呼びます。作るときに決める項目は、Type（種類）、Name（名前）、Content（中身）、Proxy status（受付を通すか）、TTL（写しを手元に置いてよい時間） です。
実物では、A は名前 → IPv4 の番号、AAAA は名前 → IPv6 の番号、CNAME は名前 → 別の名前、という種類です。作る経路はダッシュボードの DNS Records 画面で Add record です。
1 行の中に、名前・種類・中身・受付を通すかの雲マーク・時間が並びます。どれか一つ欠けても行になりません。
つまり、DNS レコードは「誰を、どこへ、どう案内するか」を 1 行で書いたものです。
3. 受付を通す行の目印（proxied と DNS-only）
Section titled “3. 受付を通す行の目印（proxied と DNS-only）”第 1 章の復習です。電話帳に受付の番号を載せるか、本社直通を載せるかで、お客さんが通る道が変わります。
Cloudflare では、受付を通す行を proxied（オレンジ雲）、通さない行を DNS-only（灰色雲） と呼びます。proxied の行に問い合わせると、本社の番号ではなく Cloudflare の anycast IP が返ります。公式は、proxied にできるのは A・AAAA・CNAME の行だと書いています。
実物では、後の章で使う守り（WAF・Rate Limiting）や速さ（Cache Rules）は、proxied の行にしか効きません。DNS-only の行は電話帳としてだけ働きます。
proxied（オレンジ雲）
DNS-only（灰色雲）
同じ電話帳でも、行ごとに雲の色を選べます。受付を通したい行だけオレンジにします。
つまり、Cloudflare の機能を使う行は proxied にします。
4. 電話帳の封印（DNSSEC）
Section titled “4. 電話帳の封印（DNSSEC）”電話帳が途中で書き換えられたら、お客さんは偽の窓口へ案内されてしまいます。写しを配る途中で改ざんされないよう、封印が要ります。
Cloudflare では、この封印を DNSSEC と呼びます。DNS の応答に暗号の署名を付け、受け取った側が本物かを確かめられる仕組みです。公式は、Cloudflare の全利用者に無料で提供し、ワンクリックで有効化できると書いています。
実物では、Registrar で登録したドメインなら、DNSSEC の有効化に必要な登録先への設定も Cloudflare 側でまとまります。
封印のある電話帳は、途中で差し替えられても見破れます。封印そのものは中身を隠しません。
つまり、DNSSEC は電話帳の「本物である証明」です。
Cloudflare Lab での使われ方
Section titled “Cloudflare Lab での使われ方”ここで紹介した電話帳の書き方が、いま読んでいる Cloudflare Lab でどう使われているかを見ます。
Cloudflare Lab の電話帳には、行が 1 行しかありません。次の節の看板（Custom Domain）を掛けたときに自動でできた行で、手で書いたものではありません。ダッシュボードの DNS の Records 画面には、こう出ています（2026-08-27）。
- Name
- clf.cloud-labos.com
- Type
- Worker
- Content
- cloudflare-lab
- Proxy status
- Proxied
- TTL
- Auto
向き先の Worker の名前
Type の Worker は、看板（Custom Domain）を掛けた時に Cloudflare が作る種類で、この節の 2 で見た A・AAAA・CNAME を自分で選んだものではありません。同じ画面に「You have used 1 of 200 available DNS records」と出ていて、使っている行はこの 1 行だけです。
この店名を外から引くと、番号が 4 本返ってきました（2026-08-27 実測）。
- A（IPv4）
- 172.67.138.110
- A（IPv4）
- 104.21.78.238
- AAAA（IPv6）
- 2606:4700:3037::6815:4eee
- AAAA（IPv6）
- 2606:4700:3037::ac43:8a6e
4 本とも Cloudflare の窓口の番号です。行が Proxied（オレンジ雲）なので、電話帳には窓口の番号が載ります。書いた行は 1 行だけなのに番号が 4 本返るのは、Cloudflare がその 1 行を窓口の番号へ広げて返しているためです。
店名そのもの（apex の cloud-labos.com）には、受付につなぐ行を書いていません。dig +short cloud-labos.com A は何も返さず、ダッシュボードの Recommendations も「www の行が無い」「店名そのものの行が無い」「メールの行が無い」の 3 件を挙げていました。作者は cloud-labos.com を上位のサイト用に空けてあるので、www と apex の 2 件はわざとそのままにしています。
残るメールの 1 件だけは、その場で片付けました。ダッシュボードの DNS の Settings にある Email Security に「ドメインはメール送信に使用されていません」と出ていたので、「レコードを作成する」を押しています。できたのは次の 3 行です（2026-08-27 実測）。
- cloud-labos.com（TXT）
- v=spf1 -all
- _dmarc.cloud-labos.com（TXT）
- v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
- *._domainkey.cloud-labos.com（TXT）
- v=DKIM1; p=
3 行が言っているのは「この店名からメールは出しません。この店名を名乗る手紙が来たら、受け取らなくてよいです」ということです。公式は、こうした認証の行が無いと誰でもその店名を名乗って手紙を出せてしまうと書いています。差出人として認められる送り主を並べるのが SPF、手紙に署名を付けて中身が書き換えられていないかを確かめるのが DKIM、その確認に落ちた手紙をどう扱うかを受け取り側へ指示するのが DMARC です。この店名でメールを受け取ることもないので、MX の行は作られていません。
この 3 行は受付（Worker）とは無関係ですが、電話帳の行としては、この節の 2 で見た形そのままです。名前が Name、TXT が Type、引用符の中身が Content にあたります。
封印（DNSSEC）も、同じ日にダッシュボードの DNS の Settings から有効にしました。押した直後の画面には「DNSSEC is pending while we automatically add the DS record on your domain.」と出て、しばらく反映待ちになります。Cloudflare Registrar で登録した店名なので、元締めの台帳へ置く DS の行は Cloudflare が自動で置いてくれます。他社で登録した店名では、この行を自分で登録先の窓口へ届け出る手作業が要ります。
作者が押したのは 12:04、反映を確認できたのは 12:50 で、およそ 40 分で終わりました（2026-08-27）。反映後は元締めの登記記録が delegationSigned: true に変わり、dig +short cloud-labos.com DS でも同じ 1 行が引けます。
- keyTag
- 2371
- algorithm
- 13
- digestType
- 2
この後に 64 桁の digest が続く
つまずきやすいところ
Section titled “つまずきやすいところ”この節のまとめ
Section titled “この節のまとめ”- zone は店名 1 つぶんの電話帳で、nameserver はその預かり先です。
- DNS レコードは Type・Name・Content・Proxy status・TTL の 1 行です。
- 受付を通す行は proxied にし、封印は DNSSEC で無料です。
この節で出てきた言葉を、つながりの順に並べると次のようになります。
図のラベル: 電話帳 1 冊 zone / 預かり先 nameserver / 電話帳の 1 行 DNS record / Type・Name・Content Proxy status・TTL / 受付を通す proxied 本社直通 DNS-only / 封印 DNSSEC
次の節では、店名を受付（Worker）につなぐ看板を掛けます。
この節のチェック
© 2026 osdse