DNS プロバイダ & プライバシー DNS 2026 — Cloudflare 1.1.1.1 / Route 53 / Quad9 / NextDNS / ControlD / Mullvad / Pi-hole / AdGuard Home 徹底解説

プロローグ — 「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 の真実の源泉となる。

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

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 の違いは ポートと可視性。

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 が短い。

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) などがこのカテゴリ。

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 種のエンドポイント。

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 とスイスのデータ保護法で保護される。

エンドポイント。

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 に落とすので、ブラウザ広告ブロッカー無しでもすべてのアプリで広告が消える。

エンドポイント。

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」を標榜する。

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

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

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

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

dns0.eu は 2023 年に出た非営利 EU リゾルバ。本部はフランス・パリ、GDPR を厳格に適用し、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 万)。

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

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

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

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。

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

日本通信事業者の DNS。

日本は韓国より 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)
• RFC 7858 — DNS over TLS (DoT)
• RFC 9250 — DNS over QUIC (DoQ)
• RFC 9230 — Oblivious DNS over HTTPS (ODoH)
• RFC 9460 — Service Binding and Parameter Specification (SVCB / HTTPS records)
• RFC 4033 — DNSSEC Introduction and Requirements
• Cloudflare 1.1.1.1
• Cloudflare 1.1.1.1 for Families
• Cloudflare Trust Hub — 1.1.1.1 audits
• Quad9
• Google Public DNS
• OpenDNS / Cisco Umbrella
• AdGuard DNS
• NextDNS
• ControlD
• Mullvad DNS
• dns0.eu
• AWS Route 53 Documentation
• Google Cloud DNS
• Azure DNS
• NS1 (IBM)
• PowerDNS
• BIND9 — ISC
• CoreDNS
• Knot DNS — CZ.NIC
• Unbound — NLnet Labs
• dnsmasq
• Pi-hole
• AdGuard Home
• Technitium DNS Server
• Blocky — DNS proxy
• Stubby — DoT client
• OpenWRT https-dns-proxy
• DNSperf — public DNS benchmarks
• APNIC — 1.1.1.1 history