Защита DNS от DDoS: что должно работать до первого всплеска трафика

Защита DNS от DDoS: что должно работать до первого всплеска трафика

DNS ломают не «по-серому», а по площадям: flood по UDP, NXDOMAIN-шторм, амплификация через открытые резолверы и попытки выбить control plane. Давайте разберем флоу запроса: клиент → anycast edge → фильтрация → авторитативный сервер → ответ. Если на любом участке нет запасов по PPS, толку от красивой зоны немного.

Базовый набор защиты выглядит скучно, и именно поэтому он работает:
• anycast для распределения нагрузки и поглощения локального перегруза;
• RRL и rate limiting на уровне ответов;
• жесткий ACL на recursion, чтобы не кормить атакующего амплификацией;
• separate management plane, чтобы панель управления не делила CPU с обслуживанием запросов.

Отдельно смотрим на протоколы и размеры ответов. EDNS0, DNSSEC, large responses и TCP fallback увеличивают стоимость запроса; это не повод их отключать, но повод считать бюджеты по bandwidth и conntrack. Проверим влияние на RTT и консистентность зон: при перегрузе страдают не только ответы, но и обновления, журналирование, репликация вторичных серверов.

Самая частая ошибка — защищать только внешний периметр и забывать про upstream-провайдера, IX и план аварийного сужения сервиса: укрупненные ответы, временное отключение второстепенных записей, перевод части трафика на вторичный контур. Исключаем Human Error через автоматизацию.

Стабильность DNS — это фундамент, а не опция: стройте защиту так, чтобы атака упиралась в инфраструктуру, а не в один сервер или один человек.