Понимание типов записей DNS
Типы DNS-записей — это базовые элементы, которые определяют, как домен должен работать в интернете. Когда кто-то открывает сайт, отправляет письмо, подтверждает домен в стороннем сервисе или подключает приложение к hostname, DNS почти всегда оказывается первым задействованным слоем. Многие проблемы с доменом и хостингом, которые сначала кажутся сложными, на деле сводятся к простой ошибке в DNS: A-запись указывает не на тот IP, MX-запись отсутствует, CNAME конфликтует с другой записью, а TXT-значение введено с неправильным синтаксисом. Поэтому понимание DNS полезно не только системным администраторам, но и владельцам сайтов, разработчикам и всем, кто управляет доменами.
На практике DNS работает как распределённая адресная книга. Вместо того чтобы запоминать числовые IP-адреса, пользователи работают с именами вроде example.com или mail.example.com. Но DNS делает гораздо больше, чем просто перевод имени в IP. Он указывает, куда доставлять почту, помогает подтверждать владение доменом для внешних сервисов, публикует anti-spam политики и поддерживает поддомены и базовое обнаружение сервисов. Если вы управляете доменом через регистрацию доменов, размещаете сайт на хостинге или используете виртуальные серверы, с DNS-записями вам рано или поздно придётся работать.
Главное, что нужно помнить: DNS — это зона из многих записей, а не один параметр. У одного домена одновременно может быть несколько записей, и каждая отвечает за свою задачу. Корневой домен может использовать A-запись для сайта, MX-записи для почты, TXT-записи для SPF и верификации, а также иметь поддомены со своей отдельной конфигурацией. Когда вы понимаете основные типы записей, диагностика становится намного проще, потому что DNS начинает выглядеть не как случайный список в панели, а как логичная структура.
A-запись — самая известная. Она связывает hostname с IPv4-адресом. Если ваш сайт работает на сервере с IP 203.0.113.10, A-запись для example.com может указывать именно на этот адрес. AAAA-запись делает то же самое, но для IPv6. На практике, когда браузер спрашивает, где находится example.com, DNS-сервер возвращает IP из A или AAAA записи.
example.com. 3600 IN A 203.0.113.10 example.com. 3600 IN AAAA 2001:db8::10
CNAME-запись устроена иначе. Она не указывает прямо на IP-адрес, а сообщает, что один hostname является алиасом другого hostname. Например, www.example.com может быть CNAME на example.com, а shop.example.com — CNAME на внешний SaaS hostname. CNAME удобен тем, что если у целевого имени меняется IP, сам алиас менять не нужно. Но есть правило, которое часто забывают: hostname с CNAME не должен одновременно содержать A, MX или другую конфликтующую запись на том же имени.
www.example.com. 3600 IN CNAME example.com.
MX-запись управляет доставкой электронной почты. Она говорит другим почтовым серверам, какой mail host отвечает за приём почты для вашего домена. Если кто-то отправляет сообщение на info@example.com, сервер отправителя сначала проверяет MX-записи для example.com, а затем подключается к указанному почтовому серверу. У MX-записей обычно есть приоритет, и меньший номер означает более высокий приоритет. Частая ошибка — создать MX, но забыть, что сам mail hostname тоже должен разрешаться через A или AAAA запись.
example.com. 3600 IN MX 10 mail.example.com. mail.example.com. 3600 IN A 203.0.113.20
TXT-записи очень гибкие. В современной практике DNS они чаще всего используются для верификации и публикации политик. Такие сервисы, как Microsoft 365, Google и поставщики сертификатов, часто требуют добавить TXT-запись, чтобы подтвердить владение доменом. Почтовая защита тоже опирается на TXT. SPF публикуется именно через TXT и сообщает, какие серверы имеют право отправлять почту от имени вашего домена. Поскольку TXT-значения часто бывают длинными, типичные ошибки — неправильные пробелы, отсутствующие кавычки и публикация записи не под тем hostname.
example.com. 3600 IN TXT "v=spf1 mx ip4:203.0.113.20 -all" _acme-challenge.example.com. 3600 IN TXT "verification-token"
С почтой тесно связаны и DKIM с DMARC. DKIM использует TXT-записи под селектором, например default._domainkey.example.com, чтобы публиковать открытый ключ для проверки подписанных писем. DMARC обычно публикуется на _dmarc.example.com и сообщает получающим серверам, что делать, если проверки SPF или DKIM не прошли. Вместе MX, SPF, DKIM и DMARC составляют практическую DNS-основу деловой почты. Когда письма уходят в спам, причина очень часто частично находится именно в DNS.
NS-запись определяет, какие DNS-серверы являются авторитетными для домена или делегированного поддомена. На уровне регистратора NS сообщает интернету, где находится DNS-зона домена. Внутри самой зоны NS может делегировать поддомен другому DNS-провайдеру или внутреннему серверу. Запись SOA содержит административную информацию о зоне, включая основной авторитетный сервер и серийный номер, который используется для обновлений зоны.
example.com. 3600 IN NS ns1.provider.net. example.com. 3600 IN NS ns2.provider.net.
Ещё один распространённый тип — PTR, который используется для обратного DNS. В отличие от A-записи, связывающей имя с IP, PTR связывает IP-адрес с hostname. Reverse DNS особенно важен для почтовых серверов, потому что многие получающие системы проверяют, есть ли у IP отправителя корректная PTR-запись. В отличие от обычных DNS-записей, PTR чаще всего управляется поставщиком IP, а не вашим стандартным DNS-редактором.
Существуют и более специальные типы, которые встречаются реже, но остаются полезными. SRV-записи помогают клиентам находить сервисы с указанием host и port. CAA-записи определяют, каким центрам сертификации разрешено выпускать SSL-сертификаты для вашего домена. Маленькие сайты могут никогда их вручную не менять, но в более серьёзных инфраструктурах они помогают уменьшать ошибки и усиливать контроль.
_sip._tcp.example.com. 3600 IN SRV 10 5 5060 sip.example.com. example.com. 3600 IN CAA 0 issue "letsencrypt.org"
Как правильно читать DNS и избегать частых ошибок
При работе с DNS самые важные привычки — последовательность и терпение. Всегда проверяйте hostname, тип записи, целевое значение и TTL. TTL определяет, как долго ответ может храниться в кеше. Если вы изменили A-запись и не увидели результата сразу, это не обязательно означает, что изменение не сработало; очень часто ответ ещё просто закеширован. Перед миграциями администраторы часто заранее уменьшают TTL, выполняют изменение, проверяют трафик и только потом снова повышают TTL.
Одна из самых частых ошибок — неправильное сочетание записей на одном и том же имени. Например, hostname не должен одновременно иметь и CNAME, и A-запись. Другая типовая проблема — путаница между корневым доменом и поддоменом. TXT или MX, опубликованные не на том уровне, могут выглядеть правильно в панели, но полностью не работать на практике. Особенно чувствительна к ошибкам почтовая DNS-конфигурация, где даже маленькая синтаксическая ошибка в SPF, DKIM или DMARC ломает проверку.
Практический способ проверить DNS — запрашивать его напрямую. Инструменты вроде nslookup, dig или онлайн DNS-checkers помогают быстро подтвердить, опубликована ли запись и видна ли она извне. Например, проверка A или MX-записи часто сразу показывает, где именно проблема: в самом DNS или уже в другом слое, например в веб-сервере или firewall.
nslookup example.com nslookup -type=MX example.com dig example.com A dig example.com TXT
Полезный практический совет — смотреть на изменения из нескольких точек. Локальный DNS-кеш, публичный resolver и сам авторитетный DNS-сервер не всегда отдают одинаковый ответ в одну и ту же минуту. Поэтому после правок полезно сравнивать ответы из разных источников. Это помогает быстро понять разницу между “запись не опубликована” и “запись уже опубликована, но ещё не распространилась повсюду”.
Если вы управляете сайтом, почтой и внешними сервисами под одним доменом, работать с DNS намного проще, когда изменения документируются. Полезно вести простой список поддоменов, назначения записей и сервисов, которые от них зависят. DNS сложен не потому, что отдельные записи загадочны. Он становится сложным только тогда, когда никто уже не помнит, зачем конкретная запись была добавлена изначально.
В итоге понимание типов DNS-записей означает понимание логики поведения домена. A и AAAA связывают имена с серверами, CNAME создаёт алиасы, MX направляет почту, TXT публикует данные для верификации и политик, NS и SOA задают авторитетность, PTR отвечает за reverse lookup, а более специализированные SRV и CAA решают узкие задачи. Когда эти роли становятся понятны, DNS-панели перестают казаться хаотичными и начинают выглядеть предсказуемо и логично.