DNSルートサーバへのアクセスのうち、45.80%はChromiumの検索仕様による無駄な通信だった 37
ストーリー by nagazou
もしかして 部門より
もしかして 部門より
VerisignのCSO Applied Research部門の主任エンジニアであるMatthew Thomas氏は、APNICのブログで、DNSルートサーバーのトラフィックの半数は、Chromium系ブラウザから出ている大量のクエリが原因であると指摘する（APNIC、ZDNet）。
Chromiumには初期の頃から、ユーザーがウェブサイト名、URL、または検索語を入力できるアドレスバーの機能が存在していた。しかしアドレスバーには、入力された単語を検索語として扱うのか、URLとして扱うのかといったインターフェースとして問題があるという。通常は「marketing」と打ち込めば検索語として扱われる。しかし「もしかして http:// marketing」というようにURLではないかとして判断する挙動を見せるときも多い。
この原因はChromiumがネットワークを信頼しているかどうかにあるという。DNSサーバーが傍受されないDNS応答を返さない場合、すべての検索語で「もしかして」という情報バーが表示されてしまうこともある。Chromiumベースのブラウザは、7〜15文字からなる3つのドメイン名をランダムに呼び出してテストし、2つのドメインの応答が同じIPを返した場合のみブラウザは、ネットワークが存在しないドメイン要求をキャプチャして、リダイレクトを行っていると考えられるという。
同氏の調査では、2020年5月13日の総トラフィックの45.80％は、Chromiumプローブからのトラフィックであるように見えるとしている。ルートサーバーのDNSトラフィックの半分が単一のブラウザをサポートするためだけに使用されているのではないかと指摘している。
Chromiumには初期の頃から、ユーザーがウェブサイト名、URL、または検索語を入力できるアドレスバーの機能が存在していた。しかしアドレスバーには、入力された単語を検索語として扱うのか、URLとして扱うのかといったインターフェースとして問題があるという。通常は「marketing」と打ち込めば検索語として扱われる。しかし「もしかして http:// marketing」というようにURLではないかとして判断する挙動を見せるときも多い。
この原因はChromiumがネットワークを信頼しているかどうかにあるという。DNSサーバーが傍受されないDNS応答を返さない場合、すべての検索語で「もしかして」という情報バーが表示されてしまうこともある。Chromiumベースのブラウザは、7〜15文字からなる3つのドメイン名をランダムに呼び出してテストし、2つのドメインの応答が同じIPを返した場合のみブラウザは、ネットワークが存在しないドメイン要求をキャプチャして、リダイレクトを行っていると考えられるという。
同氏の調査では、2020年5月13日の総トラフィックの45.80％は、Chromiumプローブからのトラフィックであるように見えるとしている。ルートサーバーのDNSトラフィックの半分が単一のブラウザをサポートするためだけに使用されているのではないかと指摘している。
これって (スコア:5, 興味深い)
DNSに検索ワードが漏れてない？
Re:これって (スコア:1)
漏れてる、といえるんじゃないかな。
日本語の検索キーワードもどれだけDNSに流されているのか...
Re:これって (スコア:1)
なるほど
GoogleがDNSサーバーとして8.8.8.8を提供しているのはそういうことか
Re: (スコア:0)
表向き、アドレスバーで使用される検索エンジンを変えれる設定があるが、google以外にしても拾えるってことなの？
アドレスバーで検索キーワード入力するようにしたのは、その為なの？
googleって、他にも、androidは、bletoothオンにするのにgps有効にしないといけないのかが、わからないんだけど、
これもなにか裏あるの？
Re: (スコア:0)
> bletoothオンにするのにgps有効にしないといけない
アプリがBTを使うには位置情報権限も必要って話とごっちゃじゃない？
BTデバイススキャンはWiFiのSDIDスキャンと同様に簡易な位置情報源になり得るので、
位置情報権限が無いアプリにはスキャンも許可できないと言うだけの話かと。
権限与えれば別にGPSはoffでも問題なく動く。
Re: (スコア:0)
CloudflareのDNSはプライバシー保護も売りにしてますね。
若干目的が違いますがQuad9も同じような感じ。
Re: (スコア:0)
そりゃお金になるから無償提供するわけで
NTPサーバとかLinuxリポジトリとかは本物の慈善団体じゃないと公開しないっしょ
でも利用する側にとっては困ることでもないし、嫌なら使わなきゃいいだけだわな
Re: (スコア:0)
> DNSに検索ワードが漏れてない？
漏れてるし、逆も言えて、
URLを直接入力してるつもりが、検索キーワードの自動補完機能のために
そのURLが検索エンジンに漏れるパターンもあるってことですね。
なので自分はURLバーに検索機能を持たせるのは嫌いで
Firefoxを「keyword.enabled: false」設定で使ってます。
検索はURLバーじゃなくて検索ボックスの方を使います。
Re: (スコア:0)
DNSに検索ワードが漏れてない？
DNSに関してはそんなことはないかと。
元記事に書いてあるコードを読む限り、
ランダムな文字列を3回問い合わせることでDNSサーバーが健全かどうか調べてから
「もしかして : `http://hoge`」と表示しているようなので。
Re: (スコア:0)
まあでも、「『誰が』このワードで検索をかけているのか」ということまで伝わっていなければ、別にいいんじゃね？
バカをサポートするためにリソースの半分が消費される (スコア:1)
どこでも見られる光景じゃないの？
バカを支えるコストは膨大だけど、だからバカは死ねと言ってよいのかって話
Re: (スコア:0)
NTPのアレと構図は一緒ですな
まだ、ハードコートされたやつでないぶんマシかも知れないが
# 解消する当てはあるのだろうか
Re: (スコア:0)
無数のバカなら仕方ないが、今回やらかしてるのはGoogle一社じゃないの。
Re: (スコア:0)
バカが多くて疲れません？
#エー○イ
DNSにもUser-Agent的な項目を入れろよ (スコア:0)
そうすれば、不良クライアントがすぐに判明する
Re: (スコア:0)
通信量が増えるだけでは
Re: (スコア:0)
DNS-over-HTTPSを普及させよ、と？
Re: (スコア:0)
そんなもん今更誰が従うんだよ
Re: (スコア:0)
判明したところでどうする？
Re: (スコア:0)
どうせ今度もまた偽装しまくりで、信頼おけなくなるに一票。
前回の失敗から学習しない人っているんだよね。
Re: (スコア:0)
プライバシーの時代に逆行する
DNSキャッシュがランダム文字列でいっぱい (スコア:0)
なにごとかと思って調べたら犯人はChromeだった
Re: (スコア:0)
いいえ違います。
Chromium系ブラウザの問題でChromeに限った問題ではありません。
と、G社が言いそうな気も…
Re:DNSキャッシュがランダム文字列でいっぱい (スコア:2)
G社はリソースは使い倒す主義だから。
DNSルートサーバーのトラフィック半数はびっくりですが。
Re: (スコア:0)
DNSがヘッポコなのが問題。DNSルートサーバーは弊社が管理するようになれば問題解決、とか言い出しそう。
Re: (スコア:0)
そもそもNXDOMAINをNXDOMAINじゃない応答するDNSがいなければ
Re: (スコア:0)
レジストラがやってる
このドメインは現在販売されております。
ご連絡先:~~~
みたいなのは同じIPを返してきそうですね。
この場合TDLが偶然ダブルとルートサーバにいっちゃいますね。
或いは従業員がサボった時用に社内DMSからhentai.xxxみたいなのにアクセスしたら会社のホームページにリダイレクトみたいな。
Re: (スコア:0)
Chromiumでgoogleへ行って検索テキストフィールドに入力を始めるとアドレスバーに入力されはじめる。
誰がうれしいんだ、この仕様。
Re: (スコア:0)
ランダムに見えるだけの文字列だったりして。おっと誰か来たようだ。
google管理のサブドメインにすればいい (スコア:0)
たとえばgoogleがhogehoge.comみたいなドメインをchrome用に取得して、
[ランダム文字列].hogehoge.com
みたいな問い合わせをすればいい
Re:google管理のサブドメインにすればいい (スコア:1)
DNSの仕組み的に、そんなのは意味がないですよ。
foo.hogehoge.com のIPアドレスを知りたい場合の、名前解決(IPアドレス取得)の流れは
1. foo.hogehoge.com についてルートサーバに問い合わせる → [.com を管理するDNSサーバ]に問い合わせるよう応答が返ってくる
2. foo.hogehoge.com について[.comを管理するDNSサーバ]に問い合わせる → [hogehoge.com を管理するDNSサーバ]に問い合わせるよう応答が返ってくる
3. foo.hogehoge.com について[hogehoge.comを管理するDNSサーバ]に問い合わせる → foo.hogehoge.com のIPアドレスが返ってくる
となります。
この後、別の bar.hogehoge.com について問い合わせる場合、
また1のルートサーバーへの問い合わせからやりなおし。
「同じhogehoge.comだからいきなり3に問い合わせればいいや」とはなりません。
まったく同じホスト名を再度問い合わせるなら、キャッシュすることで無駄な問い合わせは減らせられますが、
ランダムな場合は都度ルートサーバへの問い合わせが発生しますので、
ごく一部のランダム文字列クエリが、ルートサーバへの問い合わせの半分近くを占める、
というのはいかにもな状況です。
ルートサーバへのクエリを防ぐ方法ですが、
通常はブラウザが直接ルートサーバなどに問い合わせたりせず、
「問い合わせに対して、上記1～3のクエリを実施してその最終結果を返す」ような「リゾルバ」DNSサーバに対してブラウザは問い合わせるので、
・ブラウザの問い合わせ先のDNSサーバを、Google管理下の 8.8.8.8 などを使うようにする
・8.8.8.8のサーバは、hogehoge.com の情報を返すスレーブサーバにしておく
とかすれば、ルートサーバへのクエリを減らすことができますが、
そもそも、今回の問題のクエリ挙動を行う理由が、
リゾルバとして指定されたDNSサーバがNXDOMAINハイジャックしているかどうかの確認のため、ですので、
8.8.8.8 に問い合わせるようにする時点で、そもそもランダムクエリは不要です…
Re:google管理のサブドメインにすればいい (スコア:1)
>「同じhogehoge.comだからいきなり3に問い合わせればいいや」とはなりません。
手元の unbound で tcpdump した範囲だと、ちゃんと中間のNSレコードはキャッシュされ、ルート問い合わせは発生してないよ？
Re:google管理のサブドメインにすればいい (スコア:1)
> ちゃんと中間のNSレコードはキャッシュされ、ルート問い合わせは発生してない
そうでしたか。すみません、何か勘違いしていたようです。
…とすると、ルートサーバへの問い合わせが出るということは、TLDを乱数生成してるってことですかね…なんて無茶を…
Re: (スコア:0)
TLDというか、ピリオド一切含まない7〜15文字のランダムなアルファベット列でリクエスト飛ばすっぽい。
Privoxy使ってんだけどたまにホスト名解決失敗のログが湧いてきて大分鬱陶しい。
Re: (スコア:0)
ISPや企業や大学ではDNSリゾルバサーバのキャッシュを十分にチューニングしなければならぬと言うわけですね
Re: (スコア:0)
御高説のところ申し訳ないけど
> 8.8.8.8 に問い合わせるようにする時点で、そもそもランダムクエリは不要です…
8.8.8.8がハイジャックされてないかどうかはどうやって確認するんですか？
Re: (スコア:0)
そしたら、Google が検索キーワードを暗号化して傍受しているって悪評が立つでしょ。
意識高い人たちがドメインをブロックして検索が機能しなくなったら、抱合せだって騒ぐでしょ。
Google に依存させてはうまくいかなくなることもあるんだよ。