では
- リゾルバ
- 再帰問い合わせ
- 反復問い合わせ
- ルートサーバ
から見ていきましょうか。
リゾルバ
そういや「リゾルバ」ってスルーしたから忘れてたな。
「リゾルバ（resolver）」は名前解決の機能のことで、直訳したら「答えを見つけてくるもの」みたいな感じです。リゾルバが仕事してくれるおかげで、名前解決ができるんですね。
ふーん、そういやPCの設定のDNSサーバのことを「リゾルバ」だって言ってたな。機能じゃなくて設定じゃねーの？
リゾルバにも種類があるんです。
- スタブリゾルバ：人間から最初に名前解決の要求を受け取るリゾルバ
- フルリゾルバ：他のリゾルバからの名前解決要求を処理するリゾルバ
大きくこの2つで、PCの設定の「DNSサーバ」は使用する「フルリゾルバ」となるホストを設定しているんです。
スタブリゾルバは？
スタブリゾルバはWindowsなどのOSやブラウザの機能です。ブラウザのURLバーに「www.example.com」みたいに入れたら、フルリゾルバに名前解決要求を送信し、その結果を受け取って次の処理を行います。
へー、じゃあリゾルバが名前解決の結果を扱うんなら、キャッシュはここにあるってことであってる？
そのとおりです！
ブラウザ、OS、もしくはフルリゾルバでキャッシュ機能が使われている場合にはここに名前解決の結果が保持されます。
なるほど、じゃあ浸透するのはキャッシュってことでファイナルアンサー！
まぁそう焦らず…
再帰問い合わせ、反復問い合わせ
その前に、リゾルバが実際にどういう動きをしてるかを確認しておきましょう。名前解決要求はクエリ（問い合わせ）と言いますが、問い合わせにも種類があります。
まず「再帰問い合わせ」。
再帰（recursive）はプログラミングでもありますが「自身を再利用する」ようなものを指します。再帰問い合わせも同様で「この問い合わせの最終結果が得られるまでこの問い合わせを繰り返せ（最終結果だけ教えろ）」というものです。
最終結果だけよこせって、DNSサーバに聞けばすぐ答え返ってくるじゃん。
まぁまぁ。
次に「反復問い合わせ」。
反復（iterative）は「次々と続けて行う」ものです。反復問い合わせはある意味たらい回しのような感じで「この問い合わせはこっちに聞け」と返された結果を元に指定された次の問い合わせ先に同じ問い合わせを行う、というのを繰り返すものです。
再帰と反復、人任せと自分が頑張る、って違い？
そんな感じですね。
でもDNSサーバに問い合わせたら1発で答えが返ってくるんだから、反復問い合わせとかいらなくね？
ここが大事なところです。先程
PCの設定の「DNSサーバ」は使用する「フルリゾルバ」となるホスト
と言いましたが、ざっくりいうと「スタブリゾルバは再帰問い合わせをフルリゾルバに送る」「フルリゾルバは再帰問い合わせの結果を返すために反復問い合わせを行う」のです。つまり、PCやブラウザからの再帰問い合わせを受け取った「DNSサーバ＝フルリゾルバ」は、最終結果を返すために頑張って反復問い合わせを行い、結果を返すという大変な仕事をしているのです。
それはわかったけど、なんで反復問い合わせがいるのよ。フルリゾルバも再帰問い合わせすれば一発で答え返ってくるんじゃねーの？
これはDNS全体の仕組みに関わってきますので、ちょっと話が変わりますがお付き合いください。
大前提として「DNSは分散データベース」の仕組みを使っているということです。これは「すべてのデータが一元管理されている」のではなく「すべてのデータは散在し、それぞれ独立して管理されている」というものです。
はぁ
そして、この「独立して管理」する単位が「ドメイン」であり、その範囲を表すものが「ドメイン名」なのです。
俺の独自ドメインは俺が管理してるから、それはわかる。
そうです。では、有名どころのドメイン名を例にしてみましょう。
例えばTwitterのドメイン名は「twitter.com」ですが、このドメイン名を管理する権利を .com から分割してもらうことで、独立して管理することができるようになっています。
.com から分割？
はい。.com はTLD（Top Level Domain）で、「なんとかかんとか.com」というドメイン名の親玉になります。.com は . から管理する権限を分割してもらっています。
ちょっと、. からってどういうことよ？
おっと、大事な説明が抜けていましたね。ドメイン名はツリー状の階層構造を持つのですが、その起点が「. （ドット）」なのです。このドットのことを「ルート」と呼びます。
ほぅ
すべてのドメイン名に関する名前解決は、この「ルート」から始まります。ツリー状なので、ルート（根）からたどって行けば最終目的地の枝の先端まで到達できる、というのがDNSの名前解決の基本です。
このルートを担当するサーバを「ルートサーバ」と呼びます。
まぁ確かにたどっていけば到達できるだろうけど
- ルートの位置ってどうやって知るのよ？
- どうやって枝分かれさせるのよ？
ありがとうございます！まず「ルート」の知り方ですが、これは問い合わせ先はありません！
は？じゃあ名前解決できねーじゃん。バカなの？
そのために存在するのが「ルートヒント」です。ルートヒントにはルートとなるサーバのアドレスが記載されていて、フルリゾルバは反復問い合わせの最初にこのルートヒントに記載されたアドレスに問い合わせを行います。
へー。アドレス固定なの。
そうなんです。逆に言うと「ルートヒントが更新されていない古いリゾルバは、新しく追加された or アドレスが変更されたルートサーバの情報を知らない＝名前解決の失敗率が上がる」ということが起こりえます。そういう意味でも、ちゃんと更新をする必要がある情報だということがわかります。
まーね、更新は重要よね。
で、次に「枝分かれさせる」です。
ルートは .com に管理権限を分割しますが、同時に .jp や .net などにもそれぞれ管理権限を分割しています。つまり、ルートの時点で枝分かれは始まっていることになります。
あー、.com の管理と .jp の管理は別物ってこと？
はい、ここがすでに「分散データベース」の始まりになっています。このときに「このドメインについてはこいつに聞いてくれ」と、たらい回しが始まるのですが、そのときに渡されるのが「ネームサーバ」の情報であり、このネームサーバが「ドメイン内の管理情報のデータベース」になります。
あるドメイン名の配下に子になるドメイン名を追加して、そのドメイン名配下の情報を管理する「ネームサーバ」を登録することで管理権限が分割されます。これを「委譲、委任（delegation）」といいます。
え、じゃあ俺が独自ドメインとったらその時点で委譲されるってこと？
正確には「そのドメイン名を管理するネームサーバが、上位のドメインに正しく登録された時点」といったほうがいいですかね。
なんだよその「正確には」とか「正しく」とか。試験かよ。
これはいわゆる「浸透待ち」や、ドメイン名の乗っ取り被害を生む要因なのです。例えば
- 新規にドメイン名を取得
- そのドメイン名を管理する「ネームサーバ」を登録
- しかし、「ネームサーバ」の構築や、必要な情報登録を後回しにしている（委譲された範囲に関する問い合わせが返せない） or 登録したネームサーバ情報が誤っている（綴り間違いなどで正しいネームサーバに到達できない）
のようなときに、「浸透しない」や別人が構築した異なるネームサーバによる偽応答が実現しうるのです。
ですので、「そのドメインを管理するネームサーバ＝権威サーバを先に正しく構築する」が重要なのです。
乗っとりねぇ。浸透するのが早ければ関係なくない？
それは反復問い合わせの内容を確認してからにしましょう。
反復問い合わせは先程「たらい回し」と言いました。これは「委譲された、権威（責任）を持つネームサーバによる回答を得るまで、繰り返す」ということです。 twitter.com の名前解決を手で実際にやってみましょう。
名前解決の動作確認には dig というツールを使うとわかりやすいです。オプションを
+norec: 再帰問い合わせを行わない（デフォルトは再帰問い合わせを行う）@問い合わせ先サーバ: クエリを送る宛先- 問い合わせるリソースレコードのタイプは未指定（デフォルトは「Aレコード:名前に対応するIPアドレス」）
として、フルリゾルバの気持ちで名前解決してみます。
※実行例はmacOS Big Surで取得しています。
まず、ルートサーバに問い合わせます。ルートサーバは a から m の13ありますが、ここでは a に聞いてみます。
$ dig +norec @a.root-servers.net twitter.com
; <<>> DiG 9.10.6 <<>> +norec @a.root-servers.net twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12906
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com. IN A
;; 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.
;; ADDITIONAL SECTION:
e.gtld-servers.net. 172800 IN A 192.12.94.30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
j.gtld-servers.net. 172800 IN A 192.48.79.30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
m.gtld-servers.net. 172800 IN A 192.55.83.30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
i.gtld-servers.net. 172800 IN A 192.43.172.30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
f.gtld-servers.net. 172800 IN A 192.35.51.30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
g.gtld-servers.net. 172800 IN A 192.42.93.30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN A 192.54.112.30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
l.gtld-servers.net. 172800 IN A 192.41.162.30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
k.gtld-servers.net. 172800 IN A 192.52.178.30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
c.gtld-servers.net. 172800 IN A 192.26.92.30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN A 192.31.80.30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
;; Query time: 282 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sun Apr 25 12:56:51 JST 2021
;; MSG SIZE rcvd: 836AUTHORITY SECTIONには「そのドメインを委譲されたネームサーバ」についての情報が入っています。AUTHORITY SECTIONで、.com については a から m までの gtld-servers.net に聞くようにと言われています。それらのサーバのドメイン名やIPアドレスは、追加情報として提供されるADDITIONAL SECTIONに書いてありますので、ここでは一番上の e.gtld-servers.net. を使ってみましょう。
$ dig +norec @e.gtld-servers.net. twitter.com
; <<>> DiG 9.10.6 <<>> +norec @e.gtld-servers.net. twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27622
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com. IN A
;; AUTHORITY SECTION:
twitter.com. 172800 IN NS ns3.p34.dynect.net.
twitter.com. 172800 IN NS ns4.p34.dynect.net.
twitter.com. 172800 IN NS d01-01.ns.twtrdns.net.
twitter.com. 172800 IN NS d01-02.ns.twtrdns.net.
twitter.com. 172800 IN NS a.r06.twtrdns.net.
twitter.com. 172800 IN NS b.r06.twtrdns.net.
twitter.com. 172800 IN NS c.r06.twtrdns.net.
twitter.com. 172800 IN NS d.r06.twtrdns.net.
;; Query time: 249 msec
;; SERVER: 192.12.94.30#53(192.12.94.30)
;; WHEN: Sun Apr 25 12:57:39 JST 2021
;; MSG SIZE rcvd: 211今度は、 twitter.com については、AUTHORITY SECTIONの8つのサーバに聞くようにと言われています。同様に最初の ns3.p34.dynect.net. に問い合わせます。
$ dig +norec @ns3.p34.dynect.net. twitter.com
; <<>> DiG 9.10.6 <<>> +norec @ns3.p34.dynect.net. twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50747
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 10, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com. IN A
;; ANSWER SECTION:
twitter.com. 1800 IN A 104.244.42.129
twitter.com. 1800 IN A 104.244.42.65
;; AUTHORITY SECTION:
twitter.com. 13999 IN NS ns1.p34.dynect.net.
twitter.com. 13999 IN NS d01-01.ns.twtrdns.net.
twitter.com. 13999 IN NS b.r06.twtrdns.net.
twitter.com. 13999 IN NS d01-02.ns.twtrdns.net.
twitter.com. 13999 IN NS c.r06.twtrdns.net.
twitter.com. 13999 IN NS d.r06.twtrdns.net.
twitter.com. 13999 IN NS a.r06.twtrdns.net.
twitter.com. 13999 IN NS ns3.p34.dynect.net.
twitter.com. 13999 IN NS ns4.p34.dynect.net.
twitter.com. 13999 IN NS ns2.p34.dynect.net.
;; Query time: 29 msec
;; SERVER: 208.78.71.34#53(208.78.71.34)
;; WHEN: Sun Apr 25 13:00:04 JST 2021
;; MSG SIZE rcvd: 293ようやく名前に対応するIPアドレスである「Aレコード」が得られました。104.244.42.129と104.244.42.65の2つでした。
このように、反復問い合わせではルートサーバからたどって「委譲先」として返されたネームサーバに同じクエリを送信し、Aレコードが得られるまで繰り返します。
ここで「委譲先」として返されたネームサーバが正しく応答しない場合は名前解決に失敗するので「浸透しない」という原因になりえます。
例えば api.example.com のつもりで ap.example.com と登録し、動作確認のために フルリゾルバに api.example.com で再帰問い合わせを送ると結果としては「存在しない」というエラーが返されます。そのエラー情報がフルリゾルバやスタブリゾルバにキャッシュ（ネガティブキャッシュ）されてしまうと、ネガティブキャッシュのTTLが切れるまでは誤った名前を修正しても正しい情報が取得できないということが起こります。
そのような失敗にはまらないようにするには、登録後すぐにブラウザなどから再帰問い合わせを実行するのではなく、digのようなツールで反復問い合わせを行う必要があります。
まじか！俺登録してすぐ普通にブラウザでアクセスして確認してたわ。
データを確認する場合は、キャッシュではなくデータベースの情報を参照する必要がある、ということですね。
浸透（とは）
…ねえちょっと待って。
はい、何でしょう？
「フルリゾルバの気持ちで」とか言って反復問い合わせ見せられたけどさ、浸透の説明は無いの？
残念ながら無いですね。
なんでよ？
うーん、逆にお聞きしたいのですが…
まず「リゾルバが名前解決要求である問い合わせを行う」ことで名前解決の結果が得られる仕組みだということはご理解いただけましたか？
そうね。基本、PCとかが再帰問い合わせするのを、DNSサーバが反復問い合わせして結果返してくれるって話だったよな。
そのとおりです。では、説明を聞きたいという「浸透」とはどのような挙動のことですか？
そりゃ、俺の取得した独自ドメインをみんなが見られるようになるまでにかかる時間のことだろ。
おや？アクセスしてくる皆さんは先程までの名前解決に必要な「問い合わせ」とは違う動作をされているのですか？
いや、俺と同じWindowsやiPhoneとかのスマホだろ。
では、同じように名前解決に「問い合わせ」を使うのであれば、なぜみなさんが見られるようになるまで時間がかかるのですか？
そりゃ浸透してないからだろ。
なにがどこに浸透するのですか？
俺のとった独自ドメインが…
が？
…レジストリ？
レジストリには「お名前.com」のようなレジストラが登録作業を行いますよ。
登録することが「浸透」でしょうか？
…ちげぇ。
では、「浸透」とは何なのでしょう？
しらん。俺はDNS屋じゃねえから。
前回memcachedを例にした際に「データベースの情報が勝手にキャッシュの情報を更新することはない」というお話をされましたよね。DNSもそれと同様で、「登録した情報が勝手にどこかへ伝わることはない」のです。伝わるとしたら、それは「問い合わせ」を行った結果なのです。
うっ、こういう説明をするサイトがあるのですか…
残念ながら「浸透期間」というものは存在しません。先程の反復問い合わせで確認したとおり、「委譲されたネームサーバが正しく応答を返せる」ようになったら、それで終わりなのです。
ただし、それ以前に「問い合わせた結果」としてキャッシュされた情報がリゾルバに残っていた場合、意図しない挙動になる事があるので、
- 新旧ネームサーバの並行稼動期間を設ける
- 作業結果は、権威サーバのデータを直接確認する（キャッシュではなくデータベースを参照する）
- 不用意に再帰問い合わせを行わない
という考慮が必要な場合があります。
これらをおこたると「浸透しない」事態に遭遇する確立が非常に高くなります。
…マジ？
マジです。「浸透」という存在しない仕組みと、それについてのおかしな説明のせいで、みなさんが自分から落とし穴にハマっているのです。
でもよ、実際俺が独自ドメインとったときになかなかブログ見れなかったぜ。確か1週間経ってもだめだったかな。
なんでそんなことになるんだよ。
その時の登録状態にもよりますので、一概には言えないですね…
さぁ、実際に遭遇した「浸透しない」は解決できるのか！？
コメント