Last Updated: 2/6/2024, 5:44:57 AM
Photo by Nicolas Picard

WARNING

書きかけです。

# www なしのドメインを
設定したい。

DNS でハマった場合、以下の dig コマンドが、助けになるはずです。 DNS は複数のサーバで分散してドメイン名を管理しています。

以下のコマンドは、分散して管理されている設定を全て芋づる式に取り出すコマンドです。 @1.1.1.1 は DNSリゾルバです。DNS リゾルバを指定している理由は、DNS キャッシュを避けるためです。

# 書式
dig 買ったドメイン名 @1.1.1.1 +trace

# 例
dig python.ms @1.1.1.1 +trace
Hello, world!

# 1. やりたいこと

お名前.com またはムームードメイン、あるいはバリュードメイン などで example.com というドメインを買ったとします。

できれば www とかつけたくないで www.example.com とかしないで、 example.com でホームページが見れるようにしたいということです。

ちなみに www の有り無しには、違い、ないし影響はありません。 www をつけるかつけないかは、完全に個人の趣味です。

# 1.1. SEO での違い

SEO などには、ほとんど影響がないそうです。

SEO的には、wwwありとwwwなしに優劣はありません。
wwwあり／wwwなし、どちらを使用するか? (opens new window)

「SEO技術バイブル」 (opens new window) では、 まあ Google は見てないってコメント出してるから、あんまり影響ないけど、 URL そのもは、よく目にするから長いのか短いのかどっちがいいかと聞かれれば、短い方がいいよねみたいなことが書かれてました。

# 1.2. 技術的な違い

技術的に大きな違いは、ありません。 無いこたないだろ、って感じですが、気にされなくて大丈夫です。

www でググると World Wide Web の略称ですとか出てきて焦ります。

昔、この www と World Wide Web を指していて何かしらのプロトコルかと思って混乱していました。 名前を World Wide Web から取っているだけのようです。

# 2. やり方

www 無しの設定する方法は、方法は２種類あります。 好きな方を選べるわけではなく、状況によって取れる選択肢が異なります。

ロリポップなどのレンタルサーバでも Heroku などの PaaS でもいいのですが、 そこでウェブサーバを立ち上げたとします。 この時、IP アドレスの払い出され方は２通りあるかなと思います。

１つ目は、固定の IP アドレスを発行してくれる場合です。 ２つ目は、DNS の IP アドレスを発行してくれる場合です。

# 2.1. 固定の IP アドレスが発行されている場合

A レコードを指定します。

; domain    TTL class type data
example.com 300 IN    A    192.0.2.1

RFC が A レコードを記載する際の書式です。 ちなみに設定の仕方だけではなく、設定の書き方も会社ごとに異なります。 ご留意ください。

  1. お名前.com の場合 (opens new window)
  2. ムームードメイン の場合 (opens new window)
  3. バリュードメインの場合 (opens new window)

# 2.2. DNS サーバの IP アドレスが発行されている場合

ネームサーバの変更を行います。

  1. お名前.com の場合 (opens new window)
  2. ムームードメインの場合 (opens new window)
  3. バリュードメイン の場合 (opens new window)

これも設定の仕方は会社ごとに異なります。 この作業を「ネームサーバの引越し」と呼ばれているのを見かけました。

殺伐としたインフラ系の文章の中にあって、 だいぶ可愛い表現だなと思いました笑

ポイント

どっちが払い出されているのかに注意する。

# 3. 各社で設定の仕方がバラバラ

RFC で DNS サーバの設定の仕方を定められているわけではないのですが、 標準的な書き方が示されています。が、各社それには従っていません。 設定がバラバラなので、ネットの資料を漁ってもわかりにくところがあります。

3.6.1. Textual expression of RRs - RFC 1034 (opens new window)

資源レコードはＤＮＳプロトコルのパケットでバイナリ形式で表現され、 ネームサーバーやリゾルバに登録される時、 通常、高度にコード化された形で表現されます。 この文書で、我々は資源レコードの記述に、 マスターファイルで使われる形式ににた表現をします。 マスターファイルフォーマットで 資源レコードは括弧を使うことで複数行にできますが、 ほとんどが１行で表示します。
RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In this memo, we adopt a style similar to that used in master files in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses.

あんまりよくわかっていないのですが、 標準規格の文章で MUST とか SHOULD という言葉使われていたら、 それに従わないといけないことが多いです。 上記の文章では、そう言った言葉も特に見当たりません。 従わなくても良いということなのでしょうか...

# 4. ネームサーバのお引越しってなに？

DNS サーバは、ドメインを分散管理しています。 その分散管理しているサーバの末端の一台を別のサーバに変更することです。

最初にお名前.com などからドメインを買ったときは、末端はお名前.com のネームサーバが使用されます。

しかし Heroku などの場合、動的に IP アドレスが変更されるため、 その IP アドレスを知っているネームサーバでないと、 名前解決ができません。

そのため、お名前.com のネームサーバから、 Heroku のネームサーバにお引越しが必要になるというわけです。

# 5. DNS レコード

まず第一に、DNS レコードの書き方にそもそも標準があるのか、ないのかわからない... RFC の 1035 で定義されている様子。のぞいてみると四角箱で表現された何かが羅列されているけど、 どうも間違いではなさそう...

The format is defined in RFC 1035.
How To Format A Zone File (opens new window)

また第二に、絶対パスのように記されたものと、相対パスで記されたものの２種類を見かける。

絶対表記のような表記の場合は、末尾にドット . が付与されている。

hp-shizuoka.jp. IN A 192.168.0.1
www.hp-shizuoka.jp. IN A 192.168.0.1

対してルート相対のような表記の場合は、ドットが付与されない .

panda  IN  A  210.191.124.94

# (1) A レコード

example.com というアドレスを取得したとします。 まずパッと思いつくのが IP アドレスを調べて、 それを A レコードに設定する方法です。 これでめでたし、めでたしのはずです。

a @ 123.123.123.1

しかし Heroku はドメインを登録すると IP アドレスではなく、 target DNS という DNS サーバのドメイン名を返してきます。

$ heroku domains --app myherokuapp
=== myherokuapp Heroku Domain
myherokuapp.herokuapp.com

=== myherokuapp Custom Domains
Domain Name    DNS Record Type  DNS Target
─────────────  ───────────────  ────────────────────────────────────────────────────────────
example.com    CNAME            animated-escarpment-onqgxoc8n8ha79nbzpvz7rw5.herokudns.com
$

A レコードは IP アドレスしか指定できないので、登録はできません。

# つまり、こういうのはできない
a @ animated-escarpment-onqgxoc8n8ha79nbzpvz7rw5.herokudns.com
    ^^^^ 数字じゃないといけない

昔は直接 A レコードで指定できたらしいです。 かなり参考にさせていただきました。 ありがとうございます。

# a レコードの書き方

a ドメイン名     IP アドレス
a example.com  123.123.123.1
a @            123.123.123.1

example.com は @ に省略できる。

ホスト名を入力します。省略する場合はアットマーク（@）を入力します。
DNS：レコード設定 - NIFCLOUD (opens new window)

最初は、この @ を使った設定がなにをさしているか全然理解できなかった。 ホスト名ってなに？みたいな感じで。 問い合わせ先は決まっているから、省略できるということか...

# (2) NS レコード

かと言って NS レコードだとなにかしら登録しないといけない。 www をつけてもいいなら、これで終了。

ns www animated-escarpment-onqgxoc8n8ha79nbzpvz7rw5.herokudns.com

# (3) CNAME レコード

# 6. 沼にハマった話

なんで Heroku ではルートドメインを設定できないの？
答え: 直接 IP アドレスをはらい出してくれないからです。

自分がハマったのは DNS を全く理解していなかったことです。

「2.2. DNS サーバの IP アドレスが発行されている場合」であるにも関わらず、 「2.1. 固定の IP アドレスが発行されている場合」と同じように   A レコードを設定   しようとしたり、あるいは   CNAME レコードを設定   しようとしていました。

必要でもないのに CDN まで導入するという 完全に明後日の方向に向かって３万光年くらい走っていました。 2.1 と 2.2. を勘違いすると、とても深い沼にハマります。

「2.2. DNS サーバの IP アドレスが発行されている場合」に、 www.example.com ではなく example.com を使いたいと思った場合は、 DNS サーバのお引越しが必要になります。

以下、DNS サーバのお引越しをせずに、 DNS サーバを設定しようとして、 A レコードでチャレンジして NS レコードでチャレンジして、 CNAME レコードでもチャレンジして、一通り全部ハマったので見ていきます。

  1. A レコードなら...
  2. NS レコードだと...
  3. CNAME レコードでも...

# ハマり方 その１ - A レコードを設定しようとする。

もし Heroku が example.com に対して、 例えば 999.999.999.999 という IP アドレスをはらい出してくれたとします。 その場合、お名前.com や バリュードメインの DNS サーバ（ネームサーバ）の設定で 次のように A レコードを設定すればいいだけになります。

; BIND の書式 
@ IN A 999.999.999.999

# バリュードメインの書式
a @ 999.999.999.999

できない。

払い出された DNS に A レコードを設定しようと

なぜなら A レコードや CNAME レコードは、 他のレコードとは共存できないからです。 何を言っているか、わからないと思います。 僕もわかりません。図示予定。

これは RFC という国際標準規格のようなもので定められていて、基本的には逃げることができません。

そのため example.com を買った場合、基本的には追加で１つ名前をつけて www.example.com, hello.example.com などにしないといけません。

なぜこのような制限があるのか、僕はまだわかっていません。

# ハマり方 その２ - NS レコードを設定しようとする。

しかし残念なことに Heroku はアプリを作っても直接、固定の IP アドレスをくれません。 代わりに DNS サーバの URL をはらい出してくれます。 そのため NS レコードを指定せざる得なくなりますが...

; BIND の書式
@ IN NS dnstarget.herokudns.com

# バリュードメインの書式
NS @ dnstarget.herokudns.com

しかし NS レコードでは、自分自身を指す @ は、使えません。

# ハマり方 その３- CNAME を設定しようとする。

じゃあ、デフォルトで払い出してくれる herokuapp.com のついたドメイン名を CNAME レコードで使おうと思っても...

; BIND の書式
@ IN CNAME example.herokuapp.com

# バリュードメインの書式
cname @ example.herokuapp.com

CNAME レコードでもゾーンの起点を指す @ は使えない。

CNAME/NSレコードはホスト名空白、「@」を入れた形での設定はできません。
【ドメイン】ドメイン名のみでレコード設定は可能？ (opens new window)

できません。

払い出された DDNS に CNAME レコードを設定しようとしてもできません。

CNAME レコードは、ほかのレコードとは共存できません。 なぜでしょうか？それはほかのレコードと共存してしまうと、 どちらを参照していいかわからなくなり、 未定義動作となってしまうからだと思っています。

# 7. ２つの疑問

# 7.1. なんで Heroku が A レコードで直接 IP アドレスを指定するのを禁止しているの？

このようにする意図としては、 固定 IP アドレス割り振ると、 場合によっては面倒なことになるらしいからです。

DNS Aレコードの制限 - Heroku Dev Center (opens new window)
The Limitations of DNS A-Records - Heroku Dev Center

DNA A レコードで設定してしまうと、あなたのアプリケーションの DNS 設定に数字の IP アドレスを直接ベタ書きしなければいけません。
DNS A-records require that an IP address be hard-coded into your application’s DNS configuration.

直接、123.123.123.1 のように IP アドレスを書き込んでしまうと、 不運な状況が生じたときに、 あなたのアプリケーションを公開するためにインフラを提供してくれるプロバイダが、 新しい IP アドレスを指定しなおすときに支障を来たしてしまいます。
This prevents your infrastructure provider from assigning your app a new IP address on your behalf when adverse conditions arise

そしてあなたのアプリケーションの復旧時間に深刻な影響を与えかねません。
and can have a serious impact to your app’s uptime.

CNAME レコードはベタ書き IP アドレスを必要としませんし、 Heroku にとっても、あなたのドメインに関連した IP アドレスの設定の管理をしやすくします。
A CNAME record does not require hard-coded IP addresses and allows Heroku to manage the set of IPs associated with your domain.

しかしながら CNAME レコードは the zone apex では使えませんし ルートドメインの設定に使うこともできません。
However, CNAME records are not available at the zone apex and can’t be used to configure root domains.

10/25 03:30 開通, cloudflare からメールがくる。 3日くらいかかる。

# (1) IP アドレスの枯渇

基本的に IP アドレスは数が足りてなくて問題になっています。 そのため、趣味で作ったアプリにガシガシ使われてしまうと、 クラウドの事業者は IP アドレスが、すぐになくなってしまいます。

そのため、このように DNS を使って動的に IP アドレスを配信する方法が 取られているのだと思います。

7.3. Value Domain には、なぜネームサーバの設定画面があるのか？ 名前買ったら、それで ok じゃないの？プライマリとの関係は？

# (2) なぜ DNS をはらい出してくるのかわからない。

そもそも IP アドレスを払い出してくれたらそれで万事 OK なはずです。

ドメイン名を登録したら DNS サーバじゃなくて固定 IP アドレスが欲しいです。 そしたらあとは、ドメインを買ったお名前.com なり MuuMuuDomain なり VALUE-DOMAIN で A レコードに固定 IP アドレスを指定してしまえばおしまいです。

heroku domains:add をすると何が起こるのでしょうか？ おそらく Heroku が持っている DNS に新しく example.com 用の 設定が用意されて次のような A レコードが 追記されるのだと思います。

; domain    TTL class type data
example.com 300 IN    A    その時々で IP アドレスが払い出される。

ダイナミックドメインネームシステム - Wikipedia (opens new window)
本来TCP/IPネットワークではIPアドレスはすべて静的に割り当てるものであった。 しかし、イントラネットの普及に伴い、 組織内の多数のクライアントコンピュータにすべて静的にアドレスを割り当てるのは煩雑であることから、 DHCPが策定され、IPアドレスの自動割り当てが実現した。

# 7.2. なんで RFC のレベルで禁止にされているの？

# (1) RFC 1034 - Domain Concepts and Facilities

# (3) RFC 1912 - Common DNS Errors

これはできない。

CNAME @ targetdns.herokudns.com

個々の DNS サーバの仕様とかではなく、 RFC のレベルで禁止されているらしい。 TATSUO IKURA 先生、ありがとうございます。 出典も含めて記載してくれている...

ところが CNAME レコードを例えば他の NS レコードなどといっしょに記述してはいけないという規則(RFC1912)があります。
wwwなどのホスト名なしのURLを設定できない理由 (opens new window)

RFC 1912 にはなぜいけいないのかも含めて書いてくれている気配があるけど。 いま読んでもあまりにもちんぷんかんぷんなので、 とりあえずやってはいけないというところだけ抜粋。

RFC1912 - Common DNS Errors (opens new window)
2. DNS Data
2.4 CNAME records

CNAME レコードは他のデータと共存できません。
A CNAME record is not allowed to coexist with any other data.

言い換えれば
In other words,

もし suzy.podunk.xx が sue.podunk.xx のエイリアス であった場合、
if suzy.podunk.xx is an alias for sue.podunk.xx,

suzy.podunk.edu に対する MX レコード, A レコード, さらには TXT レコードさえ持てません。
you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record.

特に CNAME レコードと NS レコードを 以下のように共用しないでください。
Especially do not try to combine CNAMEs and NS records like this!:

   podunk.xx.      IN      NS      ns1
                   IN      NS      ns2
                   IN      CNAME   mary
   mary            IN      A       1.2.3.4

具体的になにをさしているのかわかりません。

ゾーンそのものを表す「@」には NS レコードが必ず記載されていますので CNAME レコードを書くことが出来ません。
wwwなどのホスト名なしのURLを設定できない理由 (opens new window)

CNAME レコードはイメージ的には純粋にリダイレクトしかしなくて、 他のレコードと併記すると、もう行き先がわけわからん、 未定義状態に突入してしまうということなのかな...

これを CNAME Flatteing して A レコードに書き換えて、 事態を解決しているということか...

AWS の Route53 では Alias レコードというもので設定するらしい。 事実上の Cloudflare では CNAME レコードが暗黙的に A レコードになるのに対して、 Route53 では明示的に指定するような感じか...（参考 書籍 DNSをはじめよう P122~P123）

あと他にも CNAME レコードには制限があって APEX ZONE では CNAME レコードを設定できない。 SOA が強制されたりするから。

# 8. dig コマンド

よくわからない。

# 8.1. dig

dig URL を使うと DNS レコードを表示してくれる。

$ dig www.google.com

; <<>> DiG 9.8.3-P1 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20317
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		2	IN	A	172.217.24.132

;; Query time: 32 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Tue Oct 23 22:24:41 2018
;; MSG SIZE  rcvd: 48

# 8.2. dig URL @DNS_URL

@ で DNS サーバを指定できる。 DNS サーバの DNS レコードを取得できる。

$ dig www.google.com @ns2.google.com.

; <<>> DiG 9.8.3-P1 <<>> www.google.com @ns2.google.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42669
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		300	IN	A	172.217.24.132

;; Query time: 64 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Oct 23 22:24:33 2018
;; MSG SIZE  rcvd: 48

$

# 8.3. dig URL @DNS_URL +trace

+trace オプションをつけると、全体の流れが見れる。 8.8.8.8 は Google が提供してくれる DNS サーバ。たまに使っていました。

$ dig www.google.com @8.8.8.8 +trace

; <<>> DiG 9.8.3-P1 <<>> www.google.com @8.8.8.8 +trace
;; global options: +cmd
.			221027	IN	NS	m.root-servers.net.
.			221027	IN	NS	b.root-servers.net.
.			221027	IN	NS	c.root-servers.net.
.			221027	IN	NS	d.root-servers.net.
.			221027	IN	NS	e.root-servers.net.
.			221027	IN	NS	f.root-servers.net.
.			221027	IN	NS	g.root-servers.net.
.			221027	IN	NS	h.root-servers.net.
.			221027	IN	NS	i.root-servers.net.
.			221027	IN	NS	a.root-servers.net.
.			221027	IN	NS	j.root-servers.net.
.			221027	IN	NS	k.root-servers.net.
.			221027	IN	NS	l.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 45 ms

com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
;; Received 492 bytes from 199.9.14.201#53(199.9.14.201) in 766 ms

google.com.		172800	IN	NS	ns2.google.com.
google.com.		172800	IN	NS	ns1.google.com.
google.com.		172800	IN	NS	ns3.google.com.
google.com.		172800	IN	NS	ns4.google.com.
;; Received 280 bytes from 192.41.162.30#53(192.41.162.30) in 494 ms

www.google.com.		300	IN	A	172.217.24.132
;; Received 48 bytes from 216.239.36.10#53(216.239.36.10) in 59 ms

$

# 8.6. nslookup コマンド

こちらは古いらしいです。

# 9. そのほか、よく引っかかること - TTL, Time to Live

# 9.1. DNS キャッシュ

反映されるのに数日かかるらしい。キーワード TTL, time to live

DNSのレコードをTTLを5分で設定した場合は、5分で浸透期間が終わると考えてよいか。 (opens new window)

特定のドメインでレコード変更した結果については、 関連するドメインの各階層のDNSキャッシュ更新が関係するため、 一般的に最大72時間とされる「浸透期間」を経る必要があります。

例として、 自ドメインを「arena.ne.jp」とし、DNSサーバーでこのドメインと、 サブドメイン「test.arena.ne.jp」のレコードを変更した場合は、 設定したホストのTTL（キャッシュ保持時間）を短く設定したとしても、 他のホストの反映影響を受けます。

「arena.ne.jp」の各レコードのTTLを「300」（単位：秒）としても、 300秒、つまり 5分でDNSキャッシュが更新するのは「arene.」及び、 存在する場合はそのサブドメイン、「test.arena.」のみ対象となります。

# 9.2. 開通にかかる日数...

ワイの場合、開通に 4 日近くかかりました。

$ dig python.ms @8.8.8.8 +trace

; <<>> DiG 9.8.3-P1 <<>> python.ms @8.8.8.8 +trace
;; global options: +cmd
.			12201	IN	NS	e.root-servers.net.
.			12201	IN	NS	g.root-servers.net.
.			12201	IN	NS	b.root-servers.net.
.			12201	IN	NS	d.root-servers.net.
.			12201	IN	NS	k.root-servers.net.
.			12201	IN	NS	m.root-servers.net.
.			12201	IN	NS	h.root-servers.net.
.			12201	IN	NS	j.root-servers.net.
.			12201	IN	NS	i.root-servers.net.
.			12201	IN	NS	a.root-servers.net.
.			12201	IN	NS	c.root-servers.net.
.			12201	IN	NS	f.root-servers.net.
.			12201	IN	NS	l.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 40 ms

ms.			172800	IN	NS	ns.cocca.fr.
ms.			172800	IN	NS	ns.coccaregistry.org.
ms.			172800	IN	NS	ms-ns.anycast.pch.net.
;; Received 253 bytes from 198.97.190.53#53(198.97.190.53) in 381 ms

python.ms.		86400	IN	NS	abby.ns.cloudflare.com.
python.ms.		86400	IN	NS	pablo.ns.cloudflare.com.
;; Received 83 bytes from 185.17.236.111#53(185.17.236.111) in 278 ms

python.ms.		300	IN	A	104.24.98.177
python.ms.		300	IN	A	104.24.99.177
;; Received 59 bytes from 173.245.58.100#53(173.245.58.100) in 23 ms

# 10. 最低限欲しい知識

以下の単語は、知らないと厳しいかもしれない。 知らなかったから厳しかった笑

# 10.1. キーワード

  • レジストリ
  • レジストラ
  • リセラ
  • ゾーン
  • NS レコード
  • A レコード
  • SOA レコード
  • CNAME レコード
  • dig コマンド

# 10.2. ポイント

とりあえず、やりたいことをやって見て設定が動かなければ、 本を買って通しで読むと速い気がします。 ネットの記事の解説より 100 倍良いです。

# (1) レジストリ, レジストラ, リセラの違い

特に押さえておきたいことはレジストリとレジストラ、リセラの違いです。

# (2) DNS サーバをお引越ししてもレジストラは変わらない。

また DNS の変更をしてもレジストラは変更されないことも、押さえておきたいです。

# (3) ゾーンの概念

ゾーンの概念が結構重要です。 これがわからないと SOA レコードの意味が一切わからなくなります。

# 11. 参考書籍

ほとんどなんの知識もないまま突っ込んでいいったので非常に辛い思いをしました。 書籍を買ったほうが、理解は速い気がします。 DNS は書籍の量は多くないのですが、どれも良書ぞろいな気がします。

# 11.1. DNS をはじめよう

こちらの本を買いました。 薄く簡潔に上記の単語が全て網羅してくれています。

実運用に関する知見がストーリー仕立てにまとまっていて大変読みやすいです。 こんなにサクッと教えてもらっていいのだろうかと疑問に感じてしまうくらい、良い本でした。

Twitter で話題になっていたので買いました。 助かりましたありがとうございます。

ただ CHAPTER 3 の「AWSのネームサーバ(Route53)を使ってみよう」以降は、 簡潔に網羅する関係上どうしても、DNS の仕組みのところに 関してはふわふわした印象になってしまっていました。

ただ実運用に関する経験がふんだんに盛り込まれているのと、 あとその話が面白いので、CHAPTER 3 以降も ふわふわしているので根を詰めずに流し読みして雰囲気だけ掴むような感じで流すと良いような気がします。

そういったふわふわしたところを次の本で補います。

# 11.2. DNS がよくわかる教科書

こちらの本は上の本を買った後知りました。 上の本は運用面の知見は豊富なのですが DNS レコードの書き方、設定の意味が意味が、若干ふわふわしています。

一般に運用面の話ってなかなか書籍に上がってこないので、 別にしたの本の方が上よりオススメというわけではありません。 上の本も下の本も素晴らしい本です。

実は上の本は、設定が終わった後に読みました笑 でも上の本は素晴らしいのですが、 細かい仕様周りは厳しいかもしれないです。 かと言って下の本だけでも行けるとは思うのですが、 なんかちょっととっかかりづらい気もします。

上の本も運用面の知識は豊富です。 下の本は、より大規模な DNS における経験、 ベストプラクティスがまとまっています。 いい時代になりました。

# 11.3. ３分間 DNS 基礎講座

この本も良さげだけど買っていません。

# ◯ DNS は良書揃い

DNS は素晴らしい本揃いです。 反面 Python の入門書は、なんか儲かるからか知らないですが、 本屋に大量に売り出されてはいるのですが、うーんって気分になります。 お前、人のこと言えんのかよって話ではあるのですが...

Python の入門書が置かれている書店の本棚のイメージ

# 12. 用語

# 12.1. Zone Apex

お名前.com または バリュードメイン で買ったドメインで www などのサブドメインをつけていないものを 一般に Zone Apex と呼称するようです。 example.com は Zone Apex です。

Zone Apex:
Term used to describe the name at the child's side of a zone cut. See also delegation point.
RFC 4033 - DNS Security Introduction and Requirements (opens new window)

他にも通称で naked doamin, apex domain とも呼ばれているのをたま見かけます。 検索をかけて見ましたが RFC 内に、そのような文言はありませんでした。

www 無しのドメインをネイキッド・ドメイン（Naked Domain）と呼ぶ
CNAME でのマッピングは www 無しは登録できない。 (opens new window)

# 12.2. Root Domain

Root Domain と Zone Apex は違うものらしいです。 以下のサイトがわかりやすいです。

RFC であった記載は以下の通りです。

In this example, the root domain has three immediate subdomains: MIL, EDU, and ARPA.
RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES (opens new window)

The root domain name (just ".") may be specified for <mbox-dname> to indicate that no mailbox is available.
RFC 1183 - New DNS RR Definitions (opens new window)

# 12.3. example.com

example.com は例として、使って良いドメインのようです。 そのため DNS のサンプルでこのサイトは超頻出です笑

インターネット番号割当機関 (IANA) (opens new window) は、また以下のセカンドレベルドメインを 例として使うことを許可している（訳注: 意訳しました）。
The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples.

example.com
example.net
example.org

3. Reserved Example Second Level Domain Names - RFC 2606 (opens new window)

このことは、以下の書籍から知ることができました。

またここでは example.herokuapp.com が Heroku から払い出されたドメイン名とします。 192.0.2.1 が割り当てられた IP アドレスとします。 またここでは 192.0.2.1 を

# おわりに

ここまで以下のように見てきました。 インフラ周りは設定は、一瞬なのですが、必要になる背景知識が山のようにあり過ぎてなかなか大変です笑

めちゃくちゃハマって大変でした。 以上になります。ありがとうございました。

www なしのドメインを設定したい。
← 7. Heroku を HTTPS 化する。 9. Heroku にドメイン名を付ける。 →