Предыстория

Я являюсь владельцем домена bozdaganian.com. Завел его я довольно давно - когда регистрировался у Google в (тогда ещё) бесплатном сервисе Google Apps (сейчас Google Workspace). Завел именно через Google, хотя непосредственным регистратором выступил Enom. Почему не напрямую через регистратора? Всё просто: через Google домен заводить было очень удобно, так как при этом автоматически у регистратора добавлялись все необходимые записи - MX-записи для почты, A-записи для сайта, еще какие-то записи для работы с Google. Я тогда в этом ничего не понимал (нельзя сказать, что теперь я дока, но представление уже какое-никакое имею), поэтому помощь Google была бесценна.

В общем, завел домен - и славно. Спустя какое-то время зарегистрировал поддомены для своих блогов (computers-marginalia и programmers-marginalia) на платформе Blogger все от того же Google, после чего на долгое время забыл и про своего регистратора и про домен. Просто, не находил другого применения. Google исправно раз в год списывал (и продолжает списывать) эквивалент десяти долларов в оплату услуг Enom, так что, делать особо нечего, кроме как пописывать время от времени заметки в своих блогах. И так продолжалось до тех пор, пока я не загорелся идеей обрасти self-hosted сервисами.

Варианты адресации self-hosted сервисов

Когда это произошло, я стал искать информацию о том, как можно все это дело провернуть, в смысле, как мне правильно организовать доступ к своим будущим сервисам - ведь в адресной строке браузера надо будет что-то набирать. Какими они должны быть, адреса моих собственных сервисов?

Из всего, что я нашел и вычитал, больше всего мне понравилась концепция с поддоменами, на которой, я, в конце концов, и остановился. В основе ее лежит мысль, что на каждый сервис следует выделить свой поддомен (subdomain). Домен у меня зарегистрирован, осталось придумать поддомены.

Я решил пойти простым путем, то есть, если у меня есть сервис, на котором размещен мой блог, то логично для него завести поддомен blog, и адрес моего сервиса для блога будет тогда выглядеть так:

blog.bozdaganian.com

Альтернативным подходом является использование для каждого сервиса своего каталога. Если бы я выбрал такое решение, то адрес моего блога должен был бы выглядеть так:

bazdaganian.com/blog

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

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

Адресация при помощи поддоменов

Начнем с того, что надо было эти поддомены как-то описать у регистратора (в этом вопросе, конечно, с каталогами проще - регистратору до них дела нет). Хорошо, что раньше я уже это делал, выполняя подсказки Google для подключения собственного домена к блогам на платформе Blogger. Многое тогда я делал не задумываясь, просто выполняя инструкции, как автомат, но я хорошо запомнил впервые увиденный загадочный термин - CNAME-запись. И это было неплохой точкой отсчета, отталкиваясь от которой я стал самостоятельно разбираться в предмете, читая материалы по всевозможным DNS записям. Надо сказать, что все это оказалось не так уж и страшно, довольно быстро я понял, что мне придется иметь дело с двумя типами записей: A-запись и CNAME-запись. Что же это за звери такие?

A-записи

A-запись одна из самых важных и наиболее часто используемых записей, она задает соответствие между именем и IP адресом. То есть, если у вас есть IP адрес и доменное имя, то вы их можете связать при помощи A-записи. После этой привязки, любой пользователь, набравший в адресной строке браузера ваше доменное имя, будет перенаправлен на нужный IP адрес. Именно так все и работает. Ведь совсем не сложно, правда?

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

Дело в том, что запись-то вы внесли, но внесли вы ее у своего регистратора. И пока она есть только у вашего регистратора, естественно, что ее смогут найти только те устройства, которые имеют на него выход. Но, после внесения, информация о том, что такая запись появилась у такого-то регистратора, начинает мигрировать (реплицироваться) на DNS сервера более высокого уровня. И вот тогда, когда она достигнет вершины иерархического дерева DNS серверов (таких сейчас, вроде, 13), ваше доменное имя станет общедоступным. Видимо, эти 72 часа - не что иное, как максимальное время, за которое информация о новой записи достигает корневого DNS сервера. У меня на практике задержка составляла несколько минут.

Требования к IP-адресу

Исходя из сути A-записи, становится понятно, почему так необходим "белый" IP адрес, то есть, адрес из общедоступного диапазона - без него просто некуда перенаправить запрос по доменному имени. IP адрес, полученный же от, например, DHCP сервера локальной сети (так называемый "серый" адрес), не подойдет - к нему нет доступа извне локальной сети. Будет еще лучше, если "белый" адрес постоянен (статический) - тогда нет нужды в изменении информации в A-записях при изменении адреса. К тому же, есть такое понятие, как кеш DNS сервера, и пока там находится старый адрес, в то время, как вам уже выдали новый, ваш домен будет недоступен со всех устройств, пользующихся услугами этого DNS сервера. Конечно, рано или поздно, все наладится, главное, чтобы адрес вновь не изменился. ^[1]

Возникает логичный вопрос: как можно стать счастливым обладателем нормального "белого" статического IP адреса? Тут все непросто. Мне, например, повезло - "белый" адрес бесплатно предоставляется провайдером, более того, адрес не меняется, пока нет перерыва в оплате абонентки или не производится смена тарифного плана^[2]. Но даже если мой IP адрес изменится, я просто сменю его и у регистратора.

Итак, мне повезло, а ведь кому-то, возможно, придется оплачивать дополнительную услугу провайдера по предоставлению статического "белого" IP адреса (цены могут быть самые разные). Ну и некоторым не везет катастрофически - провайдер просто не выдает "белых" IP адресов своим абонентам. Это, например, относится к Yota^[3]. Но, даже для таких невезучих, похоже, сейчас есть выход, хотя его трудно назвать совсем "независимым": можно попробовать использовать роутер Keenetic c прошивкой не ниже версии 2.07.B2 и сервис KeenDNS. На сайте Keenetic есть примеры и для актуальной версии прошивки, и для предыдущих поддерживаемых версий^[4].

Создание A-записи у регистратора

Ну, вроде, с получением IP адреса всё ясно, разберём теперь, что именно с ним предполагается делать. Как я уже говорил, мой домен создавался при регистрации в Google Apps и "Корпорация Добра" услужливо настроила кое-какие вещи. В частности, у регистратора были созданы A-записи для перенаправления на сервера Google запросов по адресам bozdaganian.com и www.bozdaganian.com. Мне же нужно было направить запросы на свой условно-постоянный IP адрес, выдаваемый провайдером. Боясь что-нибудь поломать, я не стал менять A-записи, настроенные Google, а, подумав, решил: пусть на мой IP должны будут переадресовываться запросы, направленные к домену третьего уровня, скажем xxx.bozdaganian.com. Конечно, на самом деле, вместо xxx я указал другой поддомен, но, для целей демонстрации, вполне подойдет и этот, тем более, что он немного раскрывает суть того, как проходил процесс познания 🤣.

Создать запись для такой переадресации совсем не сложно.

Буквально через несколько минут после того, как я создал A-запись, адрес xxx.bozdaganian.com ^[5] стал откликаться на запросы в браузере. Мои ощущения в тот момент было трудно передать.

CNAME-записи

Но потом встал вопрос: а что делать с другими доменами третьего уровня, которые я хотел направить на свои сервисы? Как их описывать у регистратора? В принципе, для них тоже можно создать A-записи, ссылающиеся на тот же самый адрес. Позже, уже на моей стороне, можно будет разобраться, какой конкретный адрес вбил пользователь в своем браузере для того, чтобы обратиться к одному из моих сервисов, и перенаправить запрос в нужное место. Но меня в таком решении не совсем устраивало одно обстоятельство: адрес, который мне выделяется провайдером, был постоянным лишь условно. И, если память мне не изменяет, была парочка случаев, когда он у меня менялся, причем, не по вине провайдера: один раз я сменил тарифный план, в другой раз - потерял счет дням и не заплатил в срок. Представим на мгновение, что это вдруг произошло вновь, а сервисов не два и не три, а под два десятка. Что, так и менять все эти все A-записи у регистратора? Понятно, что так можно поступить, но это как-то уж очень прямолинейно и совсем... скучно и однообразно.

И вот тут на помощь пришла CNAME-запись. Этот тип записи позволяет задать псевдоним для уже существующего доменного имени. То есть, при ее заведении, надо указывать, с одной стороны, новое (только что придуманное 😉) доменное имя (в моем случае, это домен третьего уровня для нового сервиса), а с другой стороны - уже cуществующее имя домена (вместо явного IP адреса), который заблаговременно ( при помощи A-записи) привязан к нужному IP-шнику (в нашем примере таким доменом выступает xxx.bozdaganian.com). В результате, имеем тот же эффект - другое доменное имя приводит на тот же IP адрес, но, в случае, если я вновь допущу смену выделенного мне IP, править придется лишь одну A-запись. Разве не здорово? Вот так выглядит CNAME-запись у Enom (обратите внимание на то, что после домена первого уровняcom стоит символ . - это отсылка к корню доменной системы):

Сказано - сделано. Я прикинул, какие сервисы было бы неплохо хостить у себя, придумал им домены третьего уровня (поддомены своего зарегистрированного домена второго уровня bozdaganian.com) и зарегистрировал их в Enom. С течением времени, список расширялся, записи все добавлялись, пока я не уперся в ограничение: уж не знаю, то ли это ограничение конкретного регистратора, то ли ограничение, принятое в качестве стандарта, но в какой-то момент при регистрации очередного поддомена мне было выдано сообщение, что больше записей мне создавать нельзя.

Продолжение будет

Вот, пожалуй и все, что хотелось рассказать про идею использования поддоменов в адресах self-hosted сервисов, а также про то, как и при помощи каких DNS записей можно описать такие адреса у ресгистратора. Но это только начало пути, интересного и полного препятствий 😉