В различных реализациях протокола DNSSEC выявлены две уязвимости, затрагивающие DNS-серверы BIND, PowerDNS, dnsmasq и Unbound. Уязвимости позволяют добиться отказа в обслуживании DNS-резолверов, выполняющих валидацию при помощи DNSSEC, через создание высокой нагрузки на CPU, мешающей обработке других запросов. Для совершения атаки достаточно отправить на DNS-резолвер, использующий DNSSEC, запрос, приводящий к обращению к специально оформленной DNS-зоне на сервере злоумышленника...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60599
Knot dns не подвержен? Получается, настоящие днс в безопасности?
Только что обновление вышло https://www.knot-resolver.cz/2024-02-13-knot-resolver-5.7.1....
>В качестве мер для блокирования уязвимостейполный отказ от DNSSEC по причине ugly by design
DNS без DNSSEC слишком прост и надёжен.Кому вообще нужны системы, которые просто работают? Если ничего не падает, то зачем нужен админ?
> DNS без DNSSEC слишком прост и надёжен.DNS (и с DNSSEC, и без) не прост и не надёжен. То, что у тебя дома на OpenWRT dnsmasq без проблем годами работает не значит, что так везде. Кто публичные резолверы держал тот знает.
# echo 'showServers()' | dnsdist -c
# Name Address State Qps Qlim Ord Wt Queries Drops Drate Lat TCP Outstanding Pools
0 10.75.0.53:53 up 74.0 0 1 1 4049028 277 0.0 0.2 0.3 0
1 10.85.0.53:53 up 49.0 0 1 1 3674731 262 0.0 0.8 2.0 0
All 121.0 7723759 539Этот кусочек инфры сойдёт за маленький dnsmasq?
dnsdist, по сравнению с dnsmasq жрёт ресурсы немерено и не умеет также быстро опросить все серверы и ответить, если часть из них не работает
это же балансировщик
> dnsdist, по сравнению с dnsmasq жрёт ресурсы немереноПоэтому и запускаем мы его не на роутере с OpenWRT.
> и не умеет также быстро опросить все серверы и ответить, если часть из них не работает
Это не входит в его задачи. Его функция — распределять нагрузку, а не умножать её, дублируя один и тот же запрос на все апстримы.
Первое, от чего стоит избавиться в проде — от балансировщика днс. Его функция — увеличивать задержки и являться единой точкой отказа. Хуже придумать просто нельзя.
> Первое, от чего стоит избавиться в проде... это от советов людей, которые прода никогда не видели
> являться единой точкой отказа
... и наивно верят, что перед L7-балансировщиками нет L3 (BGP) и L4 (IPVS) яруса.
А ещё эти гадкие балансировщики позволяют делать так
-- Drop rules
addAction(MaxQPSIPRule(2500, 32, 64), DropAction())
addAction(MaxQPSIPRule(5000, 24, 48), DropAction())-- Refuse rules
addAction(MaxQPSIPRule(2000, 32, 64), RCodeAction(DNSRCode.REFUSED))
addAction(MaxQPSIPRule(4000, 24, 48), RCodeAction(DNSRCode.REFUSED))-- Truncate (force TCP) rules
addAction(AndRule({MaxQPSIPRule(500, 32, 64), TCPRule(false)}), TCAction())
addAction(AndRule({MaxQPSIPRule(1000, 24, 48), TCPRule(false)}), TCAction())
> ... и наивно верят, что перед L7-балансировщиками нет L3 (BGP) и L4 (IPVS) яруса.Больше балансировщиков к трону бога балансировщиков! Ну наслаждайся своим ланчиком. Там действительно можно что угодно ставить в любых количествах, хоть на RPI DNS-инфраструктуру развернуть, и всё равно работать будет.
> А ещё эти гадкие балансировщики позволяют делать так
Такой примитив и сам ДНС-сервер может делать. Я бы ещё понял, если бы у тебя там какая-то эвристика была, анализ потока с детектором аномалий, сложные алгоритмы, ИИ, ещё что-то интересное. Но нет, ты выбрал просто увеличение латенси и лишние сущности. Нужно больше золота^Wбалансировщиков!
Без аптайма это фигня какая-то, а не инфа. 7723759 — это за день? За час? В секунду? Или может быть ты «работает — не трогай» и это за три года?Впрочем, я по «красивеньким» RFC1918 адресам вижу, что это какой-то нескучный ланчик — то ли общажная сеть, то ли завод, то ли местячковый провайдер с тысячей клиентов.
> Без аптайма это фигня какая-то, а не инфа. 7723759 — это за день? За час? В секунду? Или может быть ты «работает — не трогай» и это за три года?Для умеющих читать, там есть столбец Qps.
Попробуйте позвать к компьютеру кого-то, кто владеет этим сакральным знанием, пусть он вам прочитает :)> Впрочем, я по «красивеньким» RFC1918 адресам вижу, что это какой-то нескучный ланчик — то ли общажная сеть, то ли завод, то ли местячковый провайдер с тысячей клиентов.
И действительно, серьёзные дяди выставляют все бэкенды голой задницей в интернет.
> Для умеющих читать, там есть столбец Qps.А для умеющих думать ещё и очевидно, что Qps сильно зависит от времени измерений, и чем оно уже, тем больший вес имеют случайные пики. Так что твой выпендрёж снова мимо кассы. Как и смешная цифра в 121 запрос в секунду. Для таких тривиальных объёмов городить три уровня балансировки — это уровень университетской лабы, где надо показать уверенное понимание модели OSI.
> И действительно, серьёзные дяди выставляют все бэкенды голой задницей в интернет.
Серьёзные дяди пользуются публичным адресным пространством и хардварными фаерволлами. Клиенты за лишнюю миллисекунду задержки ответа начинают ЗВОНИТЬ в саппорт и требовать всё срочно починить.
Прастити, у вас ДНС работают на ZX-Spectrum, раз перед ими при нагрузке аж в 121 запрос в секунду пришлось поставить балансировщик?
И что же он знает?
Ну, уважаемый "Аноним (6)" явно знает, как делать громкие заявления, но определённо не знает, как устроены продовые DNS-резолверы (судя по его реакции на балансировщик).
Валидация DNSSEC сейчас используется примерно на 30% публичных резолверов. Начали более-менее массово использовать, появился интерес со стороны исследователей, начали находить дыры. Нормальный процесс в действии. Но диванные в комментариях всё равно будут ныть о том, что им сразу нормально не сделали™. Собаки лают, караван идёт.
Если стандарт 2005 года начали "массово использовать" только в 2024, то караван не очень-то идёт.Ну и главное отличие DNSSEC от HTTPS — в случае проблем с HTTPS пользователь видит в браузере нормальное сообщение о том, что произошло (просроченый серт, некорректное доменное имя, самоподпись), а в случае проблем с DNSSEC — "не удалось найти сервер". И это приговор DNSSEC как системе.
Так ослаблять сеть начали не так давно, раньше это никому в голову не приходило. Теперь нельзя доверять совершенно никому.
То ли дело раньше, никакого SSL и TLS. Что перехватил — все твоё!
Ну собственно провайдеры занимавшиеся продажей подобных данных поступали незаконно, но хотя бы не встраивали рекламные сети с малварью в трафик. Как это стало обычной практикой, все перешли на шифрованный трафик. Начали подменять dns, dnssec получил распространение.
О да, наш любимый DNSSEC очень вам поможет, если провайдер встроит что-то в текст страницы.
> главное отличие DNSSEC от HTTPSВ том же, в чём отличие мягкого от зелёного. Дальше читать твои измышления смысла нет, ты не понимаешь базовых вещей.
> В том же, в чём отличие мягкого от зелёногоНу да, точно. У них действительно нет ничего общего, даже предназначения. HTTPS нужен для безопасности (в том числе, для аутентификации открываемого сайта), DNSSEC — для прикола.
Я не могу тебе запретить упорствовать в твоём невежестве.
DNSSEC - это конечно редкостное удолбище.
Хорошо, что товарищ майор не состоит в ISO.
Там только господа майоры.
А что с systemd-resolved? Неуязвим?
Там DNSSEC дописан наполовину и выключен по умолчанию и разработчиков колышет слабо: https://github.com/systemd/systemd/issues/25676#issuecomment...
> It's very hard to get this work in a reasonable way given the state of DNSSEC servers in the wild.Можно корректно реализовать DNSSEC и подарить пользователям случайные отвалы любимых сайтов, а можно этого не делать, и пользователи будут довольны.
Поттеринг выбрал второе. Потому что он очень злой и нехороший. Только и думает о том, как бы сделать, чтобы пользователи не страдали.
nsd еще жив?
Ты дурной? NSD authoritative only, он валидацией не занимается.
> Ты дурной? NSD authoritative only, он валидацией не занимается.Если оставить за скобками что ты дурной и перечитать мой вопрос, будет ли там что-то про то, что nsd занимается валидацией? Правильно, не будет. Так что, ты дурной, да. На вопрос можешь не отвечать.
Вообще-то, тут обсуждают новость про> Уязвимости позволяют добиться отказа в обслуживании DNS-резолверов, выполняющих валидацию при помощи DNSSEC
И авторитативные серверы тут вообще не при делах.
> CVE-2023-50868 (кодовое имя NSEC3)Уважаемый автор новости, NSEC3 это не кодое имя уязвимости. У этой уязвимости нет "имени" типа KeyTrap. NSEC3 это тип записей в DNS зонах, где используется DNSSEC. Является альтернативой записям типа NSEC.
(пишу в ветке, потому что не удаётся постить комментарий первого уровня).
В первоисточнике
> CVE-2023-50387 (referred here as the KeyTrap vulnerability) and
> CVE-2023-50868 (referred here as the NSEC3 vulnerability).
Хорошо, но контест тоже важен. И в отличие от KeyTrap vulnerability, где уязвимости дали название (тренд поставил Heartbleed в OpenSSL, если помните) "NSEC3 vulnerability" имеется в виду "уязвимость связанный с NSEC3", а не уязвимость, которое имеет "кодовое имя NSEC3".В любом случае, не важно. Спасибо автору за перевод, 100%-ая корректность тут не важна.
Ниже приводится выдержка из описания CVE, в которой уточнено, что уязвимость назвали NSEC3 в честь, неожиданно, NSEC3.
>> CVE-2023-50868 (кодовое имя NSEC3)
> Уважаемый автор новости, NSEC3 это не кодое имя уязвимости. У этой уязвимости
> нет "имени" типа KeyTrap. NSEC3 это тип записей в DNS зонах,
> где используется DNSSEC. Является альтернативой записям типа NSEC.
> (пишу в ветке, потому что не удаётся постить комментарий первого уровня).The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue.
https://www.cve.org/CVERecord?id=CVE-2023-50868
aka the "NSEC3" issue говорят...
Нет DNSSEC - нет проблем.
Сколько вам ещё должно сломатся чтобы понять?
Просто кому-то эти проблемы выгодны.
Нет, просто DNSSEC это костыль, который не хотят выкидывать ибо везде театр безопасности.
Будет время - надо свои YADIFA погонять на предмет уязвимости. Хотя разговор вроде идет о проблемах в проектировании самого DNSSEC
Название - тоненький намёк на то, что NSEC3 - это и есть дыра.