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

Кстати, на d-russia.ru – сообщение про новые правила (проект) регистрации доменных имён .RU, .SU, .РФ. Если прочитать сами правила, то там, как и ожидалось, буквально везде требуется идентификация через ЕСИА, даже для делегирования имени, не то что при регистрации, продлении регистрации или при передаче права управления.

Когда-то, благодаря старому регистратору RU-CENTER, издавался такой замечательный, уникальный журнал – “Доменные имена”. Журнал выходил в печатном варианте, оформляли и верстали его, ни много ни мало, а в Ателье “Афиши”. У журнала был собственный заказной шрифт, особая бумага и удивительный дизайн каждого номера. А я некоторое время был главным редактором, так что хорошо помню процесс. Нынче даже и сайт журнала уничтожен (до сих пор не могу понять – почему).

Но сейчас не об этом.

Вот в 2012 году мы с Артемием Ломовым написали для этого журнала (ДИ, 2012/1(6)) занятную статью – “Сценарии конца Интернета”. Я на эту статью несколько раз уже ссылался на dxdt.ru. Интересно, что некоторые моменты из статьи стали сбываться, – частично, конечно, – прямо на следующий год после публикации. Например, сценарий про “Красную кнопку”. В статье упомянуты и “белые списки”, правда – в контексте “борьбы за копирайт”. В общем, дальше – пошло и поехало.

Там, в той статье, есть и про повреждение магистральных линий связи. Даже конкретно – подводных кабелей (не трудно было угадать, впрочем). Есть и про утрату инженерного подхода – тоже идёт процесс в этом направлении: посмотрите вокруг. В общем, много что охвачено. Но не нужно думать, что развал интернетов начался с той статьи. Вовсе нет. Я полагаю, что всё началось с желания писать слово “Интернет” со строчной буквы. Постоянно про это говорю. Не надо было так делать.

А вот чего нет в той статье, так это про сценарий с разгулом псевдо-ИИ на LLM, который мы сейчас наблюдаем. Разгул – с последующим уничтожением, как минимум, веба, путём затопления бредом, сгенерированным роботами для роботов. Ну, как – нет. Чтобы вот сказать, что прямо в точку – такого нет. А если вообще, про генераторы текста и затопление, то такое есть. Но немного в другом контексте. Цитата:

“А возможно, никакой технологической сингулярности не случится: как мы разобрались, есть угроза утраты человечеством инженерных навыков, поэтому разумные машины строить будет некому. В таком случае люди могут просто заскучать от «всех этих ваших интернетов», потерять интерес к компьютерам — и в результате мягкого глобального помешательства Сеть больше не нужна никому, сайты заброшены и не обновляются, замерз на ленте последний твит никому не известного жителя Техаса. Некоторое время разнообразные спам-боты и генераторы контента еще продолжат наполнять базы данных бессвязным текстовым бредом, предназначенным для чтения роботами поисковых машин, но потом потухнет и эта активность.

Опустевший Интернет завершил существование.”

Одно печально – когда мы эту статью писали, 14 лет назад, то сложно было представить, что реализовываться будет не один какой-то сценарий, а сразу все, параллельно. Видимо, чтобы наверняка.

Как я уже выше отметил – сайт журнала, который находился в домене nic.ru, уничтожен, и довольно давно. Поэтому даже и ссылку дать не получится: бумажные номера остались, но они – без гипертекста.

Кстати, прошлый заход “борьбы с Telegram”, который был весной 2018 года, привёл к тому, что сайт dxdt.ru был довольно длительное время недоступен из сетей российских провайдеров (Telegram, конечно, продолжал работать).

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

Переносить тогда сайт и заменять основные IP-адреса – я не стал, но зато пришлось добавить IP-адресов для того, чтобы был какой-то доступ по HTTPS: это кратко описано в записке из тех времён.

Воскресное чтение манускриптов. Продолжаем читать фрагменты “Арифметики” Диофанта, в изложении манускрипта 13 века Vat.gr.191 из Ватиканской Апостольской библиотеки (пока ещё до сайта библиотеки есть доступ). Манускрипт на древнегреческом. В прошлый раз изучали, как обозначаются степени (неизвестной) при помощи букв Δ и Κ на том же манускрипте. В этот раз – предложение про “отрицательность” и “положительность”. Как говорится, “минус на минус даёт плюс”. Как ни странно, но буквально это и написано в данном манускрипте, на следующей странице после определения записи степеней. А именно – см. скриншот ниже (я выделил соответствующий фрагмент).

Здесь сразу пара занятных моментов.

Во-первых, Диофант не использует концепцию отрицательных и положительных чисел в полном смысле, как это описывали бы сейчас, то есть, при помощи понятия обратных по сложению чисел, сумма которых равна нулю. Зато у Диофанта есть понятие “дефицит” (“нехватка” – там в женском роде, но это неважно), которое обозначается словом λεῖψις, и обратное к “дефициту” понятие – “достояние”, которое обозначается словом ὕπαρξις (здесь, видимо, в общем значении – “существование”, но в смысле – “имущество”, а именно, “то, что есть”).

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

Во-вторых, здесь же вводится обозначение для “дефицита” – в виде некоторого символа, типа “шалаша” из трёх чёрточек, который сейчас принято обозначать “𐅢” – если на вашем устройстве не отображается, то это такая вот усечённая “индейская национальная изба”, как в известном советском мультфильме. Однако в тексте с манускрипта эти три чёрточки интерпретируются несколько иначе. То есть, сам фрагмент с манускрипта (конец третьей подсвеченной строки, в современной типографике, без знаков препинания): “καὶ τῆς λείψεως σημεῖον Ψ ἐλλιπὲς κάτω νεῦον 𐅢”. Это переводится так: “и дефицита обозначение – Ψ, урезанное, вниз обращённое: 𐅢”. Однако данный фрагмент выглядит странным: зачем переворачивать и усекать пси? Так что данный кусочек мог быть дописан к исходному тексту в качестве пояснения, кем-то из сотрудников скриптория, а в исходнике Диофанта его не было.

Тут не нужно забывать, что манускрипт-то – 13 века, но исходный текст старше на тысячу лет, или около того, поскольку период деятельности Диофанта Александрийского – это третий век. Дописать пояснение могли раньше, не в 13 веке. Но всё равно, на момент дополнения текста, исходнику могло быть несколько веков. Смысл пояснения про “пси-переворот” в том, что странный знак нужно было описать текстом, для тех, кто будет переписывать манускрипт позднее. Забавно, но, буквально, та же история, как и в предыдущем абзаце, где я попытался описать символ словами про индейскую избу, на тот случай, если символ не отображается на вашем устройстве.

При этом сам Диофант, предположим, использовал просто некий вариант Λ с дополнительной “ногой”, потому что Λ (лямбда) – это первая буква слова λεῖψις, но чистую лямбду сложно отличить от обозначения числа 30 (см. например, T. L. Heath. Diophantus of Alexandria. Cambridge, 1910). Довольно интересная трактовка.

И, кстати, странные закорючки в начале первой и второй строки фрагмента на скриншоте выше, это скорописное сокращение слова ἐπί, кто бы мог подумать: см. скриншот ниже.

Слово встречается много раз, в том числе, на скриншоте, а сокращение – содержит все диакритические знаки из современной типографики, если приглядеться.

Кстати, вот ещё из очевидного “творчества” ИИ/LLM – попалось на “Хабре” (где, похоже, результатов генерации LLM, – “ИИ-помоев”, – только становится больше), дословная цитата:

“TXT-запись — это произвольная строка текста привязанная к домену. Придумали её для SPF (верификация почтовых серверов) и DKIM, потом стали использовать для подтверждения владения доменом в Google Search Console и Let’s Encrypt.”

На минуточку: TXT-записи – описаны в RFC 1035, это 1987 год, однако сама концепция размещения TXT-записей – ещё старше. Никакого SPF, – а тем более, DKIM, – тогда ещё не было, и никто не придумывал TXT-записи для SPF и DKIM.

SPF (эта технология оформилась в начале 2000-х годов, TXT-записи уже были) – вообще первоначально использовала отдельный специальный тип DNS-записи (SPF-запись), который сейчас отнесён к устаревшим, а данные SPF, действительно, сейчас размещаются в TXT-записях, но из этого не следует, что TXT-записи “придумывали для SPF”. DKIM – та же история, только ещё более свежая, из 2007-2011 (исходный документ RFC 4870 – это 2007 год, но данный RFC сейчас имеет статус “исторического” и не применяется).

Ну и забавно выглядит утверждение, что “потом стали использовать для подтверждения владения доменом” – то есть, вообще не верно: подтверждение с помощью TXT-записи применялось раньше и независимо от SPF/DKIM.

Понятно, что LLM это всё неведомо, так как LLM просто генерирует текст, а проверить его на соответствие реальности – просто некому. Дальше это всё попадает через “Хабр” в “поисковые системы”, которые, так как “Хабр” считается авторитетным, опять загоняют это всё в LLM и показывают пользователям, уже “со ссылками”. Поэтому-то результат и печалит.

В 2023 году я писал на dxdt.ru об одном из эффективных, для DNSSEC, способов динамического удостоверения факта отсутствия DNS-записи (или DNS-имени), который, в частности, применяют в Cloudflare. В конце 2025 года этот способ, с некоторыми добавлениями и обновлениями, получил спецификацию RFC 9824.

В частности, RFC 9824 вводит “мнимую” DNS-запись NXNAME (TYPE128) – это запись-сигнал об отсутствии в DNS-зоне запрошенного имени. Причина для введения такого сигнала в том, что упомянутый способ в принципе не позволяет отвечать со штатным для DNS статусом NXDOMAIN. Почему? Потому что весь смысл состоит в “подделывании” состава ответа, но, так сказать, с благими целями: при получении запроса о несуществующем имени, авторитативный сервер отвечает так, как если бы для этого имени нет DNS-записей в зоне: ANSWER: 0 и флаг NOERROR. В терминах DNS такой ответ называется NODATA – то есть, это корректный DNS-ответ без статуса ошибки, но пустой – не содержащий никаких ответных, – в блоке ANSWER, грубо говоря, – записей (естественно, это не означает, что DNS-ответ в целом не содержит записей: пуст только блок ANSWER, но записи в ответе есть, это дополнительные, “авторитативные” записи – SOA, NSEC и т.д.).

Однако, логически, NODATA – это не NXDOMAIN. Статус NXDOMAIN специально предназначен для указания на отсутствие самого имени. Действительно, если нет имени, то для него не может быть и никаких DNS-записей. Понятно, что и NODATA укладывается в схему, но с той лишь точностью, что NODATA – это отсутствие записи конкретного типа, пусть для несуществующего имени и нельзя разместить никакую запись, никакого типа. То есть, NXDOMAIN – мощнее, поскольку указывает на отстутствие самого имени. (Это всё может показаться сложным. Если так, то это не кажется: DNS вообще весьма и весьма непростая система. Зато, заметьте, что здесь очередной раз обыгрываются различные трактовки понятия “пустое множество”.)

Для того, чтобы в новой схеме отличить ситуацию, когда действительно нет записей, от ситуации, когда нет имени, как раз и служит новая запись-сигнал NXNAME. Авторитативный сервер указывает NXNAME в составе полей NSEC-записи, если нет DNS-имени. NSEC – это запись, обозначающая “границу” зоны (в данном случае – фиктивную границу), NSEC нужна для того, чтобы было что подписывать, так как нельзя подписывать пустое значение. Технически, подписать-то можно, но такую подпись легко скопировать и применять к отсутствию любых записей в DNSSEC, то есть в безопасной DNS-зоне: это как раз пример того, что все пустые множества одинаковые, а окрашивать можно только пустые коробки, вот как в случае с NXNAME/NODATA и NXDOMAIN.

Здесь играет роль ещё одна нетривиальная особенность DNS, которую мало кто понимает. А именно: в DNS распространены ситуации, когда возникают заведомо пустые, но поименованные, фрагменты имени. Предположим, что есть имя a.b.c.example.com, для которого указана A-запись. Это имя находится в зоне example.com, но A-запись указана только для a.b.c. Как трактовать имя b.c.example.com (без a.)? Оно, вроде как, есть, потому что в DNS полное имя строится в форме иерархии лейблов, разделяемых точками. Но, не менее “вроде как”, этого имени и “нет”, потому что для него в принципе не указаны никакие записи: из “полных” имён тут будет только example.com и a.b.c.example.com. Для корректной обработки такого случая, в схеме, где NXDOMAIN-ответ невозможен, нужен сигнал, позволяющий отличить несуществование имени от несуществования записи для этого имени. Это и есть NXNAME.

Конечно, занимательно. Но, другое дело, что, с одной стороны, новый подход позволяет быстро, в онлайн-режиме генерировать подписанные DNS-ответы, удостоверяющие отсутствие запрошенной записи или отсутствие имени. С другой стороны, логика DNS очередной раз усложняется, а клиент, резолвер – должен подерживать обработку NXNAME, иначе для него разные пустые коробки склеиваются в одну (отсутствие записи склеивается с отсутствием имени).

На Hackaday – попытка построить радар с ФАР (AERIS-10) на базе открытой архитектуры и из доступных комплектующих. Сантиметровый диапазон: частота 10.5GHz. Низкоуровневую “радарную” работу реализуют на FPGA и готовых формирователях луча, общее управление – на микроконтроллерах STM32. Предусмотрено механическое сканирование по азимуту и привязка к GPS-координатам.

Надпись под картинкой X-76 SPRINT на сайте DARPA: “Artist’s concept for the SPRINT X-76, a proof-of-concept technology demonstrator that aims to demonstrate technologies and concepts needed for runway-independent, high-speed flight”. Вчитайтесь в повторы слов: концепция (concept) концепции о технологическом демонстраторе, нацеленном на демонстрацию технологий и концепций… и так далее. Видимо, чтобы слов хватило на нужную длину строки. Как говорится, ИИ-LLM, несомненно, идёт на смену копирайтерам, в том числе, и силами самих копирайтеров.

(Речь в пресс-релизе о некоторой “концепции о концепции” некоторого реактивного конвертоплана с “гибридными” движителями: такой продвинутый вариант V-22 Osprey, как бы из компьютерной игры, только ещё сложнее, потому что не только поворачиваются мотогондолы и меняется конфигурация крыла, но ещё и лопасти складываются в полёте. С крейсерской скоростью в 400 узлов и не требует оборудованной полосы для разбега. Впечатляет. Если верить картинкам, конечно. Всё с планами на 2028 год и далее. То есть, пока что ничего интересного, но выглядит так, как если бы без LLM не обошлось.)

Ещё в копилку реального использования LLM, но, в данном случае, “картиночных”.

Это ChatGPT современной версии (которая доступна через веб-интерфейс на бесплатном аккаунте, видимо, какая-то 5.x). Попробовал старинный запрос – нарисовать настенные часы. Но в этот раз – с 11-часовым циферблатом (такие картинки полезны, когда нужно объяснить арифметику остатков, например, сравнивая составное 12 и простое 11). Пишем достаточно подробный, на мой взгляд, промпт на русском (специально):

“Нарисуй настенные часы с 11-часовым циферблатом, которые показывают без двадцати десять”.

Казалось бы, прошло уже несколько лет “улучшений” и хайп только набирает обороты, но, к сожалению, результат, как обычно, не слишком-то полезный – см. ниже.

(Здесь двенадцать часовых отметок, но две обозначены символом “11”, да и стрелки показывают не 9:40.)

Типовая спутниковая навигационная система (GNSS, типовой пример – GPS) работает в модели, когда приёмник “смотрит” на спутники, а спутники – приёмник не видят: спутники лишь излучают сигнал с метками. Приёмник, на основании полученных данных о местоположении спутников, определяет собственное положение в пространстве (относительно спутниковой системы координат, естественно).

Такой подход выглядит пассивным, в том смысле, что приёмник только принимает сигнал, но никак не участвует в формировании навигационного поля: не передаёт запросов, не отвечает подтверждениями. То есть, в теории, если считать, что GPS-приёмник полностью пассивный (это не всегда так с приёмниками радиосигналов), то схема получается достаточно скрытной: собственные координаты поступают, но не уходят – нельзя узнать положение приёмника (через навигационную систему). Но координаты нужно вычислять, и делать это нужно относительно того, как “видны” спутники с точки зрения приёмника (его антенны/антенн, если говорить совсем строго). Это сопряжено с проблемами спуфинга и помехопостановки: приёмник может принимать дефектный/поддельный сигнал, не принимать ничего вовсе, кроме помех, а сама внешняя система – не знает про такую ситуацию конкретного приёмника, поэтому никак не может содействовать в улучшении его сигнального положения (например, в сетях мобильной связи с условным обозначением 5G, это не так – зная положение приёмника и его “электромагнитную ситуацию”, можно резервировать лучи для этого прёмника).

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

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

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

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

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

Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.

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