あなた専用の DNS リゾルバー。
誰も移そうとは思わない、あのログ。

「自分専用の DNS サーバー」という言葉の裏には、まったく異なる2種類のマシンが隠れており、ほとんどのチュートリアルは間違った方を作ってしまう。何かをインストールする前にこれを決めておくこと。それが、プライバシーツールと、他人のプライバシーポリシーの単なる代理人との違いになるからだ。

フォワーダー は、あなたのクエリを受け取り、別のリゾルバー — 典型的には Cloudflare、Google、Quad9、あるいはあなたの ISP — に渡し、返ってきたものをキャッシュする。シンプルで速いが、クエリの全体像をまるごと単一の第三者に引き渡すことになる。「では最後にアップストリームを 1.1.1.1 に設定してください」で締めくくられるガイドは、すべてこれを作っている。

再帰リゾルバー は、その作業を自分自身でこなす。mail.example.com を見つけるために、まずルートサーバーに .com を管理しているのは誰かを尋ね、次に .com サーバーに example.com を管理しているのは誰かを尋ね、最後に example.com 自身のネームサーバーにそのレコードを尋ねる。3つか4つの異なる運営者との、3つか4つの短いやり取りであり、そのうちの誰も、他の相手について何も知らされない。QNAME 最小化を有効にすればさらに徹底できる — ルートには .com についてしか尋ねず、.com サーバーには example.com についてしか尋ねない。完全な名前が明かされる相手はただ一者のみ — その名前をホストしている当人であり、どのみち30ミリ秒後にはあなたの接続を受け取ることになっていた相手だ。

右側の2列は競合しているのではなく、同じ構成の二つの半分だ。AdGuard Home がポート53を受け持ち、ブロックリストを適用し、暗号化トランスポートを終端する。Unbound はその裏でループバック上に控え、名前解決を行う。どちらの半分も、相手の仕事はうまくこなせない。両者をつないでも、必要な RAM は合計で100メガバイト程度にすぎない。

このページから一つだけ持ち帰るとすれば、これにしてほしい。パブリックな DNS プロバイダーへ転送するリゾルバーは、あなたの DNS をプライベートにはしていない。それはログをホップ一つ分だけ移動させ、あなたの保守対象リストにサーバーを一台増やしただけだ。再帰こそがすべての要点だ。

Unbound は NLnet Labs が開発した、検証・再帰・キャッシュ機能を備えたリゾルバーだ。あらゆる場所でパッケージ化されており、インターネットの相当な部分がすでにこれを動かしている。標準の状態では再帰動作をする — フォワーダーにするには、わざわざ手を加える必要がある。ルートヒントパッケージと一緒にインストールしておけば、どこからもリストを取得することなく、ルートサーバーの場所を把握できる。

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

dns-root-data パッケージは、ルートヒントを /usr/share/dns/root.hints に、DNSSEC のルートトラストアンカーを /usr/share/dns/root.key にインストールし、通常のパッケージ経路を通じて両方を更新し続けてくれる。それが、地味だが正しい入手方法だ。cron ジョブで URL から root.hints をダウンロードするやり方は、いずれ気づかれないまま失敗する類のやり方だ。

/etc/unbound/unbound.conf.d/nb-resolver.conf

server:
    # ---- Who may ask. Deny first, allow narrowly.
    interface: 127.0.0.1@5335
    interface: 10.8.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.8.0.0/24 allow

    # ---- Privacy of the recursion itself.
    qname-minimisation: yes
    qname-minimisation-strict: no
    hide-identity: yes
    hide-version: yes
    rrset-roundrobin: yes

    # ---- DNSSEC. The anchor is maintained by the dns-root-data package.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    root-hints: "/usr/share/dns/root.hints"
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    harden-large-queries: yes
    harden-short-bufsize: yes
    aggressive-nsec: yes
    val-clean-additional: yes

    # ---- Do not be a reflector, even by accident.
    refuse-any: yes
    ratelimit: 1000
    ip-ratelimit: 200
    edns-buffer-size: 1232

    # ---- Cache. This is where the 4 GB actually earns its keep.
    msg-cache-size: 128m
    rrset-cache-size: 256m
    cache-min-ttl: 60
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    serve-expired-ttl: 3600

    # ---- Never chase a name that has no business being on the internet.
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

    num-threads: 2
    so-reuseport: yes
    verbosity: 0
    logfile: ""

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

そのうちの4行が実質的な仕事をこなしており、それぞれ一言ずつ説明する価値がある。

• 01access-control: 0.0.0.0/0 refuse — インターネットに対するデフォルトの答えは「ノー」だ。それ以降に書くものはすべて、意図して設けた例外にすぎない。この1行だけで、ファイアウォールが出る幕もなく、ステップ02の増幅攻撃の顛末を止めてしまえる。
• 02qname-minimisation: yes — ルートサーバーに尋ねられるのは .com についてだけで、完全なホスト名ではない。RFC 9156 であり、現行の Unbound ではデフォルトで有効になっている。再帰リゾルバーが、図が示唆するよりも少ない情報しか漏らさない理由もここにある。厳格モードはオフのままにしておくこと — ごく少数の設定ミスのあるゾーンは、いまだにこれで壊れてしまう。
• 03refuse-any: yes — ANY クエリは、可能な限り小さな質問に対して可能な限り大きな答えを返す。これはまさに増幅攻撃が求めているものだ。正当な用途でこれを必要とするものは何もない。
• 04serve-expired: yes — 権威サーバーに到達できないとき、失敗する代わりに古い(stale)答えを渡し、バックグラウンドで更新する。この設定のおかげで、遠く離れた場所の障害が、家中の全員にとって「インターネットが落ちた」ように見えてしまう事態を防げる。

2つのリスナーに注目してほしい。ポート5335のループバックは、次のステップで AdGuard Home が使うものだ。10.8.0.1 はトンネルのアドレスであり、フィルタリング層を省略することにした場合、VPN 上のクライアントが Unbound に直接クエリを送れるようにしている。まだ WireGuard を動かしていないなら、この2行目のインターフェース指定は今のところ削除しておくこと — その箱に存在しないアドレスでは、Unbound は起動してくれない。

起動して、動作することを確かめる。

unbound-checkconf
systemctl restart unbound && systemctl enable unbound

apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short

# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org  | grep 'status:'

最初の応答に付く ad フラグは、Unbound がルートからそのレコードまでの署名の連鎖を検証し、それが成立していたことを意味する。2番目の応答での SERVFAIL は、検証が改ざんされた答えをあなたに渡さず拒否したことを意味する。もし2番目がアドレスを返してしまうなら、検証が有効になっておらず、まず確認すべきはトラストアンカーだ。

誰も到達できないリゾルバーは役に立たず、誰もが到達できるリゾルバーはステップ02で見た失敗モードそのものだ。優れた答えはちょうど2つあり、たいていの人は結局その両方を使うことになる — 自宅とノートPCではトンネルを、スマートフォンや UDP がフィルタリングされるネットワークでは暗号化 DNS を。

選択肢A — WireGuard 経由。 2つのうちより優れている方であり、本ガイドがしつこく WireGuard ガイドを指し示している理由でもある。ポート53はインターネットからは見えないままであり、クエリそのものがどんな形であれ信頼できないネットワークを横切ることはなく、更新すべき証明書もない。VPS がすでにあなたの VPN の出口になっているなら、これは各ピアの設定にたった1行加えるだけで済む。

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

多くの人を悩ませる、ちょっとした落とし穴がある。Linux では、wg-quick はそのアドレスを resolvconf か systemd-resolved 経由で設定するが、どちらもインストールされていない場合、トンネル自体は問題なく確立される一方で、静かに何もしないまま終わってしまう。トンネルを確立した後、resolvectl status で確認するか /etc/resolv.conf を読んで確認すること — トンネルは正常に動いているのに古いリゾルバーの設定が残ったままというのは、まさにこの取り組み全体が防ごうとしているリークそのものだ。

選択肢B — DNS-over-TLS と DNS-over-HTTPS。 デバイスが常にトンネル上にいられるとは限らない場合に必要になる。どちらも証明書によって認証され、それはつまりホスト名が必要になるということだ — A レコードを VPS に向け、AdGuard Home に証明書を直接持たせるか、すでに TLS を終端しているリバースプロキシの背後に置く。リスナーは DoT が 853/tcp、DoH が 443/tcp だ。

ufw allow 853/tcp                     # DNS-over-TLS
ufw allow 443/tcp                     # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status

DoH のエンドポイントには、推測できないパスを与えること — AdGuard Home では /dns-query/<random> のような形で配信できる。人ごとに異なるパスにしておけば、他の全員のものは何一つ変更せずに、一人だけアクセスを取り消すことができる。これは強い意味での認証ではないが、パブリックなリスナーが、手順が一つ増えただけのオープンリゾルバーになってしまうのを防いでくれる。

ルーターの行こそ、よく考えるべきものだ。DHCP 経由でリゾルバーを配れば、設定画面すら持たない機器も含めて、家中のすべてのデバイスを一度にカバーできる — しかしそうすると、ルーターから VPS までのホップは、公開インターネットを渡るプレーンな DNS になってしまい、それはまさにあなたが止めようとしていたことそのものだ。ルーター自体でトンネルを動かすか、最後の1マイルが暗号化されていないことを受け入れ、再帰の恩恵だけを勝ち取るかのどちらかになる。

最後にもう一つ、知っておく価値のある設定がある。DNS-over-HTTPS を有効にしたブラウザは、トンネルの有無にかかわらず、自身のリゾルバーを使い、システムの設定を静かに無視してしまう。Firefox も Chrome も、地域によってはこれをデフォルトで有効にして出荷している。ブラウザ側もあなたのエンドポイントに向けるか、その DoH をオフにしてオペレーティングシステムに従わせるか、どちらかにすること。

プライベートなリゾルバーは、本物の改善ではあるが、覆い隠すマントではない。それをマントとして売りつけてくる者がいれば、何か別のものを売りつけようとしていると思っていい。以上をすべて実施した後にも、なお見えたままになっているものの一覧をここに示す。残された露出の形を知っておくことこそが、本物の防御と、ただの気休めとの違いになるからだ。

接続そのものは、依然として発生する。 名前解決の1ミリ秒後、あなたのデバイスは、たった今知ったアドレスへ TCP 接続を開く。あなたの回線を見ている者には、そのアドレスが見えている。専用 IP を持つサイトにとっては、そのアドレスこそがサイトそのものだ。暗号化 DNS は問いを取り除いてくれるが、答えまでは取り除いてくれない。

TLS ハンドシェイクは、たいていサイトの名前を明かしてしまう。 Server Name Indication は、ほぼすべての HTTPS 接続の開始時に平文で送信されるため、受動的な観測者にはどのみちホスト名が読み取られてしまう。Encrypted Client Hello はこれを解決するが、普及にはむらがある — ブラウザとサイトの双方が対応していれば名前は隠されるが、そうでなければ隠されない。有効になっていると決めてかからないこと。

リゾルバーの運営者は、いまやあなた自身であり、あなたはたった一人だ。 あなたのリゾルバーが話しかけるすべての権威サーバーには、自分のゾーンについて尋ねてくる単一の IP アドレスが見えている。多くのゾーンにまたがって見れば、その IP には特徴的なパターンがあり、そのパターンとはすなわち一つの家庭だ。これは最初の章で触れた匿名セットの代償であり、それを和らげてくれる唯一のものは、その IP が名前にたどり着けないこと — 暗号通貨払いの KYC 不要 VPS であること — であり、理想を言えば、あなたのトラフィックがすでに出ていっているのと同じ IP であることだ。

プロバイダーには、いつも通りパケットが見えている。 VPS は、誰かのハードウェア上で、誰かのデータセンター内で動いている。NordBastion は顧客のトラフィックを検査しないし、透明性レポートとウォラントカナリアは、もし要求があった場合に何が起きるかを説明している — それでも、正直なアーキテクチャ上の事実として、あなたが借りているマシンは、他の誰かが物理的に手を伸ばせるマシンでもある。セルフホストによって変わるのは、製品レベルのクエリログも、アナリティクスのパイプラインも、後から改定されうるプライバシーポリシーも存在しなくなるという点だ。そこにあるのはただ、RAM の中でキャッシュを保持する1つのプロセスだけであり、それはあなたが設定し、あなたが意図して選んだ法域の中にある。

あなたが実際に手に入れたものを正確に言えば、こうなる。あなたに関する行動データの中で最も豊富かつ最も安価な情報源が、それを収集することがビジネスモデルの一部であるような主体によって、もはや収集されなくなったということだ。それは限定的な主張であり、同時に本物の主張でもある。脅威モデルが Tor を求めている場面において、このページの内容が Tor の代わりになることは何もない — そしてその場合には、下記の onion サービスガイドこそが、次に読むべき正直な選択肢だ。