DNS — штука удобная, когда речь идёт о публичных сайтах и API. Людям проще запомнить wikipedia.org, чем IP-адрес, и менять адрес за доменом можно безболезненно. Но автор статьи предлагает присмотреться: а зачем вообще использовать DNS для внутренней IT-инфраструктуры, будь то облако или on-prem?
Проблема в том, что DNS — лишний компонент. Надёжная система строится на минимуме деталей. Каждый новый узел — это потенциальный сбой и неочевидные взаимодействия вроде циклических зависимостей. Вспомните классическийhaiku: «Это не DNS... А, это был DNS». Или громкий сбой Facebook/Meta, когда из-за DNS-зависимостей людей не пускали в здания. Корень проблемы — не сам DNS, но его взрывной радиус делает любой инцидент катастрофическим.
Основной недостаток для операционной работы — кэширование по TTL. Клиенты ведут себя по-разному, и единственный способ заставить серверы увидеть новый IP — принудительно сбросить им кэш. Но для общения машин с машинами DNS не нужен. Можно просто прописать IP-адреса в конфиги — с помощью Ansible или pyinfra это делается массово. Контраргумент: людям проще читать доменные имена. На это автор отвечает: используйте /etc/hosts. Его легко раздавать, запросы к нему быстрые, а DNS-сервер не нужен.
Безопасность — ещё один удар по DNS. Большая часть трафика теперь шифруется, а DNS по умолчанию — нет. Внутреннюю сеть можно считать безопасной, но атака на DNS или спуфинг пакетов всё равно разрушительны. DNSSEC теоретически исправляет это, но добавляет ещё один слой сложности с риском ошибок в настройках.
Хуже того, DNS — отличный канал для эксфильтрации данных. Egress-фильтрацию часто пропускают для «доверенных» систем. А зря: атакующий может получить домен, поднять свой authoritative nameserver и отправлять на него запросы вида sensitivedata.evil.domain прямо с взломанного сервера. Данные окажутся в логах DNS-сервера злоумышленника. Для таких атак существуют даже готовые инструменты — dnscat2 и iodine. Поэтому автор предлагает хотя бы запретить серверам напрямую запрашивать публичные DNS-записи, а для внешних соединений использовать прокси с allow-листами.
В итоге всё сводится к компромиссу: контекст, риск-аппетит и культура организации решают. Но поразмышлять о том, чтобы вообще отказаться от DNS внутри инфраструктуры ради надёжности и устойчивости, определённо стоит. Автор ждёт обсуждения в ветке на Hacker News.