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

В продолжение предыдущей записки: можно ли вообще обойтись без доменного имени для веб-сайта? Можно, но это доставит некоторых дополнительных проблем, да и “игра” получается с другими правилами. В принципе, сейчас уже можно автоматом заказывать и выпускать TLS-сертификаты для IP-адресов от хорошо известного (доверенного в “коробочных” браузерах) УЦ – это сертификаты от Let’s Encrypt, на шесть дней валидности.

Наличие TLS-сертификата и выделенного IP-адреса позволяет поднять веб-сервер с доверенным TLS прямо по IP-адресу, без использования доменного имени. Вот, посмотрите, я сделал для примера – должно работать в любом распространённом веб-браузере:

185.39.19.199.

Этот URL – использует https, но указан просто IPv4-адрес, а не имя хоста/доменное имя. Сертификат я за несколько секунд выпустил при помощи утилиты certbot и профиля shortlived, всё при nginx в качестве веб-сервера, вот так:

certbot certonly \
--preferred-profile shortlived \
--ip-address 185.39.19.199 \
--webroot --webroot-path /var/www/html/

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

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

Понятно, что главная-то проблема с таким использованием IP-адресов – это то, что пользователю сложно запомнить обычный адрес. А адресов вида 1.1.1.1 или 8.8.8.8 – очень мало по определению. Кроме того, наверняка будут проблемы с ПО для веба, которое ПО может быть заточено под имена хостов. (Точно будут проблемы с почтовым ПО, но это не веб.)

И всё же, хотя бы возможность простого выпуска TLS-сертификатов для IP-адресов может тут оказаться полезной.

(Но я пока что не планирую переводить dxdt.blog на “чистую” IP-адресацию. Хотя, кто знает.)

Месяц с момента замены доменного имени сайта на dxdt.blog (вместо зоны .ru) – из зоны .ru я перенёс сайт 22 марта 2026 года. За прошедший месяц поисковые сервисы, в основном, обновили ссылки: я сужу по Google, DuckDuckGo и “Яндексу” (в последнем, как ни странно, ситуация со ссылками на dxdt.blog даже лучше, чем я ожидал – я допускал, что там только .ru так и останется, но – нет, поменялось достаточно быстро, это плюс). Старые URL, как я подозреваю, всё ещё попадаются в выдаче, особенно, в DuckDuckGo, поэтому пока что придётся сохранить редирект с dxdt.ru.

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

Есть и очень много внутренних ссылок на самом сайте: исторически так сложилось, что эти ссылки внутренние только по их происхождению – сами URL там полные и “внешние”, содержат dxdt.ru. Я планирую эти ссылки поменять скриптом в БД, но пока что не дошли руки. После того, как поменяю эти URL, буду уже думать насчёт того, отключить ли редирект на старом имени, которое в .ru, если ещё останется смысл – может, проще будет убрать A-записи.

В рамках “ренейминга”, связанного с миграцией сайта с доменов .ru, сделал субординатные имена авторитатвиных серверов DNS для dxdt.blog. “Субординатные” – означает, что имена авторитативных серверов (NS) находятся в той же зоне, которая делегирована на эти серверы: например, ns1.example.com, ns2.example.com для example.com. Такую схему именования ещё иногда называют “красивые NSы”. В случае dxdt.blog, имена NS-ов – в зоне dxdt.blog.

Соответственно, делегирующий ответ с такими именами обязательно содержит так называемые glue-записи – то есть, записи с информацией об IP-адресах NSов. Иначе рекурсивный опрос не будет работать, так как зациклится. Я об этом писал неоднократно, в том числе, про сложную рекурсию, связанную с перекрёстными зависимостями.

Например, сама зона .blog размещена на NS-ах с субординатными именами:

alex@garlic-crusher:~$ dig blog. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
blog.			172800	IN	NS	a.ns.nic.blog.
blog.			172800	IN	NS	d.ns.nic.blog.
blog.			172800	IN	NS	c.ns.nic.blog.
blog.			172800	IN	NS	b.ns.nic.blog.

;; ADDITIONAL SECTION:
[...]

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

alex@garlic-crusher:~$ dig ru. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.

;; ADDITIONAL SECTION:
[...]

Однако, если говорить строго, то окажется, что любое имя в глобальной DNS Интернета так или иначе связано с “субординатными” NS-ами: потому что в делегирующих ответах, в качестве основного состава, могут быть только хостнеймы – имена серверов, и в какой-то момент рекурсивного опроса DNS обязательно возникнет проблема “курицы и яйца”. Более того, в DNS наступление такой проблемы можно откладывать до уровня корневой зоны, но вот IP-адреса серверов корневой зоны – распространяются по рекурсивным резолверам тем или иным способом, отличным от DNS (исторически – это всем известный hints-файл), именно для того, чтобы система заработала при первоначальном запуске.

Эта монета весит, примерно, 12.14 грамма, а её диаметр – чуть более 31 мм: ко Дню Космонавтики – ракета, в виде памятника, Спутник и космическая станция, как они видны на реверсе олимпийского рубля времён СССР.

Отмечу отдельно пять записок из вышедших в марте 2026:

• Цифры и числа в системах счисления
• GNSS и трансляция координат в другую сторону
• Техническое: DNSSEC-ответы об отсутствии записей и RFC
• Уравнение Бомбелли и мнимая единица
• “Арифметика” Диофанта и обозначение неизвестной

Напоминаю, что в марте, вынужденно, поменялся домен сайта – теперь это dxdt.blog.

Неделю назад, 22.03.2026, я настроил в качестве основного адреса сайта dxdt.blog. Пока что под новым адресом сайт продолжает нормально работать. На веб-сервере для dxdt.ru – установлен безусловный HTTP-редирект (301), по HTTPS. Конечно, это несколько непривычно: много лет я традиционно называл сайт “dxdt.ru”, то есть, вместе с TLD; это, к сожалению, “не сработало”, что печально. Более того, dxdt.blog зарегистрирован через того же регистратора, что и вариант в .ru, так что нельзя исключать, что ЕСИА распространят вообще на все услуги и домены. Но посмотрим.

Интересно, кстати, что замена адреса тут же привела к набегу разнообразных ботов. Домен dxdt.blog я зарегистрировал несколько лет назад, но не делегировал его. Видимо, контроллеры ботов отслеживают не только новые HTTP-редиректы, но и вновь делегированные имена – этим объясняется увеличение потока прямых HTTP-запросов.

Так как основной домен сайта поменялся (было dxdt.ru – стало dxdt.blog), то, очевидно, браузерная идентификация (регистрация, пароли, cookie и пр.), как и кеширование, связанные с dxdt.ru, на dxdt.blog автоматом не переносятся (это браузерная политика, тут ничего не поделать: сервер один, IP-адрес такой же, но вот домены – разные). Авторизацию я на стороне сервера поправил, поэтому, если снова залогиниться, всё должно работать. Капча тоже должна работать как и раньше.

RSS – тут поменялась ссылка, стало – https://dxdt.blog/feed/, но так как по старому адресу сервер отвечает c HTTP-редиректом, то должно просто прозрачно продолжать работать в RSS-клиентах. Если вдруг нет, то нужно заменить ссылку вручную, к сожалению.

Ссылки на разные файлы (картинки и т.д.) – пока что, за редким исключением, остались с доменом dxdt.ru. Я планирую их поправить позже. Опять же, должно продолжать работать прозрачно, потому что редирект. Конечно, редирект – это дополнительные запросы, но, в принципе, на скорость доступа к dxdt.blog это не должно сильно повлиять (но может быть заметно).

Обратную зону, адресацию почтового сервера сайта (который только на отправку уведомлений тут работает), я пока не трогал.

Сделал основным адресом сайта dxdt.blog (вместо dxdt.RU). Обновите ссылки. Пока что под старым именем настроил HTTP-редиректы, потому что очень много ссылок внутри, которые указывают на адреса в dxdt.ru. Но должно работать. Если что-то не работает – пишите в комментарии или почтой. Постепенно, думаю, поправлю и старые ссылки.

(Я не знаю, как будет развиваться ситуация с доменными именами и их регистрацией, но пока что так – решил перенести не в .pw, а в .blog. Посмотрим.)

На сайте “Ру-центра” появилось сообщение про ввод требования аккаунта ЕСИА. Сейчас написано, что только для имён .ru/.su/.рф, но, вообще говоря, непонятно, можно ли на это рассчитывать – скорее, рассчитывать нужно на то, что будет и для всех прочих TLD добавлено, у российских регистраторов. Дело в том, что для того, чтобы ввести что-то подобное на стороне регистратора, вовсе не обязательно, чтобы регистратуры и реестры других зон верхнего уровня требовали какой-то дополнительной привязки для аккредитации (как в .ru/.su/.рф).

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

Не сказать, чтобы вот прямо внезапно это ввели. Про ЕСИА и регистрацию доменов в .ru я писал ещё в 2024 году, когда думал, куда перенести dxdt.ru. Собирался переносить, но пока так и не перенёс. Возможно, проще закрыть. С другой стороны, вся эта ситуация очередной раз показывает, что домен – это чисто “виртуальная география”, контролировать которую администратор реально не может – администратор только получает некоторую иллюзорную возможность управления. Пусть это управление и продолжалось успешно больше четверти века (у меня есть имена .ru, которые старше dxdt.ru), его легко перечеркнуть.

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

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

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

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