Типы ресурсных записей DNS

Согласно стандарту RFC 1035^[9], все ресурсные записи имеют общий формат для передачи в сети, который используется в разделах ответов, полномочий и дополнительной информации в DNS-сообщениях.

Схема двоичного формата ресурсной записи^[9]:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Каждая запись состоит из стандартизированного набора полей:

• NAME (Имя) — доменное имя, к которому относится данная ресурсная запись. Поле имеет переменную длину; для экономии места в DNS-сообщениях используется схема сжатия имён. В файлах зоны может применяться специальный символ @, обозначающий имя текущего домена^[9].
• TYPE (Тип) — два октета (16 бит), указывающие тип ресурсной записи (например, A, AAAA, MX, CNAME). Поле определяет формат и назначение данных в поле RDATA^[9].
• CLASS (Класс) — два октета (16 бит), определяющие класс данных (тип сети). В подавляющем большинстве случаев для сетей на базе TCP/IP используется значение IN (Internet)^[9][10].
• TTL (Time To Live, время жизни) — согласно RFC 2181, 32-битное целое число без знака, указывающее допустимое время в секундах, в течение которого запись может храниться в кэше DNS-сервера. Нулевое значение означает, что запись не должна кэшироваться. Все записи одного набора (RRset) должны иметь одинаковое значение TTL^[11].
• RDLENGTH (Resource Data Length) — 16-битное целое число без знака, указывающее длину поля RDATA в октетах^[9].
• RDATA (Resource Data, ресурсные данные) — поле переменной длины, содержащее данные, специфичные для конкретного типа записи. Например, для записи типа A поле содержит 32-битный IPv4-адрес, а для MX — приоритет и доменное имя почтового сервера^[9].
• Расширение EDNS0 (RFC 6891) вводит псевдо-запись OPT, которая переиспользует поля RDLENGTH и RDATA для передачи дополнительных опций без изменения их стандартного двоичного формата^[12].

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

Выбор значения TTL напрямую влияет на скорость обновления информации для конечных пользователей и на уровень нагрузки на авторитативные DNS-серверы:

• Низкие значения TTL (например, от 60 до 300 секунд) позволяют изменениям в DNS-записях распространяться по сети значительно быстрее. Это востребовано при плановых изменениях инфраструктуры, таких как смена IP-адреса. Однако более частые запросы на обновление приводят к увеличению нагрузки на авторитативные серверы.
• Высокие значения TTL (например, 3600 или 86400 секунд) снижают количество обращений к авторитативным серверам и ускоряют выдачу ответов для стабильных ресурсов. Главным недостатком является то, что при внесении изменений на авторитативном сервере пользователи продолжат получать устаревшие данные из кэша вплоть до истечения заданного времени. Хотя традиционно считалось, что процесс распространения изменений может занимать до 48 часов, в современных сетях это время обычно составляет 4—8 часов^[13].

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

Механизм отрицательного кэширования (negative caching) позволяет рекурсивным DNS-серверам временно сохранять информацию об отсутствии запрашиваемой ресурсной записи. Согласно стандарту RFC 2308, время хранения несуществующих записей в кэше определяется значением поля MINIMUM в записи SOA^[14].

Современные рекомендации по выбору значений TTL зависят от типа записи: для статичных записей A и AAAA рекомендуется устанавливать от 1 до 4 часов, для почтовых записей MX — от 12 до 24 часов, для записей NS — 24 часа и более, а для динамических записей — от 5 до 10 минут^[15].

В настоящий момент определены следующие типы ресурсных записей (жирным выделены наиболее используемые записи): Авторитетным источником информации о всех типах ресурсных записей является реестр IANA^[16][17].

Согласно стандартам DNS (RFC 1912 и RFC 1034), использование записи типа CNAME на вершине зоны (корневом домене) запрещено. Это ограничение связано с тем, что при наличии записи CNAME для узла не могут существовать никакие другие ресурсные записи. При этом вершина зоны обязательно должна содержать записи SOA и NS, необходимые для корректной работы доменной зоны, что делает невозможным их совместное использование без возникновения конфликтов^[25].

Для обхода данного ограничения современные DNS-провайдеры применяют технологию CNAME Flattening (сглаживание CNAME) или проприетарные типы записей, такие как ALIAS и ANAME. Эти решения позволяют указывать целевое доменное имя для вершины зоны: DNS-сервер провайдера самостоятельно разрешает его в IP-адреса и возвращает клиенту в виде стандартных записей A или AAAA, не нарушая архитектуру DNS^[26].