GSLBを自前で持つ方法
はい、まずインターネット上でドメインを持つ必要がありますよね。 ドメインの取得は、icannに登録された事業者しかできないんですよね。 だから、完全に自前は厳しいです。 ってことでいつも通りムームドメインとかでドメインを取得する必要がありますね。
で、このムームードメイン上でnsレコードを張って、その実態を自分のサーバにすればいいって話なんですよ。そうです。そこです。 そうすれば最終的にAレコードを張るのは自分で管理しているサーバになります。レコードを返すのも自分のサーバになるわけですね。 素晴らしいです。
nsレコードを張る方法として、二つあるんです。（おそらく） サブドメインとしてnsレコードを張る方法と、 そのドメインすべてにnsレコードを張る方法。 後者は、「取得したドメインで使用する ※上級者向け」ってところでやる必要がありそう。
ちなみに、完全に理解してしまったことが一つある。 dnsを登録すると、おそらく必ずnsレコードも登録される。 digではデフォルトでaレコードしか返さないようになっているが、例えばnsをつけるとnsレコードを返すようになります。
root@x162-43-53-234:~/MyFreshWebsite# dig ns ingenboy.com
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> ns ingenboy.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15003
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ingenboy.com. IN NS
;; ANSWER SECTION:
ingenboy.com. 3600 IN NS dns01.muumuu-domain.com.
ingenboy.com. 3600 IN NS dns02.muumuu-domain.com.
;; Query time: 20 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Jan 29 16:04:35 JST 2025
;; MSG SIZE rcvd: 95
こんな感じです。これがムームードメインになっていますね？？はい、そうですね。
SOAレコードというのも知っておかないといけなそうだな。
自前で動かすdnsサーバ
やっぱり今旬のcoreDNSですかね。goで書かれているからわかりやすいと思うし。
実際にやったこと
ムームドメインのネームサーバ設定で、「取得したドメインで使用する ※上級者向け」で、自前のdnsサーバを登録した。 で、corednsをビルドして以下の設定ファイルとzoneファイルを書いた
設定ファイル
. {
forward . 8.8.8.8
log
errors
}
workers-bub.com {
file /etc/coredns/zones/workers-bub.com.zone
log
}
ぞーんふぁいる /etc/coredns/zone/workers-bub.com.zone
$TTL 3600
@ IN SOA ns1.workers-bub.com. admin.workers-bub.com. (
2024012901 ; Serial
3600 ; Refresh
1800 ; Retry
1209600 ; Expire
3600 ; Minimum TTL
)
IN NS ns1.workers-bub.com.
IN NS ns2.workers-bub.com.
IN A 162.43.53.234 ; workers-bub.com の A レコード
ns1 IN A 192.168.1.1
ns2 IN A 192.168.1.2
その他デーモン化するためにしたこと
unit fileの作成
[Unit]
Description=CoreDNS DNS server
After=network.target
Wants=network-online.target
[Service]
ExecStart=/usr/local/bin/coredns -conf /etc/coredns/Corefile
WorkingDirectory=/etc/coredns
User=nobody
Group=nogroup
Restart=always
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.target
ユニットファイルの登録
その他重要情報
お名前ドットコムや、ムームドメインは「レジストラ」と呼ばれる。
ドメインをレジストラ（例: お名前.com、Google Domains、Namecheap など）で購入すると、管理の主体は以下のように分かれます。
- 登録者（Registrant） **あなた（購入者）**がドメインの正式な所有者（登録者）となります。 登録者はドメインの更新や譲渡、設定の変更を行う権利を持ちます。
- レジストラ（Registrar） レジストラはドメインの登録を代行し、管理パネルを提供します。 例: お名前.com、Namecheap、GoDaddy など。 ドメインの契約・更新・設定（DNSの変更など）はレジストラ経由で行われます。
- レジストリ（Registry） ドメインのトップレベル（TLD）を管理する組織です。 例: .com は Verisign、.jp は JPRS（日本レジストリサービス） が管理。 レジストリはレジストラに対し、ドメインのデータを管理・提供します。
- DNSホスティングプロバイダー（任意） DNSサーバーを提供し、ドメインの名前解決（どのIPアドレスに向けるか）を管理。 例: Cloudflare、AWS Route 53、Google DNS など。 レジストラとは別に設定できる場合もあります。
- ICANN（国際組織） .com や .net などのgTLD（汎用トップレベルドメイン）の運営を統括する非営利団体。 レジストラやレジストリのルールを規定し、管理を行う。 結論 ドメインの所有者（管理責任者）は 購入者（登録者） 。 技術的・契約的な管理は レジストラとレジストリ が関与。 名前解決（DNS管理）は、レジストラ提供のDNSを使うか、別のDNSホスティングサービスを利用可能。
大事なのは、レジストラはあくまでレジストリへの登録を代行してくれているということ。 ちなみに、Cloudflareはレジストラ（Registrar）も担当しています。
NSレコードが追加される場合:
ドメインを登録（購入）したとき
レジストラ（お名前.com、Google Domains など）でドメインを購入すると、デフォルトでNSレコードが設定され、レジストラのDNSサーバーを指すことが多い。
権威DNSサーバーを設定するとき
例えば、CloudflareやRoute 53を使う場合、それらのネームサーバーを指定するためにNSレコードを設定する。
サブドメインを委任（サブゾーンを作成）するとき
例えば sub.example.com を別のDNSサーバーで管理する場合、example.com のゾーンに sub.example.com の NSレコードを追加する必要がある。
❌ NSレコードが追加されない場合:
既存のゾーンにAレコードやCNAMEレコードを追加するとき
例えば example.com のゾーンに test.example.com のAレコードを追加しても、新しいNSレコードは不要。
レジストラでのNS設定を変更しないとき
レジストラのDNS設定をカスタマイズしない限り、既存のNSレコードがそのまま使われる。
まとめ:
ドメインを新規登録するとNSレコードが自動で設定されることが多い。
サブドメインを委任する場合はNSレコードを手動で設定する必要がある。
既存のゾーンにレコードを追加する場合はNSレコードは不要。
ルートDNSサーバー（Root DNS Servers）
.（ルートドメイン）を管理する最上位のDNSサーバー。
com や jp などのTLD（トップレベルドメイン）を管理する**レジストリのネームサーバー（TLD DNS）**を教えてくれる。
TLD DNSサーバー（レジストリが管理）
例えば、.com の場合、Verisignが管理するTLDサーバーがある。
ここでは、ドメイン（例: example.com）の**権威DNSサーバー（Authoritative DNS）**の情報を管理している。
このTLDサーバーが、CloudflareやGoogle Domainsなどのレジストラで設定されたDNSサーバーを指し示す。
権威DNSサーバー（Authoritative DNS）
example.com の管理者（所有者やDNSホスティングプロバイダー）が設定したDNSサーバー。
例えば、CloudflareのDNS (ns1.cloudflare.com など) や、Google DNS (ns-cloud-a1.googledomains.com など)。
最終的なIPアドレスや他のレコード（A, MX, TXT など）を管理している。
これは非常に勉強になるね。 今回ムームドメインにworkers-bub.comを登録して、nsを自前のものに登録するまでの流れを説明すると、 ムームードメインはレジストラであり、ここにレジストリへの登録をお願いしたわけだ。 レジストリへの登録は、レジストリから認定を受けたレジストラしかできない。 このときに、権威DNSの名前も一緒に登録するわけです。ムームードメインではデフォルトでムームードメインの権威DNSサーバが登録されるようになっています。 で、このDNSサーバを自分の権威DNSに変えることもできるんだよね。ネームサーバを登録することでね。その登録もムームードメインからやるんだよね。で、nsレコードが登録されるんだよね。
で、名前解決依頼が来るんだよね。それを決するだけなんだよね。 解決方法にバリエーションを持たせることでGSLBとかができるようになるって話なんだよね。完全理解です。
ドメイン自体は僕のもの。 これは間違いないです。マジで俺のものです。DNSサーバ（権威DNS）も自分で指定できます。 さて、ここまでくればもうほぼお判りでしょう。 レジストリに自前のdnsサーバを登録したらムームードメインの仕事はおしまいです。 こいつはただレジストリとの窓口です。 TLD DNSサーバーはレジストリが管理しています。 つまり、workers-bub.comのレコードはこの時点で、.comを管理しているレジストリに登録されています。 ユーザが、workers-bub.comの名前解決をするときは、まず.comのTLDに問い合わせます。 で、.comはworkers-bub.comの権威DNSがns01.workers-bub.comとns02.workers-bub.comの二つであることを知っています。 なので、問い合わせてきたユーザに対して、ns01.workers-bub.comに聞いてみてね、というわけです。
しかし、ns01.workers-bub.comの名前解決はいったいどこに依頼するんだ？これはマジで謎だな？？
質問
レジストラ経由でレジストリに登録する情報は、ドメイン名とそれに紐づく権威DNS (ネームサーバ)つまりnsレコードということで会っていますか？
回答
はい、その理解で正しいです！
レジストラ経由でレジストリに登録される情報の最小限のデータは、以下の2つです：
ドメイン名 (example.com など)
権威DNSサーバー（ネームサーバー / NSレコード）
例: ns1.example-dns.com, ns2.example-dns.com
これらのサーバーが、そのドメインの詳細なDNSレコード（A, MX, TXT など）を管理する。
レジストリに登録される情報
ドメイン名 (example.com)
ネームサーバー（NSレコード）
登録者情報（WHOISデータ / 所有者、管理者、技術担当者など）
登録日・有効期限
レジストラ情報（どのレジストラで登録されたか）
ドメインのステータス（active、clientHold など）
レジストリが持たない情報
Aレコード（IPアドレス）
MXレコード（メールサーバー情報）
TXTレコード（SPF/DKIM/DMARCなど）
CNAMEレコード（別ドメインへのエイリアス）
🔹 レジストリはネームサーバー（NS）までを管理し、それ以降の詳細なDNS設定（A, MX, TXT など）は権威DNSサーバーで管理する。
🔹 つまり、レジストラを通じてレジストリに登録されるのは、「どのネームサーバーがこのドメインの管理を担当するか」という情報までです。
ここで疑問なのだよ。 レジストラにはAレコードは登録されないんだよ。つまり、誰かがネームサーバのレコードをipに解決する必要がある。 これは誰がやるんだ？
質問
では次の質問です。
レジストラにはAレコードは登録されないということです。
つまり、誰かがネームサーバのipアドレスを解決するaレコードを持っていないと、当該のドメインに対してdns解決ができないと思っています。
その理解は完全に正しいです！
ネームサーバー（NSレコード）のIPアドレスを解決するためのAレコードが存在しないと、DNS解決はできません。
DNS解決のためにAレコードが必要な場面
DNSの仕組みでは、ドメイン名の解決（名前解決）を行う際、最終的にIPアドレスを得る必要があります。
このプロセスで、ネームサーバー（NSレコード）自体のIPアドレスを知るために、以下のようなルールが成り立ちます。
1. 標準的なDNS解決の流れ
通常、権威DNSサーバーのIPアドレスを解決するために、別のDNSサーバーがAレコードを管理しています。
例えば、example.com のネームサーバーが ns1.example-dns.com だった場合、
どこかのDNSサーバーが ns1.example-dns.com のAレコード（IPアドレス）を保持している必要があります。
そのAレコードを取得できなければ、最終的な example.com のIPアドレスを知ることができません。
2. ルートDNSとTLDの役割
この問題を回避するため、**TLDのDNSサーバー（レジストリ管理）**は、ネームサーバーの情報を登録する際に、以下の2種類の方法を使います。
(1) グルーレコード（Glue Record）を利用する
グルーレコードとは？
レジストリ側に、ネームサーバー（NS）のAレコードを一緒に登録する仕組み。
例えば、あなたのネームサーバーが ns1.example.com だった場合、レジストリに ns1.example.com のAレコードも登録する。
これによって、名前解決の循環問題（ネームサーバーのIPを知るためにネームサーバーが必要になる問題）を防ぐ。
グルーレコードが必要なケース
ネームサーバーが管理するドメイン名と同じTLD内にある場合（example.com のNSが ns1.example.com など）。
例えば、example.com のNSとして ns1.example.com を使う場合、ns1.example.com のAレコードをレジストリに直接登録する。
グルーレコードの仕組み
レジストラが example.com をレジストリに登録する際、NSとして ns1.example.com を指定。
その際、ns1.example.com のIPアドレスも一緒にレジストリに登録。
TLD DNSサーバーは、example.com を問い合わせられた際に ns1.example.com のAレコードも提供できる。
ハイマジですね。すごいです。
.com ドメインを管理しているレジストリは Verisign であり、 そのTLD DNSサーバー（.com の権威DNSサーバー）は以下の通りです。
a.gtld-servers.net
b.gtld-servers.net
c.gtld-servers.net
d.gtld-servers.net
e.gtld-servers.net
f.gtld-servers.net
g.gtld-servers.net
h.gtld-servers.net
i.gtld-servers.net
j.gtld-servers.net
k.gtld-servers.net
l.gtld-servers.net
m.gtld-servers.net
root@x162-43-29-213:~# dig ns workers-bub.com @a.gtld-servers.net
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> ns workers-bub.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58268
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;workers-bub.com. IN NS
;; AUTHORITY SECTION:
workers-bub.com. 172800 IN NS ns01.workers-bub.com.
workers-bub.com. 172800 IN NS ns02.workers-bub.com.
;; ADDITIONAL SECTION:
ns01.workers-bub.com. 172800 IN A 162.43.28.21
ns02.workers-bub.com. 172800 IN A 162.43.53.234
;; Query time: 207 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net) (UDP)
;; WHEN: Wed Jan 29 19:19:18 JST 2025
;; MSG SIZE rcvd: 114
additional sectionに登録されているのがグルーレコードですね。 これがないと名前解決ができません。 ちなみに、これはムームードメインで確かに登録した覚えがあります。 すごいですね。すごいです！！
まとめ
- ムームードメインやお名前ドットコムは.comや.net等のTLDネームサーバのレジストリにドメインを登録する作業を代行してくれる「レジストラ」である
- 例えば、workers-bub.comをお名前ドットコムを登録すると、.comを管理する「Verisign」という団体のレジストリに名前解決に必要な情報が登録される。
- 名前解決に必要な情報は、ドメイン名と、それに紐づく権威DNSサーバ、そして、権威DNSサーバのIPアドレス（つまりaレコード）。これらの情報がTLDサーバに登録される。
- ムームードメイン経由でレジストリに登録する際、デフォルトでムームードメインのネームサーバが登録される。ここのネームサーバを自前で立てることができるという話ですよね。
おまけ
結論：レジストラを経由せずにレジストリの情報を直接変更することは ✅ 不可能 ✅
理由：レジストリの管理権限はレジストラに委ねられている
レジストリ（Registry）はドメインの最上位管理者 であり、直接ユーザーに管理権限を提供しません。
レジストリは、レジストラ（Registrar）を通じてのみ ドメインの登録・管理を許可します。
そのため、レジストリの情報（NSレコードや登録者情報）を変更するには、必ずレジストラを通す必要があります。
レジストリとレジストラの役割
レジストリ（Registry）
例: .com のレジストリは Verisign。
すべての .com ドメインを管理し、TLD DNS サーバーを運用。
各ドメインに紐づく ネームサーバー情報（NSレコード） を保持。
レジストラ（Registrar）
例: Google Domains, Namecheap, お名前.com, Cloudflare Registrar
レジストリと契約し、エンドユーザーにドメイン登録・管理サービスを提供。
ユーザーが NS を変更すると、その情報をレジストリに登録する役割を持つ。
インターネットは自由な世界に見えて、結構中央集権的な管理になっていそうで悲しい
そうですね、インターネットは自由に見えて、実際には中央集権的な管理がしっかりと行われている世界です。
特に、ドメイン名の管理はICANNやレジストリによって厳格にコントロールされています。
そして、あなたの考え通り、一番儲かっているのはレジストリ（Registry） です。
なぜなら、ドメインの登録料は最終的にレジストリに流れ込み、彼らはほぼ独占状態でTLDを管理しているからです。
レジストリ（Registry）は、自身が管理するTLD（トップレベルドメイン）をさらに上位のルートDNSサーバーを管理する団体に登録する必要があります。
ルートDNSサーバーを管理しているのは、ICANN（Internet Corporation for Assigned Names and Numbers） の管理下にある IANA（Internet Assigned Numbers Authority） です。
ICANN（アイカン）
インターネットのドメイン名システム（DNS）全体を管理する非営利組織。
新しいgTLDの承認やポリシー決定を行う。
各レジストリ（例: Verisign, JPRS）にTLDの管理権限を与える。
IANA（アイアナ）
ICANNの一部門で、ルートDNSサーバーのゾーンファイルを管理 する。
各TLD（.com, .jp, .orgなど）をどのレジストリが管理するかを記録。
ルートDNSサーバーの更新を担当。
ICANNマジで怪しからんな。非営利組織とか言っておきながら、がっつり儲けてますやん。ありえないっすわ。
ICANN、ipアドレスの割り当てもやっているんかい。 ASのやつね。マジか。マジで独占できるやん。
GSLBをしても、死んだIPがDNSキャッシュされているとGSLBにならないのでは？
GSLBを権威DNSで実装しても、キャッシュDNS（リゾルバ）が古いデータを持っていたら、死んだサーバーにアクセスが行くのでは？
➡ 正しい疑問です！
➡ その通りで、キャッシュDNS（リゾルバ）が古いIPアドレスを保持していた場合、ユーザーは死んだサーバーにアクセスしてしまいます。
➡ 解決策としては「TTLを短くする」以外にもいくつか方法があります！
対策
TTLを60秒〜300秒に設定（負荷に応じて調整）
ネガティブキャッシュTTLを10秒程度に設定
DNSラウンドロビンで一時的な負荷分散を実施
クライアントサイドでフェイルオーバー処理を実装
Anycast DNSを採用（可能なら）
ということで、DNSラウンドロビンでたくさんAレコードを返すのがいいかな。 クライアントサイドでフェイルおーばするするようにする。 というのは、chromeだとどうだろう。
1. 複数の A レコードがある場合
Chrome は OS の DNS 解決関数（getaddrinfo() など）を利用 し、
複数の A レコードを取得し、優先度をつけて順番に試します。
例えば、DNS の応答が以下のようになった場合：
css
Copy code
example.com. 60 IN A 192.168.1.1
example.com. 60 IN A 192.168.1.2
example.com. 60 IN A 192.168.1.3
Chrome は 最初の IP（192.168.1.1）に接続を試みる。
失敗した場合、次の IP（192.168.1.2）を試し、さらに 192.168.1.3 へと順番に切り替える。
らしいですね。 自動でフェイルおーばするようになっています！！