Поддомены для серверов: отдельное имя для каждого сервера и приложения

Поддомен - это одна запись в зоне, которой вы уже владеете. Он ничего не стоит, создаётся за пять минут и даёт возможность менять адрес под ним, никого не предупреждая. Это весь аргумент, и он предъявляет счёт при первом же переезде сервера, а такой переезд всегда случается раньше, чем вы планировали.

Раздавать 203.0.113.10:25571 можно ровно до того момента, пока адрес не изменится. Потом он оказывается в сорока закреплённых сообщениях Discord, в трёх записях списков серверов, на странице вики, которую уже никто не может отредактировать, и в мышечной памяти каждого вашего игрока. Раздавать play.example.com - значит, что изменение - это одна строка в форме. Приём ниже идёт чуть дальше одного имени: два слоя имён, так что переезд службы и переезд машины - это две разные правки по одной строке.

Что такое поддомен на самом деле#

Доменное имя - это список меток, разделённых точками и читаемый справа налево. com - это зона, example.com - имя внутри неё, делегированное вам регистратором, а play.example.com - имя внутри зоны, которую вы теперь контролируете. Создание поддомена - не покупка и не регистрация. Это запись в файле вашей зоны, и у любого DNS-провайдера для этого есть форма.

Правила, которые стоит знать, коротки:

• Каждая метка - не более 63 символов, всё имя - не более 253. Ни того, ни другого вы не достигнете.
• Метки могут содержать буквы, цифры и дефисы, но не начинаться и не заканчиваться дефисом.
• Регистр в именах не учитывается. Play.Example.com и play.example.com - одно и то же имя.
• Подчёркивания не разрешены в имени хоста, но намеренно используются в служебных записях вроде _minecraft._tcp.play.example.com. Поэтому они и выглядят странно: это не имена хостов.
• Глубина ничего не стоит. eu.play.example.com не дороже и не медленнее, чем play.example.com.

Различие, на котором спотыкаются, - между добавлением записи и делегированием зоны. Если вы добавляете запись A для play, отвечает ваш DNS-провайдер. Если вы добавляете записи NS для play, вы передали чужим неймсерверам весь play.example.com и всё под ним, а ваши собственные записи для этих имён перестают использоваться. Делегирование нужно, чтобы передать поддерево другой команде или другому провайдеру. Чтобы поставить сервер за именем, нужна запись. Подробнее это различие разобрано в статье неймсерверы или DNS-записи, и прочитать её стоит до того, как вы переносите домен между провайдерами.

Схема имён, которая переживёт три сервера#

Ошибка - направлять каждое имя прямо на адрес. Это работает, а потом вы переезжаете на другую машину, правите девять записей и пропускаете одну.

Используйте два слоя. Имена машин хранят адреса, имена служб указывают на имена машин.

; layer 1 - one name per machine, the only place an address appearsde01        300  IN  A      203.0.113.10de02        300  IN  A      203.0.113.11; layer 2 - one name per service, pointing at a machineplay        300  IN  CNAME  de01.example.com.creative    300  IN  CNAME  de01.example.com.api         300  IN  CNAME  de02.example.com.

Теперь есть два вида переезда, и каждый - одна правка. Машина получила новый адрес: измените запись A у de01, и все службы на ней последуют за ней. Одна служба переезжает на другой сервер: измените её CNAME, и остальная зона этого не заметит. Сравните с девятью записями A, из которых вы обновите семь.

Над самими именами стоит подумать секунд десять, потому что игроки их вводят и произносят вслух:

Называйте службу, а не программу. play переживёт день, когда вы перейдёте с Paper на что-то другое; paper.example.com - нет. Избегайте номеров версий и приставки new-, потому что new-play.example.com будут называть так и через два года. Делайте имя коротким и однозначным на слух: игроки будут читать его друг другу в голосовом чате, и mc каждый раз побеждает minecraft-survival-01.

Одно имя пропускать не стоит: заведите себе скучное административное имя вроде de01, даже если сервер пока один. Как только серверов станет два, вы порадуетесь, что адрес хранится ровно в одной записи.

Создание записи у вашего DNS-провайдера#

Запись нужно создавать там, куда указывают неймсерверы вашего домена, и это часто не регистратор и почти никогда не хостинг-провайдер. RE:NODE не продаёт домены и не ведёт для вас DNS, так что этот шаг выполняется в Cloudflare, Namecheap, Porkbun, в панели вашего регистратора или там, где на самом деле живёт ваша зона.

1. Убедитесь, какой провайдер авторитетен. Это покажет dig +short NS example.com, и только этот ответ имеет значение. Правка записей в панели, которая не авторитетна, - популярный способ потерять вечер.
2. Выберите тип записи. A для адреса IPv4, AAAA для IPv6, CNAME для другого имени. Никогда не ставьте A и CNAME на одно и то же имя.
3. Заполните поле имени в том виде, какого ждёт эта форма. Именно здесь всё идёт не так.
4. Задайте TTL. 300, пока вы работаете, и 3600, когда всё устоялось.
5. Сохраните, затем сами разрешите имя, прежде чем сообщать о нём кому-либо.

Поле имени встречается в трёх видах. Одни формы хотят только метку (play), другие - полное имя (play.example.com), а некоторые принимают любой вариант. Определите свой, посмотрев на уже созданную запись: если у существующей записи www в колонке хоста стоит www, форма относительная и вы вводите play. Если стоит www.example.com, вводите имя целиком. Ввод полного имени в относительную форму даёт play.example.com.example.com - вполне допустимую запись для имени, которое никто никогда не запросит, и никакой ошибки вы не увидите. @ или пустое поле означает сам домен.

Что поддомен нести не может#

Имя сопоставляет адрес. Это всё, что оно делает, и почти любое разочарование поддоменами возникает от ожидания большего.

Он не несёт порт. play.example.com разрешается в 203.0.113.10, а клиент по-прежнему должен знать, что нужен порт 25571. Способов обойти это ровно три, и выбор одного из них - весь смысл статьи как привязать домен к игровому серверу: опубликовать запись SRV для игры, клиент которой её читает, запустить службу на порту, который клиент подразумевает по умолчанию, или поставить перед ней прокси, слушающий ожидаемый порт и пересылающий внутрь.

Он не несёт ни протокол, ни путь. DNS понятия не имеет, что такое HTTPS. Перенаправление old.example.com на https://example.com/new - дело веб-сервера, а не записи; см. www или apex: домен и редиректы.

`CNAME` не может делить имя ни с чем другим. Это записано в исходной спецификации, а провайдеры соблюдают правило неравномерно. Если play.example.com - это CNAME, у него не может быть ещё и записи TXT для подтверждения домена: её добавление либо будет отклонено, либо тихо сломает CNAME. По той же причине CNAME на apex недопустим: на apex уже лежат записи NS и SOA. Провайдеры, которые как будто это позволяют, делают ALIAS, ANAME или CNAME flattening - это синтетическая запись A, создаваемая на их стороне. Это нормально, но это не CNAME.

Он ничего не скрывает. Любой может разрешить имя за две секунды и прочитать адрес. Поддомен - это слой удобства, а не слой безопасности. Между вашим сервером и лавиной трафика стоит фильтрация выше по цепочке, да и она отсекает лишь очевидный объёмный трафик; честный рассказ об этом - статья что мы делаем с атаками.

Wildcard-записи и когда их избегать#

*.example.com отвечает за любое имя под доменом, у которого нет более конкретной собственной записи. Это по-настоящему полезно для многопользовательского приложения, где каждый клиент получает customer.example.com, и это плохая идея для нескольких серверов.

*           300  IN  A      203.0.113.20play        300  IN  CNAME  de01.example.com.

Здесь anything.example.com попадёт на 203.0.113.20, play.example.com по-прежнему пойдёт на de01, потому что конкретная запись всегда побеждает, а сам example.com не совпадает вовсе: wildcard никогда не отвечает за apex.

Причины избегать её в небольшом хозяйстве практические. Опечатки разрешаются: paly.example.com тихо работает, и никто не сообщает о сломанной ссылке. Мониторинг, проверяющий, разрешается ли имя, становится бесполезным, потому что разрешается всё. И вы теряете опись: список записей перестаёт быть списком того, что вы эксплуатируете.

Wildcard также меняет то, как работают сертификаты. Сертификат для *.example.com можно выпустить только после подтверждения контроля над зоной через проверку DNS-01, а это значит, что на сервере лежит токен API вашего DNS-провайдера. Сертификаты для отдельных имён используют гораздо более простую проверку HTTP-01. Оба метода проверки разобраны в статье HTTPS и Let's Encrypt простыми словами.

TTL и порядок переезда, который скучен#

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

Есть второй кэш, на котором ловятся. Когда имени не существует, отрицательный ответ тоже кэшируется, и его срок берётся из поля minimum записи SOA зоны, а не из какой-либо записи. Проверьте play.example.com до того, как создали его, и ваш резолвер может ещё час продолжать твердить, что его нет, хотя для всех остальных запись прекрасно работает. Не проверяйте имя, которое ещё не создано.

Порядок переезда сервера скучен намеренно:

1. За день до переезда снизьте TTL у имени службы и его цели до 300.
2. Выждите прежний TTL целиком, чтобы каждый кэш в мире успел получить короткий.
3. Переместите службу. Измените ту единственную запись, что на неё указывает.
4. Оставьте старый сервер работающим и доступным на несколько часов. Уже идущие сессии ничего не разрешают заново, и устаревшие кэши всё ещё будут приходить туда.
5. Следите за журналом подключений старого сервера. Когда он затихнет, переезд закончен.
6. Верните TTL на 3600.

Остальное о миграции, включая ту часть, где мир копируют до смены DNS, а не после, есть в статье как переехать, не потеряв игроков.

Проверка, прежде чем раздавать имя#

Никогда не публикуйте адрес, который вы не разрешили сами, снаружи своей сети.

$ dig +short CNAME play.example.comde01.example.com.$ dig +short A play.example.com @1.1.1.1203.0.113.10$ dig +short A de01.example.com @8.8.8.8203.0.113.10

Явное указание резолвера - самое важное. Запрос к 1.1.1.1 или 8.8.8.8 обходит всё, что закэшировали ваш роутер и провайдер, и так отличают «ещё не опубликовано» от «ещё не распространилось». Если хотите убрать из картины все кэши, dig +trace play.example.com спускается от корневых серверов и показывает, что говорят сами авторитетные неймсерверы.

В Windows, где dig не установлен:

nslookup -type=A play.example.com 1.1.1.1

Затем докажите, что на другом конце что-то действительно слушает, потому что верная запись, указывающая на закрытый порт, с точки зрения клиента ничем не отличается от сломанной:

$ nc -vz play.example.com 25571Connection to play.example.com 25571 port [tcp/*] succeeded!

В PowerShell для той же задачи есть Test-NetConnection play.example.com -Port 25571. Для UDP-игры такого рукопожатия для проверки нет, так что настоящая проверка - сам клиент игры; почему UDP-служба может работать и оставаться недоступной, разбирает статья порты игрового сервера.

Поддомены, сертификаты и слот прокси#

Для всего, что говорит по HTTP, имя - лишь половина дела. Вторая половина - сертификат, и от того, какое имя вы на что направите, зависит, сколько будет мучений.

В RE:NODE тарифы для приложений и сайтов включают слот обратного прокси. Вы добавляете запись A для своего имени на адрес, показанный в панели, а сертификат выпускается и продлевается автоматически в окне в 21 день до истечения. Поскольку соединение с вашим приложением устанавливает прокси, ваш код видит клиентом прокси, а реальный адрес посетителя приходит в заголовке X-Forwarded-For; читайте этот заголовок, если вы ведёте логи, ограничиваете частоту запросов или определяете геолокацию, иначе все посетители будут выглядеть одним и тем же человеком. Запрос по порядку разбирает статья что делает обратный прокси, а пошаговая версия, включая причины отказа выпуска, - как направить домен на сервер.

Каждому имени нужны своя запись и свой сертификат, так что api.example.com и app.example.com - это по два экземпляра всего. Это достоинство: они могут переезжать независимо, что и было целью затеи.

У игровых тарифов слота прокси нет, и это правильный замысел: HTTP-прокси нечего делать с UDP-потоком игры. Ваш поддомен указывает прямо на адрес сервера, порт остаётся в том, что вводят игроки, или в записи SRV, а панель показывает оба значения на странице самого сервера.

Где поддомены кусаются#

Ничего из этого не теоретично. Всё это обычное дело.

Висячие записи. Вы удаляете сервер и оставляете old.example.com указывающим на адрес, который на следующей неделе выдадут кому-то другому. Если запись указывала не на сырой адрес, а на платформу, тот, кто займёт это имя на платформе, унаследует ваш поддомен и сможет отдавать с него что угодно, вместе с cookies. Удаляйте запись одновременно с сервером и считайте «разрешается во что-то, чем я не управляю» инцидентом.

Проксированная запись перед игровым трафиком. Оранжевое облачко Cloudflare проксирует HTTP и HTTPS. Игровой протокол - ни то, ни другое, поэтому проксированная запись выдаёт игрокам адрес, который никогда не примет игровое соединение. Запись, которую разрешает игровой клиент, должна быть только DNS, то есть серое облачко. Полный список того, что оранжевое облачко проносит, а что нет, есть в статье Cloudflare для сайтов и игровых серверов.

Публичный DNS как карта вашего хозяйства. db.example.com, staging.example.com и grafana.example.com можно перечислить публично, а журналы прозрачности сертификатов публикуют каждое имя, для которого вы когда-либо запрашивали сертификат. Ничего фатального в этом нет, но это значит, что имя - подсказка, а настоящий контроль - это межсетевой экран перед службой. Если ничто снаружи машины не подключается к вашей базе данных, у неё не должно быть ни публичной записи, ни открытого порта; какие порты действительно стоит держать открытыми, описано в статье правила firewall, которые действительно важны.

Почта. Записи MX лежат на apex и поддоменами не наследуются. Почта для you@play.example.com - это иная конфигурация, чем для you@example.com, и ни то, ни другое не предоставляет игровой хостинг. Мы не хостим почту, так что почтовые записи всегда остаются у того, кто её хостит.

FAQ#

Стоят ли поддомены денег?

Нет. Поддомен - это запись в зоне, за которую вы уже платите, и любой распространённый DNS-провайдер позволяет создавать их сколько угодно без доплаты. Если вам называют цену за поддомен, вам продают хостинг, а не DNS.

Сколько поддоменов я могу иметь?

Практически сколько угодно. Технические пределы - 63 символа на метку и 253 на всё имя, а число записей на зону провайдеры ограничивают цифрами в тысячах. Практический предел - число имён, назначение которых вы помните, и он гораздо ниже.

Чем должно быть имя игрового сервера: записью A или CNAME?

Подойдёт любое. CNAME, указывающий на имя машины, аккуратнее, когда серверов больше одного, потому что переезд сводится к одной правке. Прямая запись A на один запрос короче и вполне годится для единственного сервера. Единственное место, где CNAME запрещён, - apex домена.

Может ли поддомен включать порт, чтобы игрокам не приходилось его вводить?

Сам по себе нет. Записи A и AAAA несут адрес и ничего больше. Используйте запись SRV для игры, клиент которой её читает, например Minecraft Java; точные поля описаны в статье SRV-записи для Minecraft - или запустите службу на порту по умолчанию.

Как скоро заработает новый поддомен?

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