Руководство по DNS

DNS (Domain Name System) — это распределённый справочник, который связывает доменные имена с сетевыми адресами и сервисами. Когда вы вводите в браузере example.com, ваш компьютер не знает, где находится сервер с этим сайтом. Он спрашивает у DNS-серверов: «Какой IP-адрес у example.com?» И получает ответ. Без DNS мы бы запоминали сайты по наборам цифр вроде 93.184.216.34. Звучит не очень, правда?

Но DNS — это не просто перевод имён в IP-адреса. Это целая распределённая иерархическая система, которая управляет маршрутизацией почты, проверкой подлинности доменов, балансировкой нагрузки и многим другим.

В этой статье мы подробно разберём:

Что такое DNS и как он устроен (иерархия, типы серверов, зоны).
Основные типы DNS-записей и их назначение.
Как управлять DNS: где и как редактировать записи.
Пошаговая настройка DNS для нового домена и поддоменов.
Настройка DNS для работы с внешними сервисами (почта, CDN, S3).
Автоматизация управления DNS через API.
Типичные ошибки при настройке DNS и как их избежать.
Инструменты для диагностики DNS (dig, nslookup, whois).

Наша цель — чтобы после прочтения вы чувствовали себя уверенно при работе с любой DNS-панелью и понимали, что происходит «под капотом».

1. Что такое DNS и как он устроен

1.1 Основная задача

Основная задача DNS — преобразование доменных имён (например, site.ru) в IP-адреса (например, 95.163.120.15), понятные компьютерам. Это называется разрешением имени (name resolution).

Но DNS также может:

Указывать, какой сервер принимает почту для домена (MX-записи).
Перенаправлять один домен на другой (CNAME).
Проверять, что домен принадлежит вам (TXT-записи для подтверждения прав).
Распределять нагрузку между несколькими серверами (A-записи с разными IP или SRV-записи).

1.2 Иерархическая структура DNS

DNS — это распределённая база данных, организованная в виде дерева. Вся система состоит из множества серверов, каждый из которых отвечает за свою часть этого дерева.

Корневые серверы (Root Servers) — вершина иерархии. Их 13 логических кластеров по всему миру. Они хранят информацию о том, где находятся серверы для каждой зоны верхнего уровня (TLD), таких как .ru, .com, .org, .net. Корневые серверы управляются ICANN.
Серверы верхнего уровня (TLD Servers) — отвечают за конкретные доменные зоны. Например, серверы зоны .ru знают, где находятся DNS-серверы для домена site.ru (если он зарегистрирован в этой зоне). Их делегирует корневой сервер.
Авторитативные DNS-серверы — это главные серверы для конкретного домена (например, site.ru). Именно они хранят все DNS-записи домена: A, MX, CNAME, TXT и другие. Регистратор домена указывает на эти серверы через NS-записи в зоне.
Рекурсивные DNS-резолверы — серверы, которые «ходят» по цепочке от корневых до авторитативных серверов и возвращают конечный IP-адрес клиенту. Обычно их предоставляют интернет-провайдеры, Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) и другие.

1.3 Как работает запрос к DNS (процесс разрешения)

Представьте, что пользователь ввёл в браузере www.site.ru. Происходит следующая цепочка:

Браузер проверяет локальный кеш — не запрашивал ли он этот домен недавно. Если есть, использует сохранённый IP.
Если в кеше нет, он обращается к системному DNS-резолверу (обычно к DNS-серверу провайдера или указанному в настройках сети).
Рекурсивный резолвер начинает поиск:
- Спрашивает у корневого сервера: «Где серверы для зоны .ru?»
- Получает адреса серверов .ru.
- Спрашивает у сервера .ru: «Где авторитативные серверы для site.ru?»
- Получает адреса серверов site.ru.
- Спрашивает у сервера site.ru: «Какой IP у www.site.ru?»
- Получает IP-адрес.
Резолвер возвращает IP-адрес браузеру.
Браузер устанавливает соединение по полученному IP и загружает сайт.

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

1.4 Зона и файл зоны

Зона — это логическая часть DNS-пространства, которая администрируется как единое целое. Например, зона site.ru содержит все записи для этого домена.

Файл зоны — это текстовый файл, который хранит DNS-записи в стандартном формате. Он содержит SOA-запись (начало зоны), NS-записи (указывают на авторитативные серверы) и все остальные записи.

Пример простого файла зоны:

$TTL 3600
site.ru. IN SOA ns1.dns-provider.com. admin.site.ru. (
    2025011501   ; серийный номер (серийный номер формата ГГГГММДДNN)
    7200         ; частота обновления (refresh)
    3600         ; частота повтора при ошибке (retry)
    1209600      ; срок действия кеша (expire)
    3600         ; минимальный TTL (min TTL)
)

site.ru. IN NS ns1.dns-provider.com.
site.ru. IN NS ns2.dns-provider.com.

site.ru. IN A 95.163.120.15
www.site.ru. IN CNAME site.ru.
mail.site.ru. IN A 95.163.120.15
site.ru. IN MX 10 mail.site.ru.

Пояснения:

$TTL — время жизни записей по умолчанию (в секундах).
SOA — Start of Authority, содержит информацию о зоне: имя сервера, email администратора, серийный номер, тайминги.
NS — запись, указывающая на авторитативные DNS-серверы для этой зоны.
A — запись, связывающая имя с IPv4-адресом.
CNAME — каноническое имя, псевдоним для другого имени.
MX — почтовый обменник, указывает сервер, принимающий почту для домена.

Это классический формат, но в современных панелях управления (например, cPanel, Plesk или панелях регистраторов) вы видите графический интерфейс, который генерирует файл зоны за кулисами. В панелях SOA не редактируется вручную!

2. Основные типы DNS-записей и их назначение

Современный DNS поддерживает более 40 типов записей. Мы рассмотрим самые распространённые.

2.1 A-запись (IPv4)

Связывает доменное имя с IPv4-адресом. Это самая используемая запись.

Пример:

site.ru. 3600 IN A 95.163.120.15

Здесь 3600 — TTL (время жизни кеша в секундах).

Когда использовать: всегда, когда ваш ресурс (сайт, API, сервер) доступен по IPv4. Сейчас это почти все случаи, кроме совсем новых проектов, у которых может быть только IPv6.

2.2 AAAA-запись (IPv6)

Аналогична A, но для IPv6-адресов.

Пример:

site.ru. 3600 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Когда использовать: если ваш сервер имеет IPv6-адрес и вы хотите, чтобы пользователи с IPv6 подключались напрямую, без двойного перевода. Рекомендуется использовать для повышения доступности и скорости.

2.3 CNAME-запись (Canonical Name)

Создаёт псевдоним (алиас) для другого доменного имени. CNAME указывает на имя, а не на IP.

Пример:

www.site.ru. IN CNAME site.ru.
blog.site.ru. IN CNAME site.ru.

Тогда запрос к www.site.ru и blog.site.ru будет разрешаться в тот же IP, что и site.ru.

Важные ограничения:

CNAME-запись не может существовать вместе с другими записями (A, MX, TXT) для того же имени.
CNAME нельзя использовать для корневого домена (@) — только для поддоменов.
Не стоит цепочить CNAME (CNAME на CNAME) — это замедляет резолвинг.

Когда использовать: для поддоменов, которые должны указывать на основной домен или на внешний сервис (например, static.site.ru на CDN).

2.4 MX-запись (Mail Exchange)

Указывает почтовый сервер, который принимает электронную почту для домена. Может быть несколько MX-записей с разными приоритетами (чем меньше число, тем выше приоритет).

Пример:

site.ru. IN MX 10 mail.site.ru.
site.ru. IN MX 20 backup-mail.site.ru.

Здесь mail.site.ru — основной сервер (приоритет 10), backup-mail.site.ru — резервный (приоритет 20). Если основной недоступен, почта будет направлена на резервный.

Когда использовать: всегда, если для домена настроена почта (любой почтовый сервис: собственный, Яндекс, Google Workspace, Mail.ru).

2.5 TXT-запись (Text)

Хранит произвольный текст. Часто используется для:

SPF (Sender Policy Framework) — указывает, какие серверы могут отправлять почту от имени домена. Защищает от подделки отправителя (спама).
DKIM (DomainKeys Identified Mail) — содержит публичный ключ для проверки подписи писем.
DMARC — политика обработки писем, не прошедших проверку SPF/DKIM.
Верификация домена для сервисов (например, Google Search Console, Яндекс.Вебмастер, подтверждение домена в сервисах).

🛠 Практический инструмент: Чтобы не собирать SPF‑строку вручную и не превысить лимит в 10 DNS‑запросов, используйте наш генератор SPF и DMARC. Он подскажет, если лимит будет превышен, и сразу выдаст готовые TXT‑записи.

Пример SPF-записи:

site.ru. IN TXT "v=spf1 mx a include:_spf.google.com ~all"

Это разрешает отправку с MX-серверов, с A-записи, а также включает SPF Google Workspace.

Когда использовать: обязательно для почтовых доменов (SPF, DKIM, DMARC). Также для подтверждения прав на домен в различных сервисах.

2.6 NS-запись (Name Server)

Указывает авторитативные DNS-серверы для домена. Эти записи хранятся на стороне регистратора и в зоне домена. Делегирование домена на DNS-серверы происходит через NS-записи.

Пример:

site.ru. IN NS ns1.dns-provider.com.
site.ru. IN NS ns2.dns-provider.com.

Когда использовать: при переносе домена на другой DNS-хостинг (например, с DNS регистратора на Cloudflare). Менять NS-записи на стороне регистратора.

2.7 SRV-запись (Service)

Указывает сервер для конкретного сервиса (например, SIP, XMPP, LDAP). SRV-записи содержат домен, порт, приоритет и вес.

Пример для сервиса SIP:

_sip._tcp.site.ru. IN SRV 10 5 5060 sipserver.site.ru.

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

2.8 PTR-запись (Pointer)

Обратная запись — преобразует IP-адрес в доменное имя (обратное разрешение). Используется в основном для почты.

Пример:

15.120.163.95.in-addr.arpa. IN PTR site.ru.

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

2.9 SOA-запись (Start of Authority)

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

Не редактируется напрямую в панелях, но знание о ней полезно для диагностики.

3. Управление DNS: где и как редактировать записи

Управление DNS-записями обычно происходит в одном из трёх мест:

Панель управления вашего регистратора (хостинг-провайдера) — например, в личном кабинете REG.RU, NIC.RU, TimeWeb, Beget и т.д.
Сторонний DNS-хостинг — Cloudflare, DNSimple, Yandex DNS, Amazon Route 53 и другие. Это часто удобнее, особенно если вам нужно больше контроля или более высокая отказоустойчивость.
Собственный DNS-сервер — если вы большой провайдер и хотите сами управлять всей инфраструктурой (на практике редкий случай для обычных веб-мастеров).

3.1 Где находятся DNS-записи

По умолчанию DNS-записи обслуживаются DNS-серверами, указанными у регистратора. Если вы ничего не меняли, записи хранятся на DNS-серверах хостинг-провайдера или регистратора.

Чтобы проверить, какие NS-серверы используются для вашего домена, выполните:

Bash

whois site.ru | grep -i "name server"

whois site.ru | grep -i "name server"

Или используйте онлайн-инструменты.

3.2 Как изменить DNS-записи

Шаг 1: Войдите в панель управления вашим доменом (обычно это панель регистратора).
Шаг 2: Найдите раздел «Управление DNS», «DNS-записи» или «Зона DNS».
Шаг 3: Добавьте, отредактируйте или удалите нужные записи.
Шаг 4: Сохраните изменения.

После сохранения изменения вступают в силу в течение времени, указанного в TTL (время жизни). По умолчанию это от 5 минут до нескольких часов. Вы можете уменьшить TTL заранее (например, за несколько часов до плановых изменений), чтобы новые записи распространились быстрее.

3.3 Использование сторонних DNS-серверов (Cloudflare, Yandex DNS)

Если вы переносите домен на внешнюю DNS-площадку, вам нужно:

Зарегистрироваться в сервисе (например, Cloudflare).
Добавить свой домен в панель управления сервиса.
Сервис предоставит вам пару или более NS-адресов (например, ns1.cloudflare.com, ns2.cloudflare.com).
В панели регистратора заменить текущие NS-серверы на те, что выдал сервис.
Дождаться делегирования (обычно до 24-48 часов, но часто быстрее).
Все изменения записей теперь делать уже в панели сервиса, а не у регистратора.

Почему это делают:

Удобное управление записями.
Дополнительные функции (защита от DDoS, аналитика, бесплатные SSL-сертификаты).
Ускорение DNS за счёт глобальной сети серверов.

3.4 Использование API для автоматизации

Многие DNS-провайдеры предоставляют API для программного управления записями. Это полезно в CI/CD-пайплайнах, при автоматическом добавлении поддоменов, или при создании динамического DNS.

Пример (REST API Cloudflare):

Bash

# Добавление A-записи через API
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" \
     -H "Authorization: Bearer YOUR_API_TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"type":"A","name":"sub.domain.com","content":"192.168.1.1","ttl":3600}'

# Добавление A-записи через API
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" \
     -H "Authorization: Bearer YOUR_API_TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"type":"A","name":"sub.domain.com","content":"192.168.1.1","ttl":3600}'

Документацию по API можно найти у конкретного провайдера (Cloudflare, AWS Route 53, DigitalOcean и др.).

3.5 Автоматическое обновление A-записи (DDNS)

Динамический DNS (DDNS) нужен, когда IP-адрес сервера меняется (например, домашний сервер с динамическим IP). Клиент на сервере периодически обновляет A-запись через API провайдера.

Популярные DDNS-сервисы: DuckDNS, No-IP, Dyndns, Cloudflare DDNS.

Простой скрипт для обновления через Cloudflare:

Bash

#!/usr/bin/env bash
set -euo pipefail

API_TOKEN="${CLOUDFLARE_API_TOKEN:?Установите переменную CLOUDFLARE_API_TOKEN}"
ZONE_ID="${CLOUDFLARE_ZONE_ID:?Установите переменную CLOUDFLARE_ZONE_ID}"
RECORD_NAME="${CLOUDFLARE_RECORD_NAME:?Установите переменную CLOUDFLARE_RECORD_NAME}"
TTL=300

CURRENT_IP=$(curl -s http://ipv4.icanhazip.com)
if [ -z "$CURRENT_IP" ]; then
  echo "Не удалось получить текущий IP" >&2
  exit 1
fi

# Получаем ID записи
RESPONSE=$(curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?name=$RECORD_NAME" \
  -H "Authorization: Bearer $API_TOKEN")

RECORD_ID=$(echo "$RESPONSE" | jq -r '.result[0].id // empty')
if [ -z "$RECORD_ID" ]; then
  echo "Запись $RECORD_NAME не найдена в зоне $ZONE_ID" >&2
  exit 1
fi

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"A\",\"name\":\"$RECORD_NAME\",\"content\":\"$CURRENT_IP\",\"ttl\":$TTL}" > /dev/null

echo "DDNS обновлён: $RECORD_NAME -> $CURRENT_IP"

#!/usr/bin/env bash
set -euo pipefail

API_TOKEN="${CLOUDFLARE_API_TOKEN:?Установите переменную CLOUDFLARE_API_TOKEN}"
ZONE_ID="${CLOUDFLARE_ZONE_ID:?Установите переменную CLOUDFLARE_ZONE_ID}"
RECORD_NAME="${CLOUDFLARE_RECORD_NAME:?Установите переменную CLOUDFLARE_RECORD_NAME}"
TTL=300

CURRENT_IP=$(curl -s http://ipv4.icanhazip.com)
if [ -z "$CURRENT_IP" ]; then
  echo "Не удалось получить текущий IP" >&2
  exit 1
fi

# Получаем ID записи
RESPONSE=$(curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?name=$RECORD_NAME" \
  -H "Authorization: Bearer $API_TOKEN")

RECORD_ID=$(echo "$RESPONSE" | jq -r '.result[0].id // empty')
if [ -z "$RECORD_ID" ]; then
  echo "Запись $RECORD_NAME не найдена в зоне $ZONE_ID" >&2
  exit 1
fi

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"A\",\"name\":\"$RECORD_NAME\",\"content\":\"$CURRENT_IP\",\"ttl\":$TTL}" > /dev/null

echo "DDNS обновлён: $RECORD_NAME -> $CURRENT_IP"

ВАЖНО: для проверки, что запись вообще нашлась, используйте :

if [ -z "$RECORD_ID" ]; then echo "Запись не найдена"; exit 1; fi

Храните токены в переменных окружения, а не в скрипте!

4. Пошаговая настройка DNS для нового домена

Давайте пройдём полный путь: от регистрации домена до настройки записей для работающего сайта и почты.

4.1 Сценарий: настраиваем домен `mysite.com`

Предположим, у вас есть:

Домен mysite.com, зарегистрированный у регистратора.
Сервер с веб-приложением на IP-адресе 95.163.120.15.
Почтовый сервис на Яндексе или Google Workspace (выделим отдельно).

Шаг 1: Проверяем делегирование домена.
Выясняем, на какие NS-серверы делегирован домен. Если вы хотите управлять записями в панели регистратора — убедитесь, что там указаны их NS-серверы. Если планируете использовать Cloudflare — меняем NS-серверы у регистратора на ns1.cloudflare.com и ns2.cloudflare.com.

Шаг 2: Создаём основную A-запись.
Добавляем запись:

@ 3600 A 95.163.120.15

Или в графическом интерфейсе: имя записи оставляем пустым (или указываем @), тип A, значение 95.163.120.15, TTL 3600.

Шаг 3: Создаём запись для www.

www 3600 A 95.163.120.15

Либо можно через CNAME:

www 3600 CNAME mysite.com.

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

Шаг 4: Настраиваем почту (например, Яндекс.Почта для домена).
Яндекс даёт инструкцию с записями:

MX: @ MX 10 mx.yandex.ru.
TXT (SPF): @ TXT "v=spf1 include:_spf.yandex.net ~all"
Возможно, DKIM и DMARC (зависит от сервиса).

Добавляем всё это.

Шаг 5: Проверяем, что всё работает.
Ждём время TTL (может быть до 10 минут, если TTL небольшой) и проверяем через dig или онлайн-сервисы.

Шаг 6: Дополнительные поддомены.
Если нужно, добавляем записи для api.mysite.com, admin.mysite.com, test.mysite.com и т.д. Все они могут указывать на тот же сервер или на разные.

4.2 Настройка DNS для внешнего сервиса (S3, CDN)

Часто статику (картинки, CSS, JS) выносят на CDN или в S3-хранилище. Например, Amazon S3 + CloudFront.

Для S3 в Amazon:

Создаёте бакет static.mysite.com в регионе.
Настраиваете бакет на хостинг статики.
Добавляете CNAME-запись:

static.mysite.com CNAME static.mysite.com.s3-website-region.amazonaws.com.

Для Cloudflare или других CDN:

Подключаете домен к CDN-сервису.
Они предоставляют CNAME-запись:

static.mysite.com CNAME static.mysite.com.cdn.cloudflare.com.

Или используете A-запись с их Anycast-IP (редко).

4.3 Настройка DNS для балансировки нагрузки

Если у вас несколько серверов для одного домена, можно использовать несколько A-записей с одинаковым именем. DNS будет возвращать их в случайном порядке (Round Robin), распределяя нагрузку.

@ 3600 A 95.163.120.15
@ 3600 A 95.163.120.16
@ 3600 A 95.163.120.17

Более сложный способ — использовать SRV-записи или специальные DNS-провайдеры с поддержкой гео-балансировки и Health Checks (например, AWS Route 53, Cloudflare Load Balancing).

⚠️ Round‑Robin DNS — это не полноценный балансировщик нагрузки. Он не проверяет здоровье серверов (health check), не учитывает задержку и не защищает от отказов. Для продакшена используйте специализированные решения (Cloudflare Load Balancing, AWS Route 53 Health Checks, HAProxy/Nginx upstream).

4.4 Настройка DNS для мультирегиональных проектов

Используйте GeoDNS — маршрутизация запросов в зависимости от геолокации пользователя. Например, европейских пользователей направлять на сервер в Европе, а азиатских — в Азии.

Это реализуется через расширения DNS (например, EDNS Client Subnet) или через сторонние сервисы (Cloudflare, AWS Route 53, Yandex DNS). Для этого нужно создать несколько A-записей с одинаковым именем, но с разными политиками маршрутизации. В панелях типа AWS Route 53 это настраивается через политики маршрутизации: Geolocation Routing, Latency Routing, Weighted Routing.

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

5. Типичные ошибки при настройке DNS и как их избежать

5.1 Ошибка: пропущенная точка в конце домена

В DNS-записях (особенно в текстовых файлах зон) очень важно ставить точку в конце полного доменного имени. Если её нет — запись может быть интерпретирована как относительная, и DNS-сервер добавит к ней текущее имя зоны.

Пример ошибки:

site.ru. IN MX 10 mail.site.ru

Правильно:

site.ru. IN MX 10 mail.site.ru.

Или в некоторых интерфейсах просто mail (без точки).

В современных панелях эта проблема решена, но при ручном редактировании файла зоны или работе с API — всегда помните про точку.

Где это реально критично: API (Cloudflare, Route 53), файлы зон BIND, скрипты генерации.

5.2 Ошибка: использование CNAME для корневого домена

CNAME-запись для корневого домена (@) запрещена стандартами DNS. Если вы попытаетесь создать @ CNAME, сервер откажется применять изменения или выдаст ошибку.

Правильное решение: для корневого домена всегда используйте A- или AAAA-записи.

5.3 Ошибка: слишком маленький TTL

TTL (Time To Live) указывает время кеширования записи у DNS-резолверов. Если установить TTL слишком маленьким (например, 60 секунд), каждый раз, когда пользователь заходит на сайт, его браузер будет делать новый DNS-запрос. Это может увеличить нагрузку на ваши DNS-серверы и немного замедлить загрузку.

Рекомендация: для стабильных записей (A, MX) ставьте TTL от 3600 (1 час) до 86400 (24 часа). Перед плановыми изменениями уменьшите TTL до 300–600 секунд за 1–2 дня до изменения, чтобы новые записи распространились быстрее.

5.4 Ошибка: неправильно настроенная SPF-запись

Если у вас несколько почтовых сервисов (например, свой сервер + Google Workspace), SPF-запись должна перечислять все разрешённые источники. Если SPF слишком строгий (заканчивается на -all вместо ~all), некоторые легитимные письма могут попасть в спам.

Пример SPF с несколькими сервисами:

v=spf1 include:_spf.google.com include:spf.mail.ru mx ~all

⚠️ Лимит SPF: в одной SPF‑записи допускается не более 10 DNS‑запросов (включая вложенные include). Если нужно больше — создавайте промежуточные TXT‑записи вида _spf.mysite.com, где будут собраны части, и ссылайтесь на них через include:_spf.mysite.com.

5.5 Ошибка: забыли про обратные записи (PTR)

Для почтовых серверов критически важно наличие PTR-записи, которая указывает с IP на домен. Если PTR отсутствует или не совпадает с именем сервера в почтовом заголовке, многие почтовые системы будут отбрасывать письма или отправлять их в спам.

PTR-записи настраиваются не в вашей DNS-панели, а у провайдера, который выдал вам IP-адрес. Поэтому обязательно проверьте, что:

PTR указывает на ваш домен (например, server.mysite.com).
Это имя совпадает с HELO/EHLO в настройках почтового сервера.
Для IPv6 также настраивается PTR.
В панели VPS/облака: поле «Reverse DNS / PTR» рядом с IP. Если нет — тикет в поддержку с просьбой установить PTR на server.mysite.com.

5.6 Ошибка: не указаны NS-записи на новый DNS-хост

При переносе DNS на внешнего провайдера (например, Cloudflare) нужно изменить NS-записи в панели регистратора. Если забыть это сделать, изменения записей в Cloudflare не будут применяться, потому что домен всё ещё делегирован на старые NS-серверы.

Решение: Дождаться, пока WHOIS покажет новые NS-серверы. Процесс может занять до 48 часов, но обычно быстрее.

5.7 Ошибка: конфликт DNS-записей (например, CNAME + MX)

CNAME-запись не может существовать вместе с другими типами записей для одного и того же имени. Если вы создали www CNAME, то не сможете создать для www A-запись, TXT или MX. Это стандартное ограничение протокола.

Решение: используйте A-запись для тех поддоменов, где нужны другие записи (например, www часто используется как основной адрес сайта, и для него лучше задать A-запись). CNAME применяйте для служебных поддоменов без других типов записей.

5.8 Ошибка: не учли кеширование после изменений

Вы изменили DNS, но ничего не произошло? Скорее всего, вы или ваши пользователи видите закешированную версию. Кешируют записи и браузеры, и ОС, и DNS-резолверы провайдеров.

Как ускорить распространение:

Заранее уменьшите TTL для изменяемых записей.
Используйте инструменты для сброса кеша (например, ipconfig /flushdns в Windows, sudo dscacheutil -flushcache на macOS).
Проверяйте через онлайн-инструменты, которые не используют кеш (например, на сайте DNS Checker).
Если изменения не приходят даже через 24 часа — возможно, вы не изменили NS-серверы или не увеличили серийный номер SOA (при ручном редактировании файла зоны).

6. Инструменты для диагностики DNS

6.1 dig (Domain Information Groper)

dig — самый мощный инструмент для запросов к DNS. Устанавливается в составе пакета dnsutils в Linux.

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

Bash

# Запрос A-записи для домена с указанием DNS-сервера (8.8.8.8)
dig @8.8.8.8 site.ru A

# Запрос MX-записи
dig site.ru MX

# Запрос NS-записей
dig site.ru NS

# Обратное разрешение (PTR)
dig -x 95.163.120.15

# Трассировка полного пути разрешения (+trace)
dig +trace site.ru

# Вывод в компактном виде (только IP)
dig +short site.ru A

# Запрос A-записи для домена с указанием DNS-сервера (8.8.8.8)
dig @8.8.8.8 site.ru A

# Запрос MX-записи
dig site.ru MX

# Запрос NS-записей
dig site.ru NS

# Обратное разрешение (PTR)
dig -x 95.163.120.15

# Трассировка полного пути разрешения (+trace)
dig +trace site.ru

# Вывод в компактном виде (только IP)
dig +short site.ru A

6.2 nslookup

nslookup — более простой и доступный инструмент, есть в Windows и Linux.

Bash

# Запрос A-записи
nslookup site.ru

# Запрос MX-записей
nslookup -type=MX site.ru

# Запрос с указанием сервера
nslookup site.ru 8.8.8.8

# Запрос A-записи
nslookup site.ru

# Запрос MX-записей
nslookup -type=MX site.ru

# Запрос с указанием сервера
nslookup site.ru 8.8.8.8

6.3 whois

whois — показывает информацию о домене, включая NS-серверы, контактные данные, дату регистрации и истечения.

Bash

whois site.ru

whois site.ru

Для Linux админов: host site.ru — простая альтернатива nslookup. А getent hosts site.ru — показывает, как ОС видит резолвинг (полезно при проверке /etc/hosts).

6.4 Онлайн-инструменты

DNS Checker — проверяет, как распространяется DNS-запись в разных частях мира. Позволяет выбрать любой из множества DNS-серверов по всему миру.
MX Toolbox — проверяет MX-записи, SPF, DKIM, DMARC, а также чёрные списки.
IntoDNS — комплексная проверка DNS-конфигурации на ошибки.
ViewDNS.info — набор инструментов для диагностики DNS (включая историю изменений).

7. Заключение

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

Ключевые выводы:

DNS преобразует доменные имена в IP-адреса и выполняет много других задач (почта, безопасность, балансировка).
Иерархическая структура включает корневые серверы, TLD-серверы и авторитативные серверы.
Основные типы записей: A (IPv4), AAAA (IPv6), CNAME (псевдоним), MX (почта), TXT (SPF, DKIM, DMARC, верификация).
Управление DNS обычно происходит через панель регистратора или стороннего провайдера (Cloudflare, Yandex DNS).
При настройке DNS для почты обязательно добавляйте SPF, DKIM, DMARC и PTR-записи (у провайдера IP).
Типичные ошибки: точка в конце, CNAME на корневой домен, слишком большой/маленький TTL, неверные SPF-записи, забытые NS-изменения.
Для диагностики используйте dig, nslookup, whois и онлайн-инструменты.
Всегда проверяйте изменения через dig +trace или онлайн-чекеры, чтобы убедиться, что записи распространились корректно.

Руководство по DNS: управление, настройка и типичные ошибки

1. Что такое DNS и как он устроен

1.1 Основная задача

1.2 Иерархическая структура DNS

1.3 Как работает запрос к DNS (процесс разрешения)

1.4 Зона и файл зоны

2. Основные типы DNS-записей и их назначение

2.1 A-запись (IPv4)

2.2 AAAA-запись (IPv6)

2.3 CNAME-запись (Canonical Name)

2.4 MX-запись (Mail Exchange)

2.5 TXT-запись (Text)

2.6 NS-запись (Name Server)

2.7 SRV-запись (Service)

2.8 PTR-запись (Pointer)

2.9 SOA-запись (Start of Authority)

3. Управление DNS: где и как редактировать записи

3.1 Где находятся DNS-записи

3.2 Как изменить DNS-записи

3.3 Использование сторонних DNS-серверов (Cloudflare, Yandex DNS)

3.4 Использование API для автоматизации

3.5 Автоматическое обновление A-записи (DDNS)

4. Пошаговая настройка DNS для нового домена

4.1 Сценарий: настраиваем домен mysite.com

4.2 Настройка DNS для внешнего сервиса (S3, CDN)

4.3 Настройка DNS для балансировки нагрузки

4.4 Настройка DNS для мультирегиональных проектов

5. Типичные ошибки при настройке DNS и как их избежать

5.1 Ошибка: пропущенная точка в конце домена

5.2 Ошибка: использование CNAME для корневого домена

5.3 Ошибка: слишком маленький TTL

5.4 Ошибка: неправильно настроенная SPF-запись

5.5 Ошибка: забыли про обратные записи (PTR)

5.6 Ошибка: не указаны NS-записи на новый DNS-хост

5.7 Ошибка: конфликт DNS-записей (например, CNAME + MX)

5.8 Ошибка: не учли кеширование после изменений

6. Инструменты для диагностики DNS

6.1 dig (Domain Information Groper)

6.2 nslookup

6.3 whois

6.4 Онлайн-инструменты

7. Заключение

Инструменты

4.1 Сценарий: настраиваем домен `mysite.com`