日本からipv4only.arpaへの名前解決が大量に送られてるっぽい

一番下に追記あり

ipv4only.arpa への名前解決

Cloudflareの1.1.1.1を使ったドメインランキングを眺めていたら人気でないはずのドメインが日本国内ランキングで上位に。

ipv4only.arpaへの名前解決が大量に。

Image

https://radar.cloudflare.com/domains/domain/ipv4only.arpa

https://radar.cloudflare.com/domains/jp

51位にあった amazon.co.jp より高い位置に。

確実にネットワーク機器か何かソフトウェアが行っているDNS。(ランキング上位はそのようなものがどっちみち多いが)

でも日本だけ多いのがとても不思議。

ipv4only arpaの名前解決をそんなに大量にするってどんな状況だろうか?

ipv4only arpaのAAAAクエリの名前解決はDNS64 (及びNAT64) がネットワークにあるか探す行為。

datatracker.ietf.org

追記:(言葉足らずではてブで説明してくださってる方がいた)

日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ

前提・自明として書かれてないけど、ipv4only.arpa.は文字通りipv4のみのAレコード192.0.0.170と171、これをAAAAで聞きに行った返答内容(なしと返るか、返るにしてもどんな合成ipv6が返るか)をみてDNS64対応状況をみるんだね。

2023/09/30 09:51

b.hatena.ne.jp

Chromeに昔これを使ってNAT64配下でのCLAT機能を実装した。

momoka0122y.hatenablog.com

ipv4only arpaのAAAAクエリの名前解決はDNS64 (及びNAT64) がネットワークにあるか探す行為。  
それをしてるソフトウェアかネットワーク機器が日本から大量の名前解決をしてそう。

しかしなぜこんなに大量なんだろうか。

上のChromeにNAT64配下でのCLAT機能を実装したときはまず、IPv4ソケットは作れないけどIPv6ソケットは作れるという状況のときのみ機能が発動するようにした。(そしてIPv6オンリーであることは稀なので大量の名前解決は起きないようにしてある(無駄なので)。

このDNSクエリを投げているソフトウェア、ネットワーク機器を見つけたいですね。

昔ipv4only arpaへの名前解決をtcpdumpか何かで見かけたことある気がする。(気がするだけかも)

関連してそうだけどあまり情報を得られなかったリンク先

Sudden jump in requests to ‘ipv4only.arpa’ from iPhone and Apple Watch : dns

 

以下色々追記: (反応ありがたいです)

 

 

日本国内から多いってことはIPv6オンリー環境からたくさん問い合わせが起きているのだろうという予想していた。↓の人と同じく。

日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ

ドコモが2022年からIPv6シングルスタックを提供していることと関係ある???

2023/09/30 10:45

b.hatena.ne.jp

 

しかしその条件は必要条件ではなさそうだった。

 

 

いろんなところでipv4only arpa へのクエリがたくさん観測されている。

それならなぜ日本でこんなに多いのだろうか?

日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ

Cloudflareだけなのか、他のPublic DNSでも同じなのか気になる。日本国内とするとアイオーとかエレコム

2023/09/30 10:05

b.hatena.ne.jp

Public DNS で観測されたというのが個人的に結構驚きポイント。 IPv6only環境ならDNS64がISPによって用意されて(用意されていなくても)そのISPのリゾルバを使うようにネットワーク設定がされていることが多い気がする。

ISPがリゾルバ用意していなくてPublic DNSを使わせているのも全然ありえるけど。

↑考えてみれば上の驚きポイントはIPv6onlyというネットワーク前提が必要だと思っていたけど、他の人がdual stackでもクエリを見つけていたので、別にPublic DNSに聞いているのはそんなに不思議でもない。

Google Public DNS64  |  Google for Developers

Public DNS64 一覧 - Qiita

 

まとめると、

「日本でのみ(台湾も多い)ipv4only.arpa のDNS問い合わせが多い」かつ「でもIPv6onlyでなくても観測される」のが不思議。

日本が特別な理由がわからない。

モバイルのみとかならわかるんだけど。

it.srad.jp

追記:

まだmacOSでしか検証できていないですが、LINEの可能性がとても高い。

LINEを停めている状態でtcpdumpしてinterface up down してもなにも見つけれなかったが、LINEを起動している状態でtcpdumpしてinterface up downしたら見事ipv4only.arpaの名前解決が発見された。そしてこれが日本と台湾で多い理由もLINEと説明がつく。

(LINEを起動した瞬間の`tcpdump udp port 53`の結果。ipv4only.arpa がLINE関連のドメインに挟まれている)

JANOGの資料に日本と台湾でLINEのIPv6対応の話がされていた。

「LINE」をIPv4/IPv6 Dual Stack環境に変更した話

日本と台湾で多いことの説明がつく。(そして逆にタイとインドネシアがランクインしていないことも説明つく)

ここでLINEが大量のipv4only.arpaの名前解決をしていると仮定してなぜしているか以下の理由が想像できる。

  • LINEアプリ内部でNAT64プレフィックスを知りたい理由がある。
    • つまりDNS64を活用できない(DNSに登録されていない)ハードコーディングされたIPv4アドレスがある。
    • それにパケットを送るためにCLATの実装がされていて、NAT64prefix::宛先IPv4アドレス というIPv6アドレスへパケットを投げたい。
    • しかし、このクエリはIPv4オンリーの環境でもdual stackの環境でも観測された。CLATがしたいならIPv6-onlyのときのみ行えば良いのではないだろうか?
  • NAT64プレフィックスを使うわけではないけど、NAT64があるのか知りたい。
    • 上と同じく、このクエリはIPv4オンリーの環境でもdual stackの環境でも観測された。CLATがしたいならIPv6-onlyのときのみ行えば良いのではないだろうか?

うーん。

一番目の場合ならDNS使えないのかと思うのと、

そもそもIPv6 socketしか作成できないかどうかの確認を事前に行えば本当に必要だった時のみクエリを出せるからその確認をしないのがよくわからない。ネットワーク的にIPv6-onlyだたっとしてもOSのCLATの機能によりアプリケーション目線ではdual-stackに見えることはよくあると思うので。

LINEのアプリケーション側でIPv6対応した時にどのような設定をいれたのかとても気になります。👀

(もしLINE関係なく観測ミスだった場合は大変申し訳ございません)

docs.google.com

追記2:

JANOGで発表した後のコメントから。

確かに、考えてみればP2Pするなら、アドレス直書きする必要があった。完全に見落としていた。恥ずかしい。