Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Наступил сентябрь 2026 года. Небольшое обновление статуса по доменам. Часть имён .ru, .su, в том числе, dxdt.ru, я перенес к другому регистратору и, – так как меня убедили, что жаль просто бросить старые имена, – передал другому администратору. Тем более, что там оказались не только имена, ценные в исторической перспективе, но и достаточно важная электронная почта.
Другую часть .ru, .su (там пара-тройка имён всего) – я не переносил, и не намерен продлевать, поэтому, вероятно, они все будут удалены (не страшно). Пишу “вероятно” потому, что уверенности нет: правила резко поменялись и в них очень много “неожиданных поворотов”, это кроме ЕСИА (однако, не хочу эти моменты обсуждать – всё это слишком печально).
Удивительно, но перенести домены между регистраторами и сменить администратора удалось буквально в последние дни августа, благодаря наличию в реестре схемы передачи с кодом подтверждения. Перенос и смена администратора проходили не без шероховатостей, но завершилось всё, вроде, успешно. К счастью, “Мастерхост”, как принимающий регистратор, не только сохранил техподдержку, но ещё и сработал, в итоге, правильно (спасибо!). Я надеюсь, что на dxdt.ru пока что сохранится HTTP-редирект, ведущий на dxdt.blog, а dxdt.blog у меня не отберут (тут я изучаю вопрос смены регистратора для .blog тоже). Но это планы. В общем, посмотрим.
Comments Off on Про (мои) домены .RU/.SU
Вроде, удалось продлить адрес dxdt.blog ещё на один год: учитывая все “странности” – успешность продления вовсе не была очевидной. Вообще, “забавно” было бы потерять ещё и dxdt.blog, куда сайт переехал.
Комментарии (5) »
Как я понимаю, большинство читателей этого блога (dxdt.blog) читают его через RSS-поток. На веб-сраницах трафик тоже есть, – и он заметно больше, – но там, реально, основная часть – это запросы разных ботов, в том числе, LLM-систем. Узел под старым адресом блога, который был в домене .RU, сейчас возвращает универсальный редирект (HTTP 301) на dxdt.blog. Это распространяется и на запросы к RSS-ленте.
И вот смотрю я в логи этого “редиректора” (то есть, на старом адресе dxdt.ru), а там всё ещё немало так GET-запросов именно на RSS-поток. Причём, если верить данным RSS-агрегаторов, которые приходят на старый адрес за RSS, там у них сотни подписчиков. Я вижу, что, после редиректа, эти же RSS-агрегаторы приходят и на dxdt.blog. С одной стороны, неплохо, что они следуют редиректу. Однако, с другой стороны, то, что эти сервисы всё ещё ходят через “редиректор”, означает, что его адрес не был вытеснен новым, а это уже плохо, потому что, как только dxdt.ru будет удалён из DNS, этот трафик, скорее всего, потеряется, а ленты в агрегаторах отломятся.
Да, я вполне понимаю логику массовых сервисов “RSS-читалок”, которую они тут применяют. Естественно, желание сохранять старый адрес, даже если там HTTP 301, вполне разумное: мало ли, что там случилось на целевом веб-узле – администратор мог сделать 301 ненамеренно, по ошибке. То есть, это здравое поведение. Идеальным было бы запоминать новый адрес, полученный через HTTP 301, но переходить на него (исключительно) только после того, как предыдущий адрес совсем исчез. Но не факт, что так сделано. Понятно, что пользователи могут переподписаться с новым адресом – но тут нужно действие от пользователя: лент у пользователя много, ожидать, что он тщательно следит за адресом каждой ленты – слишком самонадеянно.
В общем, это я вот к чему написал: сообщение на dxdt.blog – один из двух доступных мне способов проинформировать читателей о замене адреса. Поэтому напоминаю – я перенёс сайт, теперь вместо dxdt.RU стало dxdt.BLOG, если вы читаете через RSS (а это тоже правильно), то вот новый URL RSS-потока: https://dxdt.blog/feed/
Пока есть возможность, я постараюсь старый адрес сохранять с редиректом. Через какое-то время (когда дойдут руки исправить ссылки внутри сайта) я планирую на dxdt.ru выложить по URL RSS-потока отдельную запись, информирующую о том, что поток переехал на другой адрес. Опять же, это всё – если будет возможность: с доменами .RU происходит какая-то неразбериха, что там ожидать – понять я уже не могу.
Ещё раз новый адрес RSS-потока: https://dxdt.blog/feed/
Спасибо, что читаете.
Comments Off on RSS и старый адрес .RU
Небольшое сообщение: если у вас вдруг сохранились мои весьма старые адреса e-mail, которые на .RU, то лучше их не использовать для отправки почты мне, а использовать те, что не в .RU (см. например, на сайте в блоке информации справа). Опубликованный PGP.ASC, если это кому-то важно, я поправил, удалил оттуда .RU (ключ тот же; кстати, мне, вообще, PGP/gpg не очень-то нравится, но ключ я держу опубликованным, по историческим причинам – им редко кто пользуется, и он только для почты).
Некоторые домены .RU (в том числе, которые с почтой) я, конечно, попробую сохранить как-то, но далеко не факт, что это получится. (Вообще, кстати, в этом контексте особенно показательно выглядит то, что поддержка “Ру-центра” не отвечает. Поэтому домен, который в “Ру-центре”, он сейчас наиболее “рисковый”.)
Комментарии (2) »
Обновил на основном сервере dxdt.blog операционную систему до Debian 12. Обновление, понятно, принесло с собой некоторые минимальные несовместимости (например, в какой-то момент отломился PHP – надеюсь, никто не заметил), но, вроде, сейчас всё работает нормально. Если нет – пишите почтой.
Вчера сайт был несколько часов недоступен, но по другой причине, которая напрямую не связана с обновлением ОС. Вчера проблема возникла с созданием “снапшота” виртуальной машины.
Вообще, я не сторонник “снапшотов”. Я всегда говорю, что “снапшот” – это последнее, на что можно рассчитывать при каких-то сложных работах (восстановление должно происходить не “откатом”, а “перекатом”, говорю я, – но это тема для другой записки; тем более, что я же, – иногда, – шучу в адрес специалистов DevOps, что, мол, “бэкапы – это для трусов”).
Так вот, то, что “снапшот” это последнее, чем следует пользоваться, никак не отменяет того, что сделать “снапшот” не помешает. И есть хорошая практика: перед взятием “снапшота” – остановить саму виртуальную машину. Так я и поступил. Остановил виртуальную машину с веб-сервером dxdt.blog. К сожалению, мне даже не пришла в голову (нездравая) мысль, что “снапшот” всего на несколько десятков гигабайт у хостера может создаваться несколько часов – я к такому не привык, у меня машины “снапшотятся” сильно быстрее. В общем, пока копировался “снапшот” – сервер был недоступен. Но, думаю, это всё не так страшно. Сейчас всё вернул в рабочее состояние.
Комментарии (1) »
В июле 2026 года записок вышло не так много, но всё же набралось пять, которые можно отметить отдельно:
Комментировать »
Записка, вышедшая на dxdt (тогда ещё – .ru) почти что ровно пятнадцать лет назад – о том, как важен спутный след и его маскировка: то есть, возмущения в среде, через которую движется некий аппарат, выдают присутствие этого аппарата, и в записке упомянута публикация с описанием того, как специальной конструкцией можно добиться “минимизации” спутного следа. Цитата:
Вот пишут в Physicsworld.com о работе, в которой физики показывают, как с помощью специальной конструкции корпуса судна (там речь о передвижении по поверхности воды) и использования материалов с особыми свойствами можно полностью избавиться от спутного следа, возникающего в результате возмущения среды. Причём, в перспективе, технология работает не только на воде (под водой), но и в воздухе. Основная идея та же, что и в прочих схемах с “невидимостью”: “обтекание” объекта волнами происходит таким образом, что из точек, находящихся на некотором удалении от движущегося объекта, всё выглядит так, как будто никакого объекта и нет.
Занятно, что на Physicsworld.com уже по той ссылке никакой работы нет – там HTTP 404. Но сам сайт при этом продолжает действовать. А публикация сохранилась на Archive.org.
Комментарии (2) »
В продолжение прошлой записки про короткоживущие TLS-сертификаты на dxdt.blog: там было написано, что я перестал отзывать сертификаты для dxdt.blog – так вот, подумав ещё, я всё же добавил отзыв предыдущего сертификата, если успешно выпустился новый. Потому что пока что способ отозвать есть – почему бы его не использовать? Тем более, что это вполне себе обычная ситуация: новый сертификат заменяет старый, для этого даже есть код причины отзыва – Superseded (но см., однако, ниже). Другое дело, что в этих сертификатах для dxdt.blog сейчас одинаковый серверный ключ – это, как бы, переводит основной смысл отзыва в плоскость чистого эксперимента. Но тем не менее.
Let’s Encrypt сейчас предоставляет только один интерфейс для проверки статуса сертификата – списки отозванных сертификатов (CRL-файлы, адреса точек раздачи которых указаны в самом сертификате). От OCSP-респондера давно отказались (и совершенно правильно сделали: OCSP – так себе технология). Собственно, для “сверхкоротких” TLS-сертификатов сейчас вообще допускается отсутствие информации о статусе, то есть, можно и CRL не публиковать. Let’s Encrypt пока что публикуют.
Кстати, немного про устройство раздачи CRL у Let’s Encrypt. Список отозванных сертификатов (или просто “список отзыва”) – это, буквально, удостоверенный подписью список серийных номеров сертификатов, выпущенных данным Удовтоверяющим Центром (УЦ), которые отозваны (иногда – с указанием причины отзыва). Так как сертификатов Let’s Encrypt выпускает много (“много” – это мягко сказано), то можно ожидать, что и списки отозванных сертификатов будут быстро “пухнуть”.
На практике это не всегда так – сертификатов отзывается мало, потому что, вообще говоря, отзыв сертификата – не считается штатным событием. (Но, тем не менее, я таки стал отзывать каждый короткоживущий сертификат, до истечения его срока действия – но то больше в качестве эксперимента.) Всё же, чтобы, видимо, как-то подготовиться к потенциальному “распуханию” списков отзыва, Let’s Encrypt использует некий “шардинг” – CRL для одного УЦ нарезаны на несколько файлов (судя по всему, на 128): например, есть точка раздачи по адресу http://ye1.c.lencr.org/108.crl, а есть и http://ye1.c.lencr.org/18.crl, и 10.crl и т.д., думаю, схема именования ясна. Это всё CRL от УЦ YE1 (как видно и по имени хоста). Конкретный адрес, с разным “фрагментом” CRL, пишется в конкретный оконечный сертификат. Например, сейчас в сертификате на dxdt.blog указана точка http://ye2.c.lencr.org/103.crl.
Отзывать сертификат можно при помощи ACME – там есть специальный интерфейс. ACME вообще предлагает несколько способов отзыва. Понятно, что для отзыва – нужно как-то минимально подтвердить связь отзывающего аккаунта либо с сертификатом, либо с именем в сертификате. Иначе можно будет отзывать чужие сертификаты.
В ACME предусмотрено три основных способа такого “связывания”:
1) через ACME-аккаунт – то есть, запросить отзыв может тот же аккаунт, под которым отзываемый сертификат был получен от УЦ;
2) через секретный ключ от открытого, указанного в сертификате – то есть, любой аккаунт может отозвать сертификат, если запрос подписан секретным ключом от сертификата (это понятный и самый строгий механизм: если секретный ключ от сертификата скомпрометирован, то единственное, где подписи от этого ключа ещё можно доверять, это запрос на отзыв соответствующего сертификата);
3) через подтверждение права управления именем (DCV) – если ACME-аккаунт подтвердил, что управляет именем, указанным в сертификате, то этот аккаунт может отозвать любой сертификат, выпущенный УЦ для подтверждённого имени; тоже логичное решение – сторона, фактически управляющая доменом (или IP-адресом), должна иметь возможность отозвать “прошлые” или “старые” сертификаты.
Заметьте, кстати, что третий метод позволяет отозвать любой сертификат, где единственное подтверждённое имя указано в списке имён (то есть, можно отозвать сертификаты, в которых есть ещё какие-то другие имена/адреса в SAN).
Я сейчас отзываю “замещённые” сертификаты dxdt.blog просто тем же ACME-аккаунтом.
Комментировать »
Вот уже месяц сайт dxdt.blog работает на “короткоживущих” TLS-сертификатах Let’s Encrypt. Эти сертификаты валидны, примерно, шесть с половиной дней (160 часов). Соответственно, новые сертификаты заказывает автомат через API ACME (утилита certbot, в данном случае), с периодичностью один раз в двое суток.
Если новый сертификат удалось получить, то он устанавливается на веб-сервер (другим простым скриптом), если не удалось, то остаётся старый сертификат. Об изменении статуса, о попытках заказа сертификата – робот отправляет мне письмо. Заметьте, кстати, что в ACME нет такого понятия, как “продление сертификата” – нужно просто заказывать новый сертификат, вместо старого. Я несколько раз подобные “старые” сертификаты, после получения нового, даже отзывал (есть специальный статус для причины отзыва: Superseded), но сейчас решил оставлять без отзыва.
То есть, в принципе, всё сделано типовым способом и пока что работает нормально. Продолжаем наблюдать.
Комментарии (3) »
Новый 