Защита DNS от DDoS: фильтровать нужно не только трафик, но и архитектуру

Защита DNS от DDoS: фильтровать нужно не только трафик, но и архитектуру

DDoS по DNS бьёт в два слоя: в авторитативную зону и в канал доставки ответа. Если один сервер держит весь спрос, любой всплеск превращается в отказ. Давайте разберем флоу запроса: клиент → рекурсор → авторитативный узел → ответ. Слабое звено часто не в DNS-пакете, а в том, где заканчивается запас по PPS, bandwidth или state table.

Базовый набор без магии:
— Anycast для распределения нагрузки и локализации отказа;
— несколько независимых площадок и провайдеров;
— минимальный и предсказуемый ответ зоны, без «тяжелых» записей и лишних цепочек;
— RRL и ограничения на усиление через large responses;
— separate control plane: доступ к управлению зоной не должен жить рядом с публичным DNS.

Отдельно смотрим на рекурсивный и авторитативный контуры. Рекурсор под атакой может утянуть за собой кэш, upstream и каналы связи. Авторитативный сервер под UDP-флудом должен сохранять доступность хотя бы для легитимных запросов. Стабильность DNS — это фундамент, а не опция. Проверим влияние на RTT и консистентность зон: иногда лучший анти-DDoS — не «мощнее железо», а меньше точек отказа и аккуратнее политика публикации записей.

Исключаем Human Error через автоматизацию: шаблоны конфигураций, контроль изменений, тестирование failover и регулярная проверка, что NS, glue и SOA не создают лишней хрупкости. Если защита строится на одном «толстом» сервере и ручных правках, это не защита, а отсроченный инцидент.