DNS暗号化まわりについて雑に調査してみた件（前編）

DNS セキュリティ ネットワーク 技術 アドベントカレンダー2019

こんにちは

冒頭から不穏な画像ですみません。

この記事はちょっと文字が多くて長いので、結論だけ気になる人は最後の方に貼ってある調査結果のグラフあたりから読んでください！

BBSakura Networksの牧です。この記事は BBSakura Networksのアドベントカレンダー 20日目です。

私たちがいつもお世話になっているDNSですが、いまだにそのほとんどの通信が暗号化されていないため、冒頭の画像のようにどのサーバにアクセスしようとしたのかが誰からでもわかる危険性があります。
そのような現状から、近年DNS通信の暗号化手法がいくつか出現しはじめています。

しかし、暗号化と聞くとまず「ちりつもで通信が遅くなるのでは？」とか思いますし、DNSなんて一般ユーザからしたらどうでもいいものを、わざわざ暗号化なんて「めんどくさそう」とか思います。
なので、この調査では - ① DNSに暗号化をかけるとやはり遅くなるのか？ - ② 技術者でなくても簡単にDNSを暗号化できる方法はないか？

について雑に探ってみます！

今日の前編では、「① DNSに暗号化をかけるとやはり遅くなるのか？」について、DNS暗号化で名前解決のレイテンシを測定してみた結果をまとめます。

おことわり事項

  • 冒頭の画像は、実験目的で自分で生成したパケットをスニフィングしたものです。
  • この記事内では特定のサーバに対して大量にパケットを投げつけるような行為がありますが、健全な調査を目的とするものであり、すべてがnonadversarial（敵対を目的としない）のものです。

0. DNSの基本の仕組みを数行で

DNSコンテンツサーバはそのネットワーク内のDNSのボスで、ゾーン情報（そのネットワークにどんなドメインがあるのか）を管理しているサーバです。

一般的に、ユーザ端末（スマホなど）は DNSキャッシュサーバに対してDNSクエリを投げてサーバが持っているキャッシュからそのままDNS応答を得ます。
ですが、キャッシュなのでいつかはサーバから消えます（キャッシュのTTLはキャッシュサーバで任意に設定できる）。

その時にキャッシュサーバは、必要に応じて最新のレコードをコンテンツサーバに取りに行きます。

  • DNSキャッシュサーバ...ここではフルリゾルバ（リカーシブリゾルバ）の意味で使います。
  • DNSコンテンツサーバ...権威サーバとも言います。

1. (前座) DNS暗号化手法にはどんなものがある？

1.1. 冒頭ではしょった説明について

DNSの暗号化には、プライバシ保護を目的としないものと、プライバシ保護を目的とするものがあります。

「プライバシ保護を目的としないもの」は今から20年くらい前の1997年に RFC になっています。これは DNSSEC (RFC2065) です。

一方で、「プライバシ保護を目的とするもの」の方は最近いくつか手法が出てきており、 - DNS over TLS - DNS over DTLS - DNS over HTTPS - DNS over QUIC

などがあります。

冒頭では説明をはしょりましたが、この記事はこちらの「プライバシ保護を目的とするDNS暗号化」についてのものです。とくに DNS over TLS (DoT) について実験調査してみました。

1.2. 暗号化「DNSSEC」の用途

DNSSECは、コンテンツサーバへのDNSクエリに対する応答が 本当にちゃんとしたコンテンツサーバからの応答なのか？というのの検証のために存在します。
なりすましの返答じゃないよな？ということです。

また、暗号化するのはDNSのクエリ／応答の内容ではありません。差出人検証のために使う電子署名に暗号化を使っているよ〜ということなのです。つまり、プライバシの保護を目的としていません。

1.3. 暗号化「DNS over TLS」などの用途

一方で、こちらはプライバシの保護を目的としています。
どんなDNSレコードを問い合わせたのかはわからなくなります。つまり、DNSのクエリ／応答の内容をTLSなどで暗号化しているので、DNS通信の当事者以外は中身を見ることができません。

DNSSECとDNS over TLSはそれぞれ目的が違いますし、互いに独立した別々のメソッドです。なので、どちらが優れているとか劣っているということはなく、目的に合わせてそれぞれを選んだり組み合わせるというのが正しい使い方です。

2. (本題) レイテンシ測定＆比較

2.1. 実験内容＆条件

大雑把な測定です。 - 以下のパブリックな複数のリゾルバに対して、特定のドメイン・IP空間の名前解決を 正引き（ドメインからIPを得る）と逆引き（IPからドメインを得る）の両方で要求して比較しました。 - それぞれ DNS over TLS (DoT) と 従来の暗号化されていない平文(UDP) の両方で問い合わせました。Knot DNSプロジェクト による kdig というdigの拡張版みたいなツールを使いました。 - kdigでのTLS暗号化問い合わせは、毎回TLSハンドシェイクと切断が発生します。今回はこのハンドシェイクも含めたレイテンシ測定をしています。（厳密にいうとexecが走り始めてから応答を受け取るまでの時間を測定端末で測定しているので、測定端末内のオーバヘッドも含まれます） - 今回Wiresharkは見てません😫（pcapファイルが膨大になるので、、） - ハンドシェイクを除いた単純なクエリ時間についてはたぶん平文と一緒だと思って測定しませんでした（実装見たわけじゃないのにそう思う人） - 測定は日本国内のISPに接続された端末から実施しました。 - 確実にキャッシュを持っているときを測定したかったので、一回クエリを投げた後にキャッシュTTL以内に別プロセスで再度問い合わせをかけてそのレイテンシを計測しました

プロバイダ 対応タイプ IPアドレス フィルタリングの有無
Cloudflare DoT, DoH, UDP 1.1.1.1 なし
Google DoT, DoH, UDP 8.8.8.8 malicious domain
Quad9 DoT, DoH, UDP 9.9.9.9 malicious domain

※ malicious domain ... 既知の悪意あるドメインに関する問い合わせには応答しないという意味

2.2. レイテンシ測定結果と感想

2.2.1. レイテンシの表

正引き . . : 逆引き . .
リゾルバ 応答タイプ レイテンシ中央値 : リゾルバ 応答タイプ レイテンシ中央値
Cloudflare DoT 8.0 ms : Cloudflare DoT 91.5 ms
〃 UDP 36.5 ms : 〃 UDP 92.1 ms
Google DoT 87.8 ms : Google DoT 113.7 ms
〃 UDP 79.6 ms : 〃 UDP 117.6 ms
Quad9 DoT 251.7 ms : Quad9 DoT 118.7 ms
〃 UDP 222.1 ms : 〃 UDP 114.6 ms

2.2.2. レイテンシのヒストグラム

青色...DoT、オレンジ色...UDP
横軸...レイテンシ(ms)、縦軸...そのレイテンシで来た応答の数

  • 正引き（Cloudflare, Google, Quad9）

  • 逆引き（Cloudflare, Google, Quad9）

2.2.3. 感想

まず上の結果をみて あれっ？となりました。平文のUDPの方が暗号化のDoTより応答が遅いようにも見えます。。。
（2000クエリくらい連続で同じサーバに投げると10分くらいブロックされてタイムアウト時間内に応答が返ってこなくなったので、何回かやり直した😭🙏）

とはいえ、ロードバランシングされてると思うので、実際に名前解決してくれたサーバが地理的にどのくらい離れているのかとか、その辺にもよるのでなんともいえません。

また、測定した時間帯がバラバラだったりしたので、時間帯による影響もややあるかもしれません。（もしクエリかけたリゾルバがヨーロッパにあったとしたら、ヨーロッパが昼の時間帯にヨーロッパ人のアクセスが多いかもしれない）
（本当になんともいえない）

もしかしたらDoT用のサーバが別経路にあって、そちらがすいていたので応答が早かった、、などあるでしょうか。
正引き逆引きそれぞれだいたい8~14時間くらいかかりました。（クエリのクールダウンタイム含む）

※ DoTは2016年にRFCになったばかりで、DoTの提供はCloudflareが去年2018年に、Googleが今年2019年に開始したばかりです。

3. 各種DNS暗号化手法の違いと特徴

3.1. DNS over TLS

DNS over TLS はRFC7858で標準化されており、RFC2246で標準化されている TLS(Transport Layer Security) を使ったDNS通信の暗号化手法です。TLSは、公開鍵と電子署名を使った暗号化プロトコルです。デフォルトのポートは853番です。

3.2. DNS over DTLS

DNS over DTLS はRFC8094で標準化されており、RFC4347で標準化されている DTLS(Datagram Transport Layer Security) を使ったDNS通信の暗号化手法です。DTLSはTLSみたいなことをデータグラムでも実現できるプロトコルです（TLSがストリーム単位の暗号化であるのに対し、DTLSはデータグラム単位の暗号化）。デフォルトのポートは853番です。

3.3. DNS over HTTPS

DNS over HTTPS はRFC8484で標準化されており、ブラウザやOSを新たに設定する必要のないDNS通信の暗号化手法です（すばらしい！）。Googleは DNS over HTTPS のWebAPIを試験的に公開しています。さらにDNS通信をHTTPSでラッピングするため、外部からはそもそも他のHTTPS通信と区別することができません（DNS通信が流れていることすらわかりません）。デフォルトのポートは通常のHTTPSと同じ443番です。

以下のようにブラウザにURLを打ち込むと、答えがJSONで返ってきます。

https://dns.google.com/resolve?name=www.bbsakura.net&type=A

詳しくは こちら をチェック！

3.4. DNS over QUIC

DNS over QUIC はGoogleが試験的に開発している QUIC(Quick UDP Internet Connections) を使ったDNS通信の暗号化手法です。QUICはトランスポート層プロトコルです。QUIC はIETFのドラフトになっていますが、2019年時点でまだRFCにはなっていません.

3.5. DNSCrypt

DNSCrypt は上記の他のメソッドと同じくクエリのスニフィングやスプーフィングを防止することを目的としていて、DNSCrypt Projectで推進されています。しかし、DNS over TLS とは異なりパケットのパディングがないためパケット長は可変です。他のメソッドと同じようにクエリの完全性は保証しますが、プライバシの保護の観点はありません（パケット長から中身を推測する攻撃手法もある）。こちらも2019年時点でまだ標準化されていません。

まとめ

  • DoTとUDPでレイテンシを比較してみたが、ハンドシェイク含めてもそんなに変わらないかもしれない
  • 調査対象のリゾルバは、どれも2000クエリくらい連続で投げるとその後10分くらいブロックされるconfig入ってる
  • セキュリティ的に一番いいのは、DNSサーバ間を DNSSEC と DoX で暗号化してくれることです
  • 単純に平文DNSのパフォーマンス比較は こちら などにアクセスすれば見ることができます

ふろく

DNS暗号化普及率はどれくらい低い？

WEBでよく使われているHTTPSの普及率は、Googleのブログ によれば、Android, Windows, Macで70%前後（2017年）です。

DNSは 1987年にRFC1035で標準化されましたが、そこから今に到るまで暗号化通信の普及率は低いままです。
APNICのこの地図 を見ると、いにしえのDNSSEC（1997年にRFC2065で標準化）でさえ この記事を書いた時点(2019年末)の世界で普及率わずか 24% です（リンク先では常に値が変動してます）