DNSSEC имеет некоторые риски, но они не связаны напрямую с отражением или усилением. В этом случае расширение размера сообщения EDNS0 - это красная сельдь. Позволь мне объяснить.
Любой обмен пакетами, который не зависит от предыдущего подтверждения личности, подвергается злоупотреблению со стороны злоумышленников DDoS, которые могут использовать этот обмен пакетами без проверки подлинности в качестве отражателя и, возможно, также в качестве усилителя. Например, ICMP (протокол, стоящий за «ping») может быть использован таким образом. Как и пакет TCP SYN, который запрашивает до 40 пакетов SYN-ACK, даже если SYN был подделан, чтобы прийти от какой-то жертвы, которая не хочет эти пакеты SYN-ACK. И, конечно, все службы UDP уязвимы для этой атаки, включая NTP, SSDP, uPNP и, как отмечалось в других ответах, включая DNS.
Большинство устройств обнаружения вторжений, предотвращения вторжений и балансировки нагрузки являются узкими местами, которые не в состоянии справиться с трафиком со «скоростью линии». Также многие маршрутизаторы не могут работать на скорости линии, а некоторые коммутаторы. Эти узкие места, будучи самым маленьким «на пути» и меньшим, чем сами ссылки, являются реальной целью DDoS-атак на основе перегрузки. Если вы можете держать чей-то брандмауэр занятым трафиком атаки, то хороший трафик не будет проходить, даже если ссылки не заполнены. И то, что замедляет брандмауэр, это не общее количество бит в секунду (которое может быть увеличено с помощью более крупных сообщений, как это делают EDNS0 и DNSSEC), а скорее общее количество пакетов в секунду.
Существует множество городских легенд о том, как DNSSEC делает DDoS хуже из-за большего размера сообщения DNSSEC, и хотя это имеет интуитивный смысл и «звучит хорошо», это просто ложь. Но если бы в этой легенде была доля правды, реальный ответ был бы в другом месте - [потому что DNSSEC всегда использует EDNS0, но EDNS0 можно использовать без DNSSEC], и многие нормальные ответы, отличные от DNSSEC, равны DNSSEC. ответ будет. Рассмотрим записи TXT, используемые для представления политик SPF или ключей DKIM. Или просто любой большой набор адресов или записей MX. Короче говоря, никакая атака не требует DNSSEC, и, следовательно, любое внимание к DNSSEC как риску DDoS является нерациональной энергией.
DNSSEC имеет риски! Его сложно использовать, и его сложнее правильно использовать. Часто это требует нового рабочего процесса для изменения данных зоны, управления регистратором, установки новых экземпляров сервера. Все это должно быть проверено и задокументировано, и всякий раз, когда что-то ломается, связанное с DNS, технология DNSSEC должна быть исследована как возможная причина. И конечный результат, если вы все сделаете правильно, будет заключаться в том, что, как подписавшая подпись зоны, ваш собственный онлайн-контент и системы будут более хрупкими для ваших клиентов. В результате, как оператора сервера на дальнем конце, контент и системы других пользователей будут более хрупкими для вас. Считается, что эти риски перевешивают преимущества, поскольку единственным преимуществом является защита данных DNS от изменения или замены в полете. Эта атака настолько редка, что не стоит всех этих усилий. Мы все надеемся, что DNSSEC когда-нибудь станет вездесущим благодаря появлению новых приложений. Но правда в том, что сегодня DNSSEC - это все затраты, без выгоды и с высокими рисками.
Поэтому, если вы не хотите использовать DNSSEC, это ваша прерогатива, но не позволяйте никому вводить вас в заблуждение, что проблема DNSSEC заключается в его роли в качестве усилителя DDoS. DNSSEC не играет необходимой роли в качестве усилителя DDoS; Существуют и другие, более дешевые способы использования DNS в качестве усилителя DDoS. Если вы не хотите использовать DNSSEC, пусть будет так, потому что вы еще не выпили помощь Kool и вы хотите быть последним (позже), а не первым (сейчас).
Серверы содержимого DNS, иногда называемые «авторитетными серверами», должны быть защищены от использования в качестве усилителей, отражающих DNS, поскольку DNS использует UDP и потому что UDP может использоваться пакетами с поддельным источником. Способ защиты сервера содержимого DNS от такого рода злоупотреблений состоит не в блокировании UDP, не в принудительном использовании TCP (с использованием трюка TC = 1), ни в блокировании ЛЮБОГО запроса, ни в отказе от DNSSEC. Ничто из этого не поможет вам. Вам нужно ограничение скорости ответов DNS(DNS RRL), полностью бесплатная технология, которая теперь присутствует на нескольких серверах имен с открытым исходным кодом, включая BIND, Knot и NSD. Вы не можете исправить проблему отражения DNS с помощью своего брандмауэра, потому что только контент-ориентированный промежуточный ящик, такой как сам DNS-сервер (с добавленным RRL), знает достаточно о запросе, чтобы иметь возможность точно угадать, что является атакой, а что нет. Я хочу еще раз подчеркнуть: DNS RRL является бесплатным, и каждый сервер авторизации должен его запускать.
В заключение я хочу разоблачить свои предубеждения. Я написал большую часть BIND8, изобрел EDNS0, и я изобрел DNS RRL. Я работаю над DNS с 1988 года как 20 с чем-то, и теперь я сердитый с 50 с чем-то, с меньшим и меньшим терпением к полуиспеченным решениям неправильно понятых проблем. Пожалуйста, примите мои извинения, если это сообщение звучит слишком похоже на "эй, дети, убирайтесь с моего газона!"