SRV-записи для Minecraft: поля и как их проверить

Запись SRV позволяет игрокам вводить play.example.com вместо адреса и порта. Это четыре значения и цель, и почти каждая неудачная попытка - одна из одних и тех же нескольких ошибок. Вот всё целиком в одной строке файла зоны:

_minecraft._tcp.play   300  IN  SRV  0  5  25571  node.example.com.node                   300  IN  A        203.0.113.10

Две записи, а не одна. Запись SRV говорит: «служба Minecraft для этого имени живёт на node.example.com, порт 25571», а запись A говорит, где находится node.example.com. Забытая вторая запись - самая частая причина, по которой SRV ничего не делает, потому что в самой записи SRV нет ни одного адреса.

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

Когда игрок вводит имя хоста без порта, клиент Minecraft Java не идёт сразу за записью A. Сначала он запрашивает _minecraft._tcp.<hostname>. Если приходит запись SRV, клиент берёт из неё цель и порт и подключается туда. Если ничего не приходит, он откатывается к обычному запросу A или AAAA по этому имени и предполагает порт 25565.

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

Если ввести порт, запрос SRV пропускается полностью. Игрок, который вводит play.example.com:25565, получает запрос A и порт 25565, что бы ни говорила ваша запись SRV. Это полезный диагностический приём и частый источник фразы «у меня работает»: у одного человека адрес сохранён с портом с тех времён, когда вы ещё ничего не настраивали.

Тот же запрос выполняется и для пинга списка серверов. MOTD, число игроков и зелёные полоски соединения тоже проходят через запись SRV, так что если запись в списке сетевой игры показывает сервер недоступным, это уже сбой пути SRV, и нажимать Join, чтобы это узнать, не нужно.

Bedrock всё это игнорирует. У клиента Bedrock отдельное поле порта, и запросов SRV он не делает, поэтому игроки Bedrock вводят адрес и порт. Если вы запускаете Geyser, раздавайте имя хоста и порт Bedrock как две отдельные вещи.

Поля точно#

Priority и weight существуют для служб, которые действительно работают на нескольких конечных точках, и ничто в Minecraft от них не зависит. Подойдут любые значения; 0 и 5 - общепринятые, и больше о них думать не придётся.

Поле цели - то, на чём попадаются все. Это должно быть имя хоста, и это имя должно разрешаться в адрес где-то в DNS. В файле зоны нужна завершающая точка, которая означает «имя полное, не дописывай к нему мой домен». Большинство веб-редакторов DNS добавляют точку сами, а некоторые потом показывают её вам: node.example.com. в списке записей - это правильно, а не опечатка.

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

Чем отличаются формы регистраторов#

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

• Отдельные поля. Cloudflare и несколько других дают Service, Protocol и Name тремя полями. Service - это _minecraft, Protocol - _tcp, а Name - просто play, либо @ для голого домена.
• Одно относительное имя. У многих регистраторов одно поле хоста, и от вас ждут _minecraft._tcp.play, а зона дописывается автоматически. Домен здесь не вводите.
• Одно абсолютное имя. Некоторые хотят имя целиком: _minecraft._tcp.play.example.com.

Определить, какая форма у вас, можно по уже созданной записи A. Если в существующей записи в колонке хоста стоит www, форма относительная, и имя вашей записи SRV - _minecraft._tcp.play. Если там www.example.com, используйте полное имя. Ошибка здесь даёт _minecraft._tcp.play.example.com.example.com - совершенно корректную запись для имени, которого не существует, и ни одной ошибки нигде не будет.

Некоторые провайдеры также настаивают на едином поле «data» или «content» со значением 0 5 25571 node.example.com. - priority, weight, порт и цель через пробелы, именно в таком порядке.

Ошибки, которые проявляются молча#

DNS почти никогда не сообщает, что вы ошиблись. Он сообщает, что имени не существует, а это выглядит так же, как недоступный сервер. Примерно в порядке частоты:

1. IP-адрес в цели. Недопустимо. Клиент пытается разрешить 203.0.113.10 как имя хоста, ничего не получает и сообщает, что не может подключиться к серверу. Положите IP в запись A и направьте цель на имя этой записи.
2. Нет записи A для цели. Запись SRV может указывать на любое имя, в том числе придуманное на ходу при заполнении формы. Сначала создайте запись A, затем запись SRV, направленную на неё.
3. Зона дописана дважды. Описано выше, и проверять это стоит первым, потому что в списке записей это незаметно, пока не читаешь внимательно.
4. Запись A цели стоит за HTTP-прокси. Оранжевое облачко Cloudflare проксирует HTTP и HTTPS. Minecraft не является ни тем ни другим, поэтому проксированная запись отдаёт клиентам адрес, который никогда не примет игровое подключение. Запись, на которую указывает цель SRV, должна быть только DNS - серое облачко. Что оранжевое облачко пропустит, а что нет, разобрано в статье Cloudflare для сайтов и игровых серверов.
5. Неверный порт. Игровой порт, а не порт query, не RCON и не тот порт, который был у вас в прошлом месяце. В панели копируйте его из адреса сервера, а не по памяти.
6. `_tcp` написано как `tcp` или как `_udp`. Оба подчёркивания - часть имени. Java Minecraft работает по TCP.
7. Устаревший кэш. Вы исправили запись десять минут назад, а ваш резолвер до конца TTL всё ещё отдаёт старый ответ. Проверяйте через публичный резолвер, чтобы увидеть правду.

Доказываем, что работает, до объявления#

Никогда не объявляйте адрес, который вы сами не разрешили. Две команды решают дело:

$ dig +short SRV _minecraft._tcp.play.example.com0 5 25571 node.example.com.$ dig +short A node.example.com203.0.113.10

Если первая ничего не возвращает, запись отсутствует, названа неверно или ещё не опубликована. Если первая работает, а вторая ничего не возвращает, перед вами классический случай отсутствующей записи A. В Windows без установленного dig:

nslookup -type=SRV _minecraft._tcp.play.example.com 1.1.1.1

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

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

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

В PowerShell для той же работы есть Test-NetConnection node.example.com -Port 25571. Почему игра может слушать и при этом быть недоступной, объяснено в статье порты игровых серверов.

Последняя проверка - настоящая: добавьте play.example.com в клиент Minecraft без порта и посмотрите, появятся ли в списке серверов MOTD и число игроков. Так проверяется ровно тот путь, которым пойдут ваши игроки.

Чего запись SRV не умеет#

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

Она не балансирует нагрузку. В DNS SRV для этого предусмотрены поля priority и weight, но клиент Minecraft не реализует взвешенный выбор так, чтобы на него можно было рассчитывать. Если опубликовать несколько записей SRV и ждать, что игроки распределятся по ним, что-то получится, но не то, что вы задумали. Если нужно больше одного бэкенда, поставьте перед ними прокси.

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

Она ничего не даёт клиентам Bedrock. Они не спрашивают.

SRV, прокси и forced hosts#

Если перед несколькими бэкендами у вас стоит прокси вроде Velocity, запись SRV, скорее всего, вообще не нужна. Прокси слушает 25565, и простой записи A на play.example.com достаточно, - одной вещью, в которой можно ошибиться, становится меньше. Порты превращаются во внутреннее дело, и публичным остаётся только порт прокси.

Интересная часть - маршрутизация по имени. Прокси может сопоставить имя хоста с конкретным бэкендом: creative.example.com отправляет людей сразу на творческий сервер, play.example.com - в лобби, - используя имя хоста, которое клиент передал в рукопожатии. Это удобный способ дать разным сообществам разные входы, не открывая больше одного публичного порта. Проверьте это, а не предполагайте: то, что несёт рукопожатие - имя, введённое игроком, или цель SRV, - зависит от клиента и версии прокси, а forced hosts работают, только если это первое. Общая форма идеи описана в статье что делает обратный прокси.

Для одного сервера на порту по умолчанию самое простое рабочее решение - запись A и никакого SRV. Эта версия задачи описана в статье как привязать домен к игровому серверу, а как дать каждому из ваших серверов собственное имя, разобрано в статье поддомены для серверов. SRV оправдывает своё место ровно тогда, когда порт не 25565 и вы не хотите, чтобы игроки о нём знали.

TTL и переезд сервера#

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

Порядок действий при переезде скучен и надёжен:

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

Поскольку адрес живёт в одной записи A, смена места, где живёт сервер, - это правка в одну строку, и запись SRV больше никогда не понадобится трогать. Это вторая причина указывать цель SRV на имя, а не на адрес; первая - что IP в цели недопустим. Остальную часть миграции описывает статья как переехать, не потеряв игроков, а DNS-записи простыми словами - это база, если какие-то из здешних типов записей были вам незнакомы.

FAQ#

Нужна ли мне запись SRV, если сервер работает на порту 25565?

Нет. Клиенты предполагают 25565, когда записи SRV нет, так что простой записи A на имя достаточно, и её проще отлаживать. SRV существует для серверов на любом другом порту.

Почему адрес работает у меня, а у друзей нет?

Обычно потому, что вы сохранили его с портом, а это полностью пропускает запрос SRV, либо потому, что у вашего резолвера в кэше другой ответ, чем у них. Уберите порт из сохранённой записи и проверьте снова, а затем сверьте запись через 1.1.1.1, а не через свой DNS.

Можно ли направить цель SRV прямо на IP-адрес?

Нет. Поле цели должно быть именем хоста. Создайте запись A для чего-то вроде node.example.com, в которой хранится IP, и направьте цель SRV на это имя. Заодно будущие переезды сведутся к одной правке.

Сколько времени нужно, чтобы запись SRV заработала?

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

Скрывает ли запись SRV IP-адрес моего сервера?

Совсем нет. Цель разрешается в публичную запись A, которую может запросить любой. Если скрыть адрес важно, это задача для прокси перед сервером, а не для DNS.

Можно ли использовать один домен для нескольких серверов Minecraft?

Да. Дайте каждому собственное имя - smp.example.com, creative.example.com - со своей записью SRV, указывающей на нужный порт того же хоста. Все они могут использовать одну общую запись A для машины.