オープンリゾルバサービスから権威サーバへの通信に関する簡易調査
目次
はじめに
とある DNS のオープンリゾルバサービスを利用していて、某グローバルなサービスのドメイン名の名前解決を行った際、海外のエッジと思われるIPアドレスが返ってくることがありました。 その某グローバルなサービスは、どうやら IP Anycast を利用せずに DNS で最寄りのエッジのIPアドレスを返すようにしているようでした。
海外のエッジにアクセスすることになると伝搬遅延が50～100ミリ秒程度はかかるため、そのグローバルサービスの動作が非常に遅くなってしまいます。
オープンリゾルバサービスと某グローバルなサービスのどちらが悪いのかはわかりませんが、原因を少しでも解明するために、オープンリゾルバサービスが行う権威サーバとの間の通信内容について調査してみました。
調査内容
調査対象
以下の4つのオープンリゾルバサービスを調査しました。
- 8.8.8.8 (Google Public DNS)
- 1.1.1.1 (Cloudflare)
- 9.9.9.9 (Quad9)
- 208.67.222.222 (OpenDNS)
これらサービスは IP Anycast で提供されていますので、私の自宅からクエリを送信した際は東京近郊にあるデータセンターで処理されることでしょう。
参考として、自宅回線から参照可能なNTT東日本のフルリゾルバにもクエリを送信しましたので、後述の結果にも含めています。
調査項目
調査した項目は次の通りです。
- どのIPアドレスから権威サーバに問い合わせが来るか
- そのIPアドレスの実体はどこの国にあるか
多くの場合、権威サーバは問い合わせ元のIPアドレスや遅延をもとに広域負荷分散しているでしょうから、問い合わせ元のIPアドレスや国を確認しました。
調査方法
独自ドメインのサブドメインの権威サーバを Amazon EC2 上に用意し、自宅からオープンリゾルバサービスにクエリを送信し、権威サーバのクエリログやパケットキャプチャをもとにIPアドレスを調査しました。 クエリ名を分けることで、どのオープンリゾルバサービスから来た通信か特定しています。
なお、リソースレコードの TTL を5秒とし、ほぼ10秒の間隔でクエリを送信することで、毎回権威サーバに問い合わせが来るようにしました。
IPアドレスから国を判定する部分は、IPinfo を利用しました。 IPinfo の結果が100％正しいというわけではないと思いますが、現実的にはその結果を信じるのがベストな方法のはずです。
調査結果
①権威サーバを Amazon EC2 東京リージョンに用意した場合
まず、権威サーバを Amazon EC2 の東京リージョンに用意し、権威サーバには IPv4 でのみアクセスできるようにしました。
各オープンリゾルバサービスにクエリを759回送信したときの結果は次の通りです。
| オープンリゾルバサービス | 問い合わせ元IPアドレスの個数 | 国（都市） |
|---|---|---|
| 8.8.8.8 (Google Public DNS) | 90個 | 日本（東京） |
| 1.1.1.1 (Cloudflare) | 19個 | 日本（東京） |
| 9.9.9.9 (Quad9) | 3個 | 日本（東京） |
| 208.67.222.222 (OpenDNS) | 21個 | 日本（東京） |
| 参考：NTT東日本のフルリゾルバ | 19個 | 日本（大阪） |
※問い合わせ元のIPアドレスは多数観測されたため、記載を省略しています。
問い合わせ元IPアドレスは複数の範囲から来たりしていましたが、IPinfo で見ると全て日本のIPアドレスと判定されていました。 オープンリゾルバサービスの東京のエッジから東京の権威サーバに問い合わせに行くパターンなので、期待通りの結果です。
②権威サーバを Amazon EC2 バージニアリージョンに用意した場合
次に、権威サーバを Amazon EC2 のバージニアリージョンに用意しました。 引き続き、権威サーバには IPv4 でのみアクセスできるようにしています。
各オープンリゾルバサービスにクエリを455回送信したときの結果は次の通りです。
| オープンリゾルバサービス | 問い合わせ元IPアドレスの個数 | 国（都市） |
|---|---|---|
| 8.8.8.8 (Google Public DNS) | 88個 | 日本（東京） |
| 1.1.1.1 (Cloudflare) | 18個 | 日本（東京） |
| 9.9.9.9 (Quad9) | 3個 | 日本（東京） |
| 208.67.222.222 (OpenDNS) | 21個 | 日本（東京） |
| 参考：NTT東日本のフルリゾルバ | 19個 | 日本（大阪） |
問い合わせ元IPアドレスは①で観測できたものの中に含まれており、全て日本のIPアドレスとなっていました。 クエリを送信した回数が少ないため、8.8.8.8 と 1.1.1.1 では観測されなかったものもありますが、同一のプールのアドレスが利用されているようでした。
冒頭に記載した問題の原因として、オープンリゾルバサービスのバックボーン経由で海外の出口から海外の権威サーバにアクセスしているのではないかと推測したのですが、どうやらこの可能性は否定できそうです。
③権威サーバに IPv6 でアクセスさせた場合
今度は、権威サーバに IPv6 でのみアクセスできるようにしてみました。 用意した場所は Amazon EC2 の東京リージョンです。
各オープンリゾルバサービスにクエリを550回送信したときの結果は次の通りです。
| オープンリゾルバサービス | 問い合わせ元IPアドレスの個数 | 国（都市） |
|---|---|---|
| 8.8.8.8 (Google Public DNS) | 90個 | 日本（東京） |
| 1.1.1.1 (Cloudflare) | 19個 | 日本（東京） |
| 9.9.9.9 (Quad9) | 3個 | 日本（東京） |
| 208.67.222.222 (OpenDNS) | 21個 | 日本（東京） |
| 参考：NTT東日本のフルリゾルバ | 19個 | 日本（大阪） |
問い合わせ元のIPv6アドレスも全て日本のIPアドレスと判定されていました。 IPv6アドレスだから国判定がおかしくなったという可能性も否定できそうです。
考察
調査結果から、オープンリゾルバサービスは日本のIPアドレスを用いて権威サーバに問い合わせしていることがわかりました。 そのため、冒頭の問題の原因がオープンリゾルバサービス側にあるとは言えないと考えています。
むしろ、某グローバルなサービスが何らかの問題を抱えていて、日本からのアクセスに適さないIPアドレスを返してしまっていると考えるのが妥当のように思います。 IPアドレス選択のロジックが公開されていないため詳細はわからないものの、IPアドレスやその国（都市）以外の情報の影響で問題が生じたか、あるいは国判定そのものが誤ってしまっているか、そんなところでしょうか。
このサービスが入り口のドメイン名だけでも IP Anycast で提供してくれれば良いのですが、敢えて Anycast をやめたといった記述が公式ドキュメントに記載されていましたので、解決は期待できなそうです。
冒頭の問題は本記事で記載したオープンリゾルバサービスの1つだけで起きるため、そのリゾルバを利用しないようにすれば回避できるものの、あるべき姿ではないですね。
その他気付いたこと
Google Public DNS がクエリ名の一部をランダムに大文字にしている
Google Public DNS から来るクエリ名は、一部がランダムに大文字になっていました。
"test0.test20260627.ymstmsys.jp" という名前でクエリを送信したら、権威サーバには "TesT0.test20260627.YMsTmSYS.jp" や "TESt0.TeSt20260627.yMsTmsyS.JP" のような名前のクエリが来ていました。
自前で立てた権威サーバをインターネットに公開するのは今回が初めてだったので、0x20 ビットのランダム化を実際に見たのも初めてでした。
参考 : Security Benefits | Public DNS | Google for Developers
Google Public DNS は ECS オプションを利用している
Google Public DNS から来るパケットには、RFC 7871 の EDNS Client Subnet オプションが付加されていました。 当然その値は私の自宅のIPアドレスに関するもので、第4オクテットが0にマスクされた /24 プレフィックスのアドレスとなっていました。
これを良いと考えるか悪いと考えるかは判断が困るところではありますが、プライバシーを重視するなら Google Public DNS ではなく Cloudflare や回線・ISP事業者が提供するリゾルバを使うべきですね。
Quad9 は不必要なAレコードのクエリを送信している
調査の③のケースではAAAAレコードのクエリを送信していたのですが、Quad9 からは同じ名前のAレコードのクエリも来ていました。
先読みのクエリなのか実験目的なのかわかりませんが、不要なクエリは投げないで欲しいものです。
NTT東日本のフルリゾルバは TTL を正しく考慮していない
今回用意したリソースレコードの TTL は5秒としたので、自宅から10秒間隔でクエリを送信すると、毎回フルリゾルバから権威サーバにクエリが送信されてくる想定でした。
現に4つのオープンリゾルバサービスはいずれも想定通りの動作をしたものの、NTT東日本のフルリゾルバはなぜか80%程度しかクエリが送信されて来ないという結果でした。
クライアントが TTL を無視するならともかく、エンドユーザに提供するフルリゾルバが TTL を正しく考慮しないのは望ましくないものと思います。