IIJのDNS暗号化への取り組み

はじめに

ネットワーククラウド本部の其田です。今回はIIJのDNS暗号化への取り組みを紹介します。
この記事で紹介するのは、本日プレスリリースした「IIJ、接続サービスで提供するDNSのセキュリティを強化」の中の、DNSキャッシュサーバとお客様の間の通信(DoT/DoH)に該当します。

取り組みのきっかけ

IIJでのDNS暗号化の取り組みは2018年からスタートしています。
当時本命とされたDNS over TLS(DoT)は2016年にRFC化されているので、ちょっと遅いスタートだったかもしれません。DoTやDoH(DNS over HTTPS)が対象とする、フルリゾルバ(DNSキャッシュサーバ)～スタブリゾルバ(パソコンやスマホの中に組み込まれているDNS問い合わせ機能)の間の通信は、ISPの契約者がISPが用意したDNSキャッシュサーバを使う限りはインターネットを通過せず、特定のISPの中で通信が完結します。このため、フルリゾルバ～スタブリゾルバ間の通信路上で盗聴、改ざんが起こる可能性が極めて低く、DoT/DoH対応にあまり興味を引かなかったというのが実態です。

しかし、2018年を境に大きく環境が変化しました。
一つは、Android 9でのDoT対応です。しかもデフォルトで有効化した状態で市販の端末に搭載されました。これにより、一般のユーザが特に意識することなくDNS暗号化を使用できるようになります。IIJmioをはじめとしたモバイル回線のお客様を多く抱えるIIJでは、今後Android端末の更新でDoTが使える端末が増加することが予測されます。そこで、手始めにDoT＋Android 9の検証を行うことにしました。

二つ目は、FirefoxのDoH対応です。FirefoxではDoHの機能はデフォルトでは無効にされていますが、DoHのサーバとしてCloudflareのDNSサービスを使うような設定があらかじめ登録されています。また、2019年に向けてFirefoxがDoHの機能をデフォルトで有効化する方向だとの発表がありました。これが実行されると、それまでISPのDNSキャッシュサーバに流れていたDNSクエリが、利用者が把握しないままCloudflareに流れることになります。こうした方針には反対する意見も多数ありました。

IIJとしても、DNSクエリが意図せず国外のサービスに流出するのは如何なものだろうかという意識もありました。また、DNSクエリが自動的に国外へ流れるということは、日本独自で行っている児童ポルノブロッキングがブラウザの標準状態で回避されてしまうことを意味します。DNSベースの児童ポルノブロッキングの意味が薄まるようなブラウザが広汎に流通するようでは、さらに強力な手法を使ってブロッキングを行うべきではという議論を誘発しかねません。

児童ポルノブロッキングについて (一般社団法人インターネットコンテンツセーフティ協会)

そこで、 日本もちゃんとDNS暗号化に取り組んでいる、日本にもDNS暗号化に対応したサービスがあるのだから、勝手に国外のサービスをデフォルトにするなというメッセージを出す必要があると考えました。

IIJ Public DNSサービス（ベータ）

DoT/DoHサーバについて検証は行っていますが、実際にトラフィックを流してみないとわからないこともあります。そこで作ったのがIIJ Public DNSサービスです。

IIJ、「DNS over TLS」、「DNS over HTTPS」を利用したDNSの試験サービス「IIJ Public DNSサービス（ベータ版）」を提供開始

このIIJ Public DNSではサーバ・ソフトウェア構成の検証や、負荷試験などを行いました。
DoT・DoHはそれぞれ別々のソフトウェアで構成されています。DoTはLVS + Unboundの構成です。

DoHはLVS + Nginx + doh-proxy + Unboundの構成です。

DNS over TLSと遅延

Public DNSをリリースすると、モバイル回線＋Android 9でDoTがうまく使えないという報告が続々と寄せられました。
当初はサーバ側を疑い考えられる対策を追加しました。

• フルリゾルバのキャッシュが暖まっていないので暖めるクエリを流す
  • 長期間運用してるDNSキャッシュサーバには、キャッシュに多数のDNSレコード情報があり、高速にクエリに応えることが出来ます。IIJ Public DNSでは新規にキャッシュサーバを立ち上げたため、このようなキャッシュがなく、クエリへの反応が鈍くなる傾向があります。このため、他のDNSサーバで採取しておいたクエリ情報を元に、あらかじめ頻出するクエリを実行しておき、キャッシュにある程度の情報を保存させておくという方法です。(エンジンの暖機運転になぞらえ「キャッシュを暖めておく」と言っています)
•  TLSセッション再開機能
  • 当初Unboundの実装にはTLSの再接続機能が実装されておらず、DNSクエリのたびに重い(時間がかかる)TLSのハンドシェイクが実行されていました。そこで、IIJでTLSの再接続機能を実装し、ハンドシェイクの発生を最小限に抑えるようにしました
• TLS暗号化アルゴリズムの変更
  • 通信の遅延を少なくするため、処理の軽い暗号化アルゴリズムを選択しています。これも、当初のUnboundでは変更が不可能だったため、IIJ側でソースコードを変更し、実現しています

しかし、サーバ側の設定を調整しても状況が改善しません。最終的にたどり着いた原因はネットワークの遅延でした。
従来のUDPパケットのDNSが、1往復の通信で完結するのに対し、DoTはTLS(TCP)を利用するため、クエリの完了までに４往復必要になります。

固定回線のように遅延が少ない環境であれば、4往復というのはあまり問題にはなりません。しかし、遅延の大きい無線区間のあるモバイル回線ではこれが致命的になります。

次の表はモバイル回線から、各プロトコルで連続で2回クエリを実行し、応答遅延を測定した結果です。