<b>DDoS на DNS: ломается не резолвинг, а дисциплина архитектуры</b>

<b>DDoS на DNS: ломается не резолвинг, а дисциплина архитектуры</b>

DNS-инфраструктуру редко валят «силой одного пакета». Обычно бьют по двум точкам: по bandwidth и по состоянию на узле. Если authoritative-сервер сидит в одном сегменте, без anycast и без разграничения control plane/data plane, он становится удобной целью. Стабильность DNS — это фундамент, а не опция.

Давайте разберем флоу запроса. Клиент → recursive resolver → authoritative. Защита строится не на одном фильтре, а на цепочке:
— anycast для распределения нагрузки и размывания источника;
— отдельные площадки и ASN-политики для отказоустойчивости;
— rate limiting на edge, но без убийства легитимных пиков;
— минимизация зонального «шума»: no unnecessary ANY, аккуратные TTL, сжатые ответы.
Проверим влияние на RTT и консистентность зон: если защита увеличивает задержку или ломает синхронизацию, это уже не защита, а латентная деградация.

На уровне сервера важны два режима. Первый — пережить flood за счет stateless-поведения и кэша. Второй — не дать атаке съесть CPU на обработке динамики, журналировании и тяжёлых ответах. Поэтому:
— отключаем лишнюю логику на public-facing узлах;
— ограничиваем recursion там, где он не нужен;
— отделяем hidden master от внешних авторитативов;
— заранее проверяем, как ведут себя DNSSEC-ответы под нагрузкой.

И последнее: защита от DDoS начинается не в момент атаки, а в момент проектирования. Исключаем Human Error через автоматизацию: шаблоны ACL, тесты конфигурации, контроль health-checks и регулярная проверка отказа площадки. Иначе любой «анти-DDoS» превращается в дорогой способ ускорить собственный инцидент.

—
Рядом по жанру: @affcareers_moscow