DNSを更新するとどうなりますか

Fenix by Takeda11



サイトのIPアドレスを変更すると、DNSレコードの更新について多くの人が混乱します。これらのレコードがゆっくり更新されるのはなぜですか？すべてが更新されるまで本当に2日待つ必要がありますか？一部の訪問者が新しいIPを表示し、他の訪問者が古いIPを表示するのはなぜですか？Mail.ru Cloud Solutions



チームは、開発者であり記事の著者であるJulia Evansによる記事を翻訳しました。彼女はこれらの質問に答え、フロントエンドの観点からDNS更新中に何が起こるかを一般的に説明しています。



DNSレコードを更新するときに、舞台裏で何が起こるかを簡単に説明します。

DNSのしくみ：再帰的で信頼できるDNSサーバー

まず、DNSシステムについて少し説明する必要があります。 DNSサーバーには、権限のあるものと再帰的なものの2種類があります。



権限のあるDNSサーバー（ネームサーバーとも呼ばれます）は、担当する各ドメインのIPアドレスのデータベースを維持します。たとえば、現在、github.comの権限のあるDNSサーバーはns-421.awsdns-52.comです。このリクエストで、彼にgithub.comのIPアドレスを尋ねることができます。

dig @ns-421.awsdns-52.com github.com

再帰DNSサーバー自体は、誰がどのIPアドレスを所有しているかについては何も知りません。ドメインのIPアドレスは、適切な権限のあるDNSサーバーからクエリを実行して計算し、再度要求された場合に備えてそのIPアドレスをキャッシュします。したがって、8.8.8.8は再帰DNSサーバーです。



人々があなたのウェブサイトにアクセスするとき、彼らはおそらく再帰的なDNSサーバーへのDNSルックアップを行っています。では、再帰DNSサーバーはどのように機能しますか？見てみましょう！

再帰DNSサーバーがgithub.comのIPアドレスを照会する方法

github.comのIPアドレス（Aレコード）を要求したときに再帰DNSサーバー（8.8.8.8など）が実行する例を見てみましょう。まず、すでにキャッシュされた結果がある場合は、それを発行します。しかし、すべてのキャッシュが期限切れになった場合はどうなりますか？これが何が起こっているのかです。



ステップ1：ルートDNSサーバーのIPアドレスは、ソースコードにハードコードされています。これは、バインドされていないソースコードで確認できます。彼が最初に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：.comgithub.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のネームサーバーの1つです。



ステップ4：github.comのネームサーバーにgithub.comのアドレスを尋ねます。



ほぼ完了です。

$ dig @205.251.193.165 github.com

github.com.		60	IN	A	140.82.112.4

したがって、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つのオプションがあります。

1. 同じ名前のサーバーを維持します。
2. ネームサーバーを変更します。

TTLについて話しましょう

しかし、私たちは何か重要なことを忘れました。これはTTLです。前に述べたように、再帰DNSサーバーは、レコードが期限切れになるまでレコードをキャッシュします。TTL（存続時間）に基づいてレコードの有効期限を決定します。



この例では、GitHubネームサーバーはDNSレコードに対して60のTTLを返します。これは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）を更新して、test.jvns.ca1.2.3.4にマップされる新しいDNSレコードであるAレコードを取得しました。

$ 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仕様に準拠しているわけではありません。一部のISPDNSサーバーは、指定されたTTLよりも長い時間レコードをキャッシュします。たとえば、5分ではなく2日以内。そして、人々はいつでもファイルに古いIPアドレスをハードコーディングできます/etc/hosts。



実際には、5分のTTLでDNSレコードを更新する場合、クライアントの大部分が新しいIPアドレスにすばやく移動すると予想できます（たとえば、15分以内）。その後、数日でゆっくりと更新される多数の遅延が発生します。

オプション2：ネームサーバーを更新する

そのため、ネームサーバーを変更せずにIPアドレスを更新すると、多くのDNSサーバーが新しいIPアドレスを非常に迅速に取得することがわかりました。優れた。しかし、ネームサーバーを変更するとどうなりますか？やってみよう！



ブログのネームサーバーを更新したくなかったので、代わりに別のドメインを取得して、HTTPログの例examplecat.comで使用しました。



以前、私のサーバーはに設定されていましたdns1.p01.nsone.net。アドレスns-cloud-b1.googledomains.comなどのあるGoogleサーバーに変更することにしました。



変更を加えたとき、ドメインレジストラはやや不吉なメッセージを表示しました。「examplecat.comへの変更は保存されました。これらは48時間以内に発効します。」次に、1.2.3.4を指すようにドメインの新しいAレコードを設定しました。



さて、何かが変わったかどうか見てみましょう：

$ 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が表示される理由は、おそらくこれまでこのexamplecat.comについて1.1.1.1に質問したことがないためです。したがって、キャッシュには何もありません。そうだった。

ネームサーバーにはもっと多くのTTLがあります

私のレジストラが「48時間かかる」と言ったのは、NSレコードのTTL（再帰サーバーがアクセスするネームサーバーに関する情報）がはるかに大きいためです。



新しいネームサーバーは、examplecat.comの新しいIPアドレスを確実に返します。

$ 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
...

172,800秒は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レコードはどのようにしてそこに到達するのでしょうか。実際、Webサイトで新しいネームサーバーを更新して、ドメインレジストラにどのように表示するかを伝えてから、ドメインレジストラがネームサーバー.comに更新を行うように指示します。



以下のために.comこれらの更新かなり速い（数分以内）ですが、私はいくつかの他のTLDゾーンに、ネームサーバはすぐとして更新を適用しないかもしれないと思います。

プログラムのDNSリゾルバライブラリはDNSレコードをキャッシュすることもできます

TTLが実際に観察されない可能性があるもう1つの理由は、多くのプログラムがDNS名を解決する必要があり、一部のプログラムはDNSレコードをメモリに無期限にキャッシュすることもあります（プログラムが再起動されるまで）。



たとえば、DNSルックアップ用のJVMTTLの設定に関する記事があります。私自身はDNSルックアップ用のJVMコードをあまり作成していませんが、JVMとDNSに関するインターネット検索を少し行うと、すべてのDNSルックアップを無限にキャッシュするようにJVMを構成できるという印象があります（たとえば、このElasticSearchチケットを参照してください） ..。

それで全部です！

これが、DNSが更新されたときに何が起こるかを理解するのに役立つことを願っています。



DNS伝播の履歴全体がTTLだけでなく決定されることを予約します。一部の再帰DNSサーバーは、8.8.8.8のような主要なサーバーでさえ、おそらくTTLを尊重しません。したがって、小さなTTLでAレコードを更新しただけでも、実際には1〜2日以内に古いIPの要求を受信する可能性があります。



この記事を投稿した後、examplecat.comのネームサーバーを以前の値に戻しました。



他に読むべきこと：

1. GoおよびCPUキャッシュ。
2. もう一度選択する必要がないように、プロジェクト用にどのデータベースを選択するか。
3. 私たちのテレグラムチャネルは、デジタル変換に関するものです。