Автор обнаружил подмену DNS, когда разбирался с недоступным внешним сайтом в своём homelab. Ошибка возникала почти мгновенно, поэтому он проверил домен через dig и несколько публичных резолверов, включая Google DNS и Cloudflare. Обычные запросы почти всегда возвращали один и тот же IP, тогда как запрос через Cloudflare DoH дал другой адрес. Проверка владельца первого IP показала, что он принадлежит интернет-провайдеру автора. По его выводу, провайдер перехватывал DNS-запросы и возвращал изменённые ответы.
После публикации истории в социальной сети автор решил разобрать распространённые советы. Локальный Unbound сам по себе не решает проблему: рекурсивный резолвер обращается к корневым и авторитативным серверам через традиционный незашифрованный DNS, обычно по UDP. Такой трафик провайдер способен читать и изменять. Если же Unbound пересылает запросы другому резолверу по DoT, соединение с ним защищено от вмешательства в пути.
DNSSEC выполняет другую задачу. Криптографические подписи позволяют проверить подлинность DNS-данных, но не шифруют запросы и ответы. Для защиты необходимы правильно настроенная подпись домена и полная цепочка доверия. По октябрьскому исследованию Defaults.Exposed 2026 года, лишь 7,03% проверенных доменов имели корректную полностью валидируемую цепочку DNSSEC. Если изменённый ответ не проходит проверку, резолвер возвращает SERVFAIL вместо поддельного IP.
DoH и DoT тоже не устраняют все риски. Они шифруют соединение с выбранным резолвером, однако его оператор по-прежнему может видеть запросы и изменять ответы. Кроме того, провайдер способен определять посещаемые сайты по SNI во время TLS-handshake, а иногда и по IP назначения. VPN скрывает трафик от провайдера, но переносит доверие на VPN-сервис; сам автор использует Mullvad через exit node Tailscale.
В собственной инфраструктуре автор более трёх лет применяет Pi-hole или AdGuard. Сейчас основной DNS — AdGuard, а dnscrypt-proxy отправляет вышестоящие запросы по DNSCrypt. Для контейнеров, где перерыв в разрешении имён особенно нежелателен, Cloudflare настроен резервным вариантом, хотя локальный AdGuard остаётся основным. Такой резерв нужен, чтобы сбой локального DNS во время обновления одного контейнера не нарушал работу остальных. Серверы автора работают на NixOS, а его конфигурационные файлы открыты.