Защита DNS от DDoS: где ломается сервис и как не строить одну точку отказа

Защита DNS от DDoS: где ломается сервис и как не строить одну точку отказа

DNS атакуют не «на удачу», а по двум векторам: забить канал и выжечь CPU резолвера. Поэтому базовый слой защиты начинается не с фильтра, а с архитектуры: anycast на нескольких площадках, разнесение authoritative и recursive ролей, лимиты на qps и отдельные политики для публичных и внутренних зон.

Давайте разберем флоу запроса. Если авторитативный сервер отвечает всем подряд без rate limiting и ACL, attacker быстро переводит нагрузку в дорогое состояние: cache miss, рост очередей, деградация RTT. Для этого нужны:
— RRL или аналог throttling на ответах;
— отказ от open recursion;
— минимизация amplification: без лишних записей, без мусорных дополнительных секций;
— отдельный канал мониторинга, который не зависит от того же узла.

Проверим влияние на RTT и консистентность зон. Любая «защита» через централизованный reverse proxy для DNS часто превращается в узкое горлышко. Стабильнее работают распределенные точки входа, жесткие ACL на axfr/ixfr, ограничение размера ответов и sane TTL: не слишком низкий, чтобы не убить cache, и не слишком высокий, чтобы не зафиксировать мусор надолго.

Исключаем Human Error через автоматизацию: шаблоны зон, контроль изменений, preflight-проверка SOA/NS/DNSSEC, и отдельный сценарий деградации — что отключаем первым, что оставляем последним. Стабильность DNS — это фундамент, а не опция.