最近大神のDNS に関する記事を見て、非常に良いと感じたので、自分で翻訳してみました。
誤りがあれば、指摘してください。
私は、サイトの DNS レコードを更新して IP アドレスを変更することに困惑している人が多いのを見てきました。なぜこんなに遅いのか？すべての内容が更新されるまで本当に 2 日待つ必要があるのか？なぜある人は新しい IP を見て、他の人は古い IP を見ているのか？何が起こっているのか？
ここでは、DNS を更新する際に何が起こるのかを記録します。
DNS の分類：再帰 DNS サーバーと権威 DNS サーバー#
まず、DNS に関するいくつかの知識を説明する必要があります。DNS サーバーには 2 種類あります：権威サーバーと再帰サーバー。
権威DNS サーバー（別名ネームサーバー）は、各ドメイン名に対する IP アドレスのデータベースを持っています。例えば、github.com の権威 DNS サーバーは ns-421.awsdns-52.com です。dig コマンドを使用して github.com の IP を取得できます。
dig @ns-421.awsdns-52.com github.com
再帰DNS サーバーは、誰がどの IP アドレスを持っているかを知りません。正しい権威 DNS サーバーに問い合わせてドメイン名の IP アドレスを特定し、その IP アドレスをキャッシュします。8.8.8.8 は再帰 DNS サーバーです。
人々があなたのウェブサイトにアクセスするとき、彼らは再帰 DNS サーバーに DNS クエリを行っている可能性があります。では、再帰 DNS サーバーはどのように機能するのでしょうか？見てみましょう！
再帰 DNS サーバーはどのように github.com をクエリするのか？#
再帰 DNS サーバー（例えば 8.8.8.8）があなたの要求に対して github.com の IP アドレス（A レコード）を取得する際の機能の例を見てみましょう。まず、もし何かがキャッシュされていれば、それを提供します。しかし、すべてのキャッシュが期限切れの場合はどうなるでしょうか？以下のようなことが起こります：
ステップ 1：ソースコードにハードコーディングされたルート DNS サーバーの IP アドレス。これはunbound のソースコードで見ることができます。仮に198.41.0.4が最初に選ばれたとします。これはこれらのハードコーディングされた IP アドレスの公式ソースであり、「ルートヒントファイル」とも呼ばれます。
ステップ 2：ルートネームサーバーにgithub.comを問い合わせます。
私たちはdigで起こることを大まかに再現できます。これにより、新しい権威ネームサーバーが得られます：.comのネームサーバーの IP は192.5.6.30です。
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
DNS 応答の詳細はこれよりも複雑です。この場合、いくつかの NS レコードを持つ権威部分と、A レコードの部分があり、追加の検索を行うことなくこれらのネームサーバーの IP アドレスを取得できます。
（実際には、99.99％の時間、.comネームサーバーのアドレスはすでにキャッシュされていますが、実際には最初から始めるふりをしています）
ステップ 3：.comドメインサーバーにgithub.comに関する情報を問い合わせます。
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
新しい IP アドレスを問い合わせることができました！これはgithub.comのネームサーバーです。
ステップ 4：github.comドメインサーバーにgithub.comに関する情報を問い合わせます。
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
OK！今、github.comのAレコードを持っています！これで、再帰ネームサーバーはgithub.comの IP アドレスを持ち、あなたに返すことができます。これは、いくつかのIP アドレスをハードコーディングすることで実現されます：つまり、ルートネームサーバーのアドレスです。
すべての再帰 DNS サーバーを確認する方法： dig+trace#
ドメイン名を解決する際に再帰 DNS サーバーが実行する操作を確認したいとき、私は以下のコマンドを実行します:
$ dig @8.8.8.8 +trace github.com
これにより、ルート DNS サーバーから始まるすべての DNS レコードのリクエストが表示されます -- 私たちがちょうど完了した 4 つのステップです。
DNS レコードを更新する方法#
DNS の仕組みを理解したので、いくつかの DNS レコードを更新して、何が起こるか見てみましょう。
DNS レコードを更新する際には、2 つの主要なオプションがあります：
- 同じネームサーバーを維持する
- ネームサーバーを変更する
TTL について#
ここで、TTL という概念を説明します。以前に述べたように、再帰 DNS サーバーはレコードが期限切れになるまでキャッシュしますが、レコードが期限切れになるかどうかを決定する方法は、その **TTL（Time To Live）** を確認することです。
以下の例では、A レコード github のネームサーバーがその DNS レコードに返す TTL は60で、これは 60 秒を意味します：
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
これは非常に短い TTL で、理論的には、すべての人の DNS 実装がDNS 標準に従っている場合、Github がgithub.comの IP アドレスを変更することを決定した場合、すべての人が 60 秒以内に新しい IP アドレスを取得することを意味します。実際にはどうなるか見てみましょう。
オプション 1：同じネームサーバーで DNS レコードを更新する#
まず、私はネームサーバー（Cloudflare）を更新し、新しい DNS レコードを持たせました：test.jvns.caを A レコード1.2.3.4にマッピングしました。
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
これは即座に有効になります！待つ必要は全くありません、なぜならtest.jvns.caにはキャッシュされる前に DNS レコードがなかったからです。しかし、新しいレコードは約 5 分（299 秒）キャッシュされたようです。
では、その IP を変更しようとした場合はどうでしょうか？私はそれを5.6.7.8に変更し、同じ DNS クエリを実行しました。
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
うーん、どうやら DNS サーバーの1.2.3.4レコードはまだ 144 秒キャッシュされています。面白いことに、もし私が8.8.8.8を何度もクエリすると、実際に不一致な結果が得られます–時には新しい IP を、時には古い IP を返してくるのです。これは、8.8.8.8 が実際に異なるバックエンドのグループに負荷分散しており、それぞれのバックエンドが独自のキャッシュを持っているためだと思います。
5 分待った後、すべての8.8.8.8キャッシュが更新され、常に新しい5.6.7.8レコードを返しました。かなり速いと言わざるを得ません！
TTL に常に依存できるわけではない#
ほとんどのインターネットプロトコルと同様に、すべてのものが DNS 規格に従っているわけではありません。特定の ISP の DNS サーバーは、TTL が指定した時間よりも長くレコードをキャッシュすることがあります。例えば、2 日間ではなく 5 分間です。人々は常に /etc/hosts に古い IP アドレスをハードコーディングすることができます。
5 分の TTL で DNS レコードを更新する際に、実際に起こることを期待しているのは、かなりの割合のクライアントが迅速に（例えば 15 分以内に）新しい IP に移行し、その後数日間にわたって遅いクライアントが徐々に更新されるということです。
オプション 2：ネームサーバーを更新する#
私たちは、ネームサーバーを変更せずに IP アドレスを更新すると、多くの DNS サーバーがすぐに新しい IP を取得することを見てきました。しかし、ネームサーバーを変更するとどうなるでしょうか？
私は自分のブログのドメインサーバーを更新したくなかったので、異なるドメインを使用し、HTTP マガジンでの例としてexamplecat.comを使用しました。
以前、私のネームサーバーは dns1.p01.nsone.net に設定されていました。私はそれらを Google のネームサーバーに切り替えることに決めました -ns-cloud-b1.googledomains.comなど。
変更後、私のドメイン登録業者は少し不愉快にメッセージを表示しました - “examplecat.com の変更が保存されました。次の 48 時間以内に有効になります。” その後、私はそのドメインに新しい A レコードを設定し、1.2.3.4を指すようにしました。
さて、何か効果があるか見てみましょう：
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
変化はありません。もし他の DNS サーバーに問い合わせると、新しい IP アドレスが返されます：
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
しかし、8.8.8.8 は依然として変化がありません。たとえ私が 5 分前に変更したばかりでも、1.1.1.1 が新しい IP を見られる理由は、おそらく以前に誰も 1.1.1.1 に examplecat.com を問い合わせなかったため、そのキャッシュに何もないからです。
ネームサーバーの TTL が長い#
私の登録業者が「これには 48 時間かかる」と言った理由は、NS レコードの TTL（これは再帰ネームサーバーがどのネームサーバーに問い合わせるかを知る方法）が長いためです！
新しいドメインサーバーは確かに新しい IP アドレスexamplecat.comを返します。
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
しかし、私たちがgithub.comのネームサーバーを問い合わせたときに何が起こったか覚えていますか？
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172800 秒は 48 時間です！したがって、ネームサーバーを変更せずに IP アドレスを更新するのと比較して、ネームサーバーの更新には通常、キャッシュからの期限切れと伝播により、より長い時間がかかります。
ドメイン名サーバーはどのように更新されるのか？#
私が更新したドメイン名サーバーexamplecat.comで起こることは、.comドメインサーバーが新しいドメインのNSレコードを取得することです。次のように：
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
しかし、新しい NS レコードはどのようにそこに到達するのでしょうか？起こることは、私はウェブサイトでドメインを更新してドメイン登録業者に新しいドメインサーバーを知らせ、その後ドメイン登録業者が.comドメインサーバーに更新を指示することです。
.comの場合、これらの更新は非常に迅速に行われます（数分以内に）、しかし、他のいくつかの TLD では、TLD ドメインサーバーが更新を迅速に適用できない可能性があると思います。
プログラムの DNS リゾルバライブラリも DNS レコードをキャッシュする可能性がある#
実際に TTL を遵守しないもう一つの理由：多くのプログラムが DNS 名を解決する必要があり、特定のプログラムは DNS レコードをメモリに無期限にキャッシュすることがあります（プログラムが再起動されるまで）。
例えば、AWS にはDNS 名の検索に JVM TTL を設定するに関する記事があります。私は自分で DNS 検索を行う JVM コードをあまり書いていませんが、JVM と DNS に関するいくつかの注意深い研究を通じて、JVM が各 DNS 検索を無期限にキャッシュするように構成できるようです。（例えばこの elasticsearch の問題）
p.s. TTL は DNS の動作を完全に説明するものではありません–たとえ 8.8.8.8 のような主要な DNS サーバーでも、特定の再帰 DNS サーバーは TTL を絶対に無視します。したがって、短い TTL で A レコードを更新しても、実際には 1、2 日内に古い IP へのリクエストを受け取る可能性が非常に高いです。
参考#
https://jvns.ca/blog/how-updating-dns-works
初出：個人ブログ：方寸之间