ハクソク

世界を動かす技術を、日本語で。

Android向けFirefox 143でDoHを導入予定

250日前原文(blog.mozilla.org)

概要

  • Firefox は、 DNS-over-HTTPS (DoH) によるプライバシー保護をAndroidへ拡大
  • DoH 導入で暗号化されたDNS通信を実現、第三者からの盗聴防止
  • 2025年には パフォーマンスの大幅向上 を達成、デスクトップと同等の速度へ
  • CIRA や Akamai との協力により、カナダ国内外での恩恵拡大
  • ユーザー選択・透明性・厳格なプライバシー基準 を重視

FirefoxのDNSプライバシー：高速化とAndroid対応

  • 全てのウェブ閲覧 は、目的のサービスやウェブサイトの IPアドレス取得のためのDNSクエリ から始まる
  • 従来、DNSクエリは 暗号化されず 送信、ネットワーク上の第三者（ISPや公衆WiFi提供者）が内容を傍受可能
  • DNS-over-HTTPS（DoH） はDNSメッセージを 暗号化 し、プライバシー漏洩を防止
  • 2020年、 Firefox は米国で DoHをデフォルト有効化 した初のブラウザ
  • 2023年には カナダ でも CIRA との提携で DoHデフォルト展開 を開始
  • 2025年、 パフォーマンス改善 と Android対応 を実現し、より多くのFirefoxユーザーが恩恵を受ける環境を構築

Android版FirefoxでのDoH導入

  • デスクトップ向けDoH保護 を数百万ユーザーへ提供後、 Androidにも拡大
  • Firefox 143 for Android リリース以降、「 Increased Protection」のDoH設定で モバイル端末でもDoH有効化 が可能
  • 現在、 パートナーとのパフォーマンステスト を実施中
  • 期待通りの速度が確認でき次第、 特定地域でAndroid版もデフォルト有効化 を予定
  • それまでは設定から 任意で早期利用 が可能

2025年のDoHパフォーマンス革新

  • DNS解決速度 はユーザー体験に直結、複数DNSクエリが発生するページでは 速度差が蓄積
  • CIRA との連携で 信頼性・パフォーマンス測定 を継続
  • Akamai との技術協力により、 Firefox DoHの解決速度が前年比61%向上 （75パーセンタイル値）
  • DoH解決時間 が ネイティブDNSとほぼ同等 （1〜2ミリ秒差）に到達
  • カナダのFirefoxユーザー はプライバシーと速度を両立したDNS環境を享受
  • この取り組みは CIRAの他DNSユーザー（大学など）やAkamai利用の他事業者 にも波及
  • Firefoxユーザー以外にも恩恵 が広がる成果

強固なプライバシーとユーザー選択

  • Firefox は 透明性・ユーザー選択・強力なプライバシー保護 を重視
  • ユーザーはDoH設定のカスタマイズ が可能
    • オプトアウト
    • 独自リゾルバの選択
    • DoH保護レベルの調整
  • DoHの挙動や重要性 を分かりやすく提示
  • Mozillaの厳格なTrusted Recursive Resolver（TRR）ポリシー に準拠し、 法的拘束力ある契約 を結んだ信頼できるDNSリゾルバのみ採用

プライバシーと速度の両立を目指して

  • DoHの進化 は プライバシー と パフォーマンス の両立が可能であることを証明
  • デスクトップとAndroid の両方で、 高速・信頼性・暗号化DNS を実現
  • オープンスタンダード と 説明責任 に基づくパートナーシップが、 Firefoxユーザーだけでなくインターネット全体に貢献
  • 今後も「プライバシーがデフォルト」「速度に妥協なし」「誰もが使えるオープンなウェブ」 を推進
  • Firefoxの選択 は、 ユーザー本位 かつ より良いインターネット への意思表示

Firefoxで自分のインターネットをコントロール

  • Firefoxのダウンロード で、 プライバシーとパフォーマンスを両立したブラウジング体験 を実現

Hackerたちの意見

なんでこれをブラウザに組み込む必要があるのか、Androidが自分でDoHをやってるのに。理由があると思うんだけど、誰か知ってる？

└

プライバシー。

└

クエリ統計は売れる貴重なデータだよ。クライアントのDNSクエリは、検索クエリと似たようなもので、デフォルトの検索エンジン設定と合わせて最高入札者に売れるんだ。だからブラウザメーカーは、自分たちのDNSサーバーを持つ独自のリゾルバーを実装するインセンティブがある。自分たちでその統計を売りたいからか、もしくはユーザーをOSリゾルバーやISPリゾルバーの統計収集から守りたいから。

└

Androidのプライバシーツールは漏れやすいんだよね（プライバシーツールなのに、漏れたらまずいよね！）。OSレベルのVPNツールは、キルスイッチの設定をちゃんと守らないことで有名だし[0]。これだけでも、ネイティブブラウザの実装の方がOS版よりも良い解決策になるよ。[0]: https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the... これはGoogleで見つけた一例なんだけど（この場合、C関数のgetaddrinfoを使うとトンネルを完全にバイパスしちゃうんだ。特にChromeはDNSクエリにこれを使ってるからね - Android APIの呼び出しだけがトンネルを尊重する）、こういう話は数年ごとに聞くよ。その投稿では、接続チェックやNTPの更新が、キルスイッチが有効でもVPNを使っていなかった過去の事例にもリンクしてたしね。これらの問題は、執筆時点ではまだ修正されてないし（Googleは、VPNトンネルの外で発生するconncheck/NTP呼び出しをバグとは見なしていないからね）。

└

AndroidってDNS over TLSしかサポートしてないと思ってたけど、これで選択肢が増えるね。

└

まず、すべてのAndroidバージョンがそれをサポートしてるわけじゃないし、すべてのメーカーが実装してるわけでもない。最新バージョンを使ってる人やGoogle Pixelを持ってる人ばかりじゃないからね。それに、OSを通すのはセキュリティ的にあまり良くない。Googleやデバイスのメーカー、VPNアプリなど、いろんな人がそのクエリにアクセスできる可能性があるから。実際、ルートがない場合は、ADAwayみたいな広告ブロックアプリがVPN機能を使ってDNSクエリを傍受することもあるし。結局、安全を考えるなら、最初からOSを通さない方がいいよ。

└

Androidは、再帰的なDNSがDoHをサポートしていると判断した場合、同プロバイダーの自動アップグレードを行うよ（最後に確認した時は、Googleのリストに載ってる場合ね）。でも、これって自分でリゾルバーを設定しない限り、ネットワークをコントロールしている人が自分のリゾルバーに置き換えることができるってことだ。Firefoxは、信頼された再帰リゾルバーのセットを使っているから、この攻撃に対しては少し強いんだ。「少し強い」と言うのは、デフォルトでは失敗した時にシステムDNSに戻るからだけど、ハードフェイルに設定することもできる。これがより良い設計だと思うかどうかは人それぞれだけど（私はFirefoxがこういう風にやることに関わってたから、そう思う）、この違いを説明できたらいいな。詳しくはここを見てね: https://educatedguesswork.org/posts/dns-security-dox/

└

FirefoxのDoHは、いつ有効にするか無効にするか、どのDNSプロバイダーを選ぶかを選べるコントロールを提供してるけど、Androidはそんな選択肢すらないし、DoHが使われてるかどうかもユーザーに知らせないんだよね。それに、Firefoxは最も強力なプライバシー保証のために法的に拘束力のある契約を結んでいるDNSプロバイダーとだけ提携してるよ。詳しくはここを見てね：https://wiki.mozilla.org/Security/doh-resolver-policy。

└

確かAndroidはDoHじゃなくてDoTをやってるはずだよ。少なくとも「プライベートDNS」設定ではDoTエンドポイントしか設定できないから。

今のおすすめのDoHプロバイダーってどこ？クラウドフレアは中央集権的な面でちょっと問題がある気がする。

└

Mullvadはプライバシー重視のDoHサービスを運営してて、VPNサービスを使ってなくても無料で使えるよ。 https://mullvad.net/en/help/dns-over-https-and-dns-over-tls

└

quad9が好き。

└

ドイツやEUにはffmucがあるよ。 https://social.ffmuc.net/@freifunkMUC/114087819103432120 中央集権的なものじゃなくて、もっと地域のDOHプロバイダーが増えるといいな。

└

プライバシーを重視したい人には、自分専用のDOHサーバーを立てるのもアリだよ。ただし、上流のリクエストはまだ追跡される可能性があるから注意してね。でも、自分でDNSリゾルバー（bindやpowerdns）をホスティングしたり、VPNやTor接続を使ってDNS/DoHクエリを送ったり、複数のソースにクエリを分散させたりすることで、追加の安全対策が取れるよ。それぞれにセキュリティやプライバシーの影響があるから、詳しくはここでは触れないけどね :)

└

Wikimediaは実験的なDoHサーバーを運営してるよ。詳しくはここを見てね: https://meta.wikimedia.org/wiki/Wikimedia_DNS

└

NextDNSは最高だね。

└

Quad9（DoH、DoT、Dnscryptをサポート）とMullvadはどちらも良いセキュアDNSサービスだよ。セキュリティ重視ならQuad9を選んで、広告ブロック機能が欲しいならMullvadがいいね。

└

AdGuardをunboundで設定したよ。設定はDoHとDoTをサポートしてて、結構いい感じ。

DoHはDNSトラフィックをいくつかのDoHリゾルバーに集中させる。これって良くないよね。

└

これを軽減する一つのアプローチは、複数のDoHプロバイダーにクエリを分散させることだよ: https://www3.cs.stonybrook.edu/~mikepo/papers/k-resolver.mad...

└

実際、DoHはここでの状況を変えるわけじゃなくて、ただのトランスポートなんだ。FirefoxのDoHのアプローチ（「信頼された再帰リゾルバー」）は、トラフィックをある程度集中させるけど、DoHは必ずしもこの方法で展開される必要はない。例えば、Chromeは同プロバイダーの自動アップグレードを行っていて、リゾルバーを変えずに、利用可能ならDoHを使おうとするだけなんだ。

MozillaがAndroidで設定を公開するのにこんなに時間がかかった理由がよくわからないな。ずっと「秘密」の設定だったし。実際、時々、機能を長く放置しすぎることもあると思う。Waterfox for Androidでは、デフォルトでその設定を公開して、Fastlyを中継として使うDNS over Oblivious HTTP（DoOH）設定も追加したんだ（プライバシーのために彼らがホストして管理してる）。

└

ちょっとだけ、水狐の仕事に感謝したいと思って！

└

DoOHのレイテンシーはどうなの？

└

そうそう、about:configからアクセスできるよ。でももっと重要なのは、Android（少なくともGrapheneOSでは）全体でDoHの設定があるってこと。ブラウザだけでDoHを設定するのがいいとは思えないな。

DNSクエリ [...] クリアで。 [...] (DoH)はこのプライバシーの漏れを防ぐ [...] ネットワーク上の誰も、あなたのインターネットサービスプロバイダーも [...] あなたのブラウジングを盗み聞きできない。DNSトラフィックを見れる人は、接続先のターゲットはまだ見えるけどね...

└

でも、そのリクエストが大手プロバイダー（GCP、AWS、CloudFlare）に向かっている場合、ホスト名がなければ、そのリクエストはスヌープにとってほとんど意味がないものになるよ。

└

大部分のトラフィックがEncrypted Client Helloを使ってない時に、この約束は特に危険だよ。最初のリクエストでドメイン名がクリアで送信されちゃうから。前に、sniffglueからパケットデータを解析する簡単なプロトタイプを書いたことがあって、すごく低スペックのルーターで実行して、すべてのソースIPアドレスとホスト名のヘッダーをログに取ったんだ。CPUの使用量もほとんどなかったし、効率的に実装することも考えなかった。MITMの立場にいる人、特にISPは、もし望めばこのトラフィックを簡単にログに取れるってことは安全に言えると思うよ。

└

その通り。DoHは、ネットワークベースのブラウジング履歴漏洩を防ぐために設計されたメカニズムの一部（ECHを含む）として考えるのが正しい。単独で使うと価値はあるけど、その価値は限られてるね。

└

正解 - それはClientHelloで見えるね。でも、Firefoxは少し前にDoHが有効なときにECHも有効にしたよ - https://support.mozilla.org/en-US/kb/faq-encrypted-client-he...

誰か、ネットワーク上でDoHを強制的に無効にする方法知ってる？ https://support.mozilla.org/en-US/kb/canary-domain-use-appli... によると、DoHを自分でオンにしたユーザーにはカナリアドメインは適用されないみたい。sslproxyを使いたくないし、ファイアウォール上でアプリケーションレベルのプロキシが必要みたい。

└

知名度の高いDoHホストをIPブロックする以外に（例えば https://github.com/jameshas/Public-DoH-Lists）、ブレイク・アンド・インスペクトなしでやる良い方法はないよ。DoHは443上のTLSトラフィックだから、HTTPの代わりにDNSが入ってるだけなんだ。

└

アウトゴーイング接続をデフォルトで拒否するファイアウォールルールと、接続を解決した後にファイアウォールに許可を出すDNSリゾルバーがあれば可能だと思うけど、今のところ市販のものはないんじゃないかな。DoHプロバイダーも既知のSNIやESNIを使ってるだろうから、両方ともブロックできると思う。この前者のアプローチがセキュリティのために進むべき道だと思う。ネットワーク上のコンピュータがアウトゴーイング接続をしている理由を監査できない（接続前に検査・拒否できる能力がない）なら、単にブロックすべきだよ。自分のコンピュータが理解できないランダムなIPにアクセスする理由はないし、ゲートウェイで検査もできないのに。最近のコンピュータデバイスはマルウェアがプリロードされてることが多いから、デフォルトで信用できないものとして扱うべきだね。

Firefoxだけで、（時々クソみたいなところはあるけど）Androidを使い続ける理由になってる。完全な拡張機能サポート（つまり、uBlock Originのサポート）がないと困るんだよね。ここにいる人たちが他に良い代替ブラウザを知ってるか気になるな。特に、"完全な" uBlock OriginサポートがあるAndroidやiOSのブラウザ（uBlock Origin Liteじゃなくて、他のブロッカーもなし）を探してる。いくつか教えてもらえたら嬉しいな。KagiのブラウザがiOSで動くって聞いたけど（たしか？）、まだベータ版でクローズドソースだから、私のデバイスには使えないんだよね。Firefoxの仲間としてWaterfoxも知ってるよ。

└

iOSのBraveは悪くないよ。昔のAndroidのFirefoxみたいに動くね。

└

lemurブラウザを試してみて。拡張機能のサポートがあるよ。

└

Orion（Kagi製）でiOSのフルuBlock Originが使えるよ。少なくとも、Appleのエコシステムでは6ヶ月前はそうだった。俺はずっとpihole/adguard homeを使って、ルーターで広告をブロックしてたから、その後は標準のSafariに戻って、携帯サービスの時にルーターのブロッキング機能を維持するためにTailscaleを使ってる。

└

uBlock Originじゃなくて、Braveの独自ブロッカーはRustで書かれてて、Firefox+uBOよりもバッテリー効率がいいんだ。パワーも同じくらい強力だし（カスタムリストも追加できる）。Firefoxは遅いし、バッテリーも食うからね。

└

Samsungブラウザは、ADB+やAdGuardみたいな広告ブロック拡張機能をいくつかサポートしてるよ。

└

Kiwiブラウザは、uBlock OriginみたいなブロックされたChrome拡張機能を使えるんだ。

└

DNS広告ブロックをやれば、デバイスやブラウザは関係なくなるじゃん。

└

Vivaldiを試してみて。

└

Android用のEdgeも（限られた）拡張機能のサポートがあるよ。サポートされてる拡張機能の一部だけだけど、例えばuBlock Origin（フルバージョン、_lite_もあるけど）、Sponsorblock、Dark Readerを使ってるよ。

DoHは技術的には勝利だけど、自分でDNSを運用してる人にとっては実用的には後退だよね。従来のDNSだと、DHCP経由でリゾルバを配布してローカルゾーンを透明に管理できたけど、DoHだとそれができなくなった。各クライアントを明示的に設定しなきゃいけないし、トラフィックがHTTPSでラップされてるから傍受できないんだ。デフォルトも役に立たないし、ISPがクエリを見る代わりに、今はCloudflareやGoogle、ブラウザがハードコーディングしてる大手が見ることになる。それは分散化じゃなくて、より派手なマーケティングストーリーの下での中央集権だよ。暗号化はいいし、検閲抵抗もいいけど、導入がユーザーから権力を奪って、ほんの一握りのグローバルDNSサイロに向かわせてる感じがする。技術者にとっては、進歩というよりも、余計な手間がかかるロックインに感じるね。

└

DHCP経由でリゾルバーを配布して、ローカルゾーンを透明に制御できるよ。でもDoHだとそれができなくなる。RFC9463をチェックしてみて。

デスクトップの主要なブラウザではDoHを設定できるよ。iOSではプライベートリレーを使える。一つの問題は、ブラウザでDoHを設定すると、DNSサーバーでDNSフィルタリングができなくなること。自宅のLANにVPN経由でDNSを送って、そこでフィルタリングして、DNSサーバーがHTTPS経由でDNSを送る方がいいかも。Tailscaleを使えば、すべてのデバイスから選んだサーバーにDNSを送れるよ。そこからAdGuardやPiholeがフィルタリングしてHTTPSで送信する感じ。

自分のGrapheneOSデバイスでWireguardを使って、自作の再帰的DNSサーバーを長いこと使ってるんだけど、少数の有名な中央集権的プロバイダーを通してDoHを使う方がプライバシーにとって良いとは思えないな。

└

どのドメインも、自分のDNSサーバーをセッションに関連付けるようにDNSを設定できるから、これってかなりユニークで、分散してるデバイスをつなげる可能性があるんだよね。もし誰もがこれをプロファイルに追加しようとしないなら、ユーザーをもっと一般的な設定でクラスタリングする期待があるのが変に思える。