DNS

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

Например, приложение обращается к имени:

example.com

DNS может вернуть IPv4-адрес:

93.184.216.34

После этого клиент устанавливает сетевое соединение с полученным адресом.

DNS используется не только для поиска IP-адресов. С его помощью также публикуются:

Основной транспорт DNS — UDP, обычно через порт 53. TCP также используется через порт 53, например для крупных ответов, передачи зон и в ситуациях, когда UDP-ответ оказался усечённым.

Содержание

Как работает DNS

Основные компоненты DNS

В разрешении доменного имени участвуют несколько компонентов.

Stub resolver

Stub resolver — часть операционной системы или системной библиотеки, через которую приложения выполняют DNS-запросы.

Приложение обычно не обходит DNS-серверы самостоятельно. Оно передаёт запрос системному резолверу:

Какой IP-адрес соответствует www.example.com?

Адрес используемого DNS-сервера может быть получен:

Рекурсивный DNS-сервер

Рекурсивный резолвер получает запрос от клиента, ищет ответ в кэше или проходит по DNS-иерархии.

Примеры публичных рекурсивных DNS-сервисов:

1.1.1.1
8.8.8.8
9.9.9.9

Использовать публичный резолвер необязательно: в организации или домашней сети может работать собственный сервер.

Авторитетный DNS-сервер

Авторитетный сервер хранит официальные данные конкретной DNS-зоны и отвечает за неё.

Например, авторитетные серверы зоны example.com могут хранить записи:

example.com.      A       192.0.2.10
www.example.com.  CNAME   example.com.
example.com.      MX      10 mail.example.com.

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

Кэш

DNS-ответы временно сохраняются:

Продолжительность хранения записи определяется её TTL.

Иерархия DNS

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

Для имени:

api.shop.example.com

иерархия выглядит так:

. → com → example → shop → api

Корневая зона

Верхняя точка DNS-дерева обозначается точкой:

.

Полное доменное имя технически заканчивается точкой:

www.example.com.

Такое имя называется FQDN — Fully Qualified Domain Name.

В пользовательских программах завершающую точку обычно опускают:

www.example.com

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

Домены верхнего уровня

Следующий уровень — TLD (Top-Level Domain):

.com
.org
.net
.dev
.io

Существуют также национальные доменные зоны.

Серверы TLD знают, какие авторитетные DNS-серверы отвечают за зарегистрированные домены внутри соответствующей зоны.

Домен второго уровня

В имени:

example.com

example — домен второго уровня внутри зоны .com.

Владелец домена может настраивать его DNS-зону и создавать поддомены.

Поддомены

Примеры поддоменов:

www.example.com
api.example.com
mail.example.com
shop.example.com

Поддомен может быть обычным именем внутри текущей зоны или отдельной делегированной зоной.

Например, владелец example.com может делегировать:

dev.example.com

другим DNS-серверам.

Как выполняется DNS-разрешение

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

www.example.com

Упрощённая последовательность:

  1. Приложение проверяет собственный DNS-кэш.
  2. Операционная система проверяет системный кэш и локальные правила.
  3. Запрос отправляется рекурсивному DNS-серверу.
  4. Рекурсивный сервер проверяет свой кэш.
  5. Если ответа нет, он обращается к корневому серверу.
  6. Корневой сервер указывает серверы зоны .com.
  7. Сервер .com указывает авторитетные серверы example.com.
  8. Авторитетный сервер возвращает запись www.example.com.
  9. Рекурсивный сервер кэширует результат.
  10. Клиент получает ответ.

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

Рекурсивные и итеративные запросы

Рекурсивный запрос

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

Условно:

Найди для меня IP-адрес www.example.com.

Обычный клиент чаще всего отправляет рекурсивный запрос настроенному резолверу.

Итеративный запрос

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

Условно:

Я не знаю точного адреса, но спроси серверы зоны .com.

Так рекурсивный резолвер перемещается по DNS-иерархии.

DNS-зона

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

Зона обычно содержит:

Зона и домен — связанные, но не полностью одинаковые понятия.

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

Если dev.example.com делегирован отдельным DNS-серверам, зона example.com больше не содержит авторитетные данные обо всех именах внутри dev.example.com.

Формат DNS-имени

DNS-имя состоит из меток, разделённых точками:

api.example.com

Здесь:

DNS-имена регистронезависимы:

EXAMPLE.COM
example.com
Example.Com

Для DNS это одно имя, хотя на практике имена обычно записываются строчными буквами.

Основные типы DNS-записей

Общая логическая структура ресурсной записи:

имя  TTL  класс  тип  значение

Например:

www.example.com.  3600  IN  A  192.0.2.10

Где:

В панели DNS-провайдера класс IN обычно не отображается, а TTL может задаваться отдельно.

Запись A

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

example.com.      3600  IN  A  192.0.2.10
www.example.com.  3600  IN  A  192.0.2.10

Одно имя может иметь несколько записей A:

app.example.com.  300  IN  A  192.0.2.10
app.example.com.  300  IN  A  192.0.2.11
app.example.com.  300  IN  A  192.0.2.12

Резолвер может вернуть все адреса. Клиент выбирает, к какому из них подключиться.

Несколько адресов могут использоваться для:

Запись AAAA

Запись AAAA связывает имя с IPv6-адресом:

example.com.      3600  IN  AAAA  2001:db8::10
www.example.com.  3600  IN  AAAA  2001:db8::10

Название AAAA связано с тем, что IPv6-адрес имеет длину 128 бит, то есть в четыре раза больше IPv4-адреса длиной 32 бита.

Если имя содержит и A, и AAAA, клиент может использовать IPv4 или IPv6:

example.com.  3600  IN  A     192.0.2.10
example.com.  3600  IN  AAAA  2001:db8::10

Наличие AAAA имеет смысл только тогда, когда сервис действительно доступен по IPv6.

Запись CNAME

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

www.example.com.  3600  IN  CNAME  example.com.

Это означает:

www.example.com — псевдоним example.com

Клиент сначала узнаёт каноническое имя, а затем запрашивает его адресные записи.

Другой пример:

docs.example.com.  3600  IN  CNAME  documentation.provider.example.

Ограничения CNAME

Имя с записью CNAME обычно не должно одновременно иметь другие типы данных:

# Некорректная конфигурация
www.example.com.  IN  CNAME  example.com.
www.example.com.  IN  A      192.0.2.20

Для одного имени следует выбрать либо CNAME, либо обычные записи.

У корня зоны обычно нельзя использовать стандартный CNAME:

example.com

Корень зоны уже должен содержать SOA и NS, а имя с CNAME не должно одновременно иметь другие записи.

Некоторые DNS-провайдеры предлагают специальные записи:

ALIAS
ANAME
CNAME flattening

Они похожи на CNAME по назначению, но обрабатываются провайдером особым образом и не являются полным эквивалентом стандартной записи CNAME.

Цепочки CNAME

Возможна цепочка:

a.example.com → b.example.com → c.example.net → IP-адрес

Длинные цепочки нежелательны, поскольку увеличивают число DNS-запросов и усложняют диагностику.

Циклы недопустимы:

a.example.com → b.example.com
b.example.com → a.example.com

Такая конфигурация не позволяет получить конечный адрес.

Запись MX

MX (Mail Exchange) указывает почтовые серверы, принимающие электронную почту для домена:

example.com.  3600  IN  MX  10 mail1.example.com.
example.com.  3600  IN  MX  20 mail2.example.com.

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

В примере первым используется:

mail1.example.com

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

mail2.example.com

Для почтовых серверов нужны адресные записи:

mail1.example.com.  3600  IN  A     192.0.2.25
mail1.example.com.  3600  IN  AAAA  2001:db8::25
mail2.example.com.  3600  IN  A     192.0.2.26

Значением MX должно быть имя сервера, а не IP-адрес:

# Правильно
example.com.  IN  MX  10 mail.example.com.

# Неправильно
example.com.  IN  MX  10 192.0.2.25

В полном имени сервера важна завершающая точка:

example.com.  IN  MX  10 mail.example.com.

Без точки редактор zone-файла может дополнить имя текущей зоной:

mail.example.com.example.com

Поведение зависит от интерфейса. В веб-панелях DNS-провайдеров завершающую точку нередко добавлять не требуется.

Запись TXT

Запись TXT хранит текстовые данные:

example.com.  3600  IN  TXT  "Произвольный текст"

Частые варианты использования:

Пример подтверждения домена:

example.com.  300  IN  TXT  "service-verification=abc123"

Пример SPF:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.example.net -all"

Пример DMARC:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine"

У одного имени может быть несколько записей TXT:

example.com.  IN  TXT  "service-one=abc"
example.com.  IN  TXT  "service-two=xyz"

Несколько отдельных TXT-записей не следует воспринимать как одну объединённую строку.

Длинное значение внутри одной записи может быть разбито на несколько строковых фрагментов:

selector._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqh..."
)

DNS-сервер логически объединяет эти фрагменты в значение одной записи.

Запись NS

NS (Name Server) указывает авторитетные DNS-серверы зоны:

example.com.  86400  IN  NS  ns1.dns-provider.example.
example.com.  86400  IN  NS  ns2.dns-provider.example.

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

Записи NS применяются:

Например, поддомен можно делегировать отдельным серверам:

dev.example.com.  86400  IN  NS  ns1.dev-dns.example.
dev.example.com.  86400  IN  NS  ns2.dev-dns.example.

После делегирования записи внутри dev.example.com должны обслуживаться указанными авторитетными серверами.

Glue records

Иногда адрес DNS-сервера нельзя получить, не обратившись к зоне, которую он сам обслуживает.

Например:

example.com.  NS  ns1.example.com.

Чтобы обратиться к ns1.example.com, нужен его IP-адрес. Но этот адрес находится внутри зоны example.com, к которой ещё только нужно получить доступ.

Для решения используются glue records — адреса DNS-серверов, опубликованные в родительской зоне.

У регистратора могут быть зарегистрированы данные:

ns1.example.com → 192.0.2.53
ns2.example.com → 192.0.2.54

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

Запись SOA

Хотя SOA не входит в основной список адресных записей, она обязательна для авторитетной DNS-зоны.

SOA (Start of Authority) содержит основные служебные параметры зоны:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
    2026091601 ; serial
    3600       ; refresh
    900        ; retry
    1209600    ; expire
    300        ; negative cache TTL
)

Здесь:

В поле электронной почты первая точка заменяет символ @:

hostmaster.example.com.

означает:

hostmaster@example.com

Серийный номер зоны

При изменении zone-файла серийный номер нужно увеличить.

Распространённый формат:

YYYYMMDDNN

Например:

2026091601

где 01 — номер изменения за день.

Если serial не увеличить, вторичные DNS-серверы могут не обнаружить обновление.

TTL записей

TTL (Time to Live) — время, в течение которого DNS-ответ разрешается хранить в кэше.

TTL указывается в секундах:

www.example.com.  3600  IN  A  192.0.2.10

Значение 3600 означает один час.

Распространённые значения:

TTL Продолжительность
60 1 минута
300 5 минут
900 15 минут
1800 30 минут
3600 1 час
14400 4 часа
86400 24 часа

Как работает TTL

Пусть запись имеет TTL 3600.

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

Оставшийся TTL постепенно уменьшается:

3600 → 3599 → 3598 → ... → 0

После истечения TTL резолвер должен снова получить актуальные данные.

Высокий TTL

Преимущества:

Недостаток — изменения распространяются медленнее.

Низкий TTL

Преимущества:

Недостатки:

Изменение TTL перед миграцией

Если планируется замена IP-адреса, TTL желательно уменьшить заранее.

Пример:

  1. Текущая запись имеет TTL 86400.
  2. Не менее чем за сутки TTL уменьшается до 300.
  3. Нужно дождаться истечения старого TTL.
  4. После этого изменяется IP-адрес.
  5. Через некоторое время после проверки TTL возвращается к обычному значению.

Если уменьшить TTL непосредственно перед заменой IP, старые ответы уже могут находиться в кэшах с прежним большим TTL.

Отрицательное кэширование

DNS может кэшировать не только существующие записи, но и отрицательные ответы, например:

NXDOMAIN

NXDOMAIN означает, что запрошенного доменного имени не существует.

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

Продолжительность отрицательного кэширования связана с параметрами SOA и поведением резолвера.

TTL не равен гарантированному времени обновления

TTL определяет допустимое время хранения ответа, но фактическое поведение зависит от:

Поэтому выражение «распространение DNS» обычно означает постепенное исчезновение старых данных из разных кэшей, а не передачу записи одновременно всем DNS-серверам мира.

Настройка доменной зоны

Конкретный интерфейс зависит от регистратора и DNS-провайдера, но общий порядок похож.

Шаг 1. Зарегистрировать домен

Регистратор управляет регистрацией доменного имени и настройкой делегирования.

Регистратор домена и DNS-провайдер могут быть одной компанией, но это разные функции:

Шаг 2. Создать DNS-зону

У DNS-провайдера создаётся зона:

example.com

Провайдер сообщает авторитетные серверы, например:

ns1.dns-provider.example
ns2.dns-provider.example

Шаг 3. Настроить делегирование

В панели регистратора указываются авторитетные DNS-серверы:

ns1.dns-provider.example
ns2.dns-provider.example

Важно отличать:

NS-серверы домена

от:

обычных NS-записей, добавленных в интерфейс зоны

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

Шаг 4. Добавить записи

Минимальный пример:

@      3600  IN  A      192.0.2.10
www    3600  IN  CNAME  example.com.
mail   3600  IN  A      192.0.2.25
@      3600  IN  MX     10 mail.example.com.
@      3600  IN  TXT    "service-verification=abc123"

В панелях DNS символ @ обычно означает корень зоны:

example.com

Имя www относительно зоны означает:

www.example.com

Шаг 5. Проверить авторитетные серверы

Проверка NS:

dig example.com NS

Проверка через трассировку делегирования:

dig +trace example.com

Шаг 6. Проверить записи

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com TXT

Шаг 7. Проверить конкретный авторитетный сервер

dig @ns1.dns-provider.example example.com A

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

Пример zone-файла

Упрощённый zone-файл для BIND-подобного DNS-сервера:

$ORIGIN example.com.
$TTL 3600

@  IN  SOA  ns1.example.com. hostmaster.example.com. (
       2026091601 ; serial
       3600       ; refresh
       900        ; retry
       1209600    ; expire
       300        ; negative cache TTL
)

@       IN  NS     ns1.example.com.
@       IN  NS     ns2.example.com.

ns1     IN  A      192.0.2.53
ns2     IN  A      192.0.2.54

@       IN  A      192.0.2.10
@       IN  AAAA   2001:db8::10

www     IN  CNAME  example.com.

mail    IN  A      192.0.2.25
@       IN  MX     10 mail.example.com.

@       IN  TXT    "service-verification=abc123"

$ORIGIN

Директива:

$ORIGIN example.com.

задаёт базовое имя для относительных записей.

Запись:

www  IN  A  192.0.2.10

означает:

www.example.com.  IN  A  192.0.2.10

$TTL

Директива:

$TTL 3600

задаёт TTL по умолчанию для записей, у которых он не указан отдельно.

Символ @

Символ:

@

означает текущее значение $ORIGIN, то есть корень зоны:

example.com.

Завершающая точка

Абсолютное имя заканчивается точкой:

mail.example.com.

Относительное имя без точки дополняется текущим $ORIGIN.

Например, внутри зоны example.com:

mail.example.com

может быть интерпретировано как:

mail.example.com.example.com.

Поэтому в zone-файлах полные имена обычно завершают точкой.

Работа с dig

dig — консольная утилита для выполнения DNS-запросов и диагностики.

Обычно она доступна в составе:

Базовый запрос

dig example.com

По умолчанию обычно запрашивается запись A.

Сокращённый результат:

;; QUESTION SECTION:
;example.com.          IN  A

;; ANSWER SECTION:
example.com.     3600  IN  A  192.0.2.10

Запрос конкретного типа

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 www.example.com CNAME

Короткий вывод

dig +short example.com A

Пример:

192.0.2.10

Для MX:

dig +short example.com MX

Результат:

10 mail.example.com.
20 mail2.example.com.

Запрос через конкретный DNS-сервер

dig @1.1.1.1 example.com A

Другой пример:

dig @8.8.8.8 example.com A

Проверка авторитетного сервера:

dig @ns1.example.com example.com SOA

Трассировка DNS-иерархии

dig +trace example.com

Команда показывает путь:

корневые серверы → серверы TLD → авторитетные серверы домена

Она полезна при диагностике:

Запрос без рекурсии

dig +norecurse @ns1.example.com example.com A

Авторитетному серверу обычно отправляют нерекурсивный запрос, чтобы проверить данные, за которые он отвечает непосредственно.

Просмотр всех доступных записей

dig example.com ANY

Запрос ANY не гарантирует получение всех записей. 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

Обратный DNS-запрос

dig -x 192.0.2.10

Обратный запрос ищет запись PTR, связывающую IP-адрес с именем.

Для IPv4 используются зоны внутри:

in-addr.arpa

Для IPv6:

ip6.arpa

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

Основные части ответа dig

Типичный ответ содержит несколько секций.

Заголовок

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345

Поле status показывает результат запроса.

Частые статусы:

Статус Значение
NOERROR Запрос обработан без DNS-ошибки
NXDOMAIN Имя не существует
SERVFAIL Сервер не смог получить корректный ответ
REFUSED Сервер отказался выполнять запрос
FORMERR Ошибка формата запроса

NOERROR не обязательно означает, что нужная запись найдена. Имя может существовать, но не иметь запрошенного типа записи.

Флаги

Пример:

flags: qr rd ra

Частые флаги:

Флаг Значение
qr Это ответ, а не запрос
aa Авторитетный ответ
rd Клиент запросил рекурсию
ra Сервер поддерживает рекурсию
tc Ответ усечён
ad Данные прошли DNSSEC-проверку у резолвера
cd Клиент отключил DNSSEC-проверку

QUESTION SECTION

Показывает, что именно было запрошено:

;example.com.  IN  A

ANSWER SECTION

Содержит непосредственный ответ:

example.com.  3600  IN  A  192.0.2.10

AUTHORITY SECTION

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

ADDITIONAL SECTION

Может содержать дополнительные данные, например IP-адреса серверов, указанных в NS или MX.

Строка SERVER

Показывает DNS-сервер, который обработал запрос:

;; SERVER: 192.168.1.1#53

Время запроса

;; Query time: 18 msec

Это время получения DNS-ответа, а не время установления HTTP-соединения с сайтом.

Работа с nslookup

nslookup — утилита для простых DNS-запросов. Она доступна во многих операционных системах, включая Windows.

Базовый запрос

nslookup example.com

Примерный результат:

Server:  resolver.local
Address: 192.168.1.1

Name:    example.com
Address: 192.0.2.10

Запрос конкретного типа

nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
nslookup -type=SOA example.com

В Windows часто используется тот же синтаксис:

nslookup -type=mx example.com

Запрос через конкретный DNS-сервер

nslookup example.com 1.1.1.1

Запрос MX через указанный сервер:

nslookup -type=MX example.com 8.8.8.8

Интерактивный режим

Запуск:

nslookup

Далее можно вводить команды:

server 1.1.1.1
set type=MX
example.com

Завершение:

exit

dig или nslookup

nslookup удобен для быстрых проверок, особенно в Windows.

dig обычно удобнее для подробной диагностики, поскольку показывает:

Практические команды

Узнать IPv4-адрес

dig +short example.com A

или:

nslookup -type=A example.com

Узнать IPv6-адрес

dig +short example.com AAAA

Найти почтовые серверы

dig +short example.com MX

Найти авторитетные серверы

dig +short example.com NS

Посмотреть SOA

dig example.com SOA

Проверить TXT-записи

dig example.com TXT

Проверить отдельный поддомен

dig api.example.com A

Проверить CNAME-цепочку

dig www.example.com CNAME
dig www.example.com A

Для краткого вывода:

dig +short www.example.com

Сравнить ответы разных резолверов

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Если ответы различаются, возможны:

Спросить каждый авторитетный сервер напрямую

Сначала получить список:

dig +short example.com NS

Затем проверить каждый сервер:

dig @ns1.dns-provider.example example.com A
dig @ns2.dns-provider.example example.com A

Авторитетные серверы одной зоны обычно должны возвращать согласованные данные.

DNS и CDN

CDN (Content Delivery Network) — распределённая сеть узлов, которая доставляет контент с серверов, расположенных ближе к пользователям или лучше подходящих для текущих условий.

DNS часто используется как первая точка управления CDN-маршрутизацией.

Подключение CDN через CNAME

Поддомен сайта может ссылаться на имя CDN:

static.example.com.  300  IN  CNAME  example.cdn-provider.net.

Клиент запрашивает:

static.example.com

DNS приводит его к имени CDN, после чего инфраструктура CDN возвращает подходящий IP-адрес.

Корневой домен и CDN

Для поддомена можно использовать обычный CNAME:

www.example.com

Для корня зоны:

example.com

стандартный CNAME обычно неприменим.

Поэтому провайдеры используют:

Конкретный механизм зависит от DNS- и CDN-провайдера.

Географическое распределение

CDN может возвращать разные адреса в зависимости от:

Поэтому два клиента могут получить разные DNS-ответы для одного имени.

DNS-балансировка

Одному имени может соответствовать несколько IP-адресов:

cdn.example.com.  60  IN  A  192.0.2.10
cdn.example.com.  60  IN  A  192.0.2.11
cdn.example.com.  60  IN  A  192.0.2.12

Простая выдача нескольких адресов не гарантирует равномерного распределения нагрузки. Клиенты и резолверы могут выбирать и кэшировать адреса по-разному.

Промышленные CDN обычно применяют более сложные механизмы:

Anycast

При Anycast один IP-адрес объявляется из нескольких географически распределённых точек.

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

DNS и Anycast могут использоваться совместно:

TTL в CDN

CDN часто использует сравнительно небольшой TTL:

60–300 секунд

Это позволяет быстрее менять направление трафика при:

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

DNS не передаёт HTTP-контент

DNS только помогает определить адрес сервиса. После разрешения имени клиент отдельно устанавливает соединение и выполняет HTTP- или HTTPS-запрос.

Упрощённо:

DNS: static.example.com → 192.0.2.50
TCP/QUIC: соединение с 192.0.2.50
TLS: проверка сертификата static.example.com
HTTP: запрос нужного ресурса

При использовании HTTPS сертификат CDN должен быть действителен для исходного имени:

static.example.com

Даже если оно настроено через CNAME на домен CDN-провайдера.

Частые ошибки конфигурации

Запись добавлена не в ту зону

Например, запись создана в старой панели DNS, а домен уже делегирован другим авторитетным серверам.

Проверка:

dig example.com NS

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

Изменены NS-записи только внутри зоны

Добавление новых NS в zone-файл не всегда изменяет делегирование в родительской зоне.

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

Пропущена завершающая точка

В zone-файле:

@  IN  MX  10 mail.example.com

может превратиться в:

mail.example.com.example.com.

Правильный абсолютный вариант:

@  IN  MX  10 mail.example.com.

CNAME совмещён с другими записями

Некорректно:

app.example.com.  IN  CNAME  target.example.net.
app.example.com.  IN  TXT    "verification=123"

Имя с CNAME не должно одновременно содержать обычные ресурсные записи других типов.

CNAME создан в корне зоны

Конфигурация вида:

example.com.  IN  CNAME  target.example.net.

конфликтует с обязательными SOA и NS.

Следует использовать поддерживаемый провайдером механизм ALIAS/ANAME/flattening либо адресные записи.

MX указывает на IP-адрес

Некорректно:

example.com.  IN  MX  10 192.0.2.25

Правильно:

example.com.       IN  MX  10 mail.example.com.
mail.example.com.  IN  A      192.0.2.25

Не увеличен serial

При ручном управлении зоной вторичные серверы могут не загрузить изменения, если номер SOA serial остался прежним.

Слишком высокий TTL перед миграцией

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

TTL следует уменьшать заранее.

Авторитетные серверы возвращают разные данные

Проверка:

dig @ns1.example.net example.com A
dig @ns2.example.net example.com A

Причинами могут быть:

Есть AAAA, но IPv6 не работает

Клиенты могут пытаться подключаться по IPv6 и получать ошибки.

Если сервис не обслуживает IPv6, не следует публиковать неработающую запись AAAA.

Алгоритм диагностики DNS

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

1. Проверить обычный запрос

dig example.com A

Обратить внимание на:

2. Проверить другие резолверы

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Если ответы различаются, вероятна проблема кэша или распределённой конфигурации.

3. Проверить делегирование

dig example.com NS
dig +trace example.com

4. Проверить авторитетные серверы напрямую

dig @ns1.dns-provider.example example.com A
dig @ns2.dns-provider.example example.com A

5. Проверить SOA serial

dig @ns1.dns-provider.example example.com SOA
dig @ns2.dns-provider.example example.com SOA

Разные serial могут указывать на рассинхронизацию.

6. Проверить нужный тип записи

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

Успешный ответ для A не гарантирует правильность MX или TXT.

7. Проверить CNAME-цепочку

dig www.example.com CNAME
dig www.example.com A

Следует убедиться, что цепочка завершается существующей записью A или AAAA.

8. Учитывать кэш и TTL

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

9. Отделить DNS от доступности сервиса

Успешный DNS-ответ не гарантирует работу приложения.

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

curl -v https://example.com/

DNS отвечает на вопрос:

Куда подключаться?

Но не гарантирует:

Краткая памятка

Задача Запись или команда
Связать имя с IPv4 A
Связать имя с IPv6 AAAA
Создать псевдоним CNAME
Указать почтовые серверы MX
Опубликовать текстовые данные TXT
Указать авторитетные серверы NS
Описать параметры зоны SOA
Проверить IPv4 dig example.com A
Проверить IPv6 dig example.com AAAA
Проверить почтовые серверы dig example.com MX
Проверить TXT dig example.com TXT
Проверить делегирование dig example.com NS
Проследить DNS-цепочку dig +trace example.com
Спросить конкретный сервер dig @1.1.1.1 example.com A
Получить краткий ответ dig +short example.com
Выполнить обратный запрос dig -x 192.0.2.10

DNS — распределённая и кэшируемая система. Для корректной диагностики важно отдельно проверять делегирование, авторитетные данные, ответы рекурсивных серверов и оставшийся TTL.