На тему .arpa странно написано про доступность из паблика.
Владея ASN и адресами вполне можно делегировать на любой NS свои зоны in-addr.arpa и ip6.arpa (с помощью объектов типа domain в RIPE DB, например) и резолвить их публично, так и делают для PTR.
И так же можно держать их на внутренних NS, для любых адресов. Первое, что приходит в голову - зоны для RFC1918.
При более-менее серьезном DDoS conntrack на одном сервере вытечет очень быстро, отреагировать не успеете, т.к. там PPS - сотни тысяч.
И если у оператора нет инструментов митигации типа Arbor/gatekeeper и подобных - как-то значительно повлиять на атаку будет сложно.
В последнее несколько лет часто вижу целенаправленные атаки на саму инфраструктуру операторов и ЦОД, а не их клиентов прицельно Часто они к этому не готовы, т.к. привыкли решать проблему блэкхолингом проблемных адресов (а в этом случае - это все адреса).
А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.
Помимо подмены ответа, вылезают ещё проблемы в виде overhead на такие DNS запросы, зависимости от регистраторов и наверняка ещё много других подводных камней.
Хотя идея DANE в этом плане интересная, но скорее перекладывает проблему на другой слой.
И будто бы кроме централизованных CA остаётся только TOFU, но он видится нежизнеспособным в вебе.
Касаемо протоколов не уверен, что есть потребность в реализации SCEP, кажется, он изжил себя, но, возможно, я неправ, буду рад выслушать реальный кейс и боль от отсутствия такового
Он действительно устарел, но все ещё используется. Например, на сетевом оборудовании для управления PKI VPN.
Болью скорее было отсутствие EST на серверной стороне и необходимость использовать этот самый SCEP.
А потом добавляем к атакам через общий page cache большие кластеры kubernetes в каком-нибудь enterprise, с одинаковыми базовыми образами у большинства сервисов - получается совсем неприятно.
После таких вот приколов kata/firecracker/etc уже не выглядят чем-то избыточным.
DNS - он такой, очень много особенностей и легаси, так что время от времени подкидывает головоломки и опять узнаешь что-то новое :)
В почте для этого есть SMTP Banner Check, для проверки PTR. Вероятно, речь об этом.
Спасибо, очень интересный материал.
Если честно, удивило, что в архитектуру сразу не заложили шардинг, хотя профиль нагрузки явно напрашивается на это. Почему так?
И интересны причины, почему выбрали Postgres, а не ваш же YDB под эти данные?
На тему .arpa странно написано про доступность из паблика.
Владея ASN и адресами вполне можно делегировать на любой NS свои зоны in-addr.arpa и ip6.arpa (с помощью объектов типа domain в RIPE DB, например) и резолвить их публично, так и делают для PTR.
И так же можно держать их на внутренних NS, для любых адресов. Первое, что приходит в голову - зоны для RFC1918.
А как же неискоренимый .local и mDNS? :)
При более-менее серьезном DDoS conntrack на одном сервере вытечет очень быстро, отреагировать не успеете, т.к. там PPS - сотни тысяч.
И если у оператора нет инструментов митигации типа Arbor/gatekeeper и подобных - как-то значительно повлиять на атаку будет сложно.
В последнее несколько лет часто вижу целенаправленные атаки на саму инфраструктуру операторов и ЦОД, а не их клиентов прицельно Часто они к этому не готовы, т.к. привыкли решать проблему блэкхолингом проблемных адресов (а в этом случае - это все адреса).
А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.
Про миграцию и инструменты, которые предлагает этот стек, хотелось бы подробнее узнать.
Как/чем вендор рекомендует массово переносить VM из других платформ?
Помимо подмены ответа, вылезают ещё проблемы в виде overhead на такие DNS запросы, зависимости от регистраторов и наверняка ещё много других подводных камней.
Хотя идея DANE в этом плане интересная, но скорее перекладывает проблему на другой слой.
И будто бы кроме централизованных CA остаётся только TOFU, но он видится нежизнеспособным в вебе.
Скорее, что-нибудь вроде DKIM.
Текущий формат PKI в целом давно уже пора пересматривать и уходить от централизации, в т.ч. из-за таких рисков.
Непонятно только, как обеспечивать валидацю.
Поддерживаю, тоже им пользуюсь уже давно на нескольких устройствах - отлично работает.
Спасибо за детальный тест.
Интересно было бы сравнить на таких моделях, как сильно деградирует производительность при работе через PCI, без NVlink. Не пробовали?
Кластер из двух участников выглядит не очень надёжно.
Как вы решаете проблему split brain? Как обеспечивается кворум?
Он действительно устарел, но все ещё используется. Например, на сетевом оборудовании для управления PKI VPN.
Болью скорее было отсутствие EST на серверной стороне и необходимость использовать этот самый SCEP.
Спасибо за статью, интересный проект.
А не смотрели ejbca или step-ca? Интересно, чем не подошли в вашем случае.
Есть ли возможность не хранить private key в базе и передавать CSR на подпись?
Планируете добавить поддержку ACME, EST и SCEP?
Есть ZFS, можно собрать в установщике или webui.
Это всегда было, независимо от зрелости и стабильности направления. Тем более, если сейчас это модно, как AI, который все пытаются внедрить везде.
А потом добавляем к атакам через общий page cache большие кластеры kubernetes в каком-нибудь enterprise, с одинаковыми базовыми образами у большинства сервисов - получается совсем неприятно.
После таких вот приколов kata/firecracker/etc уже не выглядят чем-то избыточным.
Он редиректит на лежавший вчера https://ubuntu.com/security/CVE-2026-31431