DNSベースの広告ブロックとは?
Webサイトを開くたび、またはアプリがサーバーに接続するたび、デバイスはまずDNSルックアップを行います。analytics.example.comのようなドメイン名をIPアドレスに変換するのです。これは、実際にデータが送受信される前に起こります。DNSレベルの広告ブロックはこの処理を途中で止め、要求されたドメインをブロックリストと照合します。そのドメインが広告、トラッキングスクリプト、マルウェアの配信元として知られていれば、DNSリゾルバは実際のIPアドレスの代わりに空の応答を返します。接続自体が最初から行われません。
この方法には、従来のブラウザベースの広告ブロッカーよりも多くの利点があります。まず、ネットワーク上のすべてのデバイスで動作します。スマートフォン、タブレット、スマートTV、ゲーム機、ブラウザ拡張機能に対応していないIoTデバイスまで対象です。次に、ネットワーク層でトラッキングと広告をブロックするため、Webブラウザだけでなくアプリからの要求も捕まえます。さらに、ブロックされた要求は内容をダウンロードしないため、帯域幅の使用量も減ります。
最も一般的な構成は、自宅のネットワーク上でカスタムDNSリゾルバを動かす方法です。Raspberry Pi、NAS、仮想マシン、クラウドサーバーのいずれかで運用できます。その後、ルーターにこのリゾルバを優先DNSサーバーとして使うよう設定すると、ネットワークに接続するすべてのデバイスに自動でブロックが適用されます。
ただし、限界もあります。DNSブロックはドメイン名を対象にしており、個別のURLやページ要素までは見ません。特にYouTubeやほかの大規模プラットフォームで増えているように、アプリが広告を本体コンテンツと同じドメインから配信している場合、DNSブロッカーは両者を見分けられません。ドメインごとに、すべてブロックするか許可するかのどちらかです。さらに、DNSブロックは暗号化された通信を検査できず、アプリが実際にサーバーへ何を送っているのかも理解できません。制御できるのは接続するかどうかだけで、接続後に何が流れるかではありません。これらの制約は、このガイドの後半でDNSブロックとアプリレベルのファイアウォールを比較する際に重要になります。
Pi-hole: セルフホストの定番
Pi-holeは2014年に登場し、すぐにセルフホスティング界隈で定番のDNS広告ブロッカーになりました。元はRaspberry Pi向けに設計されたことからその名が付き、Pi-holeはローカルDNSサーバーとして動き、コミュニティ管理のブロックリストに照らしてクエリをふるいにかけます。セットアップは長年で大きく洗練され、ほとんどのLinuxディストリビューションではcurlコマンド1つで一式を導入できます。Webベースの管理ダッシュボードでは、DNSクエリ、ブロックされたドメイン、クライアントの動きがひと目で分かります。
Pi-holeのセットアップは、すでにRaspberry PiかLinuxマシンがあれば、たいてい15分ほどで完了します。インストール後はルーターのDNS設定をPi-holeのインスタンスに向けるだけで、ネットワーク上のすべてのデバイスが自動的に保護されます。標準のブロックリストで、よくある広告ドメインやトラッキングドメインの大半は検出できますし、コミュニティの追加リストを入れて対象範囲を広げることもできます。
Pi-holeの強みは、その成熟度とコミュニティにあります。長く使われてきたおかげで、ほとんどあらゆる例外パターンにドキュメントがあり、よくある問題にはフォーラムのスレッドがあり、ブロックリストのエコシステムも非常に大きいです。クエリログとダッシュボードで、ネットワーク上の各デバイスが何をしているかを細かく追えます。スマートホーム機器がどれほど頻繁に外部へ通信しているかを知ると、役立つ一方で少し驚くかもしれません。
ただし、いくつかのトレードオフもあります。Pi-holeは稼働させるハードウェアの管理が必要です。OSの更新、Piの電源や接続の維持、そしてソフトウェアアップデートで何かが変わったときのトラブルシュートなどです。cloudflaredやUnboundのようなツールを使って追加設定をしない限り、DNS-over-HTTPSやDNS-over-TLSは標準ではサポートしません。インターフェースは機能的ですが、より新しい選択肢と比べると古さを感じます。そしてPi-holeが落ちると、代替を設定していない限りネットワーク全体のDNS解決が止まります。手をかけることをいとわず、完全な制御を求める技術寄りのユーザーには、Pi-holeはいまも優れた選択です。
AdGuard Home: Pi-holeのモダンなライバル
AdGuard Homeは、AdGuardのブラウザ拡張機能やVPN製品を手がけるチームによって作られた、Pi-holeの直接の競合として登場しました。基本的な役割は同じで、不要なドメインをブロックするローカルDNSリゾルバーとして動きますが、Pi-holeでは追加設定やサードパーティーツールが必要な機能がいくつか標準搭載されています。
最も大きな違いは、暗号化DNSプロトコルを最初からサポートしている点です。AdGuard Homeは、DNS-over-HTTPS、DNS-over-TLS、DNS-over-QUICを別ソフトの導入や設定なしでそのまま扱えます。プライバシーを重視するユーザーにとっては、デバイスとAdGuard Homeのインスタンス間のDNSクエリが暗号化され、ISPやネットワーク上の他者に、どのドメインを解決しているか見られなくなるということです。
AdGuard Homeには、Pi-holeよりモダンなWebインターフェースに加え、ペアレンタルコントロール、安全なブラウジングの強制も組み込まれています。フィルタリングエンジンもより複雑なルールに対応し、正規表現ベースのフィルターを書けるほか、標準のhostsファイル形式に加えてAdGuard形式のフィルタリング構文も使えます。また、CNAME cloakingの扱いもデフォルトではPi-holeより優れています。CNAME cloakingは、トラッカーがファーストパーティーのDNSレコードの背後に隠れる手法で、DNSレベルのブロックに広告主が適応するにつれて、ますます一般的になっています。
インストールは簡単です。AdGuard HomeはLinux、macOS、Windows、FreeBSD向けに単一バイナリで配布されており、よく保守されたDockerイメージもあります。Pi-holeと同様に、ネットワークのDNSサーバーとして設定し、Webダッシュボードから管理します。セットアップウィザードが、上流DNSサーバーの選択や暗号化DNSの有効化を含む初期設定を案内してくれます。
考慮点は、AdGuard Homeが商用企業によって開発されていることです。これは長所にも短所にもなります。ソフトウェアはよく保守され、定期的に更新され、プロ向けのサポート資源もあります。一方で、セルフホスティング界隈の一部ユーザーは、Pi-holeのような完全にコミュニティ主導の開発モデルを好みます。どちらも無料のオープンソースですが、運営の仕組みは異なります。性能面では、一般的な家庭内ネットワーク用途なら両者はほぼ同等です。
NextDNS: クラウドベース、設定不要
NextDNSはPi-holeやAdGuard Homeとは根本的に異なるアプローチを取ります。ローカルネットワーク上でソフトウェアを動かすのではなく、NextDNSはクラウドDNSサービスとして動作します。アカウントを作成し、Webダッシュボードでブロックリストと設定を調整してから、各デバイスのDNS設定を変更する、ルーターを設定する、あるいは軽量なクライアントアプリを入れて、デバイスをNextDNSのリゾルバに向けます。保守すべきハードウェアも、更新すべきソフトウェアもなく、ローカルのDNSサーバーが停止する心配もありません。
設定オプションは非常に充実しています。NextDNSはPi-holeやAdGuard Homeと同じ種類のブロックリストに対応し、さらに用途別の厳選リストも用意しています。たとえば、TikTokのトラッカーをブロックする、特定プラットフォームのテレメトリーを無効にする、検索エンジン全体でセーフサーチを強制する、といった使い方ができます。分析ダッシュボードには、DNSクエリがどこで解決されたかの地理情報付きでクエリログが表示され、データがどこを通っているのか意外な事実が見えてくることもあります。
NextDNSはDNS-over-HTTPSとDNS-over-TLSを標準でサポートし、リゾルバは世界中に分散しているため、場所を問わず通常は低遅延です。セットアッププロファイル機能を使えば、デバイスごとに異なる設定を簡単に適用できます。たとえば、子どものタブレットは厳しめに、仕事用ノートPCは軽めに、自分の個人用デバイスは完全にブロックするといった具合です。
無料枠は月300,000クエリまでで、個人利用なら十分ですが、複数デバイスのある家庭では超えることがあります。有料サブスクリプションにすると、クエリ上限はなくなります。
NextDNSのトレードオフは信頼です。すべてのDNSクエリを第三者サービス経由で送るため、NextDNSはネットワーク上のすべてのデバイスが解決するあらゆるドメインを見ることができます。明確なプライバシーポリシーがあり、すべてのログを無効にするオプションもありますが、これは自前運用にはないレベルの信頼を必要とします。技術的な負担なしにDNSブロックの利点を得たいユーザーにとって、NextDNSは最も手軽な選択肢です。すべてをローカルに保ちたいなら、Pi-holeかAdGuard Homeのほうが適しています。
DNSブロッカーとアプリファイアウォールは両方必要?
DNSレベルのブロックとアプリケーションレベルのファイアウォールは、重なる部分はあるものの、根本的には別の問題を解決します。それぞれがどこに強く、どこが弱いのかを理解すると、抜けのないプライバシー環境を作りやすくなります。
Pi-hole、AdGuard Home、NextDNSのようなDNSブロッカーは、ネットワーク全体を守ります。DNSリゾルバを使うすべてのデバイスが同じブロックリストの恩恵を受けます。自分ではセキュリティソフトを動かせないデバイス、たとえばスマートTV、IoTセンサー、ゲーム機、ゲスト用デバイスも対象です。ネットワーク全体をまとめて守れることが最大の強みです。ただし、DNSブロッキングはドメイン名だけを見ます。Mac上のどのアプリが接続しているのかはわかりません。ブラウザと、同じドメインにアクセスするバックグラウンドプロセスを区別することもできません。また、アプリがドメイン名ではなくハードコードされたIPアドレスを使う場合は、DNSを完全に回避されるためブロックできません。
NetMuteのようなアプリケーションレベルのファイアウォールは、仕組みが異なります。Mac上で動作し、アプリごとの送信接続を監視します。Zoomがトラッキングサーバーに接続しようとしたときや、新しく入れたアプリが分析用エンドポイントに通信しようとしたとき、NetMuteは責任のあるアプリを正確に示し、その特定の接続だけをブロックできます。この粒度は、DNSブロッキングでは根本的に得られません。どのアプリが、どのサーバーに、どれくらいの頻度で、という全体像が見えます。あとは自分で判断するだけです。
理想的な構成は両方を使うことです。DNSブロッカーがネットワーク全体で大まかに受け止め、既知の広告ドメインやトラッキングドメインが解決される前に止めます。NetMuteのようなアプリファイアウォールが、Mac上で細かな制御を担い、アプリ固有のテレメトリー、DNSを回避する接続、そしてソフトウェアが裏で何をしているのかを可視化します。
NetMuteはMac App Storeから無料でダウンロードできます。プレミアムはアプリ内課金の一回購入で、サブスクリプションもアカウントも不要です。このガイドで紹介したどのDNSブロッカーとも組み合わせれば、ネットワーク全体のブロックとアプリごとの制御の両方を備えた、重層的なプライバシー環境を作れます。