Перейти к содержимому
DNS
NEXIP / РЕДАКЦИОННЫЙ МАТЕРИАЛ

Что такое DNS-записи

Подробно разбираем, как работает DNS, за что отвечают A, AAAA, CNAME, MX, TXT, NS, SOA, PTR и CAA, что такое TTL и как диагностировать DNS через dig и NexIP.

Редакция NexIPNexIP Дата публикации Обновлено Время чтения11 мин Читать статью
NEXIP JOURNAL Обложка публикации
← Материалы Что такое DNS-записи

DNS — одна из базовых систем интернета. Именно она позволяет открывать сайты по понятным именам вроде nexip.ru, а не запоминать IP-адрес каждого сервера. Но DNS отвечает не только за связь домена с IP: через него настраиваются почта, подтверждение сервисов, DNSSEC, сертификаты и множество других функций.

Если сайт перестал открываться после переноса, почта не приходит, часть пользователей попадает на старый сервер или изменения домена «никак не применятся», начинать диагностику почти всегда стоит именно с DNS.

Что такое DNS простыми словами

DNS — Domain Name System, система доменных имён. Её задача — находить техническую информацию, связанную с доменным именем.

Самый известный пример — преобразование имени сайта в IP-адрес. Когда пользователь вводит в браузере example.com, компьютеру необходимо узнать, к какому серверу подключаться. DNS может вернуть, например:

example.com.  300  IN  A     203.0.113.10
example.com.  300  IN  AAAA  2001:db8::10

Первая запись содержит IPv4-адрес, вторая — IPv6. После получения адреса браузер уже может устанавливать соединение с сервером.

Но DNS способен хранить гораздо больше информации: куда доставлять почту, какие DNS-серверы обслуживают зону, какие сервисы разрешены для домена и какие сертификаты могут быть для него выпущены.

Что происходит после ввода адреса сайта

Упрощённо процесс выглядит так:

  1. Пользователь вводит доменное имя в браузере.
  2. Операционная система проверяет локальный DNS-кеш.
  3. Если ответа нет, запрос отправляется DNS-резолверу.
  4. Резолвер ищет авторитетный источник информации о домене.
  5. Полученная DNS-запись возвращается устройству пользователя.
  6. Браузер подключается к найденному IP-адресу.
  7. Для HTTPS дополнительно выполняется TLS-соединение и проверяется сертификат.
  8. После этого отправляется HTTP-запрос к сайту.

Поэтому сообщение «сайт не открывается» ещё не означает проблему самого веб-сервера. Ошибка может появиться раньше — например, на этапе DNS.

Recursive resolver: кто выполняет поиск

Обычно устройство пользователя не обходит всю DNS-иерархию самостоятельно. Этим занимается recursive resolver — рекурсивный DNS-резолвер.

Это может быть DNS-сервис интернет-провайдера, корпоративный резолвер или публичный сервис. Резолвер получает вопрос вроде «какой A-адрес у example.com?» и возвращает готовый ответ.

Если нужная информация уже есть в кеше и её TTL ещё не закончился, резолвер может ответить сразу. Если записи нет, начинается поиск по DNS-иерархии.

Root DNS, TLD и authoritative DNS

DNS не хранится в единой глобальной базе. Система распределена по огромному количеству серверов.

Корневые DNS-серверы

Root-серверы находятся на верхнем уровне и помогают определить, где искать информацию о доменной зоне верхнего уровня — например, .ru, .com или .org.

TLD-серверы

Серверы доменной зоны верхнего уровня знают, какие авторитетные NS-серверы назначены конкретному домену.

Authoritative DNS

Авторитетный DNS-сервер хранит непосредственно DNS-зону домена и предоставляет окончательные ответы по её записям.

Именно поэтому при редактировании DNS важно понимать, какие NS сейчас назначены домену. Изменение записей в старой или неиспользуемой панели никак не повлияет на работу домена.

Что такое DNS-зона

DNS-зона — это набор записей, обслуживаемых авторитетными DNS-серверами для определённого пространства имён.

В типичной зоне можно увидеть записи A, AAAA, CNAME, MX, TXT, NS, SOA и CAA. У каждой записи есть своё назначение.

Важно не воспринимать DNS-зону как набор строк, которые можно без последствий добавлять «на всякий случай». Конфликтующие или устаревшие записи способны привести к трудноуловимым проблемам.

A-запись

A связывает имя с IPv4-адресом:

example.com.  300  IN  A  203.0.113.10

Если сайт переехал на новый сервер, но A-запись продолжает указывать на старый адрес, посетители будут попадать на старый сервер.

Проверить запись можно командой:

dig example.com A

AAAA-запись

AAAA выполняет ту же функцию для IPv6:

example.com.  300  IN  AAAA  2001:db8::10

Особенно неприятна ситуация, когда A-запись правильная, а AAAA осталась от старого сервера. Тогда сайт может нормально работать у пользователей IPv4 и одновременно плохо открываться у части пользователей IPv6.

dig example.com AAAA

Поэтому A и AAAA всегда стоит рассматривать вместе.

CNAME-запись

CNAME создаёт псевдоним одного DNS-имени для другого:

www.example.com.  300  IN  CNAME  example.com.

Это не прямое указание IP. Резолвер получает целевое имя и затем отдельно определяет его адрес.

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

MX-запись

MX определяет серверы, принимающие почту для домена.

example.com.  3600  IN  MX  10 mx1.example.net.
example.com.  3600  IN  MX  20 mx2.example.net.

Число перед сервером — приоритет. Чем меньше значение, тем выше предпочтение.

Важное правило: MX указывает на hostname, а не непосредственно на IP-адрес.

dig example.com MX

Самой MX-записи недостаточно для нормальной почтовой репутации. Для исходящей почты также важны SPF, DKIM, DMARC и корректный PTR.

TXT-записи

TXT позволяет публиковать произвольные текстовые данные. На практике этот тип используется для множества технических задач.

Наиболее известные примеры:

  • SPF;
  • подтверждение владения доменом;
  • параметры DKIM;
  • DMARC;
  • верификация внешних сервисов.

Получить TXT-записи:

dig example.com TXT

Наличие нескольких TXT само по себе нормально. Проблема начинается, если разные записи одной технологии противоречат друг другу — например, опубликовано несколько независимых SPF-политик.

NS-записи

NS — Name Server. Эти записи определяют авторитетные DNS-серверы домена.

example.com.  86400  IN  NS  ns1.provider.net.
example.com.  86400  IN  NS  ns2.provider.net.

Проверка NS особенно важна после переноса DNS к другому провайдеру.

dig example.com NS

Если в панели одного сервиса записи выглядят правильно, но домен продолжает работать по старой конфигурации, первым делом проверьте NS: возможно, редактируется вообще не та DNS-зона.

SOA-запись

SOA — Start of Authority содержит служебную информацию DNS-зоны.

В ней можно встретить:

  • основной сервер зоны;
  • контакт администратора;
  • serial;
  • refresh;
  • retry;
  • expire;
  • параметры кеширования.

Проверить:

dig example.com SOA

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

PTR и reverse DNS

Обычный DNS отвечает на вопрос «какой IP соответствует имени?». Reverse DNS решает обратную задачу: определяет имя, связанное с IP.

Для IPv4 используются специальные зоны in-addr.arpa, а результат обычно представлен PTR-записью.

dig -x 203.0.113.10

PTR особенно важен для почтовых серверов. Его обычно настраивает владелец IP-диапазона — хостинг или интернет-провайдер, а не обычный DNS-провайдер домена.

CAA-запись

CAA — Certification Authority Authorization позволяет владельцу домена указать, каким удостоверяющим центрам разрешено выпускать сертификаты.

Пример:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"

Неправильная CAA может стать причиной того, что автоматический выпуск или продление TLS-сертификата перестанет работать.

Что такое TTL

TTL — Time To Live определяет, сколько времени DNS-ответ может храниться в кеше.

Например:

example.com.  300  IN  A  203.0.113.10

Значение 300 означает 300 секунд, то есть пять минут.

Маленький TTL позволяет быстрее менять инфраструктуру, но увеличивает количество DNS-запросов. Большой TTL уменьшает нагрузку, однако старое значение может дольше оставаться у резолверов.

Перед запланированным переносом TTL иногда временно уменьшают заранее, а после стабилизации возвращают к нормальному значению.

Почему изменения DNS применяются не мгновенно

После изменения записи новая конфигурация уже может находиться на авторитетном DNS, но часть резолверов продолжит использовать старый ответ из кеша до окончания TTL.

Именно это часто называют DNS propagation.

При диагностике полезно сравнивать:

  • ответ авторитетного DNS;
  • ответ локального резолвера;
  • ответ нескольких публичных DNS-сервисов;
  • результат из другой сети или региона.

Если авторитетный сервер уже возвращает новое значение, а отдельный резолвер — старое, проблема обычно связана с кешированием.

Как проверить DNS через dig

dig — один из самых удобных инструментов для диагностики DNS.

Основные команды:

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS
dig example.com SOA

Краткий ответ:

dig +short example.com A

Проверка через конкретный DNS-резолвер:

dig @1.1.1.1 example.com A

Запрос к конкретному авторитетному серверу:

dig @ns1.provider.net example.com A

Так можно понять, находится ли проблема в самой зоне или только в кеше резолвера.

Как читать результат dig

В выводе обычно интересны несколько частей.

HEADER

Показывает статус DNS-запроса. Например, NOERROR означает, что запрос обработан без протокольной ошибки.

ANSWER SECTION

Здесь находится непосредственный ответ — например, A, AAAA или MX.

AUTHORITY SECTION

Может содержать сведения о серверах, авторитетных для зоны.

Query time и SERVER

Показывают время ответа и DNS-сервер, который его предоставил.

Важно: NOERROR ещё не гарантирует, что полученное значение правильное с точки зрения вашей инфраструктуры. DNS может технически работать идеально и при этом указывать на неправильный сервер.

Проверка через nslookup

На системах, где dig недоступен, можно использовать nslookup:

nslookup example.com

Для MX:

nslookup -type=mx example.com

Для NS:

nslookup -type=ns example.com

Для глубокой диагностики dig обычно удобнее, но nslookup подходит для быстрой проверки.

Типовые проблемы DNS

Домен указывает на старый IP

Проверьте A и AAAA. Иногда A уже изменена, а AAAA продолжает вести на старую инфраструктуру.

Редактируется неправильная DNS-зона

Сверьте NS домена с DNS-провайдером, в панели которого выполняются изменения.

Сайт работает у одних пользователей и не работает у других

Сравните IPv4 и IPv6, результаты разных резолверов и остаточный TTL.

После переноса сайта пропала почта

При миграции DNS легко перенести A-запись сайта и забыть MX, SPF, DKIM или DMARC.

Поддомен www работает иначе

example.com и www.example.com — разные DNS-имена. Проверяйте их отдельно.

NXDOMAIN

Статус NXDOMAIN означает, что запрошенного DNS-имени не существует по мнению отвечающего резолвера или авторитетной системы.

Причиной может быть опечатка, удалённая запись, неправильная делегация или ещё не завершённое изменение DNS.

Правильный порядок диагностики DNS

Если сайт или другой сервис перестал работать, удобно идти сверху вниз:

  1. Проверить регистрацию домена.
  2. Проверить назначенные NS-серверы.
  3. Проверить SOA зоны.
  4. Получить нужные A/AAAA/CNAME/MX/TXT.
  5. Сравнить ответы нескольких DNS-резолверов.
  6. Проверить TTL.
  7. Проверить, существует ли целевой IP или hostname.
  8. После DNS перейти к TCP, TLS и HTTP.

Такой подход значительно эффективнее случайной смены настроек.

Как проверить DNS в NexIP

Для быстрой проверки необязательно разбирать вывод терминала вручную. В DNS-инструменте NexIP можно указать домен и посмотреть обнаруженные записи в структурированном виде.

Проверяйте прежде всего:

  • A и AAAA — куда направлен сайт;
  • MX — куда поступает почта;
  • NS — кто обслуживает DNS;
  • TXT — SPF и другие политики;
  • согласованность записей между собой.

Если обнаружена проблема, полезно после исправления повторить проверку и сравнить результат с первоначальным состоянием.

DNS сам по себе не проверяет работу сайта

Правильный DNS означает только то, что имя разрешается в ожидаемые данные.

После DNS ещё могут возникнуть проблемы:

  • порт 80 или 443 закрыт;
  • сервер недоступен;
  • TLS-сертификат неправильный;
  • веб-сервер не настроен на нужный hostname;
  • приложение возвращает 500;
  • CDN или reverse proxy настроен неправильно.

Поэтому полноценная диагностика сайта должна идти по цепочке:

Domain
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
Application

Что важно запомнить

  • DNS — распределённая система сопоставления доменных имён с техническими данными.
  • A отвечает за IPv4, AAAA — за IPv6.
  • CNAME создаёт псевдоним имени.
  • MX определяет маршрутизацию входящей почты.
  • TXT используется для SPF, DKIM, DMARC, верификаций и других данных.
  • NS показывает авторитетные DNS-серверы.
  • SOA содержит служебные параметры зоны.
  • PTR используется для reverse DNS.
  • CAA ограничивает удостоверяющие центры.
  • TTL влияет на продолжительность кеширования.
  • После изменения DNS старый ответ может некоторое время сохраняться у резолверов.
  • При диагностике нужно отличать ошибку DNS от проблем TCP, TLS или HTTP.

FAQ

Сколько времени обновляется DNS?

Единого фиксированного срока нет. Всё зависит от TTL предыдущих записей, кешей резолверов и характера изменения. Авторитетный сервер может показывать новое значение практически сразу, тогда как отдельные резолверы ещё некоторое время используют старое.

Почему сайт открывается у меня, но не открывается у другого человека?

Причиной может быть DNS-кеш, различие IPv4 и IPv6, сетевой маршрут, блокировка или проблема самого сервера. Сравните DNS-ответы из разных сетей и отдельно проверьте A и AAAA.

Можно ли иметь несколько A-записей?

Да. Несколько A-записей для одного имени допустимы и могут использоваться для распределения трафика. Но каждый опубликованный адрес должен реально обслуживать нужный сайт.

Нужна ли AAAA-запись, если IPv6 не настроен?

Нет. Публиковать AAAA только ради наличия IPv6 не стоит. Если сервер не принимает IPv6-соединения, неверная AAAA может ухудшить доступность сайта.

Почему после смены A-записи я всё ещё попадаю на старый сервер?

Наиболее частые причины — DNS-кеш, неправильные NS, оставшаяся AAAA-запись, CDN или локальное кеширование. Сравните ответ авторитетного DNS с результатом используемого резолвера.

Может ли неправильный DNS сломать почту?

Да. Ошибки MX способны полностью нарушить получение писем, а проблемы SPF, DKIM, DMARC и PTR могут ухудшить доставляемость исходящей почты.

Что лучше использовать для проверки — dig или NexIP?

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

Спасибо, что дочитали

В журнале NexIP есть другие полезные разборы и исследования.

NEXIP / ИНСТРУМЕНТЫ

Проверьте на практике

Проверьте параметры из статьи с помощью инструментов NexIP.

NEXIP / ДИАГНОСТИКА

Перейдите от теории к проверке

Проверьте сайт, домен или сетевые параметры с помощью инструментов NexIP.

Открыть диагностику

Читайте дальше

Материалы по теме

FAQ

Частые вопросы

Можно ли выполнить эту проверку самостоятельно?

Да. В материале описана безопасная последовательность действий и указаны подходящие инструменты NexIP. Для изменения настроек сервера или DNS могут понадобиться доступы к панели провайдера.

Когда нужно повторить проверку?

Повторите её после внесения изменений и завершения времени обновления. Сохраните исходный результат, чтобы увидеть, что именно изменилось.

Вернуться в базу знаний