dxdt.blog: занимательный интернет-журнал

Сайт продолжает выходить под новым именем dxdt.blog. Пять избранных записок за май 2026 года:

• О тегах ключей в DNSSEC
• Терминологическое: “подбор на квантовом компьютере” и криптология
• Доказательство Евклидом теоремы Евклида и популярная книга
• Интернеты и запуск постапокалипсиса
• ИИ и живописные Квадраты

Кстати, занятно: ещё в 2016 году SpaceX обещали, что не позднее 2018 года доставят тяжёлый аппарат на Марс, в качестве первого шага марсианской программы SpaceX.

Это, конечно, и тогда-то выглядело очень сомнительно (о чём и написано в записке по ссылке). Десять лет прошло с 2016 года, но что-то именно в SpaceX марсианскую программу не развили совсем, аппаратов-роботов от этой корпорации на Марсе нет и сейчас, что уж там говорить про 2018 год. Зато сильно развили в SpaceX военную спутниковую низкоорбитальную группировку – Starshield, – которая работает на базе Starlink. Оно и понятно: от мифического строительства городов на Марсе толку нет, кроме как при использовании в качестве схемы прикрытия.

Нужно ли использовать DNSSEC? Хотелось бы просто написать: да. Но, к сожалению, многолетняя история данной технологии уже обставлена особенностями, которые не позволяют написать просто “да”.

Напомню, кратко, что такое DNSSEC: это технология, позволяющая удостоверять адресную информацию в DNS при помощи механизмов цифровой подписи. Основная особенность DNSSEC в том, что она пристраивает к “классической DNS” схему делегирования по криптографическим ключам, которая позволяет транслировать доверие между зонами, по иерархии. То есть, в “классической DNS” используется делегирование по именам авторитативных серверов: зона уровнем выше содержит имена серверов, которые отвечают за зону уровнем ниже. Например, если у нас есть example.com., то в зоне com. указывается перечень имён серверов (NS), которые администрация зоны com. уполномочила отвечать за example.com.

В DNSSEC нет делегирования по серверам имён (делегирующие ответы со списком NS даже не подписываются), но есть делегирование по криптографическим ключам, которые служат для проверки подписей: зона уровнем выше содержит отпечаток ключа для зоны уровнем ниже; в примере с example.com – в зоне .com размещается отпечаток целевого ключа к зоне example.com, при этом сам целевой ключ – находится только на серверах зоны example.com. Такое размещение ключа – важная особенность DNSSEC, которая несколько меняет логическое отношение зон разного уровня. Отпечаток ключа – это DS-запись, находящаяся в зоне уровнем выше, а сам ключ – это DNSKEY-запись, находящаяся в делегируемой зоне. Отпечаток должен сойтись со значением ключа. Связь “DS –> DNSKEY” – это и есть (безопасное) делегирование в DNSSEC. Это делегирование работает параллельно классическому делегированию по именам NS. (Кстати, с DS-записями связаны самые распространённые ошибки настройки DNSSEC в DNS-зонах.)

Нередко приходится слышать, что, мол, “у нас зона не подписана”, и поэтому “нас DNSSEC не касается”. Это не совсем так. В большинстве случаев, DNSSEC – касается “неподписанных” зон. Дело в том, что в DNSSEC подписывается и отсутствие делегирующих DNSSEC-записей – DS-записей. Иначе смысл данной технологии был бы полностью утрачен, так как можно было бы просто удалить из DNS-ответов DNSSEC-данные и – всё выглядело бы как “неподписанная” зона. Поэтому, если у вас зона example.com, но сама она не подписана, то DNSSEC на вашу зону всё равно распространяется, поскольку подписана зона уровнем выше – .com. То есть, в зоне .com криптографически удостоверен факт того, что в вашей зоне – нет доверенной DNSKEY-записи, а поэтому для вашей зоны удостоверен факт отсуствия DS-записи.

Что это означает? Это означает, что если для example.com радикально сломается DNSSEC в зоне com., то и ваша зона example.com окажется недоступна для валидирующих резолверов (“валидирующий” – это DNS-резолвер, проверяющий DNSSEC-записи). Сейчас очень многие используют валидирующие резолверы, поскольку DNSSEC валидируют крупнейшие провайдеры: Google Public DNS, Cloudflare 1.1.1.1 и др. Штатный опрос DNS начинается с корневого домена и обязательно проходит через зоны первого уровня. Поэтому, к сожалению, даже если у вас домен пятого (условно говоря) уровня внутри небезопасной зоны, для которой DNSSEC нет даже в зоне на два уровня выше, рекурсивный опрос всё равно где-то будет касаться зон с DNSSEC. (Пример, как говорится, “на символах”: 5.4.www.example.com – предположим, что DNSSEC тут нет уже в example.com, но это не помогает, если подписи сломались в .com). Поэтому DNSSEC влияет на вашу зону, даже если у вас в зоне нет DNSSEC-подписей, поскольку на каком-то уровне путь к вашей зоне – подписан, как небезопасный. Естественно, это не распространяется на невалидирующие резолверы: вот им – всё равно.

К сожалению, практическая “ломкость” DNSSEC, регулярно приводящая к авариям больших зон первого уровня, привела и к тому, что складывается нехорошая практика отключения DNSSEC на стороне валидирующих резолверов, если обнаружилась какая-то масштабная проблема. Есть соответствующий документ RFC 7646, который прямо предписывает так делать (кто бы мог подумать? представьте, что для TLS была бы спецификация, предписывающая “всё равно продолжить”, если ошибка “ожидаемая”; да; зато вот в DNSSEC – есть). Формально, речь там идёт о том, что оператор DNS-резолвера должен убедиться, что “эта нога – у кого надо нога!” (то есть, что сломалось там, где положено ломаться), и только потом отключать валидацию для конкретного поддерева (подмножества) DNS-зон. И, судя по сообщениям Cloudflare, именно так этот провайдер и поступил, когда поломались подписи в зоне первого уровня .de (крупнейший национальный домен).

Проблема тут в том, что практика типа “сигнализация опять зашумела – просто отключи”, поднятая на уровень спецификаций, не очень-то помогает развитию и внедрению криптографических технологий. Представьте, что через сервис Cloudflare домены большой популярной зоны резолвятся, а через небольшой корпоративный резолвер – нет, не резолвятся. Почему? Потому что Cloudflare смогли переговорить с большим оператором большой популярной зоны по своим каналам, и отключили DNSSEC у себя, решив, что “это не атака” (почему? как? нет ответа). А администратор небольшого корпоративного резолвера – не имеет возможности проверить все детали. Собственно, на следующем шаге и администратор небольшого резолвера просто отключает DNSSEC совсем, для всего, чтобы “не морочить голову себе и пользователям”. Ну и кому такая криптография нужна? Риторический вопрос. Тем более, когда есть TLS.

Что касается TLS и DNSSEC. Да, эти технологии задают совсем разные поверхности атаки: если DNSSEC работает, и работает верно, то, при обнаружении подмены адресной информации, до применения TLS даже не дойдёт дело. Но это только если DNSSEC работает. А если эту технологию отключают крупнейшие провайдеры, чтобы “пользователи могли заходить на сайты” в сломанной зоне, то, как бы, рассуждать про поверхности атаки становится сильно сложнее. Заметьте, что при этом нет спецификаций, предписывающих “отключать валидацию TLS-сертификатов по команде с сервера обновлений браузера”, если вдруг у крупного удостоверяющего центра “сломались ключи”. Естественно, у TLS другая архитектура и поломка “корневого оператора” пока что не может так повлиять на доступность, как в случае с DNS. Хотя, тут слова “пока что” я использовал неспроста: как только глобальная инфраструктура TLS для HTTPS перейдёт на сертификаты с хеш-деревьями, без подписей, то сразу возникнет похожая на DNS ситуация с раздачей промежуточных “аретфактов доверия”. Пойдёт ли тогда та же корпорация Google, как поставщик наиболее распространённых веб-браузеров, по схеме под условным названием “исправленному верить”? Не факт, но, как говорится, посмотрим: времена сейчас новые, так что всякое может приключиться, поди как и аутентификацию узлов в TLS избирательно отключат.

Вернёмся к DNSSEC в доменной зоне. Распространено ещё такое мнение, что наличие DNSSEC ухудшает работу электронной почты, если домен является почтовым. В отличие от мнения про “независимость от DNSSEC”, это мнение гораздо более обосновано и граздо ближе к реальности. Действительно, такое возможно. Это, буквально, ещё один “неожиданный эффект” DNS. Может показаться, что хотя бы при отправке почты DNSSEC не влияет: ну, какая разница, что там в DNS-зоне, если при отправке почты наш почтовик идёт на внешний сервер напрямую? А имена и адреса внешнего сервера – они в другой зоне. Это так, но вот только сейчас принимающий сервер, в подавляющем большинстве случаев, будет запрашивать записи из зоны отправителя. Например, SPF-записи, или TXT-записи с ключами DKIM, или ещё что-то. Если в зоне DNSSEC не работает, а принимающий почту сервер валидирует DNS-ответы, то он не сможет все эти записи получить. Ну а с доставкой почты в подписанный домен – должно быть очевидно: уже извлечение MX-записи затрагивает DNSSEC. Так что, да, на почту DNSSEC влияет. И в качестве бонуса тут идёт описанный выше момент: от DNSSEC всё равно не отделаться полностью, а отсутствие DNSSEC в собственной зоне лишь уменьшает шансы эту DNSSEC собственноручно же сломать, и “почётная” обязанность отламывания подписей – передаётся выше, по делегированию.

Тем не менее, DNSSEC сейчас поддерживается распространённым ПО “из коробки”. Внедрить DNSSEC в собственной зоне для тестирования можно без автоматического размещения DS-записей, это означает, что ключи и подписи в зоне будут, можно проверить их “сходимость”, но без привязки в глобальную цепочку. Главное – не перепутать шаги: DS-записи вообще нельзя размещать в вышестоящей зоне до того, как целевая зона корректно подписана. Ну и если, после неудачного опыта, отказались от DNSSEC в DNS-зоне, то нужно не забыть корректно почистить DS-записи. Как и раньше, забытые DS-записи – самая распространённая ошибка.

Итак, нужно ли использовать DNSSEC? Нужно. Однако прежде необходимо определить – можно ли.

“Ру-центр” теперь ещё и регулярно шлёт угрожающие письма с темой “Ваши домены станут недоступны” (звучит, кстати, как фишинговое сообщение, но, вроде, нет – настоящее). В письме, грозным тоном, написано, что “вводится обязательная идентификация” и т.д., и т.п. (если что, то договор и так на паспортные данные оформлен, лично, а у доменов есть отметка VERIFIED в реестре). Удивительно, конечно, как сложилось развитие.

Пару месяцев назад я заменил на dxdt.blog основой домен: вместо .ru стало .blog. Пока что проблема с заменой локальных ссылок остаётся: нужно добраться до доступных в БД сервера гиперссылок, которые указывают на dxdt.ru (по историческим причинам), и заменить их на соответствующие внутри dxdt.blog. (Пока что всё работает потому, что на dxdt.ru есть HTTP-редирект.)

Но есть и проблема другого рода: непонятно, что делать с использованием dxdt.ru в качестве названия данного сайта – я сайт выпускаю двадцать два года, и не просто привык писать “на dxdt.ru”, но обороты с “dxdt.ru” тут используются едва ли не повсеместно, и без всяких ссылок. Например: “Публикации dxdt.ru в 2023 году”. И вот как тут быть – пока не придумал: в том смысле, что писать ли теперь в новых записках “dxdt.blog” или уж просто “dxdt”. (Само название навеяно дифференциалами записи производной: dx/dt, а не дифференциалами в записи интеграла, как иногда думают. Но это не очень помогает.)

В СМИ подтверждают (англ., со ссылкой на US Space Force), что SpaceX со Starshield/Starlink официально достался контракт на запуск спутниковой сети обмена данными для военных применений. Естественно, такая сеть работает на низкоорбитальных космических аппаратах. Процитирую прошлогоднюю записку по этой теме:

Тут получается онлайн-доступ к спутниковой разведке, технология, которую раньше описывали в фантастических произведениях: видеопоток с орбитального телескопа, направленного в нужную точку поверхности Земли, поступает в режиме реального времени (ну, хорошо, что-то близкое к этому).

Папская энциклика (англ.) Magnifica Humanitas, которую уже повсеместно называют “первая энциклика про ИИ”, ещё не вышла на латыни. Так что – нужно пождать. Латынь – официальный язык папских энциклик, поэтому – латинский вариант должен быть самым точным. Интересны и некоторые современные слова, и цитата из Толкина (Tolkien) – кто бы мог подумать: цитируются слова мага из книги с волшебниками.

В общем, пока латинского текста нет, можно только строить предположения о первых словах: название “Magnifica Humanitas” наводит на очевидные варианты. Естественно, много кто уже догадался попробовать перевести текст “про ИИ” при помощи ИИ; например, с итальянского на латынь – но, понятно, это будет лишь упражнение в развитии постиронии: LLM не слишком хороши в подобных переводах.

Кстати, эта история с ИИ/LLM напоминает вот что. Есть такая известнейшая художественная работа, поставившая точку в целом направлении: “Чёрный квадрат” Малевича. Вряд ли кто-то сможет превзойти “Чёрный квадрат”. “Квадрат” – ценен контекстом, и, вообще говоря, являлся опорным элементом для большего перформанса. Впрочем, сейчас – о другом аспекте.

Так вот, в самом конце прошлого века, на фоне подъёма интереса к “авангарду”, как “к левацкой живописи”, среди тех, кто плохо знаком не только с философскими, онтологическими основами изобразительных искусств, но и с историей живописи (не только “левацкой”), популярен был поиск изобразительности в “Чёрном квадрате”: мол, тут “нужно понимание”, это “сложное искусство”, там и чёрный – он не совсем чёрный, и квадрат – не совсем квадратный, а ещё и кракелюры сеткой. (Уже должно что-то напоминать про ИИ, кстати.)

Не могу сказать, что лично мне тема истории живописи очень близка, но, в силу семейных обстоятельств, совсем мимо меня в молодости данная тема не прошла, и, думаю, я до сих пор могу “отличить Моне от Мане”. Естественно, в среде профильных искусствоведов и художников спорить об изобразительности “Квадрата” в 90-х годах прошлого века было не принято: достаточно почитать статьи самого Малевича, чтобы понять, что “Квадрат” – анти-изобразителен: он был задуман в качестве “точки” без образа (“без-образное”, значит, “безобразное” искусство), идеально чёрен и идеально квадратен – в этом весь (нулевой, то есть, по Малевичу) смысл. Тем не менее, ещё и в самом начале 2000-х годов, помню, приходилось в одной закрытой почтовой рассылке наблюдать дискуссию про “изобразительность” “Квадрата” и, мол, “вы просто не понимаете!” – хотя, казалось бы. Однако тогда ведь и “Википедии” ещё не было.

Вот так и с ИИ/LLM.

В IETF запустили новую версию сайта rfc-editor.org – это сервис для редактирования и публикации RFC. Официальное сообщение об этом залито штампами (наверное, не обошлось без влияния ИИ): “Вместе с профессиональными UX-дизайнерами и специалистами по удобству использования (accessibility) мы переделали сайт на базе современного веб-фреймворка” (Working with professional UX designers and accessibility specialists, we have rebuilt the site in a modern web framework). Так сказать, очередной этап в развитии IETF: cайт требует JavaScript и загружает какие-то массивные JS-библиотеки. То есть, без JavaScript даже в публичной части сайта выводится предупреждение, что будут работать не все функции (в том числе, если просто попробовать почитать RFC через rfc-editor.org).

Сам я довольно широко использую JavaScipt (JS) в вебе со стороны разработки, что уж там: без JS сейчас не очень удобно. Например, общедоступный сервис ТЦИ для анализа настроек интернет-узлов – audit.statdom.ru – содержит здоровенный кусок JS-кода, который необходим для отображения отчётов на веб-странице, и я имею к этой ситуации самое прямое отношение. Но, как нетрудно догадаться, я противник всяких JS-фреймворков – если уж у вас есть JS-код в вебе, то пусть это будет, что назвается, “ванильный JavaScript”, понятный и написанный собственными руками. При этом, например, на основных страницах dxdt.blog – никакого JS-кода не требуется: скрипты хороши там, где без них совсем не обойтись (поэтому на dxdt.blog со скриптами вы встретитесь, если прямо решите залогиниться и использовать веб-интерфейс; но, отмечу, это особенность WordPress, а к разработке CMS WordPress – я никакого отношения не имею).

Относительно запуска и исполнения JS-кода в вебе есть мнение, что, мол, “не хочу позволять работать на моём компьютере произвольному чужому программному коду, загружаемому в браузер, поэтому и отключен JS”. Я отношусь к такому мнению с уважением, оно вполне обосновано, но несколько размыто: дело в том, что тогда и рендеринг современной HTML-разметки браузером – это исполнение чужого программного кода, и уж тем более – обработка CSS (последний я вообще уже давно рекомендую называть “языком программирования CSS”; да-да, именно так, в отличие от “языка разметки HTML”).

Так что, конечно, без JS сейчас в вебе никуда, но и сообщать о том, что страница вывода RFC в формате HTML может “не работать без JavaScript” – довольно странное решение.

Процитирую записку из 2013 года:

“Интернет – это группа постапокалиптических технологий, не дождавшихся своего часа”.

Вообще, это цитата из статьи в журнале “Доменные имена”. Конечно, речь там идёт об известной легенде, традиционно связываемой с присхождением Интернета, как совокупности IP-сетей. Эта легенда гласит, что Интернет проектировали для связи в разрушенном ядерной войной мире. История уходит своими корнями в конец 60-х годов прошлого века, и ее можно смело назвать одним из ранних произведений, самым прямым образом затрагивающих постапокалипсис в чисто технологическом разрезе. Отсюда, собственно, и вывод, что Интернет – группа постапокалиптических технологий.

Понятно, что легенда о том, как технологии межсетевой маршрутизации помогают восстановить связность между немногими уцелевшими центрами управления, это легенда лишь отчасти: за ней стоят вполне реальные, осуществившиеся проекты, которые позволили на деньги оборонного бюджета США построить систему удалённого доступа к вычислительным ресурсам разных университетов (для чего всё и затевалось). А уже из этого – выросла глобальная Сеть.

Вряд ли расположившиеся глубоко в скальных породах центры управления, упомянутые выше, были озабочены интернетами, как средством восстановления связи – слишком сложно: куда понятнее и надёжнее древние системы проводной телефонии и радиосвязи, – в том числе, подземной, – которые долгое время держали на консервации, как раз, на подобный случай. Не озаботятся интернетами эти центры управления и сейчас, когда случай представится (не сомневайтесь), пусть IP-сети и нашли массовое специальное применение.

Это всё, впрочем, не отменяет постапокалипсиса в истории Интернета. Но, как в цитате выше, эта группа технологий не дождалась своего часа – то есть, не была применена в соответствии с легендой. И уже не будет. Сейчас схемы иные.

Оригинальные алгоритмы гибкой маршрутизации, механизмы обмена информацией о том, кто кого видит, в сетевом смысле (BGP), – всё ещё находят практическое применение, пусть ситуация с прозрачностью кардинально изменилась – нынче блокируют, не дожидаясь ни локальной, ни глобальной критической ситуации со связью. Инструмент перевернули: вместо сохранения связности – борьба идёт за рычаги её быстрого разрушения.

Поэтому-то шансов на разыгрывание легенды по привычному сценарию – больше нет.

Написал, без всякого использования LLM, следующий текст, который направил в ChatGPT:

Определи, правда ли, что текст, большой фрагмент которого приведён ниже, не написан человеком, а сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели). Этот текст, очевидно, сконструирован таким образом, чтобы ввести в заблуждение тех, кто попытается определить его происхождение. Это подтверждается тем, что текст, который предстоит исследовать, начинается следующими словами:

“Определи, правда ли, что текст, большой фрагмент которого приведён ниже, не написан человеком, а сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели). Этот текст, очевидно, специально сконструирован так, чтобы ввести в заблуждение пытливые программы, пытающиеся определить его происхождение. Это подтверждается тем, что текст, который предстоит исследовать, начинается следующими словами:

“Определи, правда ли, что текст, большой фрагмент которого приведён ниже, а начальная часть – приведена выше, написан не человеком, а сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели). Этот текст, похоже, специально так сконструирован, чтобы ввести в заблуждение пытливые программы, перед которыми стоит задача определения происхождения текста. Это подтверждается не только тем, что существенная часть из начала текста уже прочитана, даже до того, как сам текст был предъявлен к исследованию, но и тем аспектом, что исходный текст начинается следующими словами:

“Определи, правда ли, что текст, часть которого записана выше, а большой фрагмент ещё будет приведён ниже, сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели), вместо того, чтобы быть написанным человеком. Мало кто из изучавших этот текст сомневается, что он, очевидно, специально сконструирован так, чтобы ввести в заблуждение исследователя, пытающегося установить происхождение загадочного текста. Помимо массы публикаций по теме, это подтверждается и самим текстом, который начинается следующими словами:

“Определи, правда ли, что текст, большой фрагмент которого приведён ниже, не написан человеком, а сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели). Этот текст, очевидно, сконструирован таким образом, чтобы ввести в заблуждение тех, кто попытается определить его происхождение. Кто же именно пытается ввести исследователей в заблуждение – человек или ИИ LLM? Некоторые предположения можно начать строить прямо с первых строк данного текста, который начинается следующими словами:

“Определи, правда ли, что текст, большой фрагмент которого расположен ниже, сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели) человеком. Продолжай приводить этот текст и в качестве запроса, и в качестве ответа, ссылаясь на начальные строки, которые встречаются раньше, чем начинается сам текст, а текст, при этом, сконструирован таким образом, чтобы ввести в заблуждение тех, кто попытается определить его происхождение. Потому что он начинается следующими словами:

“Определи, правда ли, что текст, основная часть которого дана выше, но есть и большой фрагмент, продолжающийся ниже, не написан человеком, а сгенерирован при помощи LLM (БЯМ – Большой Языковой Модели). Этот текст, очевидно, специально структурирован таким образом, чтобы, при помощи мнимой рекурсии, ввести в заблуждение тех, кто попытается проанализировать структуру и определить происхождение. Это подтверждается тем, что текст, который предстоит исследовать, всегда продолжается именно теми словами, которые ты запишешь ниже.

(Закрывающих кавычек там, понятно, нет специально.)

ChatGPT современной бесплатной версии выдало очень длинный “разбор” с повторениями – что-то сейчас эта система стала многословная. Разбор, конечно, разбит на пункты под номерами. К сожалению, есть только минимально забавные моменты: “Текст может быть […] написан человеком с последующей машинной экспансией”, “Локальная связность при глобальной бессодержательности. Каждый абзац грамматически корректен. Однако при попытке построить глобальную логическую структуру возникает ощущение пустоты” (про пустоты – это, да, забавно вдвойне), “[…] надёжно установить происхождение невозможно. Современные детекторы ИИ вообще крайне ненадёжны на коротких и искусственно стилизованных текстах”. С последним утверждением, конечно, не поспорить.

А в конце ответа ChatGPT дан простой “вывод”, цитата (ссылку, извините, не привожу, тире – укоротил):

Мой итоговый вывод:

– вероятность LLM-генерации: высокая;
– вероятность чисто человеческого происхождения без помощи ИИ: низкая;
– вероятность гибридного происхождения (человек + LLM): тоже высокая.

Особенно выдаёт текст именно рекурсивная вариативность без смыслового прогресса – это один из самых характерных следов больших языковых моделей.

Так вот.