ユーザの近くにある偽DNSサーバの話

   このエントリをはてなブックマークに登録    2017/11/1-1

RIPE 75で、DNSへの問い合わせ内容によって、DNSパケットが通過するネットワークが変わってしまうという怪しい挙動の報告がありました。

この発表では、DNSのパケットが途中ネットワークで解析され、そのDNSパケットに含まれる内容に応じて、すぐ近くにある偽のDNS応答が返ってくることがあるというものでした。 DNSパケットを解析するDPI(Deep Packet Inspection)装置+偽DNS応答機能といった感じでしょうか。

発表者は、偽DNS応答がどこにあるのかを調べるために、DNSの問い合わせを用いたUDPによるtracerouteを実装しています。 偽DNS応答は、特定の名前に対するDNS queryに対してのみ発動するようなので、通常のtracerouteだと発見できないので、DNS queryのIPパケットのTTLを調整するtracerouteを作っています。


RIPE75発表資料より

dnstraceroute.pyの結果、ripe.netに対する問い合わせは、プライベートIPv4アドレス網を抜けてから、de-cix.fra.google.comを通過し、8.8.8.8へと到着しています。 DE-CIXは、ヨーロッパにあるIX(Internet eXchange)ですが、DE-CIXの拠点は、「Frankfurt, Hamburg, Munich, Dusseldorf, New York, and Istanbul」とあるので(参考)、おそらく、de-cix.fra.google.comは、DE-CIXのフランクフルト拠点でGoogleが運用しているルータであると思われます。

一方で、dnstraceroute.pyでのtwitterに対する名前解決の結果は、172.19.18.5というプライベートIPv4アドレスがつけられたルータの次のホップから、8.8.8.8として返って来ています。 AS外に抜けてなさそうなので、ISP内のネットワークであることが推測できます。

注意が必要なのは、実際は8.8.8.8であるかどうかは、この発表ではそこまで主要な論点ではない可能性も高いという点です。 この発表では、Google Public DNS(8.8.8.8)に対しての問い合わせにフォーカスしていますが、最後の質疑応答では、Google Public DNSではないDNSサーバに対する問い合わせに関しても、同様の挙動を示したとあります。

   このエントリをはてなブックマークに登録