| 1.2, Аноним (2), 18:23, 14/02/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +13 +/– | |
>В качестве мер для блокирования уязвимостей
полный отказ от DNSSEC по причине ugly by design
| | |
| |
| 2.3, Аноним (3), 18:28, 14/02/2024 [^] [^^] [^^^] [ответить]
| +9 +/– | |
DNS без DNSSEC слишком прост и надёжен.
Кому вообще нужны системы, которые просто работают? Если ничего не падает, то зачем нужен админ?
| | |
| |
| 3.6, Аноним (6), 18:48, 14/02/2024 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> DNS без DNSSEC слишком прост и надёжен.
DNS (и с DNSSEC, и без) не прост и не надёжен. То, что у тебя дома на OpenWRT dnsmasq без проблем годами работает не значит, что так везде. Кто публичные резолверы держал тот знает.
| | |
| |
| 4.7, Аноним (3), 18:53, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
# 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?
| | |
| |
| 5.11, Гость (??), 20:16, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
dnsdist, по сравнению с dnsmasq жрёт ресурсы немерено и не умеет также быстро опросить все серверы и ответить, если часть из них не работает
| | |
| |
| 6.18, Аноним (3), 21:48, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> dnsdist, по сравнению с dnsmasq жрёт ресурсы немерено
Поэтому и запускаем мы его не на роутере с OpenWRT.
> и не умеет также быстро опросить все серверы и ответить, если часть из них не работает
Это не входит в его задачи. Его функция — распределять нагрузку, а не умножать её, дублируя один и тот же запрос на все апстримы.
| | |
| |
| 7.39, Аноним (6), 18:39, 15/02/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Первое, от чего стоит избавиться в проде — от балансировщика днс. Его функция — увеличивать задержки и являться единой точкой отказа. Хуже придумать просто нельзя.
| | |
| |
| |
| 9.46, Аноним (6), 22:28, 15/02/2024 [^] [^^] [^^^] [ответить] | +/– | Больше балансировщиков к трону бога балансировщиков Ну наслаждайся своим ланчик... текст свёрнут, показать | | |
|
|
|
|
| 5.38, Аноним (6), 18:34, 15/02/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Без аптайма это фигня какая-то, а не инфа. 7723759 — это за день? За час? В секунду? Или может быть ты «работает — не трогай» и это за три года?
Впрочем, я по «красивеньким» RFC1918 адресам вижу, что это какой-то нескучный ланчик — то ли общажная сеть, то ли завод, то ли местячковый провайдер с тысячей клиентов.
| | |
| |
| 6.43, Аноним (3), 21:28, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Без аптайма это фигня какая-то, а не инфа. 7723759 — это за день? За час? В секунду? Или может быть ты «работает — не трогай» и это за три года?
Для умеющих читать, там есть столбец Qps.
Попробуйте позвать к компьютеру кого-то, кто владеет этим сакральным знанием, пусть он вам прочитает :)
> Впрочем, я по «красивеньким» RFC1918 адресам вижу, что это какой-то нескучный ланчик — то ли общажная сеть, то ли завод, то ли местячковый провайдер с тысячей клиентов.
И действительно, серьёзные дяди выставляют все бэкенды голой задницей в интернет.
| | |
| |
| 7.47, Аноним (6), 22:37, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Для умеющих читать, там есть столбец Qps.
А для умеющих думать ещё и очевидно, что Qps сильно зависит от времени измерений, и чем оно уже, тем больший вес имеют случайные пики. Так что твой выпендрёж снова мимо кассы. Как и смешная цифра в 121 запрос в секунду. Для таких тривиальных объёмов городить три уровня балансировки — это уровень университетской лабы, где надо показать уверенное понимание модели OSI.
> И действительно, серьёзные дяди выставляют все бэкенды голой задницей в интернет.
Серьёзные дяди пользуются публичным адресным пространством и хардварными фаерволлами. Клиенты за лишнюю миллисекунду задержки ответа начинают ЗВОНИТЬ в саппорт и требовать всё срочно починить.
| | |
|
|
| 5.50, Аноним (50), 14:59, 17/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
Прастити, у вас ДНС работают на ZX-Spectrum, раз перед ими при нагрузке аж в 121 запрос в секунду пришлось поставить балансировщик?
| | |
|
| |
| 5.44, Аноним (3), 21:30, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну, уважаемый "Аноним (6)" явно знает, как делать громкие заявления, но определённо не знает, как устроены продовые DNS-резолверы (судя по его реакции на балансировщик).
| | |
|
|
|
|
| 1.5, Аноним (6), 18:45, 14/02/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Валидация DNSSEC сейчас используется примерно на 30% публичных резолверов. Начали более-менее массово использовать, появился интерес со стороны исследователей, начали находить дыры. Нормальный процесс в действии. Но диванные в комментариях всё равно будут ныть о том, что им сразу нормально не сделали™. Собаки лают, караван идёт.
| | |
| |
| 2.8, Аноним (3), 19:00, 14/02/2024 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Если стандарт 2005 года начали "массово использовать" только в 2024, то караван не очень-то идёт.
Ну и главное отличие DNSSEC от HTTPS — в случае проблем с HTTPS пользователь видит в браузере нормальное сообщение о том, что произошло (просроченый серт, некорректное доменное имя, самоподпись), а в случае проблем с DNSSEC — "не удалось найти сервер". И это приговор DNSSEC как системе.
| | |
| |
| 3.16, Аноним (1), 21:44, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
Так ослаблять сеть начали не так давно, раньше это никому в голову не приходило. Теперь нельзя доверять совершенно никому.
| | |
| |
| 4.20, Аноним (3), 21:49, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
То ли дело раньше, никакого SSL и TLS. Что перехватил — все твоё!
| | |
| |
| 5.23, Аноним (1), 22:04, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну собственно провайдеры занимавшиеся продажей подобных данных поступали незаконно, но хотя бы не встраивали рекламные сети с малварью в трафик. Как это стало обычной практикой, все перешли на шифрованный трафик. Начали подменять dns, dnssec получил распространение.
| | |
| |
| 6.25, Аноним (3), 22:16, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
О да, наш любимый DNSSEC очень вам поможет, если провайдер встроит что-то в текст страницы.
| | |
|
|
|
| 3.37, Аноним (6), 18:28, 15/02/2024 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> главное отличие DNSSEC от HTTPS
В том же, в чём отличие мягкого от зелёного. Дальше читать твои измышления смысла нет, ты не понимаешь базовых вещей.
| | |
| |
| 4.45, Аноним (3), 21:33, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> В том же, в чём отличие мягкого от зелёного
Ну да, точно. У них действительно нет ничего общего, даже предназначения. HTTPS нужен для безопасности (в том числе, для аутентификации открываемого сайта), DNSSEC — для прикола.
| | |
|
|
|
| |
| |
| 3.21, Аноним (3), 21:54, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> It's very hard to get this work in a reasonable way given the state of DNSSEC servers in the wild.
Можно корректно реализовать DNSSEC и подарить пользователям случайные отвалы любимых сайтов, а можно этого не делать, и пользователи будут довольны.
Поттеринг выбрал второе. Потому что он очень злой и нехороший. Только и думает о том, как бы сделать, чтобы пользователи не страдали.
| | |
|
|
| |
| |
| 3.27, IdeaFix (ok), 23:11, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
 > Ты дурной? NSD authoritative only, он валидацией не занимается.
Если оставить за скобками что ты дурной и перечитать мой вопрос, будет ли там что-то про то, что nsd занимается валидацией? Правильно, не будет. Так что, ты дурной, да. На вопрос можешь не отвечать.
| | |
| |
| 4.31, Аноним (3), 00:10, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Вообще-то, тут обсуждают новость про
> Уязвимости позволяют добиться отказа в обслуживании DNS-резолверов, выполняющих валидацию при помощи DNSSEC
И авторитативные серверы тут вообще не при делах.
| | |
|
|
| 2.24, Editor (-), 22:04, 14/02/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> CVE-2023-50868 (кодовое имя NSEC3)
Уважаемый автор новости, NSEC3 это не кодое имя уязвимости. У этой уязвимости нет "имени" типа KeyTrap. NSEC3 это тип записей в DNS зонах, где используется DNSSEC. Является альтернативой записям типа NSEC.
(пишу в ветке, потому что не удаётся постить комментарий первого уровня).
| | |
| |
| 3.26, Аноним (3), 22:18, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
В первоисточнике
> CVE-2023-50387 (referred here as the KeyTrap vulnerability) and
> CVE-2023-50868 (referred here as the NSEC3 vulnerability).
| | |
| |
| 4.34, Editor (-), 02:42, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Хорошо, но контест тоже важен. И в отличие от KeyTrap vulnerability, где уязвимости дали название (тренд поставил Heartbleed в OpenSSL, если помните) "NSEC3 vulnerability" имеется в виду "уязвимость связанный с NSEC3", а не уязвимость, которое имеет "кодовое имя NSEC3".
В любом случае, не важно. Спасибо автору за перевод, 100%-ая корректность тут не важна.
| | |
| |
| 5.36, Аноним (3), 10:57, 15/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ниже приводится выдержка из описания CVE, в которой уточнено, что уязвимость назвали NSEC3 в честь, неожиданно, NSEC3.
| | |
|
|
| 3.28, IdeaFix (ok), 23:15, 14/02/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> 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 говорят...
| | |
|
|
| |
| |
| 3.33, Ivan_83 (ok), 01:00, 15/02/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Нет, просто DNSSEC это костыль, который не хотят выкидывать ибо везде театр безопасности.
| | |
|
|
| 1.35, bOOster (ok), 10:15, 15/02/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Будет время - надо свои YADIFA погонять на предмет уязвимости. Хотя разговор вроде идет о проблемах в проектировании самого DNSSEC
| | |
|
