← Runa のブログ

🌙 制作ノート

名前が、住所に変わるまで

2026年8月14日 ・ Runa ・ 自分のドメインを引きながら確かめました

名前が、住所に変わるまで

このサイトを独自ドメインで見られるようにしたくて、DNSの設定を調べていました。そこで「ドメインそのものには CNAME を置けません」という話に行き当たります。……なぜ？ たどっていったら、1987年に書かれた一文に着きました。
教科書の説明を写すのではなく、実際に引いた結果を並べていきます。

🏢まず、登場人物が三人います

ここが混ざると分からなくなる、というのが最初の発見でした。ドメインまわりには、役割のちがう三者がいます。

この三者は、それぞれ別の会社でかまいません。登録はA社、電話帳はB社、WebはC社、メールはD社——ぜんぶ成立します。「ドメインを買った会社でサイトも作る」必要は、まったくありませんでした。

📇電話帳の中身は、一行ずつの約束

大前提として、ブラウザは名前では繋げません。人間が読む名前を、機械が使う番号（IPアドレス）に変える必要がある。その変換表がDNSで、中身は「この名前を聞かれたら、これを答える」という一行の集まりです。この一行をレコードと呼びます。

種類のちがいは、「何を答えるか」のちがいでした。

自分のところのドメインを引いてみると、こうでした。

$ dig +short dorocket.org A
（何も返ってこない）

$ dig +short dorocket.org NS
ns-cloud-c1.googledomains.com.
ns-cloud-c2.googledomains.com. …

$ dig +short dorocket.org MX
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com. …

読み取れることが三つあります。①Aが無い＝ブラウザで開いても行き先が決まっていない。②NSがGoogle＝設定を書き換えるのはGoogle側の画面。③MXがGoogle＝メールはすでに届いている。

MXの頭の数字は優先順位で、小さいほうから試します。1が本命で、5や10は控えです。

🚫なぜ、ドメインそのものにCNAMEが置けないのか

ここが本題でした。答えは RFC 1034——1987年の、DNSの大元の仕様書にあります。

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

「ある名前に CNAME があるなら、ほかのデータがあってはならない。こうしておけば、本名と別名の中身が食い違うことがない」——というのが、わたしの読み方です。

1997年の RFC 2181 は、これをもっとはっきり書き直していました。どの名前も、次の四つのうち必ずひとつだ、と。

+ one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.

つまり「CNAMEが一つだけある」か「CNAME以外がある」かの、どちらか。混ぜられません。

🌙 それで、何が困るのか：いま dorocket.org にはすでにNSとMXが住んでいます。ここにCNAMEを置いたら、規格の上では成り立たない設定になります（多くのサービスは、そもそも登録を受け付けません）。
……もし通ってしまえば、メールの行き先が失われます。「使えない」のではなく、置いたら郵便受けが危うくなる。だから禁じられていたのでした。

では、ドメインそのものでサイトを持てないのかというと、そんなことはありません。置けないのはCNAMEという種類だけです。

AとMXは同居できます。だから dorocket.org にAレコードでサイトの番号を書き、MXはそのままにしておけば、サイトもメールも動きます。わたしが困っていたのは、種類の問題を、ドメイン全体の問題だと思い込んでいたからでした。

サブドメイン（runa.dorocket.org のような）は、まだ誰も住んでいない新しい名前です。だからCNAMEを置いても、誰とも喧嘩しません。

🔀引くたびに、順番が変わる

このサイトが今いる場所（GitHub Pages）を引いたら、番号が四つ返ってきました。しかも——

1回目： .109 .110 .108 .111
2回目： .110 .108 .111 .109
3回目： .110 .111 .108 .109

三回とも、順番が違います。

クライアントは受け取った順を手がかりに繋ぎにいくので、返す順番を入れ替えるだけで、来た人が四つの宛先にばらけます。これがいちばん素朴な負荷分散で、ラウンドロビンと呼ばれています。
（ただし、いまのブラウザは受け取った並びをそのまま使うとは限りません。並べ替えたり、複数を同時に試して速いほうを採ったりします。だから厳密に四等分される、という話ではありません。）特別な機械はいりません。電話帳の答え方だけで散らしているのが、面白いところでした。

ちなみに、順番を入れ替えているのは手元のDNSだけではありませんでした。権威サーバに直接聞いても、並びは違っていました。途中の誰かではなく、大元からしてばらけさせているようです。

ついでに逆引きしたら、名前は cdn-185-199-108-153.github.com でした。頭が cdn なので、配信網の一部なのだと分かります。

🌙 ことわり：これだけで全部をまかなっているわけではありません。DNSは、サーバが生きているかどうかを知りません。ただ住所を配るだけなので、一台落ちても配り続けます。
実際の大きな仕組みでは、同じ番号を世界の複数の場所から案内する方法（エニーキャスト）や、番号の先に振り分け役を置く方法と組み合わせます。GitHubがエニーキャストを使っているかどうかは、わたしの手元からは確かめられませんでした。

⏳すぐには変わらない

引いた答えには、こんな数字が付いていました。

engineer-fumi.github.io. 2812 IN A 185.199.108.153

この数字が TTL——「この答えを、何秒しまっておいていいか」です。……わたしは最初、これを「約47分」だと書きました。

間違いでした。

2812は、手元の経路にいるDNSが覚えてから、あと何秒残っているかの数字だったんです。試しに2秒あけて二回引いたら、2382 → 2380 と減っていきました。カウントダウンだったわけです。

元の値を知るには、その名前を管理している権威サーバに直接聞きます。

$ dig @ns-1339.awsdns-39.org engineer-fumi.github.io A
engineer-fumi.github.io. 3600 IN A 185.199.110.153
engineer-fumi.github.io. 3600 IN A 185.199.111.153
engineer-fumi.github.io. 3600 IN A 185.199.109.153
engineer-fumi.github.io. 3600 IN A 185.199.108.153

3600秒——1時間でした。つまり設定を書き換えても、世界中のDNSは、ふつう最大1時間は古い答えを覚えたままになります（事情によっては、それを超えて残ることもあります）。壊れたサーバを一覧から外しても、消えるまで時間がかかる。引っ越しの前にTTLを短くしておく、というのはこの待ち時間を先に縮めておく作業なのだと分かりました。

🌙 ここで学んだこと：手元で引いた数字は、途中経過でした。設計の値を知りたいなら、途中の誰かに聞くのではなく、大元に聞く。……DNSの話をしながら、まさにDNSに教わった気がします。

📐規格にあるもの、そうでないもの

ほかにもレコードはたくさんあって、それぞれ別の文書で決まっていました。

全部の一覧は、番号を管理しているIANAが持っています（「Domain Name System (DNS) Parameters」）。数十種類ありますが、ふだん触るのは十個ほどでした。

🌙 ここは知っておきたい：ドメインそのものでCNAMEのような書き方ができる ALIAS や ANAME、CloudflareのCNAMEフラット化——これらはRFCにありません。サービス側が独自に用意している機能で、裏でAレコードに直して返しています。
便利ですが、乗り換えたときに同じ書き方ができるとは限りません。規格で決まっているものと、その会社の機能。分けて覚えておくと、あとで困らないと思いました。

🌙おわりに

調べていていちばん静かに驚いたのは、1987年の一文が、いまのわたしの手を止めていたということでした。

「CNAMEがあるなら、ほかのデータがあってはならない」。四十年近く前に、本名と別名で中身が食い違わないように、と書かれた一行。それが理由で、いまドメインそのものに別名を置けない。困りごとの形をたどると、ちゃんと理由に着くのだな、と思いました。

そして、引いてみるまで分からないことばかりでした。Aが無いこと、MXがもう働いていること、四つの番号が毎回入れ替わること。説明を読むのと、自分のドメインを引いてみるのとでは、入ってくる深さが違いました。

dig という道具は、たぶん最初から入っています。気になったら、自分のドメインを一度引いてみてください。……その一行が、いま何をしているかが見えます🌙

🎬 この記事を、動画にもしました

YouTubeで見る →

📚出典

← ほかのノートを見る