DNSを変更するとネットワークは速くなるか

はじめに

あえてどことは言いませんが、先日某サイトで「ネット速度を高速化する方法」としてDNSサーバの設定をpublic DNSサービスに変更する記事が出てました。その記事の結論としては「変更しても大差ない」というものでしたが、DNSでネットワークを高速化するというこのような記事は何年も前からときどき見かけます。いい機会なので、このあたりについてもう少し深く掘り下げて考えてみましょう。

※この記事では、とくに明示しなければDNSサーバとはキャッシュDNSサーバ(フルサービスリゾルバ)を指すものとします。

DNS応答の速さ

DNSの設定を変えることによりネットワークの速度が速くなるとすれば、(1)DNSそれ自体の応答が速くなるか、(2)その後のWebアクセスが速くなるか、のどちらか(または両方でしょう)。このそれぞれについて検討してみましょう。

前者が速くなると画像やJavascriptなどの小さな部品がたくさんのサイトに分散して置かれているようなWebサイトで、後者が速くなるとファイルのダウンロードなど大きなコンテンツを取得するような場合に改善を期待できます。それが体感できるほどのものかどうかはともかくとして。

まずは、DNS自体の応答時間に影響を与える要因から。

DNSサーバの性能

影響しません。

DNSは非常に軽いプロトコルなので、どんなしょぼいサーバでもDNSのクエリを受け取って応答を返すまでの時間は1ミリ秒もかかりません。DNSSEC検証のようなよけいな仕事をしたとしても誤差の範囲です^(※1)。サーバを運用するにあたって性能はもちろん重要なファクターですが、重視されるのは1秒あたりで数万以上にもなる大量のクエリをいかに効率よくさばくかという点です。他の要素による遅延に比べると個々のクエリに対する応答時間は十分に小さく、ここの性能が改善しても効果はほとんどありません。

キャッシュヒット

ほとんど影響しません。

DNSサーバは得られた結果をキャッシュして、同じ問い合わせが来たらそれを再利用します。キャッシュにヒットすれば高速な応答を得られますが、ヒットせず権威DNSサーバに情報を取りにいくことになると、めちゃくちゃ時間がかかってしまいます。

ということは、たくさんのユーザが使っている大規模なDNSサーバを使うように変更すればキャッシュにヒットしやすくて応答が速くなりそうですね。しかし実際のところ、ある程度のユーザが使っているDNSサーバならばヒット率は飽和し、ユーザが増えてもそれほど変化しません。ということで、ヒット率は応答時間に大きな影響を与えますが、ISPが提供するDNSサーバを利用しているのであれば、大手でも中小でもほとんど同じ程度のヒット率であり、たいした差にはなりません。超マイナーなサイトのキャッシュの有無にもしかしたら違いがあるかも、という程度ですね。もちろん、極端にユーザの少ないDNSサーバ(たとえば自分の家族だけしか使わない自宅DNSサーバなど)であれば明確な差が出るでしょう。

DNSサーバまでの距離

DNSの応答時間はほとんど距離で決定されます。

みなさんご存知のとおり、光は非常に遅いです。光ファイバ中の光速は真空中の光速の約2/3ほど、だいたい20万km/sしかありません^(※2)。たとえば、東京-福岡間の距離がだいたい1000km、往復で2000kmありますので、福岡から東京のDNSサーバに問い合わせて応答が返ってくるまでに最低でも10ミリ秒かかります。東京-アメリカ西海岸なら往復で2万km、100ミリ秒にもなります。経路上の機器による遅延もあるので、実際には1000kmあれば10ミリ秒ではなくもっとかかりますが、それらの機器の性能が向上したとしても物理法則に由来する制約より速くなることはありません^(※3)。

速いDNSサーバを求めるなら間違っても遠いところにあるDNSサーバに変更してはいけません。できるだけ距離が近いところにあるサーバを使う(もしくはDNSサーバの近所に引っ越す)ようにしましょう。また、サーバまでの距離はユーザによって異なります。あるユーザがたまたまそのDNSサーバの近所に住んでいて速かったとしても、他のユーザにも同じように速いとはかぎりません。「ここのDNSサーバ速いよ！」という話を聞いて真似してもあまり意味がないということです。

なお、ここでいう距離とは、ネットワーク的なホップ数ではなく、もちろん直線距離でもなく、パケットが通る実際の経路に沿った距離です。福岡の人が運よく地元福岡にDNSサーバを見つけてそこに設定したとしても、実際の経路は片道で福岡-大阪-福岡となることもあり、どのサーバが「近所」なのかを判別するのは簡単ではありません。そもそもサーバの物理的な設置場所が公表されることはほとんどありません。そんなわけで、近いサーバが速いのは事実としても、それを選択基準にするのは現実的には難しいです。

トランスポートプロトコル

影響します。

通常、DNSは下位トランスポートプロトコルとしてUDPを使います。しかしそれ以外にもTCPを使うこともでき、さらに近年ではTCP上のTLSやHTTP/2、UDP上でQUICやHTTP/3もあるという、他のプロトコルにない多様な下位トランスポートを使うプロトコルになってしまいました。どのトランスポートを使うかによって、その特性により応答時間に違いが出てきます。

UDPでのDNSは、クライアントとサーバがお互いにひとつずつ問い合わせと応答のパケットを送っておしまい、という極めて簡潔なものです。一方、TCPはセッションの確立のために3 way handshakeと呼ばれる手続きが必要です。DNS over HTTPS/TLSはTCPのハンドシェイクの後にさらにTLSのハンドシェイクも必要です。名前解決できるようになるまでの準備段階だけでパケットが何往復もすることになるのです。query pipeliningだのTCP fast openだのTLS session resumptionだのTLS1.3 0-RTTだのといった、高速化するためのさまざまな工夫もありますが(それぞれの詳細はここでは説明しません)、それらを駆使してどんなにがんばっても、最初の1往復で名前解決が終わってしまうUDPのDNSより速くなることはありません。

とはいえ、DNSサーバを変えても、トランスポートプロトコルが変わらなければ、差はありません。

しかし、場合によってはDNSサーバの設定変更によりトランスポートプロトコルも変更されることがあります。Chromeでは大手のpublic DNSを利用する設定になっていると、自動的にトランスポートがHTTPSに変更されます。また、一部のpublic DNSサービスはDDRに対応しており、macOS/iOSでは自動的にTLSやHTTPSに変更されることがあります。詳しくはDNS over HTTPS/TLS (DoH/DoT)の設定方法の記事を参照してください。

ということで、public DNSを利用するようにしていると、トランスポートも意図せず変更されて遅くなることがあるので注意しましょう。

Webアクセスの速さ

さて、DNSはそれ自体が目的ではなく、Webアクセスに必要な情報を得るための手段にすぎません。次の問題は、DNSサーバを変更すると、その後のWebアクセスの速さが変化することはあるのか、です。

結論から先にいうと、多くのWebサイトはDNSサーバを変更してもWebアクセスに変化はありません。しかし、一部については変わるものもあります。

一例を挙げます。朝日新聞(www.asahi.com)にアクセスすることを考えます。

まずは、ふつうにwww.asahi.comに10回アクセスし、その平均の速度を出してみます。キモいワンライナーなのは無視してください。

% yes 'curl -s -w "%{speed_download}\n" -o /dev/null https://www.asahi.com' | head -10 | sh | paste -sd+ - | bc -e 'read()/10'
1204116

だいたい1.2Mbpsぐらいですかね。

DNSサーバを変えて同じことをやってみます^(※4)。

% yes 'curl -s -w "%{speed_download}\n" -o /dev/null --dns-servers 101.101.101.101 https://www.asahi.com' | head -10 | sh | paste -sd+ - | bc -e 'read()/10'
721372

700kbpsぐらいにまで落ちてしまいました。

なぜこんなことが起きるのか。DNSサーバからの応答を見れば一目瞭然です。

% dig +noall +ans www.asahi.com
www.asahi.com.           377    IN      CNAME   wildcard.asahi.com.edgekey.net.
wildcard.asahi.com.edgekey.net. 2017 IN CNAME   e10474.b.akamaiedge.net.
e10474.b.akamaiedge.net.  14    IN      A       23.51.136.227
% dig +noall +ans www.asahi.com @101.101.101.101
www.asahi.com.          1469    IN      CNAME   wildcard.asahi.com.edgekey.net.
wildcard.asahi.com.edgekey.net. 5902 IN CNAME   e10474.b.akamaiedge.net.
e10474.b.akamaiedge.net.  20    IN      A       23.11.91.49

DNSサーバから返ってきたIPアドレスが異なっています。異なるWebサーバにアクセスするから、速度も変わるのです。

CDNのしくみ

1000km離れたところへのアクセスは最低でも往復10ミリ秒かかるというのは、DNSサーバだけでなくWebサーバも例外ではありません。前述したように、物理法則に由来する制約なので、これ以上の高速化はできません。応答を速くするにはユーザがサーバに近いところにいなければならないのです。かといって、ユーザは気軽に引っ越すわけにもいきません。ではどうするか。サーバの方がユーザの近所に引っ越せばいいのです。

CDN (content delivery network)はこの考えのもと、世界中の主だった都市にサーバを設置し、その都市や近傍に住むユーザからのアクセスをそこに集め、それ以外の地域に住むユーザに対しては、それぞれのユーザの近所に設置したサーバにアクセスを誘導します。世界中にたくさんのサーバを設置することで負荷を分散し、近くに設置することで応答時間を小さくするというのが、CDNのおおまかなしくみです。

これを実現するための方法は大きくわけて2つあります。ひとつは同じIPアドレスのWebサーバを世界中に設置し、どのWebサーバにアクセスさせるかを経路ルーティングで制御するAnycast方式。もうひとつは、異なるIPアドレスのWebサーバを世界中に設置し、権威DNSサーバがユーザに近いところにあるWebサーバのIPアドレスを答えるDNS方式。どのCDN事業者もおおむねこのどちらか(または両方のハイブリッド)で運用されています。

CDNを使っていない場合や、Anycast方式によるCDNの場合は、どのDNSサーバを使っても得られる情報に違いはなく、同じWebサーバにアクセスすることになります。DNSサーバを変えることでWebアクセスに差が出ることはありません。

一方、DNS方式によるCDNでは、権威DNSサーバは問い合わせ元に応じてWebサーバのIPアドレスを変化させて答えます。しかし、ユーザは権威DNSサーバに直接問い合わせるわけではなく、キャッシュDNSサーバに問い合わせ、そのキャッシュDNSサーバが権威DNSサーバに問い合わせます。権威DNSサーバからはユーザが実際にどこにいるのかはわからず、キャッシュDNSサーバのIPアドレスによってユーザのいる場所を推定します^(※5)。

DNS方式を採用している代表的なCDN事業者がAkamaiで、上の例で挙げたasahi.comはAkamaiを利用しています。また、この例で使った101.101.101.101というDNSサーバは、台湾のTWNICが運営するQuad101というpublic DNSサービスです。つまり、このDNSサーバを使うと、Akamaiの権威サーバは「ユーザは台湾にいるんだな」と判断して、台湾からもっとも近いところ(おそらく台湾島内)にあるAkamaiのサーバにアクセスを誘導しようとするのです。結果として、日本からは遠くなってしまってアクセスも時間がかかることになってしまいます。

このように、ユーザのいる地域を権威DNSで推測してもっとも近くのWebサーバにアクセスを誘導するタイプのCDNの場合、DNSサーバを変更することでWebアクセスにかかる時間が変わることがあります(かならず変わるわけではありません)。ユーザはCDN事業者の権威DNSサーバに直接問い合わせるわけではないため、権威DNSサーバからはキャッシュDNSサーバのIPアドレスしかわかりませんが、多くの場合キャッシュDNSサーバごとに最適な応答を返すため、そのISPで提供されるDNSサーバをそのまま使うのが最速で、それ以外のDNSサーバを使うように変更するとかえって遅くなります。むやみに変更するのは逆効果ということです^(※6)。

まとめ

速度以外に重要な点として、変更しようとしているDNSサーバはそもそも使っていいものなのかどうか、という問題があります。public DNSサービスとして広く利用を解放しているもの以外のDNSサーバは、仮にアクセス制限されていなかったとしても、アクセス制限が漏れていたなど本来使えてはいけないはずと考えるべきであり、利用するには不適当です。

そして、広く利用を解放しているpublic DNSサービスを使うように設定すると、トランスポートがUDPではなくHTTPSに変更されてDNSの応答時間が大きくなったり、CDNサービスが最適なWebサーバに誘導できなくなったりで、速度的なメリットがあることはほとんどありません。つまり、ISPによって自動で設定されるDNSサーバをそのまま使うのが多くの場合もっとも速いです。

---