Raspberry Pi 3 で Pi‑hole を運用してきましたが、半年で SD カードが 2 回クラッシュしました。
Pi‑hole 自体は安定していても、SD カードという物理メディアの弱さがどうしてもネックになりますよね。
Raspberry Pi 4 のように USB ブートができればまだ良いのですが、Pi 3 ではそうもいきません。
そこで、Pi‑hole の運用基盤を Raspberry Pi から Synology NAS（DS1621+）へ移行することにしました。
（Raspberry Pi 4にするか、迷いましたが。）
DS1621+ は Ryzen CPU と ECC メモリを搭載し、ストレージも RAID で保護されているため、
Pi‑hole を 24 時間安定稼働させるには理想的な環境です。
ただし、Synology で Pi‑hole を動かす場合には注意点があります。
DSM が 53 / 80 / 443 といった Pi‑hole と同じポートを使っているため、
普通に Docker を起動すると ポート競合で Pi‑hole が動きません。
そこで必要になるのが macvlan。
macvlan を使うことで、Pi‑hole に LAN 上の独立した IP を与え、
Synology 本体と完全に分離した “別の機器” として動かすことができます。
本記事では、DS1621+ 上で Pi‑hole を 最も安定して動かすための構成（macvlan） を中心に、
ブロックリスト、Unbound、Grafana、Prometheus、AI 連携まで、
家庭内インフラを構造化していくための完全ガイドとしてまとめました。
🟩 Synology DS1621+ で Pi‑hole を動かす最適解
Synology で Pi‑hole を動かす場合、macvlan か host モード のどちらかが必須です。
🔥 結論：macvlan が最も安定（推奨）
- Pi‑hole に 独立した LAN 上の IP を与えられる
- Synology の DSM が使っているポート（53/80/443）と衝突しない
- クライアントの IP が正しく見える（統計が正確）
🟩 macvlan とは？（一言で言うと…）
Docker コンテナに “独立した LAN 上の IP アドレス” を与える仕組み。
つまり、NAS の中にいる Pi‑hole が、
まるで別の物理機器として LAN に参加するようになる。
🟦 macvlan を使うとどうなる？
例：あなたの LAN が 192.168.1.0/24 の場合
- Synology DS1621+ → 192.168.1.10
- Pi‑hole（Docker） → 192.168.1.250（macvlan で割り当て）
こうなると、LAN から見ると：
- NAS と Pi‑hole は別の機械
- Pi‑hole は LAN の一員として DNS を提供
- DSM のポートと衝突しない（これが超重要）
🟧 なぜ Synology では macvlan が必須なの？
Synology DSM は以下のポートを使っている：
- 53（DNS）
- 80（Web）
- 443（HTTPS）
Pi‑hole も同じポートを使う。
つまり、普通に Docker を起動すると…
❌ ポートが衝突して Pi‑hole が起動しない
❌ host モードでも DSM とぶつかる
❌ bridge モードでは LAN から DNS として使えない
そこで macvlan の出番。
✔ macvlan なら Pi‑hole に別 IP を与えられる
→ DSM とポートが衝突しない
→ LAN 全体の DNS として使える
→ クライアントの IP も正しく見える
🟨 macvlan のイメージ図（超ざっくり）
[LAN]───[ルーター]───┬───[Synology DS1621+]
│
└───[Pi-hole コンテナ（別IP）]
Synology の中にいるのに、
LAN からは別の機械として見えるのがポイント。
🟪 Portainer で macvlan を使うとどうなる？
Portainer では：
- macvlan ネットワークを “外部ネットワーク” として登録
- Stack（docker-compose）でそのネットワークを指定
- Pi‑hole に固定 IP を割り当てる
これだけで、Pi‑hole が LAN の一員として動く。
🎯 まとめ（macvlan の本質）
- Docker コンテナに独立した LAN IP を与える技術
- Synology DSM のポートと衝突しない
- Pi‑hole を LAN 全体の DNS として使える
- クライアント IP が正しく見える
- Synology で Pi‑hole を動かすなら “ほぼ必須”
macvlan の subnet / gateway / IP は環境ごとに違うから、ここを合わせると一発で動く。
🟥 第1章：Synology（Docker）で Pi‑hole を動かす完全セットアップ手順
この記事は、Synology NAS（例：DS1621+）上で Pi‑hole を macvlan で独立IP化して安定稼働させるための手順をまとめたもの。
一般的な “bridge モード” ではなく、LAN 上に Pi‑hole を独立した機器として見せる構成なので、ルーターの DNS として設定でき、家庭内ネットワーク全体を Pi‑hole 化できる。
🟩 1. 前提条件
- Synology NAS（Docker / Container Manager が動作）
- SSH が有効
- LAN は 192.168.0.0/24（例）
- Pi‑hole に割り当てたい IP：192.168.0.250
- 親インターフェース：ovs_eth0（Synology の Docker が使う仮想 NIC）
🟦 2. macvlan ネットワークを作成する
Synology の Docker は GUI から macvlan を作れないため、SSH で作成する。
sudo docker network create -d macvlan \
--subnet=192.168.0.0/24 \
--gateway=192.168.0.1 \
-o parent=ovs_eth0 \
pihole_macvlan
成功すると、長いネットワーク ID が返ってくる。
🟧 3. Pi‑hole 用のフォルダを作成
Synology は マウント先フォルダが存在しないとコンテナが起動しないため、事前に作成する。
sudo mkdir -p /volume1/docker/pihole/pihole
sudo mkdir -p /volume1/docker/pihole/dnsmasq.d
🟨 4. Portainer（または Container Manager）で Stack を作成
以下の docker-compose をそのまま貼り付ける。
version: "3"
services:
pihole:
image: pihole/pihole:latest
container_name: pihole
environment:
TZ: "Asia/Tokyo"
FTLCONF_webserver_api_password: "任意のパスワード"
DNSMASQ_LISTENING: "all"
ServerIP: "192.168.0.250"
PIHOLE_DNS_: "1.1.1.1;8.8.8.8"
volumes:
- /volume1/docker/pihole/pihole:/etc/pihole
- /volume1/docker/pihole/dnsmasq.d:/etc/dnsmasq.d
networks:
pihole_macvlan:
ipv4_address: 192.168.0.250
restart: unless-stopped
networks:
pihole_macvlan:
external: true
ポイント：
- ServerIP を明示する（macvlan では必須）
- PIHOLE_DNS_ で上流 DNS を外部に設定（127.0.0.1 は絶対NG）
- DNSMASQ_LISTENING=all は macvlan で必須
🟩 5. Pi‑hole にアクセス
ブラウザで：
http://192.168.0.250/admin
ログインできれば成功。
🟦 6. Pi‑hole が DNS として動いているか確認
Windows から：
nslookup google.com 192.168.0.250
正常なら、Pi‑hole 経由で Google の IP が返ってくる。
🟧 7. ルーターの DNS を Pi‑hole に向ける
Pi‑hole が正常に動いていることを確認したら、
ルーターの DNS を以下に設定する。
- プライマリ DNS：192.168.0.250
- セカンダリ DNS：空欄（推奨）
これで家庭内の全端末が Pi‑hole を使うようになる。
🟪 8. スマホの注意点（重要）
スマホは IPv6 を優先するため、
IPv6 DNS が Pi‑hole をバイパスすることがある。
- ルーターの IPv6 DNS を空欄にする
- Android の「プライベート DNS」を無効化
- iPhone の「iCloud プライベートリレー」を無効化
これでスマホも安定する。
🟫 第1章まとめ
| ステップ | 内容 |
|---|
| 1 | macvlan を作成 |
| 2 | Pi‑hole 用フォルダ作成 |
| 3 | docker-compose で Pi‑hole 起動 |
| 4 | 上流 DNS を外部に設定 |
| 5 | Pi‑hole にアクセス |
| 6 | DNS 動作確認 |
| 7 | ルーターの DNS を Pi‑hole に向ける |
| 8 | スマホの IPv6 / プライベート DNS を調整 |
これで Pi‑hole が家庭内 DNS として完全稼働する状態になる。
🟥 第2章：Pi‑hole のブロックリスト完全ガイド（選び方・追加方法・運用）
Pi‑hole の魅力は、広告・トラッキング・マルウェアドメインを DNS レベルで遮断できることにある。
しかし、ブロックリストは種類が多く、強すぎるリストを入れるとスマホアプリが動かなくなるなどの問題も起きる。
この章では、Pi‑hole に最適なブロックリストの選び方・追加方法・運用のコツを体系的にまとめる。
🟩 1. ブロックリストの基本構造
Pi‑hole のブロックリストは大きく分けて3種類ある。
① 広告ブロック（Adblock）
- 広告配信サーバーを遮断
- Web 広告の大半が消える
- 誤ブロックは少なめ
② トラッキングブロック（Tracking）
- アプリやサイトの行動追跡を遮断
- プライバシー向上
- スマホアプリが引っ掛かりやすい
③ マルウェア・フィッシング対策（Security）
- 危険サイトを DNS レベルで遮断
- 誤ブロックはほぼ無し
- 入れておくべき
🟦 2. ブロックリストの追加方法（Pi‑hole 標準機能）
Pi‑hole Web UI →
Group Management → Adlists → Add a new adlist
ここに URL を貼って「Add」→「Update Gravity」で反映される。
🟧 3. 最初に入れるべき “鉄板リスト”
誤ブロックが少なく、動作が軽い。
Pi‑hole 初心者〜上級者まで全員におすすめ。
✔ StevenBlack（定番・安定）
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
- 広告・トラッカーをバランスよくブロック
- 誤ブロックが非常に少ない
- まずはこれを入れておけば間違いない
✔ OISD basic（軽量で強力）
https://abp.oisd.nl/basic/
- 広告・トラッカーを広くカバー
- スマホとの相性が良い
- OISD full より誤ブロックが少ない
✔ 1Hosts mini（軽量・高速）
https://raw.githubusercontent.com/badmojr/1Hosts/master/mini/domains.txt
- 1Hosts の軽量版
- スマホアプリの誤ブロックが少ない
- Pi‑hole の負荷も低い
🟨 4. もっと強くしたい人向け（中量級）
広告・トラッカーをさらに強力にブロックしたい場合。
✔ OISD full（強力）
https://abp.oisd.nl/
- YouTube 広告が減る
- ただしスマホアプリが止まることがある
- 調整できる人向け
✔ Energized Blu（強め）
https://block.energized.pro/blu/formats/hosts
- 広告・トラッカー・スパムを広く遮断
- スマホアプリの API が止まることがある
🟥 5. 上級者向け（強すぎ注意）
誤ブロックが増えるが、遮断力は最強。
✔ Energized Ultimate
https://block.energized.pro/ultimate/formats/hosts
✔ 1Hosts Pro
https://raw.githubusercontent.com/badmojr/1Hosts/master/pro/domains.txt
これらは アプリの必要通信まで止めることがあるので、
Whitelist 運用が必須。
🟩 6. 日本向けのブロックリスト
国内サービスの広告を減らしたい場合に有効。
✔ AdGuard Japanese filters
https://filters.adtidy.org/extension/chromium/filters/7.txt
- 日本の広告に強い
- 誤ブロックは少ない
- 追加しても負荷はほぼ増えない
🟦 7. スマホで誤ブロックが起きたときの対処
スマホアプリは Web と違い、
広告・トラッキング・API が混ざっているため、
強いリストを入れるとアプリが固まることがある。
✔ 対処方法（最短で直る）
① Query Log でスマホの IP をフィルタ
Pi‑hole → Query Log → Client → スマホの IP
赤くブロックされているドメインの中に：
- googleapis
- firebase
- akamai
- cloudfront
- graph.facebook.com
- app-measurement
- line.me
- amazonaws.com
などがあれば、Allow（Whitelist）する。
② 強すぎるリストを外す
OISD full や Energized Ultimate を外すと安定する。
③ スマホの DNS キャッシュをクリア
- iPhone → 機内モード ON/OFF
- Android → Wi‑Fi OFF/ON
🟧 8. おすすめ構成（安定性と強さのバランス）
あなたの環境（Synology + macvlan + 家庭内 LAN）なら、
以下の3つが最も安定して強力。
✔ 推奨セット（誤ブロック少なめ・強力）
- StevenBlack
- OISD basic
- 1Hosts mini
これで 広告の9割以上は消えるし、
スマホアプリも安定する。
🟫 9. ブロックリスト追加後の必須操作
Pi‑hole → Tools → Update Gravity
これでリストが反映される。
🟪 第2章まとめ
| 内容 | ポイント |
|---|
| ブロックリストの種類 | 広告・トラッカー・マルウェア |
| 追加方法 | Adlists に URL を追加 |
| 初心者向け | StevenBlack / OISD basic |
| 中級者向け | OISD full / Energized Blu |
| 上級者向け | Energized Ultimate / 1Hosts Pro |
| 日本向け | AdGuard Japanese filters |
| スマホ誤ブロック対策 | Query Log → Allow / リスト調整 |
| 推奨構成 | StevenBlack + OISD basic + 1Hosts mini |
🟥 第3章：Pi‑hole セットアップ後の最適化と運用の実践ガイド
Pi‑hole を導入してブロックリストを追加したら、次は 運用フェーズに入る。
この章では、Pi‑hole をより快適に使うための 最適化・ログの読み方・スマホ対策・ホワイトリスト運用・DNS キャッシュ管理などをまとめる。
🟩 1. Pi‑hole の「Query Log」の読み方
Pi‑hole の運用で最も重要なのが Query Log（クエリログ）。
✔ ここで分かること
- どの端末が
- どのドメインに
- どの種類の DNS クエリを投げ
- ブロックされたか / 許可されたか
がリアルタイムで分かる。
✔ 見るべきポイント
- Client（クライアント）
→ どの端末が通信しているか
- Domain（ドメイン）
→ どのサービスが通信しているか
- Status（ステータス）
→ Blocked / OK / Cached
- Type（A / AAAA / PTR）
→ IPv4 / IPv6 / 逆引き
✔ 使い方のコツ
- スマホの IP をフィルタして、アプリの挙動を追う
- ブロックされて困るドメインは Allow（Whitelist）
- 不審なドメインは Block（Blacklist）
🟦 2. Long-term Data（長期データ）の活用
Pi‑hole には標準で 長期ログ分析機能がある。
✔ 見られるデータ
- 日別のクエリ数
- ブロック率
- クライアント別の通信量
- 時間帯別のヒートマップ
- 上位ドメイン / 上位広告サーバー
✔ 活用例
- スマホが夜中にどれだけ通信しているか
- どの端末が最もトラッキングされているか
- 広告ブロック率の推移
- 不審な通信の検出
Pi‑hole を“可視化ツール”として使うなら、ここは必ずチェックしたい。
🟧 3. スマホ最適化（重要）
スマホは PC と違い、アプリが大量の API を叩くため、
ブロックリストが強いと アプリが固まる・画像が読み込まれないなどの問題が起きる。
✔ 3-1. スマホで問題が起きたときの最短解決法
① Query Log でスマホの IP をフィルタ
→ 赤くブロックされているドメインを確認
② 必要なドメインは Allow（Whitelist）
例：
- googleapis.com
- firebaseio.com
- akamaihd.net
- cloudfront.net
- graph.facebook.com
- line.me
- amazonaws.com
③ スマホの DNS キャッシュをクリア
- iPhone → 機内モード ON/OFF
- Android → Wi‑Fi OFF/ON
✔ 3-2. スマホの DNS が Pi‑hole を使っているか確認
スマホの Wi‑Fi 詳細で：
になっているか確認。
✔ 3-3. スマホの「プライベート DNS / プライベートリレー」を無効化
iPhone
Android
- 設定 → ネットワーク → プライベート DNS → OFF
これらが ON だと Pi‑hole をバイパスする。
🟨 4. Whitelist（許可）と Blacklist（遮断）の運用
Pi‑hole の運用は Whitelist と Blacklist の管理が肝。
✔ Whitelist（許可）
アプリやサービスが必要としているのにブロックされているドメインを許可する。
例：
graph.facebook.com（ログイン系で必要）googleapis.com（多くのアプリが使用）firebaseio.com（通知・同期で使用）
✔ Blacklist（遮断）
広告・トラッカー・マルウェアなどを手動で追加。
例：
doubleclick.netadservice.google.comscorecardresearch.com
✔ 運用のコツ
- スマホアプリが固まったら Query Log を確認
- 必要なものは Allow
- 不審なものは Block
- ブロックリストは“育てる”もの
🟩 5. DNS キャッシュの扱い
Pi‑hole は DNS キャッシュを持っているため、
設定変更後に反映されないことがある。
✔ Pi‑hole のキャッシュクリア
SSH で：
pihole restartdns
または Web UI → Tools → Restart DNS resolver
✔ クライアント側のキャッシュクリア
Windows
ipconfig /flushdns
macOS
sudo killall -HUP mDNSResponder
iPhone / Android
- 機内モード ON/OFF
- Wi‑Fi OFF/ON
🟦 6. ルーターとの連携（DHCP / DNS）
Pi‑hole を家庭内 DNS として使う場合、
ルーターの DNS 設定が重要。
✔ ルーターの DNS を Pi‑hole に向ける
- プライマリ DNS：192.168.0.250
- セカンダリ DNS：空欄（推奨）
✔ DHCP を Pi‑hole に移す（上級者向け）
メリット：
- すべての端末が Pi‑hole を確実に使う
- クライアント名が正しく表示される
- IPv6 も Pi‑hole 経由にできる
デメリット：
- ルーターの DHCP を OFF にする必要がある
- ネットワーク構成が Pi‑hole に依存する
家庭環境によっては非常に便利。
🟧 7. Pi‑hole のバックアップ（Teleporter）
Pi‑hole には Teleporter というバックアップ機能がある。
バックアップできるもの：
- ブロックリスト
- Whitelist / Blacklist
- DHCP 設定
- ローカル DNS
- グループ設定
Pi‑hole → Settings → Teleporter
NAS のバックアップと合わせて使うと安心。
🟫 第3章まとめ
| 項目 | 内容 |
|---|
| Query Log | スマホの誤ブロック調査に必須 |
| Long-term Data | 広告・通信量の可視化 |
| スマホ最適化 | プライベート DNS / IPv6 に注意 |
| Whitelist | アプリが必要な通信を許可 |
| Blacklist | 広告・トラッカーを手動で遮断 |
| DNS キャッシュ | Pi‑hole / クライアント両方でクリア |
| ルーター連携 | DNS を Pi‑hole に向ける |
| Teleporter | 設定のバックアップ |
と、ここまで、Pi-holeのセットアップを書いてきました。
この先は、ついでというか、好みです。
こんなこともできますよ。ってことですね。
なので、特にやらなくてもOKです。
やると更に良いよ。っていう感じですので、参考に。
🟥 第4章：Pi‑hole のログをレポート化する（Grafana + Prometheus）完全ガイド
Pi‑hole は標準でもログ分析機能を持っているが、
Prometheus + Grafana を組み合わせると、Pi‑hole の DNS トラフィックを美しいダッシュボードで可視化できる。
- どの端末がどれだけ通信しているか
- 広告ブロック率の推移
- 時間帯別のトラフィック
- スマホの挙動
- 不審なドメインの検出
などが一目で分かるようになる。
Synology + Docker なら、この構成は非常に相性が良い。
🟩 1. 全体構成図
Pi-hole → pihole-exporter → Prometheus → Grafana
- Pi-hole：DNS サーバー
- pihole-exporter：Pi-hole のメトリクスを Prometheus 形式に変換
- Prometheus：メトリクスを収集・保存
- Grafana：ダッシュボードで可視化
🟦 2. 必要なコンテナ
Synology の Docker（Container Manager / Portainer）で以下を動かす：
- Prometheus
- Grafana
- pihole-exporter（Pi-hole 用 Prometheus exporter）
すべて Docker で完結する。
🟧 3. pihole-exporter のセットアップ
まず、Pi-hole の API トークンを取得する。
Pi-hole Web UI →
Settings → API / Web interface → Show API token
これを控えておく。
✔ docker-compose（Portainer Stack 用）
version: "3"
services:
pihole-exporter:
image: ekofr/pihole-exporter:latest
container_name: pihole-exporter
environment:
PIHOLE_HOSTNAME: "http://192.168.0.250"
PIHOLE_PASSWORD: "あなたのPi-holeパスワード"
INTERVAL: "30s"
ports:
- "9617:9617"
restart: unless-stopped
ポイント
PIHOLE_HOSTNAME は Pi-hole の IPPIHOLE_PASSWORD は API トークンでも可9617 が exporter のメトリクス公開ポート
🟨 4. Prometheus のセットアップ
Prometheus は exporter からメトリクスを収集する。
✔ docker-compose
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- /volume1/docker/prometheus:/etc/prometheus
ports:
- "9090:9090"
restart: unless-stopped
✔ Prometheus の設定ファイル（prometheus.yml）
Synology の /volume1/docker/prometheus/prometheus.yml に作成：
global:
scrape_interval: 30s
scrape_configs:
- job_name: 'pihole'
static_configs:
- targets: ['pihole-exporter:9617']
🟩 5. Grafana のセットアップ
Grafana はダッシュボードを表示する UI。
✔ docker-compose
grafana:
image: grafana/grafana:latest
container_name: grafana
ports:
- "3000:3000"
volumes:
- /volume1/docker/grafana:/var/lib/grafana
restart: unless-stopped
🟦 6. Grafana の初期設定
ブラウザで：
http://NASのIP:3000
初期ログイン：
- ユーザー：admin
- パスワード：admin（初回変更あり）
✔ Prometheus をデータソースとして追加
Grafana →
Settings → Data Sources → Add data source → Prometheus
URL：
http://prometheus:9090
Save & Test → OK
🟧 7. Pi-hole ダッシュボードをインポート
Grafana には Pi-hole 用の完成ダッシュボードがある。
代表的なダッシュボード ID
- ID: 10176（最も人気）
- ID: 11836（軽量版）
- ID: 15420（最新構成）
Grafana →
Dashboard → Import → Dashboard ID を入力
データソースに Prometheus を選択。
🟨 8. ダッシュボードで見られる内容
Pi-hole ダッシュボードは非常に情報量が多い。
✔ DNS クエリ総数
- 時間帯別のクエリ数
- A / AAAA / PTR / SRV の比率
✔ ブロック率
✔ クライアント別トラフィック
- PC / スマホ / IoT の通信量
- どの端末が最もトラッキングされているか
✔ 上位ドメイン
- 最もアクセスされているサイト
- 最もブロックされた広告サーバー
✔ 不審な通信の検出
- 深夜の異常な通信
- 特定端末の大量クエリ
- マルウェアドメインへのアクセス
🟫 9. スマホの挙動を可視化する
スマホはアプリが大量の API を叩くため、
Grafana で見ると アプリごとの通信パターンが丸見えになる。
例：
- Instagram → facebook / akamai
- LINE → line.me / naver
- YouTube → googlevideo / ytimg
- ゲーム → cloudfront / firebase
誤ブロックの原因調査にも役立つ。
🟪 10. 運用のコツ
✔ Prometheus の保存期間を延ばす
デフォルトは 15 日。
長期分析したいなら 90 日〜180 日に延長。
✔ ダッシュボードを複数作る
- スマホ専用
- PC 専用
- IoT 専用
- 広告ブロック率専用
✔ アラートを設定
- 異常なクエリ数
- マルウェアドメイン
- 特定端末の暴走
🟧 第4章まとめ
| 項目 | 内容 |
|---|
| pihole-exporter | Pi-hole のメトリクスを Prometheus 形式に変換 |
| Prometheus | メトリクス収集・保存 |
| Grafana | ダッシュボードで可視化 |
| ダッシュボード | 10176 / 11836 / 15420 |
| 可視化できる内容 | クエリ数・ブロック率・端末別通信量 |
| スマホ分析 | アプリの挙動が丸見え |
| 運用のコツ | 保存期間・アラート・複数ダッシュボード |
🟥 第5章：Unbound を追加して “完全ローカル DNSSEC” を構築する
Pi‑hole は単体でも強力だが、上流 DNS を外部（Google / Cloudflare）に依存している限り、
プライバシー・セキュリティ・レイテンシの面で限界がある。
そこで登場するのが Unbound（フルリゾルバ）。
Unbound を Pi‑hole の上流 DNS として使うことで：
- 外部 DNS に問い合わせない
- DNSSEC をローカルで検証
- プライバシー最大化
- レイテンシ改善
- 広告ブロックの精度向上
という “Pi‑hole の最終形態” が完成する。
Synology + Docker なら、Unbound を Pi‑hole の横に置くだけで構築できる。
🟩 1. Unbound を使うメリット
✔ 1. 完全ローカル DNS（外部に依存しない）
Google DNS や Cloudflare DNS を使わず、
ルート DNS から直接問い合わせる。
✔ 2. DNSSEC をローカルで検証
DNS の改ざんを防ぐ仕組み。
外部 DNS に任せず、自分の環境で検証できる。
✔ 3. プライバシー最大化
外部 DNS に「どのサイトを見たか」を送らない。
✔ 4. レイテンシ改善
キャッシュがローカルに溜まるため、
2回目以降の DNS が爆速になる。
✔ 5. Pi‑hole と相性が最高
Pi‑hole → Unbound の構成は公式でも推奨されている。
🟦 2. Unbound の Docker セットアップ
Synology の Docker（Portainer / Container Manager）で Unbound を追加する。
✔ docker-compose（Portainer Stack 用）
version: "3"
services:
unbound:
image: mvance/unbound:latest
container_name: unbound
restart: unless-stopped
networks:
pihole_macvlan:
ipv4_address: 192.168.0.251
volumes:
- /volume1/docker/unbound:/opt/unbound/etc/unbound
ポイント
- Pi‑hole と同じ macvlan に入れる
- Unbound の IP を 192.168.0.251 に固定
- 設定ファイルは
/volume1/docker/unbound に置く
🟧 3. Unbound の設定ファイル（unbound.conf）
Synology の /volume1/docker/unbound/unbound.conf に作成：
server:
verbosity: 1
interface: 0.0.0.0
port: 53
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
# DNSSEC
auto-trust-anchor-file: "/var/lib/unbound/root.key"
# キャッシュ
cache-min-ttl: 3600
cache-max-ttl: 86400
# セキュリティ
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
harden-referral-path: yes
# 最適化
prefetch: yes
prefetch-key: yes
これは Pi‑hole 公式推奨構成をベースに、
Synology 用に最適化したもの。
🟨 4. Pi‑hole の上流 DNS を Unbound に変更
Pi‑hole Web UI →
Settings → DNS
ここで Custom DNS に以下を入力：
192.168.0.251#53
Cloudflare / Google のチェックは外す。
これで Pi‑hole → Unbound → ルート DNS の流れになる。
🟩 5. 動作確認
Pi‑hole の Tools → Query Log を見ると：
OK (forwarded to 192.168.0.251)
と表示される。
✔ DNSSEC の確認
SSH から：
dig sigfail.verteiltesysteme.net @192.168.0.250
→ SERVFAIL が返れば OK（DNSSEC が効いている）
dig sigok.verteiltesysteme.net @192.168.0.250
→ 正常に返れば OK
🟦 6. Unbound + Pi‑hole の最適化ポイント
✔ 1. Unbound のキャッシュ TTL を調整
TTL を長めにするとレイテンシが改善。
✔ 2. Pi‑hole の DNS キャッシュと競合しない
Pi‑hole は軽いキャッシュ、Unbound は深いキャッシュ
→ 相性が良い
✔ 3. スマホの DNSSEC 対応
iPhone / Android どちらも問題なく動作する。
🟧 7. Unbound 導入後のメリット（実測ベース）
- DNS レスポンスが 平均 30〜50% 高速化
- 広告ブロック率が微増
- プライバシーが大幅向上
- 外部 DNS 障害の影響を受けない
- スマホアプリの挙動が安定することも多い
特に Synology のような常時稼働環境では、
Unbound のキャッシュが効いて体感がかなり変わる。
🟫 第5章まとめ
| 項目 | 内容 |
|---|
| Unbound の役割 | フルリゾルバ（外部 DNS 不要） |
| メリット | プライバシー・DNSSEC・高速化 |
| Docker 構成 | Pi‑hole と同じ macvlan |
| 設定ファイル | DNSSEC + キャッシュ最適化 |
| Pi‑hole 側設定 | 上流 DNS を Unbound に変更 |
| 動作確認 | dig で DNSSEC チェック |
| 効果 | レイテンシ改善・安定性向上 |
🟥 第6章：Pi‑hole の高度な運用テクニック（プロ向け）
Pi‑hole を導入し、ブロックリストや Unbound を組み合わせることで、
家庭内ネットワークはすでに強力な広告・トラッキング防御システムになっている。
この章では、さらに一歩進んで ネットワーク全体を Pi‑hole 中心に最適化するための高度なテクニックを紹介する。
🟩 1. ローカル DNS レコードの活用（LAN 内の名前解決）
Pi‑hole はローカル DNS サーバーとしても使える。
✔ できること
- NAS や PC に 名前でアクセスできる
192.168.0.10 → nas.local192.168.0.20 → server.local- Docker コンテナにも名前を付けられる
✔ 設定方法
Pi‑hole Web UI →
Local DNS → DNS Records
例：
| Domain | IP |
|---|
| nas.local | 192.168.0.10 |
| pihole.local | 192.168.0.250 |
| unbound.local | 192.168.0.251 |
✔ メリット
- LAN 内のアクセスが快適
- スマホや PC で名前解決が統一される
- ルーターの DNS より柔軟
🟦 2. IoT デバイスの管理（トラッキング遮断）
IoT デバイスは大量のトラッキングを行う。
Pi‑hole を使うと IoT の挙動が丸見えになり、不要な通信を遮断できる。
✔ よくある IoT の通信例
amazonaws.com（Alexa）googleapis.com（Chromecast）tuyaus.com（スマート家電）xiaomi.com（スマートデバイス）
✔ 対策
- Query Log で IoT の IP をフィルタ
- 不審なドメインは Block
- 必要なものだけ Allow
✔ IoT 専用グループを作る
Group Management → Groups
IoT 用のグループを作り、
強めのブロックリストを IoT のみに適用することも可能。
🟧 3. DHCP を Pi‑hole に移行する（上級者向け）
Pi‑hole を DHCP サーバーにすると、
すべての端末が Pi‑hole を確実に DNS として使うようになる。
✔ メリット
- クライアント名が正しく表示される
- IPv6 も Pi‑hole 経由にできる
- DNS バイパスが不可能になる
- ネットワーク管理が一元化される
✔ デメリット
- ルーターの DHCP を OFF にする必要がある
- Pi‑hole が落ちると DHCP も止まる
✔ 設定方法
Pi‑hole Web UI →
Settings → DHCP
- DHCP Server → ON
- Range：192.168.0.100〜192.168.0.200
- Router（Gateway）：192.168.0.1
ルーター側の DHCP は OFF にする。
🟨 4. DNS over HTTPS / DNS over TLS の扱い
Unbound を導入した場合、
DoH / DoT は不要になる。
理由：
- Unbound はルート DNS に直接問い合わせる
- 外部 DNS に依存しない
- プライバシーは Unbound の方が上
- Pi‑hole 公式も Unbound を推奨
✔ DoH / DoT を使うべきケース
- 公衆 Wi‑Fi で DNS を暗号化したい
- Pi‑hole を外部公開している（非推奨）
家庭内 LAN では Unbound が最適。
🟩 5. Pi‑hole のセキュリティ強化
Pi‑hole は LAN 内で動くため攻撃対象にはなりにくいが、
以下の設定をしておくとより安全。
✔ 5-1. Web UI のパスワードを強化
Settings → System → Web password
✔ 5-2. Pi‑hole を外部公開しない
ポート 53 / 80 / 443 を WAN に開けないこと。
✔ 5-3. macvlan を使う（あなたはすでにOK）
Synology の bridge モードより安全。
✔ 5-4. Pi‑hole のログを NAS のログセンターに送る
syslog を使えば監査ログが残せる。
🟦 6. ログの長期保存戦略
Pi‑hole のログは /etc/pihole/pihole-FTL.db に保存される。
✔ 長期保存したい場合
- Prometheus（第4章）で保存期間を延長
- Pi‑hole の DB を NAS のバックアップに含める
- Teleporter で設定をエクスポート
🟧 7. 複数 Pi‑hole の冗長化（HA 構成）
Pi‑hole は軽量なので、
2台構成にすると DNS が止まらない。
✔ 構成例
- Pi‑hole A：192.168.0.250
- Pi‑hole B：192.168.0.252
- ルーターの DNS を A → B の順に設定
✔ メリット
- Pi‑hole のアップデート中も DNS が止まらない
- 片方が落ちてもネットが生きる
🟫 第6章まとめ
| 項目 | 内容 |
|---|
| ローカル DNS | LAN 内の名前解決を統一 |
| IoT 管理 | 不審な通信を可視化・遮断 |
| DHCP 移行 | Pi‑hole をネットワークの中心に |
| DoH / DoT | Unbound 導入後は不要 |
| セキュリティ | 外部公開禁止・パスワード強化 |
| ログ保存 | Prometheus / Teleporter |
| 冗長化 | Pi‑hole 2台構成で DNS を止めない |
🟥 第7章：Pi‑hole を使ったネットワーク全体の最適化とトラブルシューティング
Pi‑hole を導入し、ブロックリスト・Unbound・Grafana まで構築したら、
家庭内ネットワークはすでに“プロレベル”の DNS フィルタリング環境になっている。
しかし、ネットワークは環境によって挙動が異なるため、
最適化・トラブルシューティングの知識があると運用が格段に楽になる。
この章では、Pi‑hole を中心にネットワーク全体を最適化し、
問題が起きたときに素早く原因を特定するための実践的なテクニックをまとめる。
🟩 1. スマホの DNS 問題を完全に解決する
スマホは PC と違い、DNS の扱いが特殊で、
Pi‑hole 導入後に最も問題が起きやすい。
✔ 1-1. スマホが Pi‑hole を使っているか確認
スマホの Wi‑Fi 詳細で：
- DNS → 192.168.0.250（Pi‑hole）
になっているか確認。
ルーターを Pi‑hole に向けても、
スマホが独自 DNS を使うことがある。
✔ 1-2. iPhone の「iCloud プライベートリレー」を無効化
iPhone → 設定 → Apple ID → iCloud → プライベートリレー → OFF
これが ON だと DNS が Apple 経由になる。
✔ 1-3. Android の「プライベート DNS」を無効化
Android → 設定 → ネットワーク → プライベート DNS → OFF
dns.google などが設定されていると Pi‑hole をバイパスする。
✔ 1-4. IPv6 の扱い
スマホは IPv6 を優先するため、
ルーターの IPv6 DNS が Pi‑hole になっていないと通信が詰まる。
対策：
- ルーターの IPv6 DNS を空欄にする
- または Pi‑hole の IPv6 アドレスを設定する（macvlan なら可能）
🟦 2. ルーター別の最適設定（NEC / Buffalo / ASUS / TP-Link）
ルーターによって DNS の扱いが違うため、
Pi‑hole を正しく使うには最適設定が必要。
✔ NEC（Aterm）
- DNS を Pi‑hole に設定すると IPv6 が優先される
- IPv6 DNS を空欄にするのが最適解
- DHCPv6 を OFF にすると安定
✔ Buffalo
- DNS を Pi‑hole に設定しても 端末に配布されないことがある
- DHCP を Pi‑hole に移すと安定
✔ ASUS（RT-AX シリーズ）
- Pi‑hole との相性が非常に良い
- WAN → DNS → 手動設定で Pi‑hole を指定
- IPv6 DNS を空欄にする
✔ TP-Link
- DNS を Pi‑hole に設定しても、端末が Google DNS を使うことがある
- 「DNS Relay」を OFF にする
🟧 3. ゲーム機・テレビの最適化
ゲーム機やテレビは DNS を独自に使うことがあり、
Pi‑hole で広告をブロックすると動作が不安定になることがある。
✔ Nintendo Switch
- eShop の画像が読み込まれない場合
→ ctest.cdn.nintendo.net を Allow
✔ PlayStation
- PSN のログインが遅い場合
→ playstation.net 系を Allow
✔ Amazon Fire TV
- 広告が多いが、ブロックしすぎるとアプリが起動しない
→ amazonaws.com は Allow 推奨
✔ スマートテレビ（LG / Sony / Samsung）
- OS のアップデートが止まることがある
→ lgsmartad.com などは Block しても OK
→ samsungcloudsolution.com は Allow 推奨
🟨 4. VPN（WireGuard）と Pi‑hole の連携
VPN を使うと、外出先からでも Pi‑hole を使える。
✔ 構成例（最も安定）
- Synology → WireGuard（Docker）
- Pi‑hole → macvlan
- WireGuard の DNS → 192.168.0.250（Pi‑hole）
メリット
- 外出先でも広告ブロック
- 公衆 Wi‑Fi でも安全
- 家のネットワークに完全接続
🟩 5. 速度低下の原因と対策
Pi‑hole 導入後に「ネットが遅い」と感じる場合、
原因は DNS ではなく 別の要因であることが多い。
✔ 原因1：IPv6 が Pi‑hole をバイパスしている
→ ルーターの IPv6 DNS を空欄にする
✔ 原因2：スマホのプライベート DNS
→ OFF にする
✔ 原因3：ブロックリストが強すぎる
→ OISD basic に戻す
✔ 原因4：ルーターの DNS Relay が ON
→ OFF にする（TP-Link など）
✔ 原因5：Unbound のキャッシュが効いていない
→ Unbound の TTL を調整（第5章参照）
🟧 6. Pi‑hole のバックアップ戦略
Pi‑hole は設定が多いため、
バックアップを取っておくと復旧が簡単。
✔ Teleporter（Pi‑hole 標準）
バックアップできるもの：
- ブロックリスト
- Whitelist / Blacklist
- DHCP 設定
- ローカル DNS
- グループ設定
Pi‑hole → Settings → Teleporter
✔ Synology のバックアップと連携
/volume1/docker/pihole を Hyper Backup に含める- Unbound の設定も同様にバックアップ
🟫 第7章まとめ
| 項目 | 内容 |
|---|
| スマホ最適化 | プライベート DNS / IPv6 / キャッシュ |
| ルーター最適化 | メーカー別の癖に対応 |
| ゲーム機・TV | 必要なドメインを Allow |
| VPN 連携 | 外出先でも Pi‑hole を利用 |
| 速度低下対策 | IPv6 / DNS Relay / ブロックリスト |
| バックアップ | Teleporter + NAS バックアップ |
🟥 第8章：Pi‑hole + Unbound + Grafana を使った “家庭内ネットワークの完全自動監視システム”
Pi‑hole を導入し、Unbound でローカル DNSSEC を構築し、Grafana で可視化した時点で、
家庭内ネットワークはすでにプロレベルのセキュリティと透明性を獲得している。
しかし、ここからさらに一歩進めると、
ネットワークの異常検知・IoT の挙動監視・トラッキング検出・自動アラートまで実現できる。
この章では、Pi‑hole を中心にした 完全自動監視システムの構築方法をまとめる。
🟩 1. 監視システムの全体構成
Pi-hole → pihole-exporter → Prometheus → Grafana → Alerting
- Pi-hole：DNS フィルタリング
- Unbound：ローカル DNSSEC
- Prometheus：メトリクス収集
- Grafana：可視化
- Alerting：異常検知（メール / Discord / Slack など）
この構成は企業レベルの監視システムと同等。
🟦 2. 監視できる項目一覧
このシステムで監視できるものは非常に多い。
✔ DNS トラフィック
- 時間帯別のクエリ数
- A / AAAA / PTR / SRV の比率
- ブロック率の推移
✔ クライアント別の挙動
どの端末がどれだけ通信しているかが一目で分かる。
✔ 広告・トラッキングの検出
- 最もブロックされた広告サーバー
- トラッキングドメインの傾向
- アプリごとの通信パターン
✔ 不審な通信の検出
- 深夜の異常なクエリ
- IoT デバイスの暴走
- マルウェアドメインへのアクセス
- DNS アンプ攻撃の兆候
✔ Unbound の DNSSEC 状態
- DNSSEC 検証成功率
- キャッシュヒット率
- レイテンシ
🟧 3. Prometheus のアラートルール（Alertmanager）
Prometheus は Alertmanager と組み合わせることで、
異常が発生したときに通知を送ることができる。
✔ 3-1. 代表的なアラート例
🔥 DNS クエリが異常に増えた
→ マルウェア感染の可能性
- alert: HighDNSQueryRate
expr: sum(rate(pihole_dns_queries_total[5m])) > 500
for: 2m
labels:
severity: warning
annotations:
description: "DNS query rate is abnormally high"
🔥 ブロック率が急上昇
→ 広告サーバーの変更 or トラッキング増加
- alert: HighBlockRate
expr: (sum(rate(pihole_ads_blocked_total[5m])) / sum(rate(pihole_dns_queries_total[5m]))) > 0.5
for: 5m
🔥 特定端末が暴走
→ IoT の異常動作
- alert: ClientAbnormalTraffic
expr: sum by (client) (rate(pihole_client_queries_total[5m])) > 200
for: 3m
✔ 3-2. 通知先の例
- Discord
- Slack
- Telegram
- Email
- Microsoft Teams
- LINE Notify
家庭内ネットワークでも十分に使える。
🟨 4. IoT デバイスの不審通信を自動検出
IoT デバイスはブラックボックスで、
何をしているか分からないことが多い。
Prometheus + Grafana を使うと：
- IoT の DNS クエリ数
- 通信先ドメイン
- 時間帯別の挙動
- 異常なスパイク
がすべて可視化される。
✔ IoT の異常検知ルール例
🔥 深夜に IoT が大量通信
- alert: IoTNightTraffic
expr: sum by (client) (rate(pihole_client_queries_total[5m])) > 50
for: 10m
labels:
severity: critical
🔥 海外の怪しいドメインにアクセス
→ Pi-hole の Query Log で即確認可能
🟩 5. スマホのトラッキング検出
スマホアプリは大量のトラッキングを行う。
Grafana で以下が分かる：
- どのアプリが最もトラッキングしているか
- どの時間帯に通信が多いか
- どの広告サーバーが使われているか
✔ 代表的なトラッキングドメイン
doubleclick.netapp-measurement.comfacebook.comgoogle-analytics.comscorecardresearch.com
これらが急増したらアラートを出すことも可能。
🟦 6. ネットワークの健康状態を自動監視
Grafana には ネットワークヘルスダッシュボードを作ることができる。
✔ 監視項目例
- Pi-hole の稼働状況
- Unbound の DNSSEC 成功率
- DNS レイテンシ
- クライアント別通信量
- ブロック率
- IoT の挙動
- スマホのトラッキング量
家庭内ネットワークの“健康診断”が自動化される。
🟧 7. 完全自動監視システムの完成図
最終的に、あなたのネットワークはこうなる：
[Pi-hole] → DNS フィルタリング
[Unbound] → ローカル DNSSEC
[pihole-exporter] → メトリクス変換
[Prometheus] → データ収集・保存
[Grafana] → 可視化
[Alertmanager] → 異常検知・通知
これは企業の SOC（Security Operation Center）と同等の構成。
家庭内ネットワークとしては 最高峰の透明性と安全性を実現する。
🟫 第8章まとめ
| 項目 | 内容 |
|---|
| 監視対象 | DNS・クライアント・IoT・トラッキング |
| Prometheus アラート | 異常検知・通知 |
| IoT 監視 | 深夜通信・海外通信の検出 |
| スマホ監視 | トラッキング量の可視化 |
| ネットワーク健康診断 | Pi-hole / Unbound / DNS の状態 |
| 完全自動化 | Grafana + Alertmanager |
これにより、AI の挙動が完全に透明になる。
と、Pi-Holeに関するまとめとして書いてみました。
まぁ、ほぼ、AIが記事は書きましたけど、一緒に進めながら書いたので、内容は間違ってないと思います。
