DNS-записи простыми словами: A, CNAME, SRV, TXT, MX и TTL

DNS - это таблица соответствий, перед которой стоит кэш, и почти всё непонятное в ней объясняется именно кэшем. Сами записи просты, создавать вам придётся от силы шесть типов, а правила, на которых спотыкаются, пересчитываются по пальцам одной руки: CNAME не может жить на apex, MX-запись не может содержать адрес, выставленный сегодня TTL начинает действовать только после того, как истечёт прежний, а «распространение» - это вовсе не процесс, который происходит с вашим изменением, а чужие кэши, протухающие каждый в своём темпе.

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

Как на самом деле работает запрос#

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

Stub-резолвер в вашей операционной системе настоящей работы не делает. Он спрашивает тот резолвер, который ему прописали, обычно по DHCP, и ненадолго кэширует ответ. Поверх этого свой кэш держат браузеры, и поэтому страница продолжает открываться по старому адресу даже после того, как вы сбросили всё остальное.

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

Корневые серверы и серверы доменов верхнего уровня хранят делегирования, а не ответы. Корень знает, какие серверы ведут зону .com; серверы .com знают, какие неймсерверы авторитетны для example.com. Ни те, ни другие никогда не слышали про play.

Авторитетные неймсерверы хранят вашу зону - те самые записи, которые вы вписали руками. Что говорят они, то и есть правда. Всё, что выше по цепочке, - это копия со сроком годности.

Отсюда два вывода, которые стоит держать в голове. Ваше изменение становится живым на авторитетных серверах немедленно: ни очереди, ни этапа рассылки тут нет. И резолвер, у которого уже есть закэшированный ответ, не спросит заново, пока не истечёт его TTL, как бы вы ни были правы.

Типы записей и зачем нужен каждый#

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

CNAME говорит: «это имя на самом деле вон то имя». Резолвер, наткнувшись на такую запись, начинает поиск заново по её цели. Она удобна, чтобы направить www на apex или поддомен на хост провайдера, который потом сможет менять адрес под ним, не предупреждая вас. Её правила вынесены в следующий раздел, потому что доставляют больше хлопот, чем всё остальное вместе взятое.

MX указывает на имя хоста с числом приоритета, где меньшее предпочтительнее. Правила два, и оба нарушают постоянно: целью должно быть имя хоста, но никогда не IP-адрес, и у этого имени должна быть запись A или AAAA, а само оно не должно быть CNAME. Ещё MX - это запись, которая не имеет ни малейшего отношения к вашему игровому серверу. Почта - отдельная служба на отдельной машине, а RE:NODE почту не хостит вовсе: если она вам нужна, это другой провайдер, и его записи живут рядом с вашими остальными. В статье SPF, DKIM и DMARC простыми словами разобраны TXT-записи, от которых зависит, поверят ли вашей почте.

TXT - это произвольный текст, и потому на него навесили столько работ. Подтверждение владения доменом для Google, Microsoft и десятков других; SPF в виде строки, начинающейся с v=spf1; открытые ключи DKIM под селектором по адресу selector._domainkey.example.com; политика DMARC на _dmarc.example.com. Строка SPF у одного имени может быть только одна: две - это ошибка конфигурации, которая тихо ломает аутентификацию почты, а не выдаёт ошибку там, где вы её увидите.

SRV упаковывает службу, протокол, хост, порт, приоритет и вес в одну запись - именно так адрес Minecraft прячет нестандартный порт. У имени жёсткая форма с ведущими подчёркиваниями, _minecraft._tcp.play, а целью должно быть имя хоста со своей записью A. В статье SRV-записи для Minecraft разобрано каждое поле и показаны команды dig, которые доказывают, что всё работает.

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

CNAME и почему он не может жить на apex#

Правило старше, чем большая часть интернета, в котором его применяют: у имени с записью CNAME не может быть никаких других записей. Ни MX, ни TXT, ни NS. CNAME - это весь ответ целиком, и резолвер обязан пойти по нему, а не искать что-то ещё.

Ваш apex - example.com без поддомена - обязан иметь запись SOA и записи NS, потому что именно это и делает его зоной. Значит, CNAME на нём не бывает никогда. Это правило соблюдает любой DNS-провайдер, а сообщение об ошибке обычно ничем не помогает.

Обходные пути в том порядке, в каком их стоит пробовать:

1. Поставьте на apex запись A и укажите в ней адрес. Просто, правильно, и означает, что при смене адреса её придётся править руками.
2. Используйте ALIAS, ANAME или CNAME flattening своего провайдера. Это не настоящие типы записей. Провайдер сам разрешает цель и отдаёт результат как запись A, обновляя его в фоне. В Cloudflare это называется flattening и делается автоматически для CNAME на apex; в Route 53 это alias record; у других это ANAME. Работает хорошо, и работает только у того провайдера, который это реализовал, так что переезд такая настройка не переживает.
3. Не используйте apex. Повесьте службу на www или на поддомен, а apex перенаправьте на неё HTTP-редиректом с чего-нибудь, что умеет отвечать на апексе. В статье www или apex: домен и редиректы разобрано, какой из них выбрать основным и почему для сайта это важнее, чем кажется.

Из того же запрета следует второе правило: CNAME не может стоять рядом с записью TXT для того же имени. Если сервис просит добавить проверочную запись TXT на www, а www уже CNAME, одному из двух придётся переехать.

TTL, кэширование и миф о распространении#

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

Ловушка в том, что снижение TTL не действует, пока не истечёт прежний TTL. Если запись жила со значением 86400, а вы опустили её до 300 за час до переезда, резолверы, у которых ответ уже есть, будут держать его до конца своих суток, и правота вам тут не поможет. Снижайте TTL минимум за один старый период TTL до того момента, когда он вам понадобится, а это обычно означает «накануне».

Есть и второй кэш, о котором большинство вообще никогда не слышало. Когда резолвер спрашивает про имя, которого не существует, он кэширует и этот ответ «не существует» - на срок, взятый из записи SOA зоны, а не из какой-либо созданной вами записи. Поэтому только что созданное имя ещё несколько минут отвечает NXDOMAIN, хотя всё уже правильно: вы проверили его до того, как создали, и теперь вам отдают ваш собственный отрицательный кэш.

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

Регистратор, неймсерверы и DNS-хостинг - это три разные роли#

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

• Регистратор - это тот, у кого вы покупаете домен и кто держит регистрацию. Его единственное отношение к DNS - хранить список авторитетных неймсерверов.
• DNS-хостинг держит эти неймсерверы и ваши записи. Именно здесь вы создаёте запись A. Часто это тот же регистратор, но так быть не обязано.
• Веб-хостинг или игровой хостинг держит сервер, на который указывают записи. Обычно это другая компания, и обычно у неё нет вообще никакого интерфейса для DNS.

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

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

Записи для игрового сервера и для сайта#

Для игрового сервера вся работа - это обычно две записи, а то и одна.

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

Запись A хранит адрес. CNAME даёт ему более дружелюбное имя, чтобы переезд сервера был одной правкой в одном месте. Запись SRV, только для Java-версии Minecraft, позволяет игрокам не писать порт. Больше здесь ничего нет: ни MX, ни TXT, ни проксирования. Если ваш DNS-провайдер предлагает HTTP-прокси - оранжевое облачко Cloudflare встречали все, - его нужно выключить для любой записи, которой будет пользоваться игровой клиент, потому что проксируются HTTP и HTTPS и больше ничего. В статье Cloudflare для сайтов и игровых серверов точно указано, где проходит эта граница.

Для сайта форма такая:

@     3600  IN  A     203.0.113.20www   3600  IN  CNAME example.com.@     3600  IN  TXT   "v=spf1 -all"@     3600  IN  CAA   0 issue "letsencrypt.org"

@ означает apex. Запись SPF со значением -all на домене, который не отправляет почту, - это небольшая любезность всем вокруг: она сообщает принимающим серверам, что ничто, выдающее себя за вас, не является подлинным. Запись CAA необязательна, и добавлять её стоит только тогда, когда вы знаете, какой центр выпускает ваши сертификаты.

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

Проверка записи через dig и nslookup#

Никогда не считайте список записей у провайдера доказательством того, что запись опубликована. Спросите резолвер.

# Короткий ответ от вашего резолвера по умолчанию$ dig +short A play.example.com203.0.113.10# Спросить конкретный публичный резолвер в обход кэша провайдера$ dig @1.1.1.1 +short A play.example.com# Спросить авторитетные серверы напрямую, убрав все кэши$ dig +trace play.example.com$ dig NS example.com +short# Другие типы$ dig +short MX example.com$ dig +short TXT _dmarc.example.com$ dig +short SRV _minecraft._tcp.play.example.com# TTL прямо сейчас, как он отсчитывается в кэше$ dig A play.example.com | grep -A1 'ANSWER SECTION'

В Windows, где dig нет, ту же работу делает nslookup -type=MX example.com 1.1.1.1, и указание резолвера в конце - самая важная часть. Явный запрос к 1.1.1.1 показывает, что видит посторонний; запрос к своему резолверу по умолчанию показывает, что закэшировал ваш роутер.

Умение прочитать строку статуса в полном ответе dig избавляет от множества догадок:

• NOERROR с пустым ответом означает, что имя существует, но записи такого типа у него нет. Вы создали запись A, а спросили AAAA, либо спросили SRV у имени, у которого есть только A.
• NXDOMAIN означает, что имени не существует. Опечатка, дважды приписанная зона или окно отрицательного кэша.
• SERVFAIL обычно означает сломанный или недоступный неймсервер либо провал проверки DNSSEC. Про неверную запись он не говорит почти никогда.
• REFUSED означает, что сервер, которого вы спросили, не авторитетен для этого имени и рекурсию за вас выполнять не станет.

Чтобы сбросить собственные кэши перед чистой проверкой: ipconfig /flushdns в Windows, sudo dscacheutil -flushcache и следом sudo killall -HUP mDNSResponder в macOS, resolvectl flush-caches в Linux с systemd. У Chrome свой кэш по адресу chrome://net-internals/#dns, и поэтому браузер может ошибаться, когда всё остальное уже верно.

Почему ваше изменение не сработало#

Примерно в том порядке, в каком каждая причина оказывается ответом:

1. Что-то всё ещё держит старую запись. Ваш резолвер, ваш роутер, ваша операционная система или ваш браузер - ровно столько, сколько разрешал прежний TTL. Проверьте через 1.1.1.1, чтобы увидеть правду.
2. Имя приписано дважды. Большинство веб-интерфейсов принимают относительное имя, поэтому play.example.com, вписанное в поле хоста, даёт запись для play.example.com.example.com. Посмотрите на любую существующую запись, чтобы понять, какое соглашение принято в этой форме. В списке записей это незаметно, если не читать внимательно.
3. Вы правили зону у провайдера, который не авторитетен. Неймсерверы у регистратора указывают куда-то ещё, нередко на хостера, от которого вы ушли месяцы назад. dig NS example.com решает вопрос одной строкой.
4. Вы внутри отрицательного кэша. Вы проверили имя до того, как его создали, получили NXDOMAIN, и резолвер вправе помнить это столько, сколько указано в минимуме SOA.
5. Запись верна, а служба лежит. DNS, указывающий на закрытый порт, выглядит ровно так же, как неработающий DNS. Проверьте порт отдельно: в статье порты игрового сервера описано, как сделать это снаружи.
6. На пути стоит прокси. Проксированная запись выдаёт адрес прокси, а не вашего сервера, и для HTTP это правильно, а для всего остального смертельно.

Порядок действий, который избавляет от всего этого при запланированном изменении, скучен и работает: снизьте TTL за сутки, дождитесь, пока истечёт старый, внесите изменение, проверьте через dig на публичном резолвере и оставьте старую цель работать ещё несколько часов. Остальное есть в статье как переехать, не потеряв игроков.

FAQ#

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

У вашего провайдера - мгновенно. Для всех, кто уже искал это имя, - до конца прежнего TTL. Совершенно новое имя, которого нигде нет в кэше, обычно работает через несколько секунд, и поэтому создание записи ощущается быстрее, чем её изменение.

Почему нельзя поставить CNAME на корневой домен?

Потому что у имени с CNAME не может быть других записей, а корень зоны обязан иметь записи SOA и NS. Используйте запись A или функцию ALIAS, ANAME либо CNAME flattening своего провайдера, если она у него есть.

Чем неймсервер отличается от DNS-записи?

Неймсерверы - это машины, которые отвечают на вопросы о вашем домене, и задаются они у регистратора. Записи - это ответы, которые они дают, и создаются они там, где работают эти неймсерверы. Смена неймсерверов переносит зону целиком; смена записи правит один ответ.

Нужна ли игровому серверу запись MX?

Нет. Записи MX нужны для почты и больше ни для чего, а почту никогда не стоит направлять на игровой сервер. Если у вас есть записи MX, указывающие на почтового провайдера, не трогайте их, пока меняете запись A своего сервера.

Какой TTL выбрать?

3600 секунд для обычной работы, 300 за сутки до запланированного изменения, а потом вернуть обратно. 60 используйте только для динамической DNS, где адрес действительно меняется без предупреждения.

Как проверить запись, не дожидаясь кэша?

Спросите публичный резолвер по имени командой dig @1.1.1.1 +short A example.com или идите прямо на авторитетные серверы через dig +trace. Оба способа обходят всё, что запомнила ваша собственная сеть.