More than 5 years have passed since last update.

Android 9 (Pie)からプライベートDNS機能が実装されているが、どうやらDNSoverTLSかDNSoverHTTPSのことを指しているらしい？

Last updated at 2019-07-12Posted at 2019-02-24

更新履歴

2019/07/12;
cloudflareが正式なDNSoverTLS/DNSoverHTTPSアプリケーションを発行していたのでiPhone/Android9以前で使ってみる部分を変更しました。また、暗号化して名前解決ができているか確認する手順を追加しました。

はじめに

私の愛用機（Xperia XZ Premium）にたまたま（必然的に）Android Pieが降ってきました。
そこで色々といじくり回していたところ、プライベートDNSなるものが...
[設定]>[ネットワークとインターネット]>[詳細設定]>[プライベートDNS]
...プライベートDNSってなんだ...

一般的なDNS名前解決

まずは当たり前であろう前提知識を書きます...
（MACアドレスは？とかいうツッコミ要りませんレイヤが下がるので今回は書きません）

コンピュータはTCP/IP プロトコル（人間でいう言語）を採用して通信しています。
IPアドレス（人間でいう住所）というものがコンピュータのNIC（ネットワークインタフェースカード：WiFiとか有線LANとか呼んでる部分）に割り当てられており、そのアドレスを指定して通信をしています。
そのIPアドレスはIPv4またはIPv6の2つが存在します、IPv6は今回無視します。
IPv4アドレスはxxx.xxx.xxx.xxxの4オクテット区切り10進数の32ビット。

...見てお判りかと思いますが**www.google.com**では**xxx.xxx.xxx.xxx**の10進数32ビットアドレスとして指定できません。＝通信できない。

じゃあどうやって10進数のxxx.xxx.xxx.xxx形式に変換してるの？

という疑問が出てきたらエクセレント。
やっとここでDNSが登場します。

DNSは、接続したいサーバの名前とIPアドレスを台帳として持っていてそれをリクエストが来たら回答するというサーバです。（超極端）

0.www.google.comに接続したいとする。

---------------------------------------------------------------

1. PCはDNSサーバに向かってUDPパケット(平文）のクエリを投げます。 

     www.google.comってどこ？
[PC]       >>[UDP]>>        [DNS]
　　　　　　　                  `-[www.google.com : 172.217.161.195]

---------------------------------------------------------------

2. DNSサーバは、それに対してレスポンスを返します（これもまた平文）
     172.217.161.195だよ！
[PC]       <<[UDP]<<        [DNS]
　　　　　　　                  `-[www.google.com : 172.217.161.195]

---------------------------------------------------------------

3. PCは目的のwww.google.comへアクセスできるようになります
(図はルーティングをガン無視してますが気にしないでください)

[PC]       <<<<        [DNS]
　| 　　　　              `-[www.google.com : 172.217.161.195]
  `-------[www.google.com]

このDNS設定はDHCPによって供給されているため、ユーザーが意図していないことが多い。
この仕組みで、おかしいなと思う部分が...

DNSへのリクエストは平文のUDPパケットである。

これです。
**HTTPSの通信で安全！**と思いきや残念...名前解決の時点で攻撃されてしまえばおしまいですね。
無料WiFiで通信する時をイメージしてみましょう。

0.www.google.comに接続したいとする。

[シナリオ上の設定]
  IP addr : 192.168.1.19
  subnet  : "今回は無視"
  DNS     : 192.168.1.1
  gateway : "インターネットの出口という認識で今回はOK、単にルータ"

---------------------------------------------------------------

1. PCはDNSサーバ(192.168.1.1)に向かってUDPパケット(平文）のクエリを投げます。 

     www.google.comってどこ？
[PC]       >>[UDP]>>        [DNS:192.168.1.1]
　　　　　　　                  `-[www.google.com : 172.217.161.195]

---------------------------------------------------------------

2. DNSサーバ(192.168.1.1)は、それに対してレスポンスを返します（これもまた平文）
     172.217.161.195だよ！
[PC]       <<[UDP]<<        [DNS:192.168.1.1]
　　　　　　　                  `-[www.google.com : 172.217.161.195]

---------------------------------------------------------------

3. それでは...攻撃者が居たとして、同じIPアドレスのDNSを立てて攻撃用サーバのIPを設定していると？


                       [DNS:192.168.1.1]
　  　　　　              `-[www.google.com : 172.217.161.195]
[PC]       >>>>> 
                       [DNS:192.168.1.1]
　  　　　　              `-[www.google.com : 10.2.0.15] 

...そうです、もし正しいDNSより攻撃者のDNSの応答が早かった場合
利用者は、めでたく攻撃サーバに接続してしまうことになりますね...恐ろしや。
正しいDNSサーバの後ろに攻撃者のDNSが権威DNS（親DNSサーバ）として割り込んだ場合も同じく危険。

Q.HTTPSは安全じゃないの？

A. 安全ですが、しっかり目視で認証局情報などを見て起きましょう。意図していないサーバに繋がっている場合もあります。

Q.HTTPSって暗号化してるんじゃないの？

A. 確かに暗号化していますが、名前解決の時点で違うサーバに飛んだら意味無し（今はブラウザ側が対応してるのか）。

...上記の恐ろしい事態を回避するために生まれたのが

DNSSEC(親DNSから子DNSサーバ)
- UDPパケット
- DNSSECはデジタル署名をDNSデータに追加します。
- DNSのクライアントが、DNSクエリへの応答として返される情報が、権威サーバーで保持されている情報の正確で忠実なコピーであることを保証する。
DNSoverTLS(子DNSサーバからPC)
- UDPパケット
- クエリ内容をTLSにより保護する
- 次へのホップ情報は保護されないため、問い合わせたDNSサーバがどこかはわかる。
- 経路上の他のDNSで攻撃者が書き換えた場合、不正な応答としてリジェクトできる。
DNSoverHTTPS(子DNSサーバからPC)
- TCPパケット
- クエリ自体HTTPSパケットとして外部のDNSにリクエストする
- DNSサーバ側の実装がDNSoverTLSより容易
- 外部DNSを使わせないプロバイダ（学校や会社）などでも効果がある。