Ваш собственный DNS-резолвер.
Единственный журнал, о переносе которого никто не думает.

За фразой «мой собственный DNS-сервер» скрываются две совершенно разные машины, и почти каждый туториал строит не ту. Определитесь с этим прежде, чем что-либо устанавливать, потому что это разница между инструментом приватности и прокси для чужой политики конфиденциальности.

Форвардер принимает ваш запрос и передаёт его другому резолверу — обычно Cloudflare, Google, Quad9 или вашему провайдеру — а затем кэширует то, что приходит в ответ. Это просто, это быстро, и это отдаёт весь поток ваших запросов одной-единственной третьей стороне. Каждое руководство, заканчивающееся словами «теперь укажите в качестве вышестоящего сервера 1.1.1.1», построило именно такую систему.

Рекурсивный резолвер делает всю работу сам. Чтобы найти mail.example.com, он спрашивает у корневого сервера, кто обслуживает .com, спрашивает у серверов .com, кто обслуживает example.com, а затем спрашивает саму запись у собственных серверов имён example.com. Три-четыре коротких обмена с тремя-четырьмя разными операторами, ни одному из которых не сообщается ничего об остальных. При включённой QNAME-минимизации всё идёт ещё дальше: у корня спрашивают только про .com, а у серверов .com — только про example.com. Полное имя раскрывается ровно одной стороне — той, что обслуживает это имя и которая в любом случае получила бы ваше соединение тридцатью миллисекундами позже.

Два правых столбца — не конкуренты, это две половины одной и той же сборки. AdGuard Home владеет портом 53, применяет списки блокировки и терминирует шифрованные транспорты; Unbound находится позади него, на loopback, и занимается резолвингом. Ни одна из половин не справляется хорошо с работой другой, а вся цепочка в сумме занимает около сотни мегабайт RAM.

Если вы вынесете с этой страницы только одну мысль, пусть будет эта: резолвер, пересылающий запросы публичному провайдеру 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, а также поддерживает оба файла в актуальном состоянии через обычный канал обновления пакетов. Это скучный, но правильный способ их получить; скачивание root.hints по URL в cron-задаче — способ, который рано или поздно молча откажет.

/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

Четыре из этих строк делают настоящую работу и заслуживают по отдельному предложению каждая.

• 01access-control: 0.0.0.0/0 refuse — ответ по умолчанию всему интернету — «нет». Всё, что после неё, — исключения, которые вы написали намеренно. Именно эта единственная строка останавливает сценарий с усилением из шага 02 ещё до того, как за дело возьмётся файрвол.
• 02qname-minimisation: yes — у корневых серверов спрашивают про .com, а не про полное имя хоста. RFC 9156, включённый по умолчанию в текущем Unbound, — причина, по которой рекурсивный резолвер утекает меньше, чем можно подумать, глядя на диаграмму. Строгий режим оставьте выключенным: небольшое число неправильно настроенных зон всё ещё ломается под ним.
• 03refuse-any: yes — запросы ANY возвращают максимально большой ответ на минимально возможный вопрос, а это именно то, что нужно атаке с усилением. Ничему легитимному они не нужны.
• 04serve-expired: yes — когда авторитативный сервер недоступен, отдавать устаревший ответ и обновлять его в фоне вместо того, чтобы просто отказывать. Именно эта настройка не даёт далёкому сбою выглядеть для всех в доме так, будто пропал интернет.

Обратите внимание на два слушателя. Loopback на порту 5335 — это то, что AdGuard Home будет использовать на следующем шаге; 10.8.0.1 — это адрес туннеля, чтобы клиенты в VPN могли обращаться к Unbound напрямую, если вы решите пропустить слой фильтрации. Если вы ещё не запустили WireGuard, пока уберите эту вторую строку интерфейса — 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 проверил цепочку подписей от корня до самой записи и она выдержала проверку. SERVFAIL во втором означает, что валидация отклонила подделанный ответ вместо того, чтобы передать его вам. Если вместо этого второй запрос вернёт адрес, значит, валидация не включена, и первое, на что стоит посмотреть, — это якорь доверия.

Резолвер, до которого никто не может достучаться, бесполезен, а резолвер, до которого может достучаться кто угодно, — это тот самый сбой из шага 02. Есть ровно два хороших ответа, и большинство в итоге использует оба — туннель дома и на ноутбуке, шифрованный DNS на телефоне и в сетях, где UDP фильтруется.

Вариант A — через WireGuard. Лучший из двух вариантов, и причина, по которой это руководство продолжает указывать на руководство по WireGuard. Порт 53 остаётся невидимым для интернета, сам запрос никогда ни в каком виде не пересекает недоверенную сеть, и нет сертификата, который нужно продлевать. Если VPS уже является точкой выхода вашего VPN, это одна строка в конфигурации каждого пира:

# 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 за вас. Слушатели — это 853/tcp для DoT и 443/tcp для DoH.

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 через открытый интернет, а именно это вы и собирались остановить. Либо запустите туннель на самом роутере, либо смиритесь с тем, что последняя миля не шифрована, и пусть вашей победой останется хотя бы рекурсия.

Ещё одна настройка, о которой стоит знать: браузер с включённым DNS-over-HTTPS будет использовать собственный резолвер и молча игнорировать системную настройку, независимо от туннеля. И Firefox, и Chrome в некоторых регионах поставляются с этим включённым по умолчанию. Либо направьте браузер тоже на свою конечную точку, либо выключите в нём DoH, чтобы он следовал настройкам операционной системы.

Приватный резолвер — реальное улучшение, но не плащ-невидимка. Всякий, кто продаёт его именно как плащ-невидимку, что-то впаривает. Вот список того, что остаётся видимым после всего сделанного выше, потому что знание формы оставшейся уязвимости — это разница между защитой и одеялом, создающим лишь иллюзию уюта.

Соединение всё равно происходит. Через миллисекунду после запроса ваше устройство открывает TCP-соединение с адресом, который только что узнало. Любой, кто наблюдает за вашей линией, видит этот адрес. Для сайта на собственном IP адрес и есть сайт. Шифрованный DNS убирает вопрос — но не убирает ответ.

TLS-рукопожатие обычно называет сайт. Server Name Indication передаётся в открытом виде в начале почти каждого HTTPS-соединения, так что пассивный наблюдатель всё равно читает имя хоста. Encrypted Client Hello это исправляет, но развёрнут неравномерно — там, где и браузер, и сайт его поддерживают, имя скрыто, а там, где нет, — не скрыто. Не считайте само собой разумеющимся, что он включён.

Теперь оператор резолвера — вы, и вы один. Каждый авторитативный сервер, с которым говорит ваш резолвер, видит один-единственный IP-адрес, спрашивающий про их зону. На множестве зон у этого IP есть характерный узор, и этот узор — домохозяйство. Это та самая плата за множество анонимности, о которой шла речь в первой главе, и единственное, что её смягчает, — это то, что IP невозможно проследить до имени (VPS без KYC, оплаченный криптовалютой), а в идеале — что это тот же IP, из которого уже выходит ваш трафик.

Провайдер видит пакеты, как и всегда. VPS работает на чужом железе в чужом дата-центре. NordBastion не инспектирует трафик клиентов, а отчёт о прозрачности и warrant canary описывают, что произошло бы в случае запроса, — но честное архитектурное утверждение состоит в том, что арендуемая вами машина физически достижима кем-то ещё. Что меняет самостоятельный хостинг — так это то, что не остаётся журнала запросов на уровне продукта, аналитического конвейера и политики конфиденциальности, которую можно изменить; остаётся только процесс, держащий кэш в RAM, настроенный вами, в юрисдикции, которую вы выбрали намеренно.

Что именно вы на самом деле купили: самый богатый и самый дешёвый источник поведенческих данных о вас больше не собирается стороной, чья бизнес-модель как раз и состоит в их сборе. Это узкое утверждение, но оно правдиво. Ничто на этой странице не заменяет Tor, когда модель угроз требует именно Tor, — и для этого честным следующим чтением станет руководство по onion-сервису ниже.