DNSリークの判定方法
VPNのサイトでは、よくDNSリークというワードを見かける。自分が名前解決に設定しているDNSサーバーと、リーク判定に用いるWebサイトのサーバーとは別なはずなのに、何故判定できるのか、その仕組みについて調べてみた。
DNSとは
知っていれば、必要ない項目だけど、何となく導入として。コミックで説明しているサイトも参考になる。
DNSとは、Domain Name Systemのことで、ネットの通信に必要なIPアドレス(53.14.333.383など)を人間が扱いやすいドメイン(example.comなど)に置き換えて管理する仕組み。
DNSの発想としては電話番号が近い気がする。電話番号が電子的にデータベース化される前は、電話番号を語呂合わせで覚えていた。それは、人が数字を覚えるのが苦手だからだ。しかし、語呂合わせを用いれば、(0120)-489-444は、“予約しようよ”1で劇団四季の電話番号だとすぐ覚えられる。電話番号の領域だけでなく、インターネット(IPアドレス)の領域でもこの語呂合わせ(置き換え)の仕組みが利用されている。
必要な情報が202.247.61.250だとしても人間には扱いにくい。置き換えの発想を用いると、shiki.jpとなる。劇団四季のWebサイトなのだが、数字よりは簡単に覚えられる。この「202.247.61.250は、shiki.jpですよ」という置き換えを管理する仕組みがDNSとなる。そこで管理されるデータベースが、電話番号の場合は電話帳だが、IPアドレスの場合はDNSレコードとなる。IPアドレスの場合、世界全体が対象なので、電話番号のように個人や企業で勝手に置き換えをしてデーターベースを作成しても共有できない。そのため、DNSレコードを標準化し、管理する団体や、細かい仕組みというのが存在する。
昔は、PCにホストファイルをダウンロードしてドメイン(ホスト)の管理をしていたらしいが、ドメインの数も以前とは違うので、今はDNSが主流だ。ただ、ホストファイル(/etc/hostsなど)に記述があればDNSより優先されるようだ。
名前解決に使用されたDNSサーバーの判定方法
本題に入る。DNSサーバーには、大別すると2つある。
- DNSキャッシュサーバー(フルサービスリゾルバや、Recursive Resolver2)
- 権威サーバー(コンテンツサーバー)
通例、クライアントからキャッシュサーバーに名前解決のリクエストをして、最終的に、実際に管理している権威サーバーまで辿り着く。そこでリクエストに対応するIPアドレスがクライアントに返される。
この時、権威サーバーを自前で用意することで、アクセスしてきたキャッシュサーバーのIPをログできる。WebページにアクセスしてきたVPNサーバーのIPと、名前解決に利用されたキャッシュサーバーのIPを比較し、異なっていればリーク判定となる。
UIDを付加するとリクエストを強制できる
ただ、キャッシュサーバーというのはその名の通り、レスポンスをTTLが有効である限りキャッシュしているので、タイミングによっては新たに権威サーバーにリクエストをすることはない。そこで、UIDとしてハッシュみたいなランダムなものをサブドメインとして付け加えリクエストを強制させる。そうすることで、使用しているキャッシュサーバーのIPをUIDとともにログできる。
例えば、名前解決させたいドメインがtest.dnsleaktest.comの場合、特にオープンリゾルバの場合だと利用者が他にも大勢いるため、キャッシュされている可能性がある。ところが、a0e4651af6b14311ab917.test.dnsleaktest.comとすれば、キャッシュされているわけもないので、キャッシュサーバーは名前解決をせざるを得ない。
DNS leak testで試すと、権威サーバー(ns1.dnsleaktest.comやns2.dnsleaktest.com)から、Aレコードが返ってきた。ただ、Mullvadの場合は、NXDOMAINとして返ってくるので、実際に存在するドメインでなくてもいいようだ。DNSキャッシュポイズニングの手法と同じ感じで、権威サーバーへのリクエストさえ飛べば良いということなのだろう。
数字にはいろいろ発音がある。そのままの発音にすると、489(よん、やっつ、きゅう)、444(し、よん、よん)となるが、それをナチュラルな文法に修正して、予約しようよ(よ、や、く、し、よう、よ)になる。数字の置き換えの発想を感じるには、語呂合わせジェネレーターが役立つかも知れないが、桁が増えると、こじつけ感は増す。 ↩︎
クライアント目線ではrecursive、キャッシュサーバー目線ではiterative ↩︎