読者です 読者をやめる 読者になる 読者になる

DNS キャシュを止めた

Ubuntu DNS

どういった変化が起きるのかを把握するため,まずは5年ほど前に行われた12.04での変更を思い出す必要があります。

12.04以前のUbuntuでは,古典的なLinux環境と同じように,「1)DNSサーバーの設定は/etc/resolv.confファイルを編集して行う」「2)名前解決の結果はキャッシュされず,毎回問い合わせる必要がある」という2つのルールに縛られていました。

12.04ではNetworkManager経由でdnsmasqを起動し,ローカルレゾルバとして動作させる修正が取り込まれています。この修正で,このうち1)のルールが破棄され,/etc/resolv.confはresolvconfパッケージによって自動的に設定されるものになりました。しかし,dnsmasqによるキャッシュ機能はさまざまな問題を含み,有効にはなっていません。名前解決の結果を単純にキャッシュさせると,複数ユーザーが利用している環境では悪意あるユーザーによって,他のユーザーの名前解決の結果が簡単に汚染されてしまいます。名前解決の結果を汚染できるということは,偽のサイトへ簡単に誘導できてしまうことを意味します(注1)。

注1
もちろん,そのような悪意を持ったユーザーが同じシステムを利用している時点で他にもさまざまな危険があるのですが,それはまた別の話です。

また,DNSキャッシュを複数のユーザーで共有するという実装には,「あるFQDNがキャッシュされているかどうか」が他のユーザーから観測できることを意味します。特定のドメイン名を解決した際の速度から,他のユーザーがどのようなWebサイトを見ているかを推定することが可能になるおそれがあります(注2)。

注2
「gihyo.jp」を例に考えてみましょう。2名のユーザーが存在するシステムにおいて,「ユーザーAがgihyo.jpを見ているかどうか」をユーザーBが推定したいとします。この場合,ユーザーBは一定時間ごとにgihyo.jpの名前解決を試み,解決にかかった時間を計測しているだけで,「gihyo.jpの名前解決結果がすでにキャッシュされているかどうか」を識別できます。システムの持つ名前解決結果のキャッシュ時間にも依存しますが,もしユーザーAがgihyo.jpを閲覧していた場合,「gihyo.jpの名前解決結果がなぜかキャッシュされている瞬間」を観測できる可能性があります。gihyo.jpであれば特に問題はありませんが,これが人に知られたくないような恥ずかしいWebサイトであった場合,ユーザーBはユーザーAの恥ずかしい秘密を知ることができたことになります。

こうした問題を回避するためにはUIDごとにキャッシュを分離するような実装が必要ですが,12.04時代から継続して問題が残っており,いまだに有効になっていません。

少なくとも12.04当時には十分な妥当性があったこの実装ですが,上述のような問題が残っている上,「DesktopやTouchとServerでは設定や挙動が異なる」という,ユーザー体験を大きく阻害する別の問題を発生させていました。また,Serverにローカルレゾルバが動作していないことで,「そのIPアドレスの逆引きを試みるとDNSサーバがタイムアウトするような回線」(注3)からSSH接続すると,接続のたびに毎回長時間待たされるという,不具合にも似た不可避の挙動をもたらしていました。

注3
そのアドレスの権威DNSサーバーが十分な速度でNXDOMAIN応答を返すのであれば問題ないものの,世の中には「応答を返してくれない権威DNSサーバー」というものが無数に存在しています。この問題は,特に逆引きの場合に顕著です。


ソ−ス:
2016年6月3日号 DNSレゾルバに関する大きな変更ふたたび・UWN#467:Ubuntu Weekly Topics|gihyo.jp … 技術評論社

を読んでDNS キャシュを止めた。


DNS キャッシュのテスト
ルックアップの速度をテストするには、dnsmasq を起動してから訪れたことのないウェブサイトを選択し

$ dig archlinux.org | grep "Query time"