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

Используйте навигацию, если не хотите читать текст полностью:

→ Обязательные записи
→ Классические записи
→ Сервисные записи
→ Записи для повышения безопасности

Обязательные записи

SOA

SOA (Start of Authority) — одна из тех записей, которые необходимы всем DNS-зонам, чтобы соответствовать стандартам IETF. Помимо очевидных параметров (имени и типа записи) может содержать другие значения.

• mname — имя основного сервера, откуда приходят обновления для вторичных серверов, на которых хранятся дубликаты DNS-записей.
• rname — адрес электронной почты администратора. Нужно обратить внимание, что здесь вместо символа @ используется точка.
• serial — номер копии зоны. При создании зоны по умолчанию указывается значение 1. При каждой синхронизации данных между серверами значение увеличивается. Таким образом, чем больше значение serial, тем новее данные на сервере.
• refresh — частота, с которой вторичные серверы запрашивают у первичных обновление SOA-записи. Указывается в секундах.
• retry — частота, с которой вторичные серверы могут запрашивать обновления у основного, если тот не отвечает.
• expire — время, по прошествии которого вторичный сервер перестает отвечать на запросы зоны, если не получает ответ от основного.

NS

NS (Nameserver) — запись указывает, какой сервер содержит фактические записи DNS. Без правильно настроенных NS-записей не получится открыть сайт или приложение, поскольку не получится получить IP-адрес домена.

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

Классические записи

Как нетрудно догадаться, это записи, которые встречаются повсеместно. Скорее всего, при запуске сайта или приложения на облачном или выделенном сервере, вы будете пользоваться одной из этих записей. Вкратце, все они указывают на адрес назначения, которым в конечном счете будет IPv4 или IPv6.

А

Тип записи, который используется для связывания IPv4-адреса сервера с ресурсной записью домена. Значение A-записи состоит только из поля value, поэтому и работает все предельно просто.

Например, у нас есть две записи: example.com и shop.example.com. Для первой в поле value указано значение 1.1.1.1, для второй — 2.2.2.2. При открытии сайта example.com браузер будет обращаться к серверу 1.1.1.1, а и при открытии shop.example.com — соответственно, к записи 2.2.2.2.

AAAA

Запись, в целом аналогичная А, но с той разницей, что ресурсная запись домена связывается с IPv6-адресом сервера. Пример значения АААА-записи: 2001:db8:abc1::54.

CNAME

CNAME (Canonical Name) — это тип записи, которая привязывает псевдоним к действительному (каноническому) доменному имени. Записи CNAME обычно используют для привязки к доменам, в которых размещен контент, и субдоменам вроде www или mail. Иначе говоря, CNAME в отличие от A и AAAA ссылается на доменное имя, а не на IP-адрес.

Первое значение в записи определяет псевдоним (обычно субдомен типа www или mail), для которого она создается. Второе — домен, на который указывает псевдоним.

Таким образом, благодаря записям CNAME легко использовать несколько служб с одного IP-адреса. Последний определяет запись А-домена. Если IP-адрес изменится, достаточно будет изменить запись А, не меняя каждую из записей CNAME.

Практический пример. У вас есть домен example.com, и вы подключаете CDN для поддомена cdn.example.com: cdn.example.com CNAME uuid.selcdn.ru. Здесь uuid.selcdn.ru — доменное имя CDN-ресурса. Вы не можете напрямую указать IP-адреса CDN, так как не управляете ими, и они могут динамически меняться. Доменное имя CDN-ресурса при этом постоянно.

Для CNAME-записи есть разные ограничения.

• Запись CNAME нельзя добавить для основного имени. Для таких целей стоит использовать запись типа ALIAS.
• Если для поддомена добавлена запись CNAME, то другую запись для него добавить нельзя.
• Если для поддомена добавлены какие-либо другие записи, то добавить CNAME нельзя.
• CNAME невозможно использовать в качестве редиректа, так как HTTP-редирект нельзя организовать в рамках DNS.

ALIAS

Записи типа ALIAS — это, по сути, CNAME на максималках. Они также копируют данные целевого домена, но имеют несколько отличий.

Прежде всего, запись ALIAS можно добавить для основного домена, а ее имя может быть любого уровня, включая второй. Кроме того, она не конфликтует с другими записями в пределах одного поддомена, в том числе с таким же именем (кроме А и АААА).

Пример с облачным хранилищем. Есть контейнер, в который мы загрузили сайт, его основной домен вида uuid.selstorage.ru. Нам нужно, чтобы сайт открывался по example.com.

Сделаем запись example.com ALIAS uuid.selstorage.ru. При попытке открыть example.com произойдет магия.

1. Браузер сделает запрос A и AAA-записей для example.com.
2. Наш DNS-сервер, зная об ALIAS-записи, запустит ресолвинг адресов целевого домена uuid.selstorage.ru и получит в ответ IPv4 или IPv6.
3. DNS-сервер вернет для example.com полученный на предудущем шаге набор IP-адресов.
4. Браузер установит соединение с серверами облачного хранилища и откроет находящийся там example.com.

При использовании записей типа ALIAS нужно помнить, что для домена/поддомена не может быть записи A или AAAA. Кроме того, ALIAS нарушит DNSSEC на основном домене (@), поскольку в ответах @ A и @ AAAA будут отсутствовать записи RRSIG. Это, в свою очередь, нарушит разрешение на всех резолверах.

Какого-либо черновика и стандарта в RFC для ALIAS нет, поэтому от сервиса к сервису могут наблюдаться разные поведения у этого типа записи.

Подробнее о записях типа CNAME и ALIAS мы писали в отдельной статье. C примерами использования и мини-гайдами по подключению и настройке.

Сервисные записи

Указывают на тип сервиса и его дополнительные параметры. Например, определяют местоположение хоста или почтового сервера, предпочтительный протокол соединения и т. д. Другими словами, в теории сервис может работать и без этих записей, но с ними пользоваться им будет удобнее, быстрее и безопаснее.

MX

MX (Mail Exchange) — тип записи, который указывает на почтовый сервер доменного имени. Это позволяет внешним почтовым серверам определять, куда отправлять электронную почту. Другими словами, запись отвечает на вопрос, где ваш почтовик.

Формат этой записи содержит два значения: priority и value. Первое поле определяет приоритет сервера, на который будет отправляться почта. Он может иметь числовое значение (integer): чем оно ниже, тем выше приоритет.

Поле value определяет доменное имя или IP-адрес сервера входящей электронной почты.

Рассмотрим на примере. Допустим, у нас есть MX-запись example.com, в которой для значения 203.0.113.102 установлен приоритет 10, а для значения 198.51.100.5 — 20. В этом случае при отправке письма на электронный адрес info@example.com, оно будет направлено на сервер 203.0.113.102, а при его недоступности — на сервер 198.51.100.5.

Несколько MX-записей актуально, когда у одного домена есть несколько почтовых серверов. Создание записи для каждого сервера с указанием приоритета помогает распределить нагрузку и/или зарезервировать почтовые серверы.

SRV

SRV (Service Record) — это тип записи, который определяет местоположение, то есть имя хоста и номер порта серверов для определенных служб. По сути, такая запись отвечает на вопрос, где сервис такого типа, каков его IP и порт. SRV придумали, чтобы не плодить новые типы записей, как получилось с MX.

Формат такой записи выглядит следующим образом:

service.proto.name TTL class SRV priority weight port target.

В этой записи последовательно указываются:

• service. — символьное имя сервиса;
• proto. — транспортный протокол (самые популярные сейчас — TCP или UDP, хотя можно использовать и другие);
• name — доменное имя, для которого действует запись;
• TTL — время в секундах, в течение которого ресурсная запись в кэше сервера считается актуальной;
• class — поле класса (в SRV-записях всегда используется класс IN);
• SRV — тип записи (всегда SRV);
• priority — полностью идентично тому, что используется в записях типа MX: чем меньше значение, тем выше приоритет хоста;
• weight — определяет относительный вес для записей с одинаковым приоритетом: чем больше значение, тем с большей вероятностью хост будет выбран;
• port — определяет TCP/UDP порт, на котором работает сервис;
• target — каноническое имя машины, на которой работает сервис.

Пример записи: xxx.tcp.example.com 86400 IN SRV 10 5 5060 xxxserver.example.com

SVCB

Это дальнейшее развитие SRV-записи с добавлением других метаданных, необходимых для сетевого соединения. Среди них — предпочтительный протокол и его версия, IP-адреса и порты.

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

SVCB-записи имеют два режима:

• AliasMode — делегирует оперативное управление ресурсом;
• ServiceMode — объединяет информацию о конфигурации для эндпоинта.

Записи SVCB имеют вид: SvcPriority TargetName SvcParams.

• SvcPriority — это число в диапазоне от 0 до 65535. Чем меньше значение, тем выше приоритет этой записи относительно других. Значение 0 включает AliasMode.
• TargetName — имя домена.
• SvcParams — список параметров, каждый из которых является либо самостоятельным, либо парой SvcParamKey=SvcParamValue.

Записи SVCB и HTTPS также предоставляют IP-адреса напрямую, без необходимости просмотра клиентом записей A и AAAA. Для этого к записям можно добавить параметры ipv4hint и ipv6hint.

Пример записи: example.com 3600 IN SVCB 1. alpn=«h3,h2» ipv4hint=«192.0.2.1» ipv6hint=«2001:db8::1»

HTTPS

HTTPS-записи — разновидность SVCB с акцентом на подключение по HTTPS. Они также помогают ускорить загрузку сайтов и приложений. В отличие от устаревшего протокола HTTP, который запрашивал у пользователя только IP-адрес, HTTPS умеет, например, создавать альтернативное подключение к эндпоинтам (HTTP/3), включать Encrypted ClientHello и поддерживает нестандартные порты TCP и UDP.

Через HTTP все пользовательские запросы отправляются без какого-либо шифрования, просто в виде текста. Это относится к паролям, данным банковских карт и любой другой информации. То есть злоумышленник может просто прочитать текст в запросе или ответе и точно узнать, какую информацию кто-то запрашивает, отправляет или получает. В случае с HTTPS запросы и ответы шифруются с помощью TLS (SSL) и выглядят как набор случайных символов.

Записи для повышения безопасности

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

SSHFP

SSHFP (Secure Shell Fingerprint) — это тип записи, который содержит отпечаток ключа, используемый сервером при подключении по протоколу SSH. Запись помогает предотвратить MITM-атаки (Man-in-the-Middle) и содержит поля algorithm, type и fingerprint.

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

• 0 — зарезервировано,
• 1 — RSA,
• 2 — DSA,
• 3 — ECDSA,
• 4 — Ed25519.

Поле type определяет тип алгоритма хэширования публичного ключа сервера. Возможные значения:

• 0 — зарезервировано,
• 1 — SHA-1,
• 2 — SHA-256.

Поле fingerprint содержит шестнадцатеричное представление результата хэш-функции публичного ключа сервера.

На практике все это выглядит так:Здесь отпечаток SHA-1 открытого ключа DSA хоста с DNS-именем host.example.com — 123456789abcdef67890123456789abcdef67890.

CAA

CAA (Certification Authority Authorization) — тип DNS-записи, предназначенный для определения центров сертификации, которым разрешен выпуск SSL-сертификатов для определенного доменного имени или поддомена.

Такие записи появились как дополнительная мера защиты, чтобы сертификат не могли выпустить третьи лица. Ими могут оказаться и злоумышленники, которым хватит даже кратковременного взлома веб-сервера для создания сертификата. Затем его можно применять, например, для проведения MITM-атак.

CAA-запись указывает на центры сертификации, которым разрешен выпуск TLS-сертификатов для доменного имени. Если разрешения есть у нескольких центров, CAA-запись должна быть создана для каждого из них.

Запись содержит три поля: flags tag и value.

Значение flag — это число, которое отражает критичность записи. Возможны два значения.

• 0 — запись некритична. Если значение tag невозможно распознать или CA (Certification Authority) не поддерживает данное значение, то выпуск сертификата возможен по усмотрению CA.
• 128 — запись критична. Если значение tag невозможно распознать или CA не поддерживает данное значение, то выпуск сертификата запрещен.

Поле tag может иметь следующие значения:

• issue — определяет CA, для которого разрешена выдача сертификатов на домен/поддомен записи.
• issuewild — определяет CA, для которого разрешена выдача wildcard-сертификатов на домен/поддомен записи.
• iodef — определяет адрес электронной почты или URL, который CA должен задействовать, чтобы уведомить владельца DNS-зоны о несанкционированной попытке выпуска SSL сертификата (формат почты — mailto:support@example.com, формат URL — HTTP(S)://example.com/caa-webhook).

Значение поля value зависит от tag. При значениях issue или issuewild

определяет название CA, при значении iodef определяет адрес электронной почты или URL.

Разберем на примере. Допустим, для записи example.com установлено значение 128 issue «aa.example.ru». Это значит, что выпустить SSL-сертификат для домена example.com может только CA aa.example.ru.

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

DNSSEC

DNSSEC (Domain Name System Security Extensions) — это набор IETF-расширений (RFC) для протокола DNS. Он нужен для обеспечения аутентичности (подлинности, полноты и точности) данных при разрешении доменных имен.

DNSSEC использует криптографию с открытым ключом. Это позволяет определить, что ответ предоставлен владельцем DNS-зоны, а не третьей стороной, аналогично SSH-ключам или HTTPS.

Чтобы подробно рассмотреть этот тип записи и тонкости работы, придется написать отдельную статью. Если тема вам интересна, дайте знать — мы подготовим публикацию с примерами и картинками.

Подробные инструкции по работе с ресурсными записями (добавление, изменение, удаление и т. д.) вы найдете в документации Selectel.