DNS over TLS/HTTPSについて考える

はじめに

昨年から DNS over TLS （DoT）、DNS over HTTPS （DoH） にまつわる動きが急速に活発になっています。

DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 （9.9.9.9）、昨年4月開始の Cloudflare （1.1.1.1）が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS （8.8.8.8） も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。

DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Firefox では6月から DoH のベータテストが開始され、正式版も8月にリリースされました。10月には Android 用 DoH クライアント Intra のリリース、Quad9 の DoH サポートが続き、そして同月ついに正式に DoH の仕様が標準化されました（RFC8484） 。Google Public DNS は現時点で公式には DoH に対応していませんが^（※1）、DoH の実験 URL はすでに誰でもアクセスできる状態になっており、正式にアナウンスされるのも時間の問題でしょう。

従来の DNS にかわって、とくにセキュリティやプライバシーを改善するものとして期待されている DoT/DoH ですが、ほんとうに安全になるんでしょうか？

DNS の仕組み

DoT/DoH について考える前に、従来の DNS の仕組みについて本稿の理解に必要な最低限度で説明します。詳しくは他の解説を参照してください。

DNS サーバは2種類あります。権威サーバとキャッシュサーバです^（※2）。

権威サーバは DNS に登録される情報の原本を保持する DNS サーバです。ルートサーバや TLD の権威サーバ、そして各ドメインの権威サーバと階層化されており、それぞれの権威サーバは自分が担当するドメインに関する問い合わせにのみ答えます。

キャッシュサーバはユーザからの問い合わせを受け付ける DNS サーバです。自分自身では原本を持たず、かわりにどの権威サーバが原本を持っているかを調べ、そこに問い合わせて得た結果をユーザに返します。また、そうして得た結果を一定時間保持（キャッシュ）し、同じ問い合わせが来た場合はそれを再利用します。

従来の DNS は下位プロトコルとして主に UDP を利用します（TCP も使えますが限られたケースになります）。UDP は TCP と異なり信頼性を確保する仕組みがありませんが、仕組みが簡単で遅延が小さいという長所もあります。DoT/DoH はこのうちクライアントとキャッシュサーバの間で使われる DNS の問い合わせについて、下位プロトコルを UDP から HTTPS ないしは TCP 上の TLS に変えるものです^（※3）。キャッシュサーバと権威サーバの間の通信はこれまでと変わりありません。

DoT/DoH は安全なのか

DoT も DoH も、安全性の担保は TLS に依拠しています。ご存知のように HTTPS ならびに TLS はインターネットのさまざまな部分で使われており、これが安全でないとしたらその影響は DoT/DoH だけでなくインターネット全体に及ぶため、さまざまな検証がおこなわれています。たまに脆弱性が見つかることはありますが微修正で済む程度のものであり、TLS そのものが否定されるほどの問題が見つかることは今後もまずないでしょう。

その TLS をベースにした DoT/DoH と従来の DNS、どちらがより安全かというなら、もちろん長々と論じるまでもなく DoT/DoH に軍配が上がります。しかし、「より安全である」ということは「絶対に安全である」を意味するわけではありません。

TLS はおおまかに以下の3つの機能を提供します。

• 通信相手が正しいことの確認
• 通信経路上で第三者に盗聴されないこと
• 通信経路上で第三者に改竄されないこと

多くの場合、これで十分安全に通信がおこなえます。しかしながら、重要な機能が抜け落ちています。それは「通信内容が正しいことの確認」はできないということです。TLS は通信経路を保護するものであって、通信経路に乗る前の改竄は検知できません。TLS による安全な通信路を改竄されたコンテンツが堂々と通り抜けられるのです。

そして、DoT/DoH はユーザとキャッシュサーバの間で利用されるということを注意しておく必要があります。キャッシュサーバはあくまでキャッシュを保持しているだけであり、自身でコンテンツを持っているわけではありません。コンテンツは他のサーバ（権威サーバ）から取得する必要があります。そしてキャッシュサーバと権威サーバの間の通信は TLS による保護はなく、従来の DNS が使われます（改竄に弱い UDP が主です）。権威サーバとキャッシュサーバの間の経路で改竄されてしまうと、ユーザとキャッシュサーバの間が DoT/DoH で暗号化されていたとしても、改竄された情報が TLS による安全な経路を通ってユーザのもとに届くことになります。ユーザとキャッシュサーバの間を改竄して影響を受けるのはそのユーザひとりですが、権威サーバとキャッシュサーバの間を改竄するとそのキャッシュサーバを使っている全ユーザが影響を受けます。攻撃する側にとっては後者の方が効率がよく狙いやすいため、むしろこちらを守る方の優先度を上げるべきでしょう。

いちおう、キャッシュサーバ-権威サーバ間における改竄を検知する技術はもう何年も前から実用化されており、やろうと思えばすぐにでも使える状態になっていますが、残念ながら普及度は非常に低いのが現状です（世界的に見ても日本はかなり低い）。DNSSEC っていうんですけどね。DNSSEC は TLS と異なり通信経路は保護しませんが、通信内容を保護します。

キャッシュと権威の間の経路を DNSSEC ではなく DoT/DoH で保護することは可能でしょうか。プロトコルとしては同じ DNS です。できないはずがありません。実際、先日 Cloudflare（キャッシュサーバ）と Facebook（権威サーバ）との間を DoT にする実験がおこなわれました。が、だからといって「みんなもやろう」というわけにはいきません。権威サーバが DoT/DoH に対応したとしても、それをキャッシュサーバに知らせる方法がないからです。Facebook と Cloudflare による実験はそれぞれの担当者が協議の上で個別設定を投入したようですが、そこから「みんなもやろう」という段階に進むためには、いちいち個別に設定するのではなく権威サーバが DoT/DoH に対応していることを知らせる/見つける仕組みが必要になります。仮にこの仕組みをこれから実装するのであれば、DoT/DoH に対応してるかどうかという情報自体を悪意の第三者に改竄されないよう保護する必要があります。なぜなら、ほんとは DoT/DoH に対応済みなのに、対応していないという嘘の情報を注入できてしまうと、せっかくの DoT/DoH が使われずに従来の DNS が使われることになってしまうからです。じゃ、どうやって改竄を防ぐんでしょうか？ DoT/DoH に対応してるかどうかの情報を DoT/DoH/DNSSEC を使わずに改竄から保護する方法があるのなら、同じ方法でそれ以外の情報も保護したほうが手っ取り早くないですか？

キャッシュサーバと権威サーバの間の経路上での改竄だけでなく、キャッシュサーバ自身により改竄される場合もあります。昨年は海賊版ブロッキングに関する話題が大きく注目されましたが、それを実現する手法のひとつである DNS ブロッキングはキャッシュサーバ自身による改竄にほかなりません。これは通信経路に情報が乗せられる前の段階でおこなわれるため、通信経路を保護する TLS で防ぐことはできません。

また、改竄しないまでも、キャッシュサーバの運用者はユーザがどのような情報を欲しているかを知ることができます（TLS、DNSSEC の利用有無にかかわらず）。この情報を集めてたとえばターゲティング広告の判断材料に利用したり、情報をほかの事業者に売ったりすることも（法的・道徳的な問題はともかくとして技術的には）可能です。TLS は通信経路上の第三者からの盗聴・改竄を防ぐことはできますが、第三者ではなく通信相手自身が通信内容を利用したり書き換えたりすることを防ぐものではないことは十分理解しておく必要があります。

そのため、どこかの public DNS が「うちは DoT/DoH が使えるから安全だよ」という謳い文句でユーザを集めていたとしても、そういった書き換えや利用をおこなっているのかどうかはユーザが見極める必要があります。たとえば、Quad9 では malicious domain blocking、すなわちマルウェアなどが設置されているドメインの名前解決を強制的に失敗させるという「改竄」をおこなっています。そして、このブロッキングを実施するために、ユーザから収集した情報を（ユーザを特定できない形に集計した上で）セキュリティ事業者に提供しています（https://www.quad9.net/policy/）。もちろん、悪意をもってやってるわけではないでしょうし、このポリシーを理解して許容できるのであればユーザにとってはマルウェア感染の危険が小さくなってむしろ安心かもしれませんが、このポリシーを許容するかどうかはユーザが個々に判断しなくてはなりません。Quad9 はポリシーがちゃんと明示されていますが、ポリシーが明らかでない場合、あるいは公表されているポリシーに嘘がないと判断できない場合に、「DoT/DoH だから安全だね」とみなしてしまっていいのかどうかはよく考える必要があるでしょう。

なお、DoH では認証をパスしたユーザだけに利用させるなどの用途を想定してか、HTTP cookie （およびその他フィンガープリント情報）の利用は明確には禁止されておらず、「明らかに必要な場合でなければ使うべきではない（SHOULD NOT）」との記述に留まっています（RFC8484）。そのため、HTTPS のレイヤにおけるユーザトラッキングが理論上は可能です。DoT においても、TLS セッションを追跡することである程度は可能でしょう。クライアントの IPアドレスぐらいしかユーザを特定する情報がなかった（NAT の背後に複数のユーザがいると区別できない）従来の DNS と比べて、サーバ側が得られる情報はだいぶ増えています。

こうして見ていくと、DoT/DoH で安全になるといっても、改竄されていない正しい情報が得られる保証はまったくなく、あくまでユーザとキャッシュサーバの間の狭い区間での盗聴・改竄を防げるだけでしかないことがわかります。DNS という仕組み全体からするとそのうちのごく一部でしかありません。もちろん、それすらもできない従来の DNS に比べれば安全性は向上するといえるのですが…。

従来の DNS は安全でないのか

ところで、ユーザからキャッシュサーバまでの間の通信経路はそんなに簡単に第三者の介入を許してしまう脆弱なものなのでしょうか。

まず、いちばん単純な例として、ISP が提供するキャッシュサーバをその ISP のユーザが利用する場合を考えます。この場合、ユーザ宅内のホームルータからキャッシュサーバまでの通信経路はすべてその ISP の提供するネットワーク内になります。ISP の網内で完結した通信に外部の第三者が介入するのは困難なので、平文であっても盗聴・改竄される可能性はきわめて低くなります^（※4）。仮にそれを容易に許すような ISP なのであれば、DNS 以前にあらゆる通信が信頼できず、そもそもそのような ISP 自体を使うべきではありません。

一方、public DNS などのISP が提供しているのとは異なるキャッシュサーバを利用する場合、ユーザの契約する ISP の網内で通信が完結せず、複数の ISP を経由して通信が成立します。この経路には様々な思惑の人物が入り込む可能性があり、また、経路がハイジャックされる事件もときどき発生しているため、第三者による盗聴・改竄の危険性は高くなります。ISP がブロッキング回避に使われる public DNS の IP アドレスを経路ハイジャックして乗っ取るなどという事例が起きたこともあり^（※5）、public DNS を使うことはむしろこういった攻撃の標的にされやすくなるとも言えるでしょう。DoT/DoH の仕様・実装がなかった数年前ならともかく、出揃いつつある現在では public DNS を平文 DNS で利用するのはできるだけ避けるべきです。

つまり、わざわざユーザが設定変更して public DNS を使おうとするからこそ暗号化しないと危険なのであって、おしきせの ISP のキャッシュサーバを使うのであれば通信路は暗号化されていなくてももともと安全性が低いわけではなく、暗号化による恩恵はそれほど大きくないのです。

public DNS はユーザが契約している ISP 回線の向こう側で他者の設備を経由しますが、手前にも ISP のものではない設備が存在する場合があります。つまり、ユーザ宅内の Wi-Fi 区間や、NTT フレッツマンションタイプにおける建物内共用設備などです。暗号化されていない Wi-Fi や、設備室（MDF室）がふだん施錠されてないようなマンションは危険ですが、そんなずさんな管理でなければ大きな問題になる可能性は低いでしょう。ただし、ホームルータの脆弱性によりキャッシュサーバの設定が外部から書き換えられてしまう事例^（※6）もあり、まったくリスクがないわけではありません。

公衆 Wi-Fi やホテルの客室内回線を利用するケースは、…えーと、長くなるので「公衆wifi 安全性」とかのキーワードで検索して見つかる記事を読んでください。全部が全部危険だとは思いませんが、安全だと自信をもてる場合以外は使わないのが無難だと思います。DoT/DoH であれば安全でない公衆 Wi-Fi であっても DNS を盗聴・改竄される危険性は減りますが、DNS だけが安全になったところで他も安全でなければ意味がありません。

また、そもそも DNS の通信を暗号化する意味があるのかという問題があります。DNS は名前解決して終わりではなく、ほとんどの場合名前解決された IP アドレスに対する通信がその直後に発生します（これこそが主目的です）。第三者が DNS を盗聴できるのであれば DNS の後に続く通信も当然盗聴できると想定すべきであり、DNS 後の通信を盗聴できれば直前の DNS のやり取りは見なくてもどんなものだったのか推測は可能です。もちろん、DNS の改竄は不正なサイトへ誘導されることになるので防がねばなりませんが、少なくとも盗聴に関してそこまでシビアに考えたところで益はあまり大きくありません。

ISP のキャッシュサーバは DoT/DoH に対応すべきなのか

以上見てきたように、DoT/DoH により従来の DNS より安全になる部分はあるものの、盗聴・改竄される危険性がなくなったわけではありません。public DNS を利用するのであれば積極的に DoT/DoH を利用するべきですが、ISP のキャッシュサーバは暗号化されていなくても十分に安全であり、DoT/DoH を使っても安全性はそれほど大きくは向上しません。

その一方で、同じ機器を自宅で使ったり持ち出して外出先で使ったりすることは珍しくなく、そのそれぞれで DNS の設定をいちいち切り替えるのは非常に面倒です。また、ISP の回線を使って ISP のキャッシュサーバを使っているような場合でも、その手前のユーザ宅内の Wi-Fi にパスワードがかかっていなかったりするようなよろしくない状態を DoT/DoH ならわずかに改善できることになります（DNS だけ対策してもあまり意味ないので大きくは改善しません）。

古墳時代にはリモートアクセスに telnet や rsh などの平文で通信するツールが使われていましたが、現在では第三者の介入が困難な組織内に完結した通信の場合であっても ssh で暗号化するのが常識になりました。DNS の場合も、ISP 内で閉じていて平文で十分安全だから DoT/DoH はいらない、というわけではなく、わずかながらでも安全性が向上するのであればそれを否定するべきではありませんし、安全なネットワークかどうかをいちいち判断して平文 DNS と DoT/DoH を使い分けるより、どんな環境でも暗号化すると決めてしまったほうが手間を省けてシンプルになります。

このような意味で、ISP のキャッシュサーバが DoT/DoH に対応する意義がまったくないわけではありません。IIJ でも DoT/DoH についてこれまで検討・検証を続けてきましたが、このたび次の検証フェイズに入ることになりました。

ということで、長い長い前置きでしたが、それでは本題です。3行しかありませんが。

IIJ Public DNSサービス（ベータ版）のお知らせ

IIJ で DoT/DoH を実験サービスとして提供することになりました。しかも、public DNS として IIJ ユーザ以外の方もお使いいただけます。
マルウェア対策のための DNS フィルタリングが一部で物議をかもしていますが、この実験サービスではおこないません（でも児童ポルノはブロッキングします）。
詳細なプライバシーポリシーやその他提供条件については https://public.dns.iij.jp/ を参照してください。