DNS わかんねえ

DNS わかんねぇ......

ドメインと IP アドレスの変換をするやつ 例：beyondjapan.com = 104.21.91.53 例えるなら電話帳みたいなやつ（電話帳は名前と電話番号を変換する）

わかんねぇポイント 分散しすぎ 別名多すぎ TTL ややこしすぎ

分散しすぎ

DNS は分散型 DB みたいなもん ルートサーバ ボスです 任せます 任せます com 用サーバ ・それぞれのドメインを管理している場所が違う（情報が 1 か所に集中していない） ・上から下に「このドメインについてはお前に任せた」と権限を渡している $ dig beyondjapan.com ;; ANSWER SECTION: beyondjapan.com. 300 beyondjapan.com. 300 IN IN A A 172.67.167.78 104.21.91.53 ドメインの最後にルート（ . ）ついてる

Q. ドメインの問い合わせをすると どのように答えが得られるのか ルートサーバ ？ てる っ ②知 m用 o c は ぼく ん ね とん 任せ に ーバ サ ③今 ① beyondjapan.com くれ スタブリゾルバ フルサービスリゾルバ ④知っとるって聞いたで ⑧ 104.21.91.53 だってよ com 用サーバ ⑤今は A に任せとんねん そっちに聞いてや ⑥おしえて ー し わ ま い A. たら 権威サーバ A ⑦104.21 .91.53 やで

ふたたびアクセスしたときの動き ちょっとまえに聞いたとき 104.21.91.53って言ってたなぁ ぼく ① beyondjapan.com くれ フルサービスリゾルバ スタブリゾルバ ② 104.21.91.53 です! キャッシュします

DNS 問い合わせを追いかけたい ！ れ g di dig コマンドでいろいろ確認できる 大事なのは「＠」と +norec オプション

ふつうに dig ると下から上へお伺いを立てる感じ ブラウザからアクセスしたときもこうなる ②キャッシュあるわ com 用サーバに聞こ ルートサーバ ぼく ① beyondjapan.com くれ スタブリゾルバ フルサービスリゾルバ ③キャッシュあるわ A サーバに聞こ com 用サーバ ⑥ 104.21.1.53 だってよ フルサービスリゾルバを通して Answer Section がもらえるまで 繰り返し（再帰的に）探す ④おしえて ー 権威サーバ A ⑤104.21 .91.53 やで

オプションをつけるとフルサービスリゾルバと同じ動きが出来る dig @ネームサーバ beyondjapan.com +norec ぼく ① お前が持っている beyondjapan.com の情報くれ ② 104.21.1.53 だよ 権威サーバ A 直接そいつにだけ聞ける（キャッシュを見ない）

DNS 問い合わせを追いかけてみる② 01 ルートサーバに聞いてみる 02 03 任されてるサーバに聞いてみる ※ AUTHORITY SECTION ＝ 今はこいつに任せとんねんゾーン $ dig @a.root-servers.net beyondjapan.com +norec ・ ・ 省略 ・ ・ ;; AUTHORITY SECTION: com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. さらに聞いてみる ※ ANSWER SECTION ＝ ほんまの答えゾーン $ dig @a.gtld-servers.net beyondjapan.com +norec ・ ・ 省略 ・ ・ ;; AUTHORITY SECTION: beyondjapan.com. 172800 IN NS ingrid.ns.cloudflare.com. beyondjapan.com. 172800 IN NS damien.ns.cloudflare.com. $ dig @ingrid.ns.cloudflare.com beyondjapan.com +norec ・ ・ 省略 ・ ・ ;; ANSWER SECTION: beyondjapan.com. 300 IN A 172.67.167.78 beyondjapan.com. 300 IN A 104.21.91.53 階層構造がよくわかる

構造を知らないと 欲しい答えがもらえず 泣く かなしいね

別名多すぎ

DNS の話するとき いろんな名称が出てきます スタブリゾルバ フルサービスリゾルバ 他にも キャッシュサーバ コンテンツサーバ とか 権威サーバ ネームサーバ どれが誰だよ

登場人物 ルートサーバ ぼく フルサービスリゾルバ スタブリゾルバ com 用サーバ 権威サーバ A

TTL のぶん レコードキャッシュ するので 登場人物 ＝ やばーい 名前「解決」 するので フルサービスリゾルバ ＝ リゾルバ ルートサーバ リゾルバ ＝ ぼく ＝ たけだ キャッシュサーバ 「名前」解決 するので ＝ スタブリゾルバ ＝ ネームサーバ ＝ com 用サーバ ＝ DNS サーバ ＝ PC の OS か ブラウザ の機能 要求を送るだけ 公開 DNS サーバとか ISP の DNS サーバとか 再起検索で完全に DNS 解決できる リゾルバに渡す コンテンツを保有 しているので 権威サーバ A ＝ コンテンツサーバ

勉強するとき どれがなにかわからんくて 泣く 別のもんに同じ名前つけなさんな

ちなみに Route53 でゾーン作成すると勝手に NS レコードが４つできる （SOA レコードも出来る） こんなん ⇒ ns-〇〇.awsdns-〇〇.com これがネームサーバ

TTL ややこしすぎ

TTL = Time To Live = たいむ とぅ らいぶ DNS レコードをキャッシュに保持してもいい時間 つまり 「キャッシュサーバへの指示」

AWS Route53 権威サーバに関しては自分で決められる

DNS 問い合わせを追いかけたときのやつ 01 02 ルートサーバ TTL = 172800 秒 = 2日 $ dig @a.root-servers.net beyondjapan.com +norec ・ ・ 省略 ・ ・ ;; AUTHORITY SECTION: com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. 03 権威サーバ TTL = 172800 秒 = 2日 $ dig @a.gtld-servers.net beyondjapan.com +norec ・ ・ 省略 ・ ・ ;; AUTHORITY SECTION: beyondjapan.com. 172800 IN NS ingrid.ns.cloudflare.com. beyondjapan.com. 172800 IN NS damien.ns.cloudflare.com. TTL = 300 秒 = 5分 $ dig @ingrid.ns.cloudflare.com beyondjapan.com +norec ・ ・ 省略 ・ ・ ;; ANSWER SECTION: beyondjapan.com. 300 IN A 172.67.167.78 beyondjapan.com. 300 IN A 104.21.91.53

TTL の観点から見た名前解決の流れ ※キャッシュ済の例 NS レコード参照 172800 秒間 ルートサーバ com サーバをキャッシュ ぼく ① beyondjapan.com くれ フルサービスリゾルバ スタブリゾルバ ② 104.21.1.53 だってよ フルサービスリゾルバくんは TTＬ 分の 秒数が経過するまではキャッシュを見続ける NS レコード参照 com 用サーバ 172800 秒間 A サーバをキャッシュ A レコード参照 300 秒間 「104.21.1.53」 キャッシュ 権威サーバ A

たとえば 300 秒経過後 172800 秒 経ってないので NS レコードについては キャッシュ参照 ルートサーバ ぼく ① beyondjapan.com くれ フルサービスリゾルバ スタブリゾルバ ④ 104.21.1.53 だってよ 172800 秒 経ってないので com 用サーバ NS レコードについては キャッシュ参照 ② おしえて ー TTＬ 分 経過したあとに問い合わせがあったら 改めて現状を確認しに行く （そして再度キャッシュ） 権威サーバ A ③ 104.21 .91.53 やで

もし権威サーバの「レコード」を変更したら このような A レコードを変更した場合 beyondjapan.com. 300 IN A 104.21.91.53 すでにフルサービスリゾルバにキャッシュされているなら 検索しても最大 300 秒は変更前の A レコード(キャッシュ)が返る 変更後、権威サーバに反映されているかすぐ確認したい......?? なら直接権威サーバに聞こう！ $ dig @権威サーバ beyondjapan.com +norec $ dig beyondjapan.com なんてしたらキャッシュが返るよ

もし「権威サーバ自体」を変更したら 権威サーバ A com 用サーバ まだ 172800 秒 経ってないなぁ キャッシュで！ これからは こっちに頼むわ フルサービスリゾルバ 権威サーバ B beyondjapan.com は 104.21.1.53 だ！ beyondjapan.com は 142.250.207.110 だ！ beyondjapan.com くれ 104.21.1.53 ！ （サーバ A の情報）権威サーバ A 作業前に「変更後 どの TTL の反映を 待つ必要があるか」理解しよう ぼく スタブリゾルバ

TTL どれくらいか 把握してないと変更時に 泣く そのとき使われる「浸透」という言い訳

おまけ

古い BIND の持つ問題 01 02 03 古い BIND を搭載した キャッシュが消える前に 現在は「NS レコードキャッ DNS サーバだと 対象のドメインを検索すると シュ更新時に既にキャッ NS レコード TTL 復活現象が 古い IP と古い NS レコードを シュ済の NS レコードの TTL 起こる 受け取って 以上の値に更新しない」な キャッシュを更新してしまう どの修正が入った 幽霊ドメイン名脆弱性

ネガティブキャッシュに気をつけて まだ Ａ レコード登録してないうちにブラウザでコンテンツ確認しちゃうポメ ぼく ① beyondjapan.com くれ ② おしえてー スタブリゾルバ 権威サーバ A ⑥ 無いって ③ そんなんないよ フルサービスリゾルバ TTL が続く間は、問い合わせても 「そんなレコードは無い！」と言われる これをキャッシュ

ネガティブキャッシュは SOA レコードに依存 SOA レコードの最後の項目か SOA 自身の TTL の どちらか短い方が適用される（下の例では 900 s） dig hogepome.com ・ ・ 省略 ・ ・ ;; QUESTION SECTION: ;hogepome.com. ;; AUTHORITY SECTION: com. 900 IN IN A SOA a.gtld-servers.net. nstld.verisign-grs.com. 1674107425 1800 900 604800 86400 ネガティブキャッシュ 食らわずに権威サーバへの反映を確認するには？ やっぱこれっすわ $ dig @権威サーバ beyondjapan.com +norec これだけ覚えて帰ってください

DNS むじぃ おわり