DNS-записи

Коротко: Записи в зоне DNS, связывающие домены с определённой информацией — самое известное IP-адреса, но также почтовые серверы, текстовые сведения или псевдонимы.

Подробнее: У каждой DNS-записи есть тип (например, A, AAAA, CNAME, MX, TXT, NS), имя, значение и TTL. У домена может быть любое число записей разных типов; какие серверы имён авторитетны для домена, определяется записями NS.

Подробности

Важнейшие типы записей

• A — домен → адрес IPv4, безусловно самый распространённый тип записи
• AAAA — домен → адрес IPv6, современный аналог A
• CNAME — домен → другое доменное имя (псевдоним); по стандарту не может существовать вместе с другими типами записей на том же имени
• MX — домен → ответственный почтовый сервер, с номером приоритета, когда записей несколько
• TXT — произвольный свободный текст, например для подтверждения домена или для SPF/DKIM/DMARC (защита от подмены адреса электронной почты)
• NS — домен → авторитетный сервер имён, определяет, у кого вообще «последнее слово» по зоне
• Другие, более редкие типы: SRV (записи служб для определённых протоколов вроде SIP/XMPP), CAA (определяет, какие центры сертификации могут выпускать сертификаты SSL), PTR (обратный DNS, IP → домен вместо наоборот)

Полный путь разрешения

Типичный запрос работает так: клиент спрашивает у своего резолвера DNS (часто провайдера интернета или публичного вроде 1.1.1.1/8.8.8.8) про emzett-digital.com. Если ответа ещё нет в кэше резолвера, он сначала обращается к одному из 13 кластеров корневых серверов (верхний уровень глобальной иерархии DNS), который отсылает его к серверу TLD .com. Тот, в свою очередь, отсылает к авторитетным серверам имён домена, названным в записи NS, которые наконец возвращают подходящую A-запись. Весь этот путь называется «рекурсивным разрешением», потому что резолвер проходит всю цепочку от имени клиента, вместо того чтобы оставлять каждый отдельный промежуточный шаг самому клиенту (что теоретически тоже возможно — «итеративное разрешение»).

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

Файлы зон и управление

Все записи домена вместе образуют его «зону», которой управляют через файл зоны у соответствующего DNS-провайдера (например, Cloudflare, Vercel DNS, сам регистратор). Файл зоны следует стандартизированному текстовому формату с записью SOA (Start of Authority, содержит метаданные вроде первичного сервера имён и серийного номера для синхронизации), за которой следуют собственно записи ресурсов. Изменения зоны вносятся через веб-интерфейс или API провайдера и затем — в зависимости от TTL изменённых записей — распространяются на все резолверы по всему миру за секунды–часы.

Частые ловушки

Классическая ошибка — поставить запись CNAME на то же имя, где уже есть запись A или MX: это нарушает RFC 1034 и приводит к непредсказуемому поведению в зависимости от резолвера. Так же многие забывают заблаговременно понизить TTL перед запланированной миграцией DNS, из-за чего само переключение становится видимым везде не за минуты, а за часы.

См. также: A-запись, AAAA-запись, CNAME, MX-запись, TXT-запись, NS-запись, TTL