Как разобраться в DNS-хостинге и ничего не сломать

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

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

SOA

Помимо очевидных параметров (имени и типа записи) может содержать другие значения.

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

NS

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

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

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

А

Например, у нас есть две записи: 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

Первое значение в записи определяет псевдоним (обычно субдомен типа 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 можно добавить для основного домена, а ее имя может быть любого уровня, включая второй. Кроме того, она не конфликтует с другими записями в пределах одного поддомена, в том числе с таким же именем (кроме А и АААА).

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

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

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

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

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

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

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

MX

Формат этой записи содержит два значения: <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

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

_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

Основное преимущество этого типа записей в том, что они повышают производительность 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

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

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

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

SSHFP

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

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

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

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

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

На практике все это выглядит так:

Имя записи	Тип записи	Algorithm	Type	Fingerprint
host.example.com	SSHFP	2	1	123456789abcdef67890123456789abcdef67890

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

CAA

Такие записи появились как дополнительная мера защиты, чтобы сертификат не могли выпустить третьи лица. Ими могут оказаться и злоумышленники, которым хватит даже кратковременного взлома веб-сервера для создания сертификата. Затем его можно применять, например, для проведения 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 использует криптографию с открытым ключом. Это позволяет определить, что ответ предоставлен владельцем DNS-зоны, а не третьей стороной, аналогично SSH-ключам или HTTPS.

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