💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「DNS は 50ms のインフラだ」という嘘

「DNS はドメインを IP に変えるだけでしょ」と 2026年に言うと、相手は片眉を上げる。真実はもっと鋭い。**あなたが情報を最初にこぼす場所は DNS だ。** ブラウザが TLS を張るより前、VPN を張るより前、広告ブロッカーが動くより前、DNS クエリは平文で ISP リゾルバに届いている。ISP はそれを見る。見ていないふりをするが、見ている。

2026年の DNS は三つの戦線が同時に動いている。**(1) プライバシー** — DoH/DoT/DoQ でクエリを暗号化し、ODoH でクライアント IP まで分離する。**(2) セキュリティ** — DNSSEC、DNS firewall、マルウェアブロックリゾルバで悪性ドメインを弾く。**(3) パフォーマンスとコスト** — Anycast で全世界の P50 を 10ms 以下に押し下げ、HTTPS/SVCB レコード (RFC 9460) で最初のハンドシェイクを 1 ラウンドトリップに減らす。

本記事はその全体地形を一気に整理する。パブリックリゾルバ 9 種(Cloudflare、Quad9、Google、OpenDNS、AdGuard、NextDNS、ControlD、Mullvad、dns0.eu)、権威 DNS 7 種(Cloudflare DNS、Route 53、Cloud DNS、Azure DNS、NS1、DNS Made Easy、レジストラ DNS)、セルフホスト 6 種(PowerDNS、BIND9、CoreDNS、Knot、Unbound、dnsmasq)、家庭プライバシー DNS 5 種(Pi-hole 6、AdGuard Home、Technitium、Unbound+Stubby、Blocky)。最後に韓国・日本の通信事業者 DNS と攻撃シナリオ、意思決定チェックリスト。

DNS は 50ms のインフラではない。インターネット全体の信頼平面である。

1章 · DNS の基礎 — 階層、レコード、再帰 vs 権威

まず用語から。DNS は木構造だ。ルート (`.`) → TLD (`com.`、`jp.`) → 権威ネームサーバ (`example.com.`) → ホスト (`www.example.com.`)。各段階は委任 (delegation) で接続され、各段階の権威サーバがその zone の真実の源泉となる。

| 役割 | 意味 | 代表 |

| --- | --- | --- |

| Recursive resolver (再帰リゾルバ) | クライアントの代わりにルートから権威までたどり、答えをキャッシュする | Cloudflare 1.1.1.1、Quad9 9.9.9.9、ISP DNS、Unbound |

| Authoritative server (権威サーバ) | 自分が持つ zone の真実を応答する | Cloudflare DNS、Route 53、BIND9、PowerDNS |

| Stub resolver | OS 内の最も薄いクライアント、通常は 1 つのリゾルバに委任 | systemd-resolved、Windows DNS Client |

| Forwarder | 自分はキャッシュだけし、実際の再帰は上流に委任 | dnsmasq、Pi-hole、家庭用ルータ |

実務でよく出会うレコードタイプは決まっている。

| タイプ | 意味 | 例 |

| --- | --- | --- |

| A | IPv4 アドレス | `example.com. 300 IN A 93.184.216.34` |

| AAAA | IPv6 アドレス | `example.com. 300 IN AAAA 2606:2800:220:1::1` |

| CNAME | 別名 | `www.example.com. 300 IN CNAME example.com.` |

| MX | メールサーバ | `example.com. 300 IN MX 10 mail.example.com.` |

| TXT | 任意テキスト (SPF、DKIM、検証) | `example.com. 300 IN TXT "v=spf1 -all"` |

| SRV | サービスディスカバリ | `_sip._tcp.example.com. 300 IN SRV 0 5 5060 sip.example.com.` |

| CAA | 証明書発行権限制御 | `example.com. 300 IN CAA 0 issue "letsencrypt.org"` |

| HTTPS / SVCB | サービスバインディング (RFC 9460) | `example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=...` |

| DNSKEY / RRSIG / DS | DNSSEC キー、署名、委任署名 | DNSSEC 有効化された zone |

TTL (Time To Live) はリゾルバが答えをキャッシュしてよい秒数だ。長すぎると変更の伝播が遅く、短すぎると権威サーバに負荷をかける。一般ウェブは 300〜3600 秒、ゲーム/CDN は 60 秒以下が普通。

2章 · DNS over HTTPS (DoH, RFC 8484)

DoH は DNS クエリを HTTPS POST/GET でラップし、443 ポートで送る。2018 年 RFC 8484 で標準化され、Firefox は 2020 年から米国ユーザーに対しデフォルト有効、Chrome は同年「DNS Secure」機能で OS DNS が DoH を支えれば自動アップグレードする。

利点は明確だ。**443 ポートなのでブロックされにくく**、**ISP が平文で見ていたクエリを見られなくなる**。欠点もある。キャプティブポータルと衝突し、企業ネットワークの split DNS とよく喧嘩する。

Cloudflare 1.1.1.1 の DoH エンドポイント。

https://cloudflare-dns.com/dns-query

https://1.1.1.1/dns-query

https://1.0.0.1/dns-query

`curl` から直接クエリ — Content-Type さえ合わせれば動く。

DoH JSON API (Cloudflare 拡張)

curl -s -H 'accept: application/dns-json' \

'https://1.1.1.1/dns-query?name=example.com&type=A' | jq .

DoH wire format (RFC 8484 標準)

echo -n 'AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' | \

curl -s -H 'accept: application/dns-message' \

-H 'content-type: application/dns-message' \

--data-binary @- \

https://cloudflare-dns.com/dns-query | xxd

ブラウザ以外に OS レベル DoH も可能。Windows 11 は「設定 → ネットワーク → DNS サーバー割り当て」で DoH テンプレートを選択でき、macOS は `.mobileconfig` プロファイルで DoH を強制できる。

3章 · DNS over TLS (DoT, RFC 7858)

DoT は 853 ポート上で TLS で DNS をラップする。RFC 7858 (2016) はより早く標準化され、モバイル端末で馴染みのある方式だ。Android 9 Pie から「プライベート DNS」項目として OS レベル DoT を支える。

DoH と DoT の違いは **ポートと可視性**。

| 項目 | DoH (RFC 8484) | DoT (RFC 7858) |

| --- | --- | --- |

| ポート | 443 (HTTPS と同一) | 853 |

| 識別性 | HTTPS と混ざり実質ブロック不可 | 853 ポートブロックで止められる |

| クライアント対応 | Firefox/Chrome デフォルト、OS 一部 | Android 9+、systemd-resolved、Unbound、Stubby |

| オーバーヘッド | HTTP/2/3 ヘッダ | TLS のみ、軽量 |

systemd-resolved で DoT を有効化 — `/etc/systemd/resolved.conf` に 1 ブロック。

[Resolve]

DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com

DNSOverTLS=yes

DNSSEC=yes

Android では「設定 → ネットワークとインターネット → プライベート DNS → プライベート DNS プロバイダのホスト名」に `1dot1dot1dot1.cloudflare-dns.com` または `dns.quad9.net` を入力すれば即 DoT。

4章 · DNS over QUIC (DoQ, RFC 9250)

DoQ は 2022 年 RFC 9250 で標準化された最も新しい転送だ。QUIC (UDP ベース、0-RTT) の上に DNS を載せる。853 ポート (DoT と同番号だが UDP)。モバイルでの接続マイグレーションが滑らかで、初期 RTT が短い。

| 転送 | RFC | ポート | ハンドシェイク RTT | 備考 |

| --- | --- | --- | --- | --- |

| DoT | RFC 7858 | 853 TCP | 1〜2 | モバイル人気 |

| DoH | RFC 8484 | 443 TCP | 1〜2 | ブロック回避に強い |

| DoQ | RFC 9250 | 853 UDP | 0〜1 (0-RTT 再起) | 最新、モバイル親和 |

AdGuard DNS、NextDNS、ControlD、Cloudflare はいずれも DoQ をサポート。クライアントは dnsproxy、AdGuard Home (6.x)、パッチ版 Stubby など。

dnsproxy で DoQ を使う例。

dnsproxy --upstream='quic://dns.adguard-dns.com' \

--listen=127.0.0.1 --port=53

5章 · Oblivious DoH (ODoH) — IP も隠す

DoH/DoT/DoQ が解く問題は「**ISP に自分のクエリを見せない**」だ。しかしリゾルバ自身 (Cloudflare、Quad9) は依然として**自分の IP** と**自分のクエリ**を両方見る。ODoH (2020 年 Cloudflare + Apple + Fastly 共同提案、RFC 9230、2022 年) はこの結合を切る。

構造は単純だ。クライアント → **Oblivious Proxy** → **Oblivious Target (リゾルバ)**。

- Proxy はクライアント IP を見るがクエリは見えない (クエリは Target の公開鍵で暗号化)。

- Target はクエリを見るがクライアント IP は知らない (Proxy が隠した)。

Cloudflare の 1.1.1.1 ODoH エンドポイントと、外部 Proxy (Surfshark、ISP 非依存) を組み合わせる構成が代表的。iOS 17 から非公式にシステムレベル ODoH に対応し、dnscrypt-proxy 2.1+ は正式対応する。

dnscrypt-proxy で ODoH を設定。

/etc/dnscrypt-proxy/dnscrypt-proxy.toml

server_names = ['odoh-cloudflare']

[sources.'odoh-servers']

urls = ['https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md']

cache_file = '/var/cache/dnscrypt-proxy/odoh-servers.md'

minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'

[sources.'odoh-relays']

urls = ['https://download.dnscrypt.info/resolvers-list/v3/odoh-relays.md']

cache_file = '/var/cache/dnscrypt-proxy/odoh-relays.md'

minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'

ODoH は採用率が低いが、**VPN 無しで IP とクエリの分離**が可能な唯一に近い標準だ。

6章 · DNSSEC — 署名された DNS、しかし展開は遅い

DNSSEC は権威サーバが応答に署名を付け、リゾルバがその署名チェーン (ルート KSK → TLD ZSK → zone) を検証する。キャッシュポイズニングや偽造応答を弾く。標準は RFC 4033/4034/4035 (2005)。

問題は導入率。2026 年時点でグローバル zone の DNSSEC 有効率はおよそ 30% 台、`.jp` zone はそれより低く、`.com` は委任可能だが大半の登録者がオフにしている。

DNSSEC 検証の確認。

+dnssec フラグで RRSIG を確認

dig +dnssec example.com A

AD ビット = Authenticated Data (リゾルバの検証が通った)

dig @1.1.1.1 +dnssec icann.org SOA | grep -E 'flags|RRSIG'

DNSSEC への実務評価は割れている。擁護派は「キャッシュポイズニングへの最後の防御線」、懐疑派は「DoT/DoH があればチャネルは既に認証され、zone 署名は運用負担だけ増やす」。2026 年の現実: **権威 zone は署名しろ、クライアント検証はリゾルバに任せろ**。

7章 · DNS firewall — 悪性ドメインを弾く

DNS firewall は既知の悪性/フィッシング/マルウェアドメインをリゾルバレベルで NXDOMAIN に落とす。RPZ (Response Policy Zone、BIND9 起源)、Cloudflare Gateway、Quad9 のデフォルトポリシー、Cisco Umbrella (旧 OpenDNS) などがこのカテゴリ。

| プロバイダ | ブロックカテゴリ | 価格 |

| --- | --- | --- |

| Cloudflare Gateway | マルウェア、フィッシング、C2、カテゴリフィルタ | Zero Trust 50 ユーザーまで無料 |

| Quad9 9.9.9.9 | マルウェア、ボットネット (スイス、ノーログ) | 無料 |

| Cisco Umbrella | マルウェア、フィッシング、信頼レピュテーション、DLP | ユーザー/月課金 |

| AdGuard DNS Family | マルウェア + 成人 + 広告 | 無料/有料 |

| NextDNS | 全カテゴリカスタム | 無料 30 万クエリ/月 + 有料 |

RPZ は zone ファイル形式でポリシーを表現する。`example.com` をブロックするなら。

$TTL 60

@ SOA rpz.local. admin.local. (1 1h 15m 30d 2h)

NS rpz.local.

; example.com とすべてのサブドメインを NXDOMAIN に

example.com CNAME .

*.example.com CNAME .

; some-malware.example.org を walled-garden IP に

some-malware.example.org CNAME walled-garden.local.

BIND9 で named.conf に RPZ を有効化したあと、`dig @localhost example.com` は `NXDOMAIN` を返す。

8章 · Cloudflare 1.1.1.1 — 最も引用されるパブリックリゾルバ

Cloudflare 1.1.1.1 は 2018 年 4 月 1 日に出た (エイプリルフールだが本物のサービス)。APNIC と協力して `1.1.1.0/24` を受け取り、「**クエリログを取らない、売らない**」を毎年 KPMG 監査で証明する。

3 種のエンドポイント。

| IP | ポリシー | 用途 |

| --- | --- | --- |

| 1.1.1.1 / 1.0.0.1 | 無フィルタ (純リゾルバ) | 一般 |

| 1.1.1.2 / 1.0.0.2 | マルウェアブロック | セキュリティ強化 |

| 1.1.1.3 / 1.0.0.3 | マルウェア + 成人ブロック | 家庭/学校 |

IPv6 も `2606:4700:4700::1111`、`::1001`、`::1112`、`::1113` に同ポリシー対応。

DoH/DoT/DoQ いずれも対応、1.1.1.1 自体が Anycast で 300+ PoP に展開され、平均 P50 は一桁 ms。日本ユーザーの場合は東京/大阪/シンガポール PoP に到達する。

最大の批判は「**集中**」。世界の DNS クエリの相当部分が Cloudflare を通る事実自体が一種の単一障害点/観測点だ。だから擁護派でも「Cloudflare 単独より Quad9、dns0.eu と分散しろ」と言う。

9章 · Quad9 9.9.9.9 — スイス、ノーログ、マルウェアブロック

Quad9 は 2017 年に IBM Security X-Force、PCH (Packet Clearing House)、GCA (Global Cyber Alliance) が共同で立ち上げた非営利リゾルバだ。スイスの非営利財団として運営 (2021 年以降)、GDPR とスイスのデータ保護法で保護される。

エンドポイント。

| IP | ポリシー |

| --- | --- |

| 9.9.9.9 / 149.112.112.112 | セキュリティブロック (マルウェア RPZ) + DNSSEC 検証 + ノーログ |

| 9.9.9.10 / 149.112.112.10 | セキュリティブロックなし、最速 |

| 9.9.9.11 / 149.112.112.11 | セキュリティブロック + ECS (EDNS Client Subnet、CDN への位置ヒント) |

IPv6: `2620:fe::fe`、`2620:fe::9`。

Quad9 の**差別化点**は二つ。(1) **ノーログの法的保護** — スイス司法管轄は米国/英国より NSL や秘密令状に強い。(2) **17 のマルウェアインテリジェンスフィード統合** — IBM、Anomali、Domain Tools、Proofpoint などのフィードをリアルタイムにマージしブロックリスト化する。

パフォーマンスは Cloudflare より少し遅い (日本から P50 15〜20ms)。しかしセキュリティブロックを有効にしながら false positive がほぼ 0 なのが強み。企業/学校で最も推奨される。

10章 · Google 8.8.8.8 — 速いがログを取る

Google Public DNS (2009 年公開) は最古のパブリックリゾルバの 1 つ。8.8.8.8 と 8.8.4.4 はほぼすべてのネットワークエンジニアが暗記している IP だ。

利点: **圧倒的なグローバルカバレッジ**、**DNS64 対応** (IPv6 のみのネットワークから IPv4 互換)、**DoH/DoT 対応**。

欠点: **ログを取る**。Google は短期ログ (24〜48 時間、IP 含む) と永続ログ (IP 匿名化後) に分けて保管すると明記する。広告に直接利用しないと言うが、Cloudflare/Quad9 の「**ノーログ**」ポリシーとは明確に違う。

2026 年の現実: 速くて安定しているが、**プライバシーが必要なら 1 位ではない**。ISP デフォルト DNS が遅すぎるときのフォールバックとしてよく使われる。

11章 · AdGuard DNS — 広告ブロックがデフォルト

AdGuard DNS はキプロス拠点の AdGuard Software が運営し、広告ブロックを **DNS レベル**で行う。広告ドメインを NXDOMAIN に落とすので、ブラウザ広告ブロッカー無しでもすべてのアプリで広告が消える。

エンドポイント。

| IP | ポリシー |

| --- | --- |

| 94.140.14.14 / 94.140.15.15 | 広告 + トラッカーブロック (デフォルト) |

| 94.140.14.15 / 94.140.15.16 | ファミリーモード (広告 + トラッカー + 成人) |

| 94.140.14.140 / 94.140.15.141 | 無フィルタ |

DoH `https://dns.adguard-dns.com/dns-query`、DoT `dns.adguard-dns.com`、DoQ `quic://dns.adguard-dns.com`。

広告ブロック DNS の限界も明白だ。**ファーストパーティ広告** (サービス自身のドメインから配信) は止められず、**DOM レベルのトラッキングスクリプト**も止められない。AdGuard 自身もブラウザ拡張との併用を推奨する。

12章 · NextDNS — カスタマイズ + 分析

NextDNS は 2019 年に始まったフランス系スタートアップ製のパブリックリゾルバだ。差別化点は**プロファイル単位のカスタマイズ**。

登録後に発行される ID (例 `abcdef`) をエンドポイントの一部として使う。

https://dns.nextdns.io/abcdef

abcdef.dns.nextdns.io (DoT/DoQ)

ダッシュボードで 100+ のブロックリスト (EasyList、OISD、StevenBlack、Hagezi など)、カテゴリブロック (SNS、ギャンブル、成人、マルウェア)、**ログ保管期間** (0/24h/3 ヶ月/それ以上)、**ロケーション** (EU/US/スイス) すべて選択可能。

価格: 月 30 万クエリまで無料、それ以上は $1.99/月または $19.90/年 (ファミリー、デバイス無制限)。

NextDNS の真価は**分析ダッシュボード**。どのデバイスが、どのドメインを、何回クエリしたかが一目でわかる。ファミリーモードで子どものデバイスが新たに学習したトラッキングドメインを追跡できる。

13章 · ControlD — 速くてルーティング可能なリゾルバ

ControlD はカナダの Windscribe VPN チームが作ったリゾルバ。NextDNS と似たコンセプトだが、**速度**と**トラフィックルーティング**にもっと重心がある。

差別化点:

- **Free Resolvers**: `76.76.2.0` 系列で多様な事前定義プロファイル (`p0`/p1/p2/...)。

- **Custom Profiles**: プロキシルーティング — 「Netflix は米国 IP で」「BBC は英国 IP で」のようにドメインごとの SOCKS5 ルーティングを DNS 応答で操作。

- **PoP**: 100+ グローバル、平均 P50 は一桁 ms。

DoH エンドポイント: `https://dns.controld.com/p2` (マルウェア + 広告 + トラッカー + SNS)、無料。

ControlD の弱みは **新興**。2020 年スタートなので NextDNS ほどコミュニティリストライブラリが豊富ではない。だが速度とルーティングの組み合わせは独特だ。

14章 · Mullvad DNS — VPN 会社の DNS

Mullvad はスウェーデンの VPN 会社。2022 年 11 月にパブリック DNS を別途公開し、「**アカウント無しで匿名のまま使える最強のプライバシー DNS**」を標榜する。

エンドポイントとポリシー。

| ホスト名 | ポリシー |

| --- | --- |

| `dns.mullvad.net` | 無フィルタ |

| `adblock.dns.mullvad.net` | 広告ブロック |

| `base.dns.mullvad.net` | 広告 + トラッカー |

| `extended.dns.mullvad.net` | 広告 + トラッカー + SNS |

| `family.dns.mullvad.net` | 広告 + トラッカー + 成人 |

| `all.dns.mullvad.net` | すべてブロック |

DoH/DoT/DoQ いずれも対応。IP は変動するのでホスト名で設定するのが推奨。

Mullvad の強みは**法的/技術的ノーログ**。スウェーデンは EU だがデータ保存法が緩く、Mullvad は 2020 年スウェーデン警察の押収事件で「サーバに残るデータが無い、応じるものが無い」を実証した。

15章 · dns0.eu — EU 共同リゾルバ (無料)

dns0.eu は 2023 年に出た非営利 EU リゾルバ。本部はフランス・パリ、GDPR を厳格に適用し、EU 資金/スポンサーで動く。

エンドポイント。

| IP | ポリシー |

| --- | --- |

| 193.110.81.0 / 185.253.5.0 | 無フィルタ |

| `https://zero.dns0.eu` | セキュリティブロック (マルウェア/フィッシング/暗号通貨マイナー) |

| `https://kids.dns0.eu` | ファミリーモード |

DoH/DoT/DoQ 対応。PoP は欧州中心。

dns0.eu は **欧州のデジタル主権**の流れの一部だ。Cloudflare/Google に依存しない EU 内部リゾルバを目指す。日本ユーザーには PoP が少なく遅くなりがちだが、**選択肢の多様性**としての意味は大きい。

16章 · 権威 DNS — Cloudflare DNS vs Route 53 vs Cloud DNS vs Azure DNS vs NS1

権威 DNS (自分の zone を提供する側) は市場が分かれている。

| プロバイダ | 価格モデル | 強み | 弱み |

| --- | --- | --- | --- |

ほとんどのスタートアップは **Cloudflare DNS** (ウェブ)、クラウドライフサイクルが深いチームは自社クラウドの DNS (Route 53、Cloud DNS、Azure DNS)。geo routing や weighted routing が本当に必要なチーム (グローバル SaaS、ゲーム) は **NS1**。

Cloudflare DNS は**無料だが権威 DNS として本当に速い**。2026 年 dnsperf のグローバル権威 DNS 応答時間で Cloudflare は通常 P50 10〜12ms で 1 位か 2 位 (NS1 と競り合う)。

17章 · Route 53 — AWS 統合の集大成

Route 53 は AWS の権威 DNS + ドメイン登録 + health check + traffic policy を 1 つにまとめたサービス。2010 年公開。

価格 — zone 単位 ($0.50/zone/月、25 zone までの free tier は無いので注意)、クエリ単位 (最初の 10 億クエリ/月で $0.40/100 万)。

ルーティングポリシーが豊富だ。

| ポリシー | 意味 |

| --- | --- |

| Simple | 単一応答 |

| Weighted | 重み比率で分岐 (A/B、カナリア) |

| Latency-based | AWS リージョン基準で最低レイテンシにルーティング |

| Failover | primary/secondary、health check ベース |

| Geolocation | クライアント位置 (国/大陸) ベース |

| Geoproximity | Traffic Flow、bias で距離調整 |

| Multivalue answer | 最大 8 IP、health check を通ったもののみ |

| IP-based | クライアント CIDR ベース |

Terraform で複数ポリシー zone。

resource "aws_route53_zone" "main" {

name = "example.com"

}

resource "aws_route53_record" "api" {

zone_id = aws_route53_zone.main.zone_id

name = "api.example.com"

type = "A"

set_identifier = "us-east-1"

latency_routing_policy {

region = "us-east-1"

}

alias {

name = aws_lb.us_east.dns_name

zone_id = aws_lb.us_east.zone_id

evaluate_target_health = true

}

Route 53 の弱みは **UI の重さ**と**価格の累積**。zone が数十個になると月数十ドルは普通に出る。それでも AWS ロックインのチームにはほぼデフォルト。

18章 · セルフホスト DNS — PowerDNS · BIND9 · CoreDNS · Knot · Unbound · dnsmasq

権威でも再帰でもセルフホストの選択肢は豊富だ。

| ツール | 種類 | 言語 | 特徴 |

| --- | --- | --- | --- |

| PowerDNS Authoritative | 権威 | C++ | DB バックエンド (MySQL/PostgreSQL)、API 豊富、GeoIP モジュール |

| PowerDNS Recursor | 再帰 | C++ | Lua スクリプティング、高速 |

| Knot DNS | 権威 | C | チェコ CZ.NIC、超高速、大型 zone 最適 |

| Knot Resolver | 再帰 | C | 同チームの再帰リゾルバ、DNSSEC 強い |

| Unbound | 再帰 | C | NLnet Labs、DNSSEC 強い、Stubby と組む |

CoreDNS の Corefile 例 — K8s 内部 DNS のまま。

.:53 {

errors

health {

lameduck 5s

}

ready

kubernetes cluster.local in-addr.arpa ip6.arpa {

pods insecure

fallthrough in-addr.arpa ip6.arpa

ttl 30

}

prometheus :9153

forward . /etc/resolv.conf

cache 30

loop

reload

loadbalance

}

dnsmasq は home router/Pi-hole のコアだ。100KB のバイナリで DHCP + DNS forwarder + TFTP までこなす。

19章 · Pi-hole 6 — 家庭用 DNS シンクホール

Pi-hole は 2015 年に GitHub プロジェクトとして始まった家庭用 DNS ブロックサーバだ。Raspberry Pi に載せるので有名になり、2025 年公開された **Pi-hole 6** (2024 年ベータ) は PHP Web UI を捨てて **all-Go REST API + 新 Web UI** に全面刷新した。

仕組みは単純。(1) dnsmasq ベースの forwarder として動作、(2) 広告/トラッカー/マルウェアドメインを NXDOMAIN で応答、(3) それ以外のクエリは上流リゾルバ (Cloudflare、Quad9 など) に委任、(4) 家庭単位のホワイトリスト/ブラックリスト管理。

Docker で 1 分インストール。

docker run -d \

--name pihole \

-p 53:53/tcp -p 53:53/udp \

-p 80:80/tcp \

-e TZ=Asia/Tokyo \

-e WEBPASSWORD=changeme \

-v $PWD/etc-pihole:/etc/pihole \

-v $PWD/etc-dnsmasq.d:/etc/dnsmasq.d \

--restart=unless-stopped \

pihole/pihole:latest

ルータの DHCP で DNS サーバを Pi-hole IP に変更すると、すべての家庭デバイスが Pi-hole を経由する。広告ブロック率 30〜50%、モバイルアプリ広告まで止まる。

限界: **HTTPS ページ内の広告枠**はブロックされるがページレイアウト崩れが時々発生する。**DoH で回るクライアント** (Firefox、Chrome 一部) は Pi-hole を迂回する — なのでルータレベルで DoH ブロックまたは強制リダイレクトが必要。

20章 · AdGuard Home — Pi-hole のモダンな代替

AdGuard Home は同領域の Go シングルバイナリ。Pi-hole が dnsmasq + PHP の組み合わせなのに対し、AdGuard Home は 1 バイナリにすべて入っている。

差別化点:

- **DoH/DoT/DoQ アップストリーム内蔵** — Pi-hole で cloudflared サイドカー無しで済む。

- **暗号化 DNS サーバモード** — 外部クライアントが我々の AdGuard Home に DoH/DoT で接続することもできる。

- **ユーザー別ポリシー** — デバイス/IP 別の異なるフィルタリスト、時間帯別ブロック (子どものデバイスは 22 時以降 SNS ブロック、など)。

- **DHCP 内蔵** (オプション)。

Docker インストール。

docker run --name adguardhome \

--restart unless-stopped \

-v $PWD/work:/opt/adguardhome/work \

-v $PWD/conf:/opt/adguardhome/conf \

-p 53:53/tcp -p 53:53/udp \

-p 80:80/tcp -p 443:443/tcp -p 443:443/udp \

-p 3000:3000/tcp \

-p 853:853/tcp \

-p 784:784/udp \

-d adguard/adguardhome

Pi-hole vs AdGuard Home — どちらも検証済みだ。Pi-hole はコミュニティ/ドキュメントが大きく、AdGuard Home は機能と UX がモダンだ。2026 年の新規インストールなら AdGuard Home の方をよく見る。

21章 · Technitium · Unbound + Stubby · Blocky — マイナーだが堅い選択肢

Pi-hole/AdGuard Home 以外の選択肢もある。

- **Technitium DNS Server**: .NET 製、フル権威 + 再帰 + ブロック + キャッシュ + DoH/DoT/DoQ サーバまで。UI が非常に豊富、**自己ホスト権威 zone** (例 `home.local`) を運用しながら同時に家庭ブロックリゾルバを回すときに強力。

- **Unbound + Stubby**: NLnet Labs の正統派。Unbound は自己再帰 (外部リゾルバを介さずルートからたどる)、Stubby は DoT クライアントデーモン。2 つを組めば「**外部リゾルバを信頼しない完全セルフホスト**」になる。

- **Blocky**: Go ベースの小さな DNS プロキシ。Pi-hole より軽く、Prometheus/Grafana メトリクスがエレガント。K8s に載せて社内ブロックリゾルバとして使う事例もある。

Unbound を自己再帰で動かす最小設定 — `/etc/unbound/unbound.conf`。

server:

interface: 127.0.0.1

interface: ::1

access-control: 127.0.0.0/8 allow

access-control: ::1 allow

do-ip4: yes

do-ip6: yes

do-udp: yes

do-tcp: yes

hide-identity: yes

hide-version: yes

qname-minimisation: yes

harden-glue: yes

harden-dnssec-stripped: yes

use-caps-for-id: yes

prefetch: yes

こうすると 1.1.1.1 すら経由せずクライアントがルートから直接たどって答えを得る。最も分散的な選択肢だ。

22章 · ルータでのプライバシー DNS — OpenWRT · Mikrotik · UniFi

OS やデバイスではなく**ルータ側**で DNS を強制すれば、すべての家庭トラフィックが一度に守られる。

- **OpenWRT + dnsmasq + https-dns-proxy**: OpenWRT 標準の dnsmasq を forwarder として、`https-dns-proxy` パッケージで DoH 上流 (1.1.1.1、9.9.9.9 など) を使う。`luci-app-https-dns-proxy` の GUI でクリック設定。

- **Mikrotik RouterOS 7.x**: 既存の `/ip dns` モードに加え、`/ip dns/set use-doh-server=https://...` で RouterOS 7 から正式 DoH 対応。

- **Ubiquiti UniFi**: UDM/UDR Pro で Threat Management による DNS カテゴリブロック、OS 3.x から DNS over HTTPS も一部対応。

OpenWRT で 1.1.1.1 の DoH を強制。

opkg update

opkg install https-dns-proxy luci-app-https-dns-proxy

uci set https-dns-proxy.@https-dns-proxy[0].bootstrap_dns='1.1.1.1,1.0.0.1'

uci set https-dns-proxy.@https-dns-proxy[0].resolver_url='https://cloudflare-dns.com/dns-query'

uci commit https-dns-proxy

service https-dns-proxy restart

ルータ側の強制は**モバイル DoH 回避**を減らす。Firefox や Chrome が独自 DoH を有効にしていればルータを素通りするが、一部のルータは既知の DoH ホストをブロックして強制的にシステム DNS に戻す。

23章 · デュアルスタック / IPv6 / HTTPS · SVCB レコード (RFC 9460)

2026 年の DNS は**レコードタイプ**も進化中だ。HTTPS レコード (RFC 9460、2023) は 1 つのドメインルックアップで IP + ALPN + ECH + ポートヒントをすべて受け取れる。

example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=93.184.216.34 ipv6hint=2606:2800:220:1::1

ブラウザがこの 1 行を受け取れば即座に HTTP/3 でハンドシェイクを始める。A/AAAA を別に引かなくてもよい。**ECH (Encrypted Client Hello)** 鍵もこのレコードに入る — SNI の平文露出までふさぐ。

Cloudflare DNS、Route 53 とも HTTPS/SVCB レコード入力に対応。iOS 14+/Safari、Chrome 100+ が自動で活用する。

IPv6 側 — デュアルスタック zone は A + AAAA を一緒に持ち、クライアントは happy eyeballs (RFC 8305) で速い方を選ぶ。2026 年に大手サイトの IPv6 有効率は 50% 台に乗ってきた。

24章 · 韓国 / 日本の DNS — KT · SK · LG · IIJ · NTT · Naver · JPDNS

韓国通信事業者の DNS。

| 通信事業者 | DNS IP |

| --- | --- |

| KT | 168.126.63.1 / 168.126.63.2 |

| SK Broadband | 219.250.36.130 / 210.220.163.82 |

| LG U+ | 164.124.101.2 / 203.248.252.2 |

| Naver Public DNS | 再稼働 (`dns.naver.com` 系、独自ポリシー) |

KT 168.126.63.1 は**韓国で最もよく暗記される IP** だ。しかし DoH/DoT を正式提供せず、**国家ブロック (warning.or.kr)** を SNI 検査/DNS 応答で強制リダイレクトする。プライバシーが必要なら KT DNS をそのまま使わず 1.1.1.1 や 9.9.9.9 に置き換えるのを推奨。

日本通信事業者の DNS。

| 通信事業者 | DNS IP |

| --- | --- |

| NTT ドコモモバイル | ユーザー APN 自動 |

| KDDI / au | ユーザー APN 自動 |

| SoftBank | ユーザー APN 自動 |

| IIJ (Internet Initiative Japan) | 210.130.0.5 / 210.130.1.5 |

| JPNIC / JPDNS パブリックキャッシュ | 一部 IIJ/NTT 共有 |

日本は韓国より ISP DNS への依存度が低く、IIJ のようなホールセール ISP が安定したパブリック DNS を提供する。**JPDNS** (JPNIC 運用 .jp 権威) は .jp TLD の応答を保証する。

日韓ユーザーともに推奨: **1 次 1.1.1.1 + 2 次 9.9.9.9** の組み合わせで ISP DNS を回避。ただし一部の国家ブロック/通信事業者付加サービスは ISP DNS に依存するので、ブロック/問題発生時は一時的に ISP DNS に戻す。

25章 · DNS 攻撃 — キャッシュポイズニング、トンネリング、DGA、リバインディング

DNS は攻撃面が広い。代表的な 4 種。

- **キャッシュポイズニング (Dan Kaminsky 2008)**: 再帰リゾルバのキャッシュを偽応答で埋め、すべてのクライアントを誤った IP に飛ばす。防御: ソースポートランダム化、0x20 エンコーディング、DNSSEC。

- **DNS トンネリング**: 平文 DNS の上に任意データをエンコードしてファイアウォールを迂回する。マルウェア C2 (iodine、dnscat2) で一般的。防御: DNS firewall、クエリ頻度/サイズの異常検知。

- **DGA (Domain Generation Algorithm)**: マルウェアが毎日数千の擬似ランダムドメインを生成し、C2 と通信を試みる、一部のみ実登録される。防御: ML ベース DGA 検知、RPZ。

- **DNS リバインディング**: 短い TTL で同じドメインが最初は公開 IP、次にプライベート IP を応答するように仕向け、SOP を回避する。防御: プライベート IP 応答の拒否 (Pi-hole/dnsmasq の `--stop-dns-rebind`)。

DoH/DoT は**攻撃面を減らすがゼロにはしない**。キャッシュポイズニングは平文 53 ポートのみが対象だが、トンネリングと DGA はチャネル暗号化と無関係に動く。

26章 · 意思決定チェックリスト — チーム/家庭は何を選ぶか

**個人/家庭**

1. モバイル/ノート 1 台だけ守りたい → OS のプライベート DNS (`1dot1dot1dot1.cloudflare-dns.com` または `dns.quad9.net`)。

2. 家族全体 + 広告ブロック → Raspberry Pi/Linux ボックスに **Pi-hole 6** か **AdGuard Home**、ルータの DHCP DNS をそれに向ける。

3. 外部リゾルバも信頼しない → **Unbound** の自己再帰、オプションで Stubby の DoT。

4. 分析ダッシュボードが欲しい → **NextDNS** か **ControlD**。

**スタートアップ/サービス権威 DNS**

1. 静的サイト/SaaS、コスト 0 優先 → **Cloudflare DNS**。

2. AWS ロックイン → **Route 53**、alias レコードと latency routing を活用。

3. マルチクラウド/エッジルーティング → **NS1** または Cloudflare DNS の Load Balancing。

4. 短い TTL の health-check ベースフェイルオーバー → Route 53 + health check、または NS1 Filter Chain。

**エンタープライズ**

1. 社内全デバイスの DNS firewall → **Cloudflare Gateway** か **Cisco Umbrella**。

2. 自社 DC、自社キャッシュ運用 → **PowerDNS** + **Unbound**。

3. K8s クラスタ内部 DNS → **CoreDNS** (EKS/GKE/AKS デフォルト)。

4. マルチリージョン権威 DNS、geo routing → **NS1**。

**基本ルール**: ISP デフォルト DNS からはできるだけ早く脱出しろ。1.1.1.1 + 9.9.9.9 のデュアルにするだけで、平均的なユーザーには即体感できる。

エピローグ — DNS はインターネットの信頼平面である

2026 年の DNS の本当の教訓は **「DNS はインフラではなく信頼平面である」** ということだ。誰を信頼して名前を IP に変えるか、その信頼はどこで記録されどこで遮断されどこで偽造されるか — それが DNS 選びのすべてだ。

ツールは単純だ。Cloudflare 1.1.1.1 を OS DNS に 1 行入れれば ISP の平文露出は終わる。Pi-hole/AdGuard Home を家庭ルータの後ろに置けば広告も終わる。しかしその単純な 1 行を**誰のために、誰を信頼して**書いたかは本人だけが知る。

次回候補: **Cloudflare Workers + DNS — Cloudflare を最後まで回し切る**、**DNSSEC を本気で有効化する方法 — `.com`/`.io`/`.jp` の委任実戦**、**HTTPS · SVCB レコードと ECH — 2026 年の新ハンドシェイクのすべて**。

> 「DNS を選ぶことは、自分が最初に情報をこぼしても良い相手を選ぶことだ。」

— DNS プロバイダ & プライバシー 2026、終わり。

参考 / References

- [RFC 8484 — DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484)

- [RFC 7858 — DNS over TLS (DoT)](https://www.rfc-editor.org/rfc/rfc7858)

- [RFC 9250 — DNS over QUIC (DoQ)](https://www.rfc-editor.org/rfc/rfc9250)

- [RFC 9230 — Oblivious DNS over HTTPS (ODoH)](https://www.rfc-editor.org/rfc/rfc9230)

- [RFC 9460 — Service Binding and Parameter Specification (SVCB / HTTPS records)](https://www.rfc-editor.org/rfc/rfc9460)

- [RFC 4033 — DNSSEC Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033)

- [Cloudflare 1.1.1.1](https://1.1.1.1/)

- [Cloudflare 1.1.1.1 for Families](https://one.one.one.one/family/)

- [Cloudflare Trust Hub — 1.1.1.1 audits](https://www.cloudflare.com/trust-hub/)

- [Quad9](https://quad9.net/)

- [Google Public DNS](https://developers.google.com/speed/public-dns)

- [OpenDNS / Cisco Umbrella](https://www.opendns.com/)

- [AdGuard DNS](https://adguard-dns.io/)

- [NextDNS](https://nextdns.io/)

- [ControlD](https://controld.com/)

- [Mullvad DNS](https://mullvad.net/en/help/dns-over-https-and-dns-over-tls)

- [dns0.eu](https://www.dns0.eu/)

- [AWS Route 53 Documentation](https://docs.aws.amazon.com/route53/)

- [Google Cloud DNS](https://cloud.google.com/dns/docs)

- [Azure DNS](https://learn.microsoft.com/en-us/azure/dns/dns-overview)

- [NS1 (IBM)](https://ns1.com/)

- [PowerDNS](https://www.powerdns.com/)

- [BIND9 — ISC](https://www.isc.org/bind/)

- [CoreDNS](https://coredns.io/)

- [Knot DNS — CZ.NIC](https://www.knot-dns.cz/)

- [Unbound — NLnet Labs](https://nlnetlabs.nl/projects/unbound/about/)

- [dnsmasq](https://thekelleys.org.uk/dnsmasq/doc.html)

- [Pi-hole](https://pi-hole.net/)

- [AdGuard Home](https://adguard.com/en/adguard-home/overview.html)

- [Technitium DNS Server](https://technitium.com/dns/)

- [Blocky — DNS proxy](https://0xerr0r.github.io/blocky/)

- [Stubby — DoT client](https://dnsprivacy.org/dns_privacy_daemon_-_stubby/)

- [OpenWRT https-dns-proxy](https://openwrt.org/docs/guide-user/services/dns/doh_dnsmasq_https-dns-proxy)

- [DNSperf — public DNS benchmarks](https://www.dnsperf.com/)

- [APNIC — 1.1.1.1 history](https://blog.apnic.net/2018/04/02/apnic-and-cloudflare-collaborate-to-offer-better-dns-service/)