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

2020年01月16日 木曜日


【この記事を書いた人】
其田 学

元ネットワークエンジニア、今はDNSやらk8sやらを触りながらコードを書く日々を送ってます。

「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往復必要になります。

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

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

1回目 2回目
UDP 200ms 200ms
DoT 600ms 200ms

1回目のクエリは、TLSのハンドシェイクが行われるため、DoTでのクエリへの応答は遅くなります。 この結果、アプリ側からは名前解決が失敗したと思われ、WEBページが表示できない等のトラブルが発生します。ただし、2回目のクエリではTLSのハンドシェイクが行われないため、DoTでもUDPと同じ速度となります。
つまり、一度セッションがつながってしまえば問題は無いのですが、しばらくスマホを使っていなくてセッションが切れた後に問題が起こるのです。例えば電車でスマホを取り出しWEBページを見ようとした時には名前解決に時間がかかり、エラーが表示されてしまいます。利用者がリロードボタンを押す頃にはDoTの接続が完了しているので、今度はすんなりとページが表示されます。しかし、これだとストレスを感じますよね。

DoTの接続を早くする機能は、いくつかあります。

  • TCP FastOpen
  • TLS セッション再開
  • TLS 1.3 0RTT

Android側の実装では、TCP FastOpenとTLS セッション再開がサポートされていて、TCP FastOpenは有効に動いています。ところが、TLS セッション再開の方はタイムアウトが短すぎるのか期待通りに機能しておらず、結局頻繁にTLSのネゴシエーションが行われることとなり、上記「1回目」レベルの遅延が多発する事態となりました。

この結果から、モバイル回線で利用するAndroidでは、DoTクライアントの実装がもうちょっとこなれないと実用は厳しいということがわかりました。
(ちなみに、このあとリリースされたAndroid 10でも状況が改善している気配はありません)

商用サービスはじめますが

と言うことで、プレスリリースの通りIIJの商用サービス(各種接続サービスで提供しているDNSキャッシュサーバ)でもDNS暗号化に対応することにしました。
ですが、モバイル接続サービス向けに提供しているDNSキャッシュサーバでは、DoHには対応しますがDoTでの問い合わせには対応しないことにしました。前述の通り、AndroidでのDoTの利用は現時点では実用的ではありません。しかし、Androidには「自動アップグレード」という機能があり、利用中のDNSサーバがDoTに対応していることを検出すると、自動的にDNSクエリをDoTで行うようになります。このため、モバイル接続サービス向けのDNSサーバでDoTを有効にすると、端末の挙動に支障が出てしまいます。

モバイル回線向けDNSサーバ モバイル回線以外向けDNSサーバ
DoT (DNS over TLS) 非対応 対応
DoH (DNS over HTTPS) 対応 対応

表1

モバイル回線でDoTを試してみたいという場合は、手動でIIJ Public DNSのサーバを設定してみてください。
なお、モバイル回線ではDoHでも同様の問題が起こることが予想されますが、現在AndroidではDoHをサポートしておらず自動アップグレードも行われないことから、接続の制限は行っていません。
まだまだDNS暗号化の技術は発展途中であり、今後は、DNS over HTTP(3), DNS over QUICなどのQUICベースのプロトコルが中心になっていくと思われます。
これらレイテンシの小さく、再接続が容易なプロトコルが中心になれば、モバイル回線でもDNS暗号化が実用になるかもしれません。

関連記事

其田 学

2020年01月16日 木曜日

元ネットワークエンジニア、今はDNSやらk8sやらを触りながらコードを書く日々を送ってます。

Related
関連記事