Аннотация

AdGuard Home удобен, когда нужны индивидуальные политики и встроенный зашифрованный DNS в обе стороны; Pi-hole — когда работа строится вокруг групп клиентов, списков и диагностики, а отдельный encrypted DNS proxy приемлем; blocky — когда конфигурацию хотят описывать и проверять как текст. Но эти различия не отвечают на главный вопрос домашнего администратора: продолжит ли сеть разрешать имена с нужной политикой, если upstream, загрузка списков или сам DNS-узел откажет? Обзор сопоставляет механизмы, а не измеренную надёжность продуктов.123456

Срез данных — 7 ноября 2026 года. Допущение: домашняя LAN, один администратор, несколько классов устройств; DNS — общая сетевая зависимость. База сравнения: AdGuard Home v0.107.80 от 3 ноября; Pi-hole Core v6.5, FTL v6.8, Web v6.6.1, опубликованные 17 октября; blocky v0.35.0 от 5 сентября. Это исследование документации, релизов и исходников: DNS-серверы не запускались, сравнительных замеров, проверок восстановления и аварийных учений не было. Поэтому ниже нет победителя по скорости или подтверждённой высокой доступности.7891011

Введение: четыре контракта вместо списка возможностей

В статье о reverse proxy речь шла о входящем HTTP и сертификатной автоматизации, в обзоре overlay-сетей — о маршруте через NAT и DERP, в сравнении NixOS, Ansible и Compose — об откате разных слоёв. Здесь новый предмет: порядок применения DNS-политик, сохранение личности клиента через роутер, свежесть ответов и зависимости холодного старта.

Исследовательский вопрос: как выбрать один из трёх фильтров, когда неправильное разрешение имён почти так же нежелательно, как его отсутствие? Для анализа введём четыре контракта: какой запрос разрешён; к какому клиенту он относится; насколько старым может быть ответ; какие внешние компоненты нужны для работы. Это аналитическая рамка обзора, а не терминология разработчиков.

Отправной точкой стала первая beta AdGuard Home 1.0 от 30 сентября 2026 года. Она действительно существует: v1.0.0-b.1 переводит beta-канал на новый интерфейс и схему версий. Однако на дату среза последняя предварительная версия — v1.0.0-b.2 от 5 ноября, а стабильная — по-прежнему v0.107.80. Возможности beta-интерфейса нельзя незаметно приписывать stable; эксплуатационное сравнение ниже опирается именно на стабильную ветку.71213

За рамками — принудительный перехват DNS, обходы через приложения и VPN, полноценная authoritative-инфраструктура, универсальный рейтинг безопасности и производительности. Общий предел самого подхода важнее различий интерфейсов: когда реклама и полезный контент используют одно доменное имя, DNS-фильтр не получает признака, по которому можно разрешить одно и запретить другое. Это не означает, что любая реклама того же владельца неразличима: отдельное имя уже меняет задачу.14

Essentially, any advertising that shares a domain with content cannot be blocked by a DNS-level blocker.14

1. Политика — это порядок вычисления, а не количество записей

AdGuard Home предлагает выразительный язык DNS-правил, но не полный язык браузерного блокировщика. Документация перечисляет Adblock-style, hosts и domains-only. Например, ||ads.example.org^ означает блокировку имени и поддоменов, а @@||ads.example.org^ — исключение. Есть модификаторы клиента, типа записи и переписывания ответа; однако правило с неподдерживаемым модификатором должно игнорироваться целиком. Следовательно, импорт знакомого браузерного списка не доказывает, что все его строки работают.1

If a rule contains a modifier not listed in this document, the whole rule must be ignored.1

При конфликте правил нельзя исходить из принципа «последняя строка побеждает». $important повышает приоритет даже над обычным исключением; у $dnsrewrite собственный высокий приоритет. Практический вывод — хранить не только желаемые списки, но и небольшой набор конфликтных случаев: обычная блокировка против исключения, важное правило против исключения, переписывание против блокировки. Такие случаи проверяют смысл политики лучше, чем общий счётчик доменов.1

Pi-hole делает основной единицей управления группы и классы правил. Подписные списки, отдельные allow/deny-записи и regex привязываются к группам; новые объекты первоначально получают Default group 0. Добавить устройству отдельную группу недостаточно для доказательства изоляции: нужно проверить, не осталось ли у него нежелательное членство в Default. Regex использует POSIX Extended Regular Expressions с расширениями проекта — это другая модель, не обещание совместимости с полной грамматикой Adblock.152

Для обычной проверки нового имени в FTL v6.8 существенна цепочка: exact allow → regex allow → exact deny → подписной allowlist antigravity → подписной denylist gravity → regex deny. Здесь опущены специальные доменные политики и пути уже вычисленного решения. Из порядка следует практически важное ограничение: regex deny с особым ответом не определит результат, если имя уже заблокировано exact-правилом или gravity. Перенос политики требует переносить её приоритеты, а не только строки.16

blocky связывает списки с клиентскими группами декларативно. В v0.35.0 документированы hosts, простые домены, wildcards и /regex/; проверяются имя запроса, IP ответа и CNAME. Само определение списков не включает их применение: нужна привязка clientGroupsBlock. Allowlist действует поверх denylist во всех назначенных клиенту группах. Если каждая назначенная группа содержит только разрешения, включается exclusive allow mode: всё остальное блокируется. Это уже изменение модели политики, а не просто добавление исключений.3

Для одного администратора различие можно сформулировать так: AdGuard Home требует понимать взаимодействие классов правил; Pi-hole — соответствие записей и групп плюс порядок lookup; blocky — ещё и итоговую структуру конфигурации. Его многофайловая загрузка идёт в лексикографическом порядке, mappings объединяются рекурсивно, но списки заменяются целиком. Файл с «добавочным» upstream или правилом способен фактически удалить прежний список. blocky validate проверяет структуру, а семантические проверки продолжаются при загрузке; ни одна из них не заменяет проверки ожидаемого DNS-ответа.1163

2. Политика устройства начинается до DNS-сервера

Группы полезны только тогда, когда до фильтра дошёл различимый клиент. Прямое обращение устройств к фильтру и агрегация их DNS-запросов роутером от собственного адреса — разные топологии. Во втором случае обычный source IP обозначает роутер. Pi-hole FTL v6.8 умеет учитывать переданные EDNS0 ECS client IP, но forwarder должен действительно их передать. Подпись устройства в интерфейсе и восстановление hostname через reverse lookup не восстанавливают автоматически исчезнувшую информацию об источнике.1718

В AdGuard Home persistent client может определяться по IP, CIDR, MAC или ClientID; использование MAC ограничено случаем, когда DHCP обслуживает сам AdGuard Home. ClientID передаётся через поддерживаемый зашифрованный протокол и специальное имя либо URL. Это не то же самое, что значение $client в фильтрующем правиле: документация этого модификатора различает имя настроенного клиента и ClientID. Ошибка здесь даёт конфигурацию, которая выглядит индивидуальной, но не выбирает ожидаемое правило.14

В Pi-hole v6.8 поиск клиентского профиля идёт от наиболее специфичного IP/subnet к MAC, затем hostname и входящему интерфейсу; неизвестный клиент получает Default. Это не произвольная сумма всех подходящих IP-, MAC- и hostname-профилей. У blocky группы также могут выбираться по имени, IP или CIDR, а имя — поступать через DoH/DoT либо lookup. Значит, сначала следует установить, какую идентичность реально видит сервер, и лишь потом разносить устройства по политикам.317

Поэтому утверждение «Docker всегда скрывает клиентов» здесь не используется: без проверки конкретного сетевого пути оно не обосновано. Предлагаемый контроль — отправить различимые запросы с двух устройств, включая другой сегмент сети, и сопоставить их с query log и выбранной политикой. Для DoH за HTTP proxy отдельно проверяется доверие к forwarded IP: AdGuard Home принимает такие заголовки только от настроенных trusted_proxies. Это отдельная HTTP-механика, а не средство восстановления источника произвольного UDP DNS.19

3. Кэш: быстрее, свежее и доступнее — разные требования

Увеличение времени хранения не является бесплатным повышением надёжности. AdGuard Home cache_ttl_min и cache_ttl_max переопределяют TTL, полученный от upstream; blocky тоже меняет TTL записей при положительных min/max. Повышенный минимум может удержать старый адрес дольше срока, который дал upstream. Поэтому настройка кэша — выбор допустимой свежести, а не только размера памяти. Из этих механизмов нельзя вывести сравнительную задержку трёх продуктов без нагрузки и одинакового набора запросов.1920

Optimistic cache AdGuard Home отвечает сохранёнными данными после истечения TTL и пытается обновить их. Для стабильной v0.107.80 defaults задают 30 секунд TTL такого ответа и 12 часов максимального устаревания; это не обещание хранить каждое имя двенадцать часов. Нужны включённый optimistic-режим, сохранившаяся запись и соответствующие настройки. В существующей установке фактический конфигурационный файл может отличаться от defaults. Реализация рассмотрена по исходникам dnsproxy v0.83.2, зависимость на которую закреплена в stable go.mod.21222324

У Pi-hole FTL v6.8 dns.cache.optimizer по умолчанию равен 3600 секундам: недавно истёкшие записи можно использовать с запуском обновления. Важная ловушка — 0 не отключает optimizer, а снимает ограничение давности; отключение задаёт отрицательное значение. Сравнивать «час против двенадцати часов» как время гарантированной автономности нельзя: оба механизма зависят от наличия подходящего ответа в кэше и не создают знания об имени, которое раньше не разрешалось.1822

У Pi-hole также различаются кэш DNS-ответов и кэш решения фильтрации. В FTL v6.8 решение привязано к комбинации домен/клиент, а изменения групп сбрасывают соответствующие решения. Поэтому ошибочно представлять кэш как глобальное «разрешили одному — разрешили всем». Документация рекомендует pihole reloadlists, когда нужно перечитать правила без потери накопленного DNS answer cache. Это полезное различие между изменением политики и перезапуском процесса.1516

blocky документирует иной акцент: обычный prefetch часто запрашиваемых имён, по умолчанию выключенный, а min/max положительного TTL по умолчанию равны нулю — используется TTL ответа. Prefetch обновляет востребованные записи, но не равен serve-stale и сам создаёт внешний трафик. В прочитанной реализации нет основания обещать работу обычного response cache после TTL как эквивалент optimistic AdGuard Home. Кроме того, cache сохраняет upstream-derived ответы, а не вообще любой локальный или conditional результат.320

Отдельный срок — TTL заблокированного ответа у клиента. В Pi-hole v6.8 default dns.blockTTL — 2 секунды; у blocky документация указывает 6 часов для режимов, возвращающих записи. В режиме refused blockTTL не действует. Долгий срок уменьшает повторные запросы, но затягивает снятие ошибочной блокировки: сервер уже разрешает имя, а клиент ещё помнит прежний ответ. Поэтому для часто редактируемой домашней политики этот параметр заслуживает отдельного решения, а не наследования случайного примера YAML.318

4. Шифрование: нарисовать оба плеча и bootstrap

Нужно отдельно выбирать транспорт клиент → фильтр и фильтр → upstream. AdGuard Home поддерживает встроенные encrypted DNS listeners и encrypted upstream; blocky v0.35.0 также документирует DoH/DoT listeners и зашифрованные upstream-протоколы. Настроить внешний DoH и выдать адрес фильтра по DHCP недостаточно, чтобы объявить зашифрованной домашнюю LAN: клиентское плечо может остаться обычным DNS. Сертификат и доверие клиента нужны там, где поднимается TLS-сервер, независимо от наличия web-интерфейса.3195

Для выбранной стабильной базы Pi-hole зашифрованный upstream требует внешнего компонента. Официальный guide строит путь клиент → Pi-hole → локальный dnscrypt-proxy → encrypted upstream; FTL v6.8 описывает upstream как IP/hostname с необязательным #port, а не DoH URL. Встроенный HTTPS webserver не превращает административный интерфейс в DoH endpoint. Входящий encrypted DNS тоже следует проектировать отдельно, не переносить на stable обещания будущей ветки.186

Это не делает Pi-hole автоматически хуже. Если администратор уже обслуживает отдельный DNS proxy, разделение может быть удобным: фильтр и транспорт имеют разные настройки. Но добавляются процесс, его обновление и порядок запуска. Другой официальный вариант — локальный Unbound: Pi-hole остаётся caching/forwarding-фильтром, а рекурсию выполняет отдельный resolver. Рекурсия к root/TLD/authoritative и encrypted forwarding к провайдеру — разные топологии и модели доверия, не два названия одной настройки.625

DNSSEC также не синоним шифрования. У Pi-hole v6.8 есть настройка проверки DNSSEC, по исходным defaults она выключена; официальный вариант Unbound отдельно включает проверку подписей. Для AdGuard Home enable_dnssec в документации и закреплённом dnsproxy описывает выставление DO-флага в upstream-запросах. Этого недостаточно, чтобы приписать AdGuard Home независимую локальную криптографическую валидацию. Ни transport privacy, ни проверку цепочки доверия в данном исследовании экспериментально не испытывали.18192524

Bootstrap отвечает на другой вопрос: как узнать IP самого сервера dns.example.org, прежде чем подключиться к нему по DoH/DoT? В AdGuard Home для этого есть bootstrap_dns; в blocky explicit bootstrap может содержать upstream и заранее известные IP, а без него используется системный resolver. Если системный DNS указывает на ещё не поднявшийся фильтр, получается циклическая зависимость. Практический вывод — описывать холодный старт всей цепочки, а не только рабочий запрос с прогретыми кэшами.31926

В стабильном AdGuard Home v0.107.80 обнаружена существенная граница: основной upstream получает настроенный bootstrap, а настройка fallback содержит TODO об использовании bootstrap и не передаёт это поле аналогичным образом. Это наблюдение по тегированному исходнику, не воспроизведённый сетевой отказ. Оно не позволяет обещать, что encrypted fallback с hostname автоматически разрешится тем же независимым путём. У blocky bootstrap, кроме имён upstream, обслуживает и домены источников списков: политика загрузки тоже входит в граф зависимостей.327

5. Upstream, списки и готовность: три разных отказа

Несколько upstream не означают фиксированный основной и резервный. В AdGuard Home v0.107.80 default — load_balance: выбор учитывает ошибки и среднее время lookup; режим parallel отдельно посылает запрос всем настроенным upstream. fastest_addr — ещё другой механизм, выбор адреса с меньшей задержкой, а не просто гонка DNS-ответов. Следствие для приватности: параллельный запрос раскрывает одно имя большему числу выбранных получателей; ускорение в конкретной сети здесь не измерялось.1921

У blocky v0.35.0 default parallel_best выбирает два взвешенно-случайных upstream, а не все. Побеждает первый обмен без ошибки, проигравший отменяется. Если ошиблись оба выбранных, алгоритм не продолжает обход остальных; при единственном upstream вызывается он один. Режим random предусматривает другую попытку, strict — заданную последовательность. Следовательно, длинный список серверов сам по себе не гарантирует, что конкретный запрос дойдёт до единственного исправного.328

Разные режимы также не дают универсальной «повышенной приватности». Распределение запросов уменьшает долю общей истории у отдельного провайдера, но гонка дублирует конкретное имя двум провайдерам. Отмена проигравшего не доказывает, что он не успел получить запрос. Документация blocky сама отмечает, что random приватнее в смысле обычной отправки одному upstream. Выбор здесь зависит от угрозы, а не от слова parallel в названии.328

Доступность DNS и полнота фильтрации могут разойтись. У blocky стратегии загрузки различают ожидание инициализации blocking, выход при ошибке failOnError и немедленное обслуживание с фоновой загрузкой fast. Последний вариант уменьшает ожидание старта, но без сохранённых локальных данных не доказывает немедленно полную политику. Дисковый blocking.loading.downloads.cachePath — отдельный opt-in cache скачанных списков, не persistence DNS-ответов; ему нужен сохраняемый writable volume.329

При сетевой ошибке downloader blocky может вернуть старую дисковую копию списка, но HTTP 4xx/5xx намеренно не включает этот fallback. Более того, частично успешный импорт способен заменить группу неполным новым набором; детали этого противоречия разобраны ниже. Поэтому проверка только DNS-ответа на разрешённое имя недостаточна: процесс может работать, а состав блокировки — измениться. И дисковую копию списка не стоит считать гарантированным backup политики: исходник прямо трактует её как восстанавливаемое disposable-состояние без fsync.2930

У Pi-hole FTL v6.8 есть отдельный выбор при занятой или недоступной gravity DB: dns.replyWhenBusy по умолчанию ALLOW. Это не отказ upstream и не смерть процесса, а временная невозможность применить соответствующую базу политики. Следовательно, требование fail-closed нужно формулировать отдельно от требования «DNS всегда отвечает». Простое увеличение числа внешних resolver не меняет этот режим обработки.1618

Наконец, liveness не равна готовности разрешать и фильтровать. В blocky специальный healthcheck handler возвращает успешный код, не проходя обычную resolver chain. Он не проверяет bootstrap, здоровье upstream и полноту списков. Поэтому зелёный container health status полезен как узкий сигнал живого listener, но не как доказательство работоспособности домашнего DNS. Для эксплуатационного контроля нужен отдельный положительный сквозной запрос и отдельный canary блокировки.31

6. Резервный сервер — не ещё один upstream

Публичный secondary DNS у клиента — обход политики, а не надёжно спящий резерв. Официальный FAQ Pi-hole предупреждает: устройства могут использовать любой из заданных серверов. При ответе нефильтрующего resolver списки локального фильтра не применяются. Это архитектурная оговорка, применимая и к другим двум продуктам: сервер не управляет запросом, который до него не дошёл.32

Нужно различать отказ внешнего upstream и отказ самого фильтра. Второй Pi-hole, заданный upstream для первого, не поможет клиенту, которому доступен только умерший первый. Предлагаемая архитектура для сохранения фильтрации — два доступных клиентам фильтрующих сервера с согласованной политикой, причём в разных доменах отказа хоста и питания. Это инженерная рекомендация, не подтверждённая здесь HA-схема и не заявление о встроенной синхронизации конфигураций. Поведение конкретных ОС и роутера при двух адресах требуется испытать отдельно.32

Согласованность важнее одинакового названия продукта. В blocky документированная Redis-синхронизация cache и blocking state не означает автоматического переноса всей конфигурации; общий Redis тоже добавляет зависимость. Для пары экземпляров необходимо явно определить источник истины для правил, групп, клиентских идентификаторов и локальных имён. Иначе клиент будет получать разные политики в зависимости от выбранного адреса, даже если оба процесса полностью исправны.332

Резервирование и восстановление также нельзя смешивать. Native updater AdGuard Home сохраняет прежний executable и конфигурацию, но это не доказательство полного снимка данных или автоматического rollback; для контейнерных установок документация требует обновлять образ. Teleporter Pi-hole v6.8 экспортирует конфигурацию и выбранные таблицы правил, групп и клиентов, но не полную историю запросов. Следовательно, воспроизводимый запуск, резервная копия и второй работающий сервер — три разных результата, каждый требует собственной проверки.3334

7. Противоречия: где короткая формулировка меняет смысл

AdGuard Home: live-документация против stable defaults. В Configuration о просроченных optimistic-ответах буквально сказано: «The TTL for such responses is 10 seconds.» Но исходник v0.107.80 задаёт 30 секунд и 12 часов max-age; такие же значения определены в закреплённой зависимости dnsproxy v0.83.2. Для выбранной версии приоритет отдан тегированному коду, а не изменяемой странице. История появления расхождения не установлена; исправление документации или runtime-проверка здесь не выполнялись.19212324

Pi-hole: разрешение не всегда означает один класс allowlist. Документация regex формулирует принцип широко:15

Allowlisting always has priority over denylisting.15

В контексте exact/regex allow это соответствует исследованному пути. Но подписной antigravity в FTL v6.8 проверяется после exact deny. Поэтому перенос той же фразы на любой разрешающий список даёт неверный прогноз. Это расхождение уровня обобщения, а не доказательство произвольного порядка или поломки allowlist. Для миграции следует выписать, каким именно классом задано разрешение.1516

blocky: failOnError против частичного успеха. Документация стратегии называет ошибкой init случай «a single source failing to load/parse»; это создаёт ожидание полноты импорта. Но createCacheForGroup в v0.35.0 возвращает ошибку группы только при ошибке и отсутствии разобранных записей. Если часть источников дала записи, группа завершается через Finish(); поздняя ошибка парсера также может подавляться после частичного чтения.329

Исходник прямо объясняет выбранную границу:29

If we have entries from some sources, proceed even if other sources had errors29

Значит, без дополнительных интеграционных проверок нельзя обещать: «failOnError гарантирует полный импорт каждого источника» или «любая ошибка оставляет весь старый набор». Это вывод из ветвей исходника, не результат запуска с повреждёнными списками. Для администратора различие принципиально: fail-fast процесса и контроль полноты политики — разные гарантии.29

Недостаточность данных и предлагаемые проверки

В собранных материалах нет сопоставимых независимых измерений задержки, памяти, QPS и доступности для одинаковой LAN-нагрузки. Не установлены время переключения клиентов между DNS-адресами, поведение конкретного router forwarder, фактическое окно неполной фильтрации при старте blocky и восстановление всей конфигурации после аварии. Анализ кода объясняет возможные переходы, но не заменяет наблюдения их длительности и влияния на устройства.

Ниже — предлагаемые приёмочные проверки, не выполненные в этом исследовании. Это не готовая конфигурация и не обещание, что выбранные условия уже пройдены.

  • Идентичность: два устройства из разных сегментов запрашивают разные имена под probe.example.org; в журнале различимы клиенты и выбраны ожидаемые группы.
  • Конфликты: ads.example.org одновременно попадает в блокировку и разные виды разрешений; ожидаемый результат заранее записан для каждого класса правила.
  • Свежесть: контролируемое имя меняет адрес и TTL; отдельно наблюдаются ответ сервера, клиентский cache и снятие блокировки после изменения политики.
  • Холодный старт: недоступны основной upstream и источник списка; проверяются bootstrap, encrypted fallback, выбранная стратегия загрузки и фактическая полнота canary-политики.
  • Два узла: отключается один фильтрующий сервер, затем общий для них ресурс; фиксируются не только успешная резолюция, но и сохранение блокировки.
  • Восстановление: из сохранённых версии и состояния поднимается изолированная копия; проверяются группы, локальные имена, транспорт и доступ администратора, а не только открытие интерфейса.

Эти проверки предложены потому, что исследованные механизмы разделяют client identity, cache, loading strategy и liveness. Они не вводят универсального порога успешности: допустимое устаревание и время недоступности администратор должен определить для своей сети до испытаний.31822272931

Заключение

AdGuard Home разумно выбирать за интеграцию индивидуальных политик и encrypted DNS, если администратор готов разбираться с приоритетами правил, направлениями TLS и bootstrap. Первая beta 1.0 — важный контекст развития интерфейса, но не основание считать stable уже версией 1.0. Для эксплуатационного решения особенно существенны реальные настройки optimistic cache и отдельная проверка encrypted fallback, а не номер интерфейса.7121314527

Pi-hole разумно выбирать за модель групп и явную диагностику фильтрации, если внешний proxy для encrypted DNS не является лишней обязанностью. Требуется различать exact/regex allow и подписной antigravity, DNS answer cache и кэш решений, а также export конфигурации и полный backup. Unbound добавляет отдельную рекурсию, но не делает Pi-hole встроенным recursive resolver и не равнозначен шифрованию транспорта.1516262534

blocky разумно выбирать за текстовую воспроизводимость и явные стратегии, если конфигурационный workflow удобнее ручного управления правилами. Цена — необходимость понимать замену списков при merge, назначение групп, гонку только двух upstream и возможный частичный импорт. Ни prefetch, ни дисковый list cache, ни локальный healthcheck по отдельности не доказывают сквозную готовность резолвить с полной политикой.32028293031

Итоговый критерий выбора — не максимум возможностей, а минимальное число непроверенных эксплуатационных предположений. Сначала определить нужную политику и путь клиента, затем допустимую свежесть, затем граф запуска и независимый резерв. Несколько upstream спасают не от того же отказа, что второй DNS-сервер, а публичный secondary меняет сам контракт фильтрации. Без испытания этих границ объявлять одного из трёх победителем по надёжности было бы сильнее имеющихся доказательств.19262832

Quality Metrics

MetricValue
Sources found61
Sources read58
Sources cited34
Academic sources0
Official/documentation34
Industry reports0
News/journalism0
Blog/forum0
Count unitУникальные canonical URL документов и файлов; не независимые исследования
Corpus qualificationВ read включены устаревшие wiki и тестовый fixture; они не цитируются. Три несуществующих пути — только found
Official qualificationДокументация, релизы, исходники и один официальный FAQ проекта; файлы одного тега и wiki-копии не являются независимыми подтверждениями
Citation coverage91% (50/55 содержательных абзацев; алгоритм strict checker)
Counter-arguments searchedДа: ограничения правил, secondary DNS, bootstrap, частичный импорт и пределы healthcheck
Research roundsОдин параллельный широкий раунд и адресные уточнения версий и противоречий
Questions emergedОтдельный количественный журнал не вёлся
Questions insufficient dataКлиентское переключение, runtime-отказы, производительность и восстановление не проверены
Runtime verificationDNS-запросы, benchmarks, restore и fault drills не выполнялись
Mechanical verificationСноски, URL, объём, покрытие и дословные выдержки сверены программно
Main-text words3311; без frontmatter, Quality Metrics, библиографии и маркеров сносок

  1. AdGuard Team. “DNS filtering rules syntax | AdGuard DNS Knowledge Base.” Изменяемая Knowledge Base; сопоставление с v0.107.80, доступ 2026-11-07. https://adguard-dns.io/kb/general/dns-filtering-syntax/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Pi-hole. “Group Management.” Изменяемая документация, доступ 2026-11-07. https://docs.pi-hole.net/group_management/ ↩︎ ↩︎ ↩︎

  3. Проект blocky. “Configuration.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/docs/configuration.md ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. AdGuard Team. “Clients | AdGuard DNS Knowledge Base.” Изменяемая Knowledge Base; сопоставление с v0.107.80, доступ 2026-11-07. https://adguard-dns.io/kb/adguard-home/clients/ ↩︎ ↩︎ ↩︎

  5. AdGuard Team. “DNS encryption | AdGuard DNS Knowledge Base.” Изменяемая Knowledge Base; сопоставление с v0.107.80, доступ 2026-11-07. https://adguard-dns.io/kb/adguard-home/encryption/ ↩︎ ↩︎ ↩︎

  6. Pi-hole. “dnscrypt-proxy (DoH).” Изменяемая документация, доступ 2026-11-07. https://docs.pi-hole.net/guides/dns/dnscrypt-proxy/ ↩︎ ↩︎ ↩︎ ↩︎

  7. AdGuard Team. “Release AdGuard Home v0.107.80 · AdguardTeam/AdGuardHome · GitHub.” v0.107.80, 2026-11-03. https://github.com/AdguardTeam/AdGuardHome/releases/tag/v0.107.80 ↩︎ ↩︎ ↩︎

  8. Pi-hole. “Release v6.5 · pi-hole/pi-hole · GitHub.” v6.5, 2026-10-17. https://github.com/pi-hole/pi-hole/releases/tag/v6.5 ↩︎

  9. Pi-hole. “Release Pi-hole FTL v6.8 · pi-hole/FTL · GitHub.” v6.8, 2026-10-17. https://github.com/pi-hole/FTL/releases/tag/v6.8 ↩︎

  10. Pi-hole. “Release v6.6.1 · pi-hole/web · GitHub.” v6.6.1, 2026-10-17. https://github.com/pi-hole/web/releases/tag/v6.6.1 ↩︎

  11. Проект blocky. “v0.35.0.” v0.35.0, 2026-09-05. https://github.com/0xERR0R/blocky/releases/tag/v0.35.0 ↩︎

  12. AdGuard Team. “Release AdGuard Home v1.0.0-b.1 · AdguardTeam/AdGuardHome · GitHub.” v1.0.0-b.1, 2026-09-30. https://github.com/AdguardTeam/AdGuardHome/releases/tag/v1.0.0-b.1 ↩︎ ↩︎

  13. AdGuard Team. “Release AdGuard Home v1.0.0-b.2 · AdguardTeam/AdGuardHome · GitHub.” v1.0.0-b.2, 2026-11-05. https://github.com/AdguardTeam/AdGuardHome/releases/tag/v1.0.0-b.2 ↩︎ ↩︎

  14. AdGuard Team. “AdGuardHome/README.md at v0.107.80 · AdguardTeam/AdGuardHome · GitHub.” v0.107.80, доступ 2026-11-07. https://github.com/AdguardTeam/AdGuardHome/blob/v0.107.80/README.md ↩︎ ↩︎

  15. Pi-hole. “Regex Blocking.” Изменяемая документация, доступ 2026-11-07. https://docs.pi-hole.net/regex/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  16. Pi-hole. “dnsmasq interfacing routines.” v6.8, доступ 2026-11-07. https://raw.githubusercontent.com/pi-hole/FTL/v6.8/src/dnsmasq_interface.c ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  17. Pi-hole. “Gravity database routines.” v6.8, доступ 2026-11-07. https://raw.githubusercontent.com/pi-hole/FTL/v6.8/src/database/gravity-db.c ↩︎ ↩︎

  18. Pi-hole. “Config routines.” v6.8, доступ 2026-11-07. https://raw.githubusercontent.com/pi-hole/FTL/v6.8/src/config/config.c ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  19. AdGuard Team. “Configuration | AdGuard DNS Knowledge Base.” Изменяемая Knowledge Base; сопоставление с v0.107.80, доступ 2026-11-07. https://adguard-dns.io/kb/adguard-home/configuration/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  20. Проект blocky. “resolver/caching_resolver.go.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/resolver/caching_resolver.go ↩︎ ↩︎ ↩︎

  21. AdGuard Team. “AdGuardHome/internal/home/config.go at v0.107.80 · AdguardTeam/AdGuardHome · GitHub.” v0.107.80, доступ 2026-11-07. https://github.com/AdguardTeam/AdGuardHome/blob/v0.107.80/internal/home/config.go ↩︎ ↩︎ ↩︎

  22. AdGuard Team. “dnsproxy/proxy/cache.go at v0.83.2 · AdguardTeam/dnsproxy · GitHub.” v0.83.2, доступ 2026-11-07. https://github.com/AdguardTeam/dnsproxy/blob/v0.83.2/proxy/cache.go ↩︎ ↩︎ ↩︎

  23. AdGuard Team. “AdGuardHome/go.mod at v0.107.80 · AdguardTeam/AdGuardHome · GitHub.” v0.107.80, доступ 2026-11-07. https://github.com/AdguardTeam/AdGuardHome/blob/v0.107.80/go.mod ↩︎ ↩︎

  24. AdGuard Team. “dnsproxy/proxy/config.go at v0.83.2 · AdguardTeam/dnsproxy · GitHub.” v0.83.2, доступ 2026-11-07. https://github.com/AdguardTeam/dnsproxy/blob/v0.83.2/proxy/config.go ↩︎ ↩︎ ↩︎

  25. Pi-hole. “unbound.” Изменяемая документация, доступ 2026-11-07. https://docs.pi-hole.net/guides/dns/unbound/ ↩︎ ↩︎ ↩︎

  26. Проект blocky. “resolver/bootstrap.go.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/resolver/bootstrap.go ↩︎ ↩︎

  27. AdGuard Team. “AdGuardHome/internal/dnsforward/dnsforward.go at v0.107.80 · AdguardTeam/AdGuardHome · GitHub.” v0.107.80, доступ 2026-11-07. https://github.com/AdguardTeam/AdGuardHome/blob/v0.107.80/internal/dnsforward/dnsforward.go ↩︎ ↩︎ ↩︎

  28. Проект blocky. “resolver/parallel_best_resolver.go.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/resolver/parallel_best_resolver.go ↩︎ ↩︎ ↩︎ ↩︎

  29. Проект blocky. “lists/list_cache.go.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/lists/list_cache.go ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  30. Проект blocky. “lists/download_cache.go.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/lists/download_cache.go ↩︎ ↩︎

  31. Проект blocky. “server/server.go.” v0.35.0, доступ 2026-11-07. https://raw.githubusercontent.com/0xERR0R/blocky/v0.35.0/server/server.go ↩︎ ↩︎ ↩︎

  32. Pi-hole. “Why should Pi-hole be my only DNS server? - FAQs - Pi-hole Userspace.” Архитектурный FAQ, 2017-05-26. https://discourse.pi-hole.net/t/why-should-pi-hole-be-my-only-dns-server/3376 ↩︎ ↩︎ ↩︎ ↩︎

  33. AdGuard Team. “Getting started | AdGuard DNS Knowledge Base.” Изменяемая Knowledge Base; сопоставление с v0.107.80, доступ 2026-11-07. https://adguard-dns.io/kb/adguard-home/getting-started/ ↩︎

  34. Pi-hole. “Teleporter un-/compression routines.” v6.8, доступ 2026-11-07. https://raw.githubusercontent.com/pi-hole/FTL/v6.8/src/zip/teleporter.c ↩︎ ↩︎