DNSに再入門: DNSサーバーを移行し、結果と速度を検証する
※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。
元記事: https://tech-blog.mitsucari.com/entry/2025/11/12/095249
こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。
DNSは昨今のWebを支える技術です。
前回の記事ではDNSのフルリゾルバについて調査・説明しました。
今回はDNSサーバーの移行作業および速度検証についてです。私はいくつかプライベートでドメインを持っていますが、そのドメインを管理するDNSサーバーをAWSからCloudflareに移転する作業を今回行いました。理解が曖昧だったり忘れている部分が多かったので、改めて再入門(復習)してみました。
概要
- レジストラ(ドメイン)とDNSサーバーは別物なので、AWS(Route53)のレジストラとCloudflareのDNSを併用可能
- 上位の権威サーバーが自分のDNS(NS)を指す。上位の権威サーバーに情報登録が行われる
- AWS -> CloudflareのDNSサーバー切り替え後に手動コマンドあるいはメトリクスで移行を確認出来る
Route53からCloudflareへの乗り換え動機
私が持っているドメインはAmazon Route53というレジストラから購入し、同じくそこのDNSサーバーで使われています。今回これをCloudflareに移行しようと思いましたが、理由は単純でコスト削減目的です。
Cloudflareには無料プランがあります。Amazon Route53のホステッドゾーン(DNSサーバー)は有料です。詳細は以下から確認できます。
いくつドメインを持っているか(ホストゾーンを作っているか)と、どの程度DNSクエリが発生するかによって料金が変動します。私個人の場合、毎月300〜500円ほどかかっていました。
初めからCloudflareなどの無料DNSを使っていない理由は主に学習のためでした。詳細は割愛します。
毎月300円とはいえ節約したいので、移行してみることにしました。
レジストラとDNSサーバーは同じでなくても良い
移行作業をする場合、あるいはDNS移行、ドメイン移管と言ったような用語を使う場合、何をどこまで移すのかを正しく把握する必要があります。
ドメインはレジストラという販売業者から購入します。大抵レジストラがDNSサーバーも用意しているため、それを使うケースが多いと思いますが、分けることも可能です。
ドメイン移管という場合は、辞書的にはレジストラを移すことだけを言います。例えばAWSで foo.com を購入して、その後Cloudflareに管理を移すようなことを指します。ただし、実際のケースではDNSサーバーも移してしまおうとなるケースが多いと思います。なので、ドメイン移管する場合はDNSサーバーも移すことを念頭に置いたり、どこまで移すのかを意識する必要があります。
DNSサーバー移行というような用語を使う場合も同様で、レジストラはそのままなのか移すのかを意識する必要があります。
今回の私の場合はDNSサーバーだけ移行して、ドメインの移管は行わないことにしました。(※Cloudflareの方がドメインの更新料が安いそうなので、レジストラも移してしまった方がコストカットにはなります。)
Cloudflare側にDNSサーバーを建てる
今回の作業ではレジストラはAWSのままですが、DNSサーバーはCloudflareにします。そのため、移行にあたってはまずCloudflare側にDNSサーバを建てます。
この辺りのやり方については既に記事にされている方がいらっしゃるので、そちらを参照すると良いと思います。以下のDevelopersIOの大村さんの記事が参考になります。
ただ、このままだと私の記事の価値がないので、上記記事に載っていない情報を載せていこうと思います。
どういう経路でDNSクエリがCloudflare側に届くのか
CloudflareにDNSサーバーを建てたタイミングではまだこちらにDNSクエリは来ません。これはなぜかと言うと、例えば example.jp のネームサーバー(NS)の場所を知っている jp の権威DNSサーバーにはRoute53のネームサーバーが設定されているからです。以下はJPRSの再帰的問い合わせ（recursive query）の解説画像を引用したものです。
引用元: JPRS用語辞典｜再帰的問い合わせ（recursive query） https://jprs.jp/glossary/index.php?ID=0173
フルリゾルバはお使いのプロバイダから提供されているDNSだと思ってください。自分のPCから何らかのDNS問い合わせが行われる場合、そこにクエリが到達します。そこからフルリゾルバは (root) -> jp -> example.jp(※現状はまだRoute53) という順序で非再帰的問い合わせを行います。jp権威DNSサーバーが指しているのがRoute53だからまだCloudflare側にDNSクエリが来ないというわけです。
そして、これはRoute53のドメイン管理ページで切り替えることができます。
(以下の画像の例ではまだNSを切り替えていないので、Route53を指しています)
(以下の画像の例ではNSを切り替え済みなので、Cloudflareを指しています)
上位の権威サーバーの設定が変わったからNSを指す場所が変わってCloudflare側にDNSクエリが届くようになるというわけですね。
本当に設定が切り替わったのか？
上記で 上位の権威サーバーの設定が変わったから と言いましたが本当に正しいのか確認してみます。確認する方法は簡単で、フルリゾルバになったつもりでDNSクエリを発行してみれば良いです。より具体的には jp権威サーバーに対して、example.jpの場所(NS)を問い合わせる ということをすれば良いです。
実際に私が持っているのはjpではなく、comなのですが、以下のようにクエリを投げてみます。以下のクエリの意味は digコマンドでDNSクエリをa.gtld-servers.netというcomの権威DNSサーバーに問い合わせる。問い合わせレコードはfoo.comのNS というものです。
> dig @a.gtld-servers.net foo.com NS
(中略)
;; AUTHORITY SECTION:
foo.com. 172800 IN NS oswald.ns.cloudflare.com.
foo.com. 172800 IN NS treasure.ns.cloudflare.com.
(後略)(※実際にはfoo.comではなく別のドメインを持っています)
結果は上記の通りで、CloudflareのDNSを指す答えが返ってきました。これで権威サーバー側の設定が変わっていることが確認できました。
他にも確認方法はあります。Route53の場合、自動でCloudWatchと連携しているため、DNSクエリの数を可視化できます。
やり方は簡単で CloudWatch -> すべてのメトリクス -> Route53 -> ホステッドゾーンメトリクス -> (対象のホステッドゾーンを選択) で可視化できます。
※この画像の例では表示期間を1ヶ月、集計の期間を1日、統計を合計に変更しています。
特定のタイミングからDNSクエリが激減しているため、Cloudflare側にリクエストが行っていることが確認できます（Cloudflare側でも DNS -> Analytics から同じようなメトリクスは見れます）。
DNS移行はこれで終わりです。ドメイン移管の場合はもう少し作業が必要ですが。
性能比較
今回の移行の主目的はコストカットですが、副次効果でDNSクエリが速くなった、というものがあります。
様々な記事でAmazon Route53よりもCloudflareの方が速いという話を聞きます。結論としてはこれは事実ですが、自分の目で確かめてみることにします。
ちゃんと測るならばキャッシュに気をつけたり、 dnsperf や DNS Benchmark というツールを使うのが良いと思いますが、今回は簡易的にdigコマンドで済ませます。
また、DNSクエリは複数の権威サーバーにまたがって通信したり、フルリゾルバへ通信したりします。しかし、今検証したいのはRoute53 vs Cloudflareであり、フルリゾルバやTLD権威サーバーなどの影響は除外したいです。
digコマンドではフルリゾルバを迂回して対象の権威サーバーに直接問い合わせることができます。単純にCLI上で指定を増やすだけです(先程のコマンドとほぼ同じです)。
まずはその権威サーバーを特定する必要があるので、自身が持っているドメインに対してNSレコードを問い合わせます。
dig foo.com NS (※実際にはfoo.comは持っていません。)
これをAmazon Route53とCloudflareそれぞれに登録のあるドメインに対して行うと２つの権威サーバーを知ることができます(※私は現時点で両方にDNSサーバーを持っています)。これは設定等によって複数出てくることがありますが、例えばRoute53であれば ns-867.awsdns-44.net であったり、Cloudflareであれば treasure.ns.cloudflare.com であったりします。
これらの権威サーバーを指定しつつDNSクエリを投げてみます。結果は以下の通りです。(以下の例ではドメイン名を変えていますが、foo.netがRoute53でfoo.comがCloudflareです)
Route53
> dig @ns-867.awsdns-44.net foo.net
(中略)
;; Query time: 148 msec
(後略)Cloudflare
> dig @treasure.ns.cloudflare.com foo.com
(中略)
;; Query time: 28 msecRoute53が148msecに対してCloudflareが28msecという結果でした。これは大きな差です。WebアプリケーションやWebサイトを開発しているとどの程度ページが高速にロードできるかは気になります。LCPやFCPを気にしたりしますが、コンテンツをDLする前には必ずと言って良いほどDNSクエリが必要なので、そこで50msec以上高速化できるというのはなかなかに魅力的ですね(※DNS結果はキャッシュされるので毎回常にn msec遅くなるわけではない。そういう意味では重要度は高くないとも言える)。
今回はあえて手動で検証してみましたが、実はこれと同じようなことを自動でやってくれているサイトがあります。
How we measure DNS Performance All DNS providers are tested every minute from 200+ locations globally. All tests are over IPv4 with a 1-second timeout. The public data is updated once per hour, but contact us for real-time data.
おそらくdigコマンドではないでしょうが、200を超えるロケーションで常に計測してアップデートしてくれているようです。
実際にここを見ると Location: Asia でRoute53が 63.15ms 、Cloudflareが 32.47ms でした。DNSは速度だけで評価はできませんが、Cloudflareは速いことが分かりました。
今回はDNSに再入門しつつ、DNSサーバーを移行してみました。他にもまだ気になる点や疑問はあるので、また別の記事として書いてみたいと思います。
現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください！