Главная› Уроки› Сети с нуля› Урок 5

Урок 5 — DNS с нуля

Есть народная мудрость SRE: «Это всегда DNS». Половина инцидентов в продакшене так или иначе связана с DNS. Понять его до конца — обязательно для любого DevOps.

В этом уроке

Зачем нужен DNS
Как устроено доменное имя
Иерархия DNS-серверов
Как имя превращается в IP — шаг за шагом
Типы записей: A, AAAA, CNAME, MX, TXT, NS
Кэш и TTL
Команда dig и nslookup
Что с этим делает DevOps
Типичные DNS-проблемы
Чек-лист «понимаю это»
Плейбук: «сайт не открывается»
Задачи с ответами

Вспомни из прошлых уроков

Чтобы установить соединение, клиенту нужен полный адрес сервера: IP + порт (урок 4). Порт обычно известен из протокола (443 для HTTPS), а вот IP… ты же вводишь в браузере google.com, а не число. Между «именем, удобным человеку» и «адресом, понятным сети» стоит целая всемирная система — DNS. Она же — первое, что ломается, поэтому у сетевиков есть поговорка: «It's always DNS».

1. Зачем нужен DNS

Ты не вводишь в браузере https://93.184.216.34 — ты пишешь example.com. Но компьютеры общаются по IP, а не по словам. Нужен переводчик. Этот переводчик — DNS (Domain Name System).

DNS отвечает на простой вопрос: «какой IP у example.com?» — и кэширует ответ, чтобы не спрашивать каждый раз.

Аналогия

DNS = телефонная книга интернета

Раньше у тебя дома лежала телефонная книга: «Иванов И.И., ул. Лесная 5 → +7 495 123 4567». Чтобы позвонить, ты вспоминал имя, лез в книгу, находил номер, набирал номер.

DNS — это гигантская распределённая телефонная книга мира. Имена — это домены. Номера — это IP. Когда браузер хочет открыть сайт, он сначала «звонит» в телефонную книгу — DNS даёт IP, и только потом браузер устанавливает соединение.

Без DNS ты бы помнил наизусть IP всех сайтов (а они ещё и меняются — облако постоянно мигрирует). Это нереально.

2. Как устроено доменное имя

Доменное имя читается справа налево. Каждая точка — это переход на уровень выше:

Доменное имя — иерархия. Читается справа: корень → TLD → SLD → поддомены.

Root (.) Корень иерархии. Управляется 13 группами «корневых» серверов по миру. Обычно точку опускают, но технически она есть.

TLD Top-Level Domain — верхний уровень. Бывают:

Generic (gTLD): .com, .org, .net, .dev, .app
Country (ccTLD): .ru, .de, .jp, .io (формально это острова Чагос, но используется тех-сектором)
Sponsored: .gov, .edu

SLD Домен второго уровня — то, что ты покупаешь у регистратора. Например, example в example.com.

Subdomain Поддомены — сколько угодно слева. Бесплатно, сам управляешь. www, api, blog — это типичные поддомены.

FQDN Fully Qualified Domain Name — полное доменное имя с точкой в конце: api.example.com. Эта точка явно говорит «отсчитывать от корня». Без точки — может быть относительным.

3. Иерархия DNS-серверов

DNS — это распределённая база. Нет одного «главного» сервера, который бы знал всё. Информация разбросана по миллионам серверов и иерархически делегирована.

Корень → TLD-серверы → authoritative-серверы домена. Каждый знает только своих «детей».

Root-серверы 13 кластеров (a–m.root-servers.net) по всему миру. Они знают только адреса TLD-серверов. Сами не отвечают на запросы про example.com — отсылают к .com.

TLD-серверы Знают, какие authoritative-серверы отвечают за каждый домен второго уровня. Спросишь у .com про example.com — он скажет: «иди к ns1.example-host.com».

Authoritative Серверы, на которых хранятся реальные записи зоны. Это «истина последней инстанции» для домена. Их выбирает владелец (Cloudflare, AWS Route 53, свой BIND).

Recursive resolver Сервер, который от имени клиента проходит всю эту цепочку и кэширует. Это 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), DNS твоего провайдера, systemd-resolved на твоём ноутбуке.

4. Как имя превращается в IP — шаг за шагом

Ты ввёл в браузере www.example.com. Вот что происходит:

Полный путь: браузер → resolver → root → TLD → authoritative → ответ. Шагов много, но всё это занимает 20-50 мс.

Цепочка кэшей сокращает работу: если кто-то рядом недавно спрашивал то же самое, ответ найдётся в первом же кэше — браузера, ОС или resolver-а.

5. Типы DNS-записей

В DNS-зоне хранятся не только «имя → IP». Есть много типов записей. Самые важные:

Тип	Что хранит	Пример
A	Имя → IPv4-адрес	`example.com → 93.184.216.34`
AAAA	Имя → IPv6-адрес	`example.com → 2606:2800:220:1:248:1893:25c8:1946`
CNAME	Алиас на другое имя	`www.example.com → example.com`
MX	Куда доставлять почту	`example.com → 10 mail.example.com`
TXT	Произвольный текст	`"v=spf1 include:_spf.google.com ~all"`
NS	Какие authoritative-серверы	`example.com → ns1.example-host.com`
SOA	«Паспорт» зоны: владелец, TTL, серийник	В каждой зоне ровно одна SOA
CAA	Кто может выпускать TLS-сертификаты для домена	`0 issue "letsencrypt.org"`
SRV	Сервис + хост + порт + приоритет	`_sip._tcp.example.com → 10 5 5060 sip.example.com`
PTR	Обратный резолвинг: IP → имя	Используется в reverse DNS

A vs CNAME — частая путаница

A указывает прямо на IP. Меняется IP — нужно обновить запись.
CNAME указывает на другое имя. Часто используется, когда IP меняется автоматически — например, CloudFront даёт тебе адрес вида dxxxxx.cloudfront.net, и ты делаешь www.mysite.com CNAME dxxxxx.cloudfront.net.

CNAME на «голый» домен — нельзя

По RFC, CNAME не может быть на «корневой» (apex / naked) домен — example.com. CNAME можно только для www.example.com или другого поддомена.

Чтобы обойти это, провайдеры (Cloudflare, Route 53) придумали «ALIAS» / «CNAME flattening» — это псевдо-CNAME для корня. На практике используешь — но знай, что под капотом не классический CNAME.

TXT — на удивление важен

TXT — просто «строка текста», но именно в нём хранится:

SPF — кто имеет право отправлять почту от твоего домена
DKIM — публичные ключи для подписи почты
DMARC — что делать, если SPF/DKIM не прошли
Верификация владения у Google, AWS, Cloudflare — добавь TXT с уникальной строкой, и они поверят, что это твой домен

6. Кэш и TTL

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

Типичные значения:

3600 (1 час) — золотая середина по умолчанию
86400 (1 день) — для стабильных записей, которые никогда не меняются
300 (5 минут) или 60 (1 минута) — когда планируешь миграцию

DevOps-сценарий: миграция

Готовишься переключить сайт на новый сервер. План:

За день до миграции — снизь TTL до 60 секунд
Подожди день — старый «длинный» TTL истечёт у всех резолверов
В день X — поменяй A-запись. Все клиенты подтянут новый IP за минуту
Если что-то сломалось — за минуту откатишься
Через сутки — верни нормальный TTL (1 час)

7. Команды dig и nslookup

Главный инструмент DNS-диагностики — dig. Он расскажет тебе всё.

# Базовый запрос — A-запись
dig example.com

# Только сам ответ, без шума
dig +short example.com

# Конкретный тип записи
dig example.com MX
dig example.com TXT
dig example.com NS

# Через конкретный резолвер
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# ★★★ Самая полезная — полный путь резолвинга
dig +trace example.com
# Покажет каждый шаг: root → .com → authoritative
# Видно, кто и что сказал

# Обратный резолвинг IP → имя
dig -x 8.8.8.8

На Windows аналог — nslookup. Менее богатый, но базовое умеет:

nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=MX example.com

Современная альтернатива dig — doggo и dog. Цветной вывод, удобный синтаксис. Опциональны, но приятны.

8. Что с этим делает DevOps

Деплой нового сайта. Регистрируешь домен → создаёшь A/CNAME → ждёшь TTL → проверяешь dig.
SSL-сертификаты. Let's Encrypt проверяет владение через DNS (_acme-challenge TXT-запись). Без понимания записей не настроишь cert-manager в K8s.
K8s service discovery. Внутри кластера сервисы находят друг друга по имени: http://my-service.namespace.svc.cluster.local. Это всё DNS, обслуживаемый CoreDNS.
AWS Route 53. Тут ты будешь жить. Здоровьем checked Routing, weighted routing, geolocation routing — всё это DNS-фичи.
Multi-region failover. Низкий TTL + health check → DNS автоматически переключает трафик на другой регион при падении.
Безопасность. Анализ DNS-логов (passive DNS) — основа threat detection. CAA-записи не дают чужим выпускать сертификаты от твоего имени.

9. Типичные DNS-проблемы

Симптом	Что проверить
«Сайт не открывается»	`dig example.com` — резолвится? Если нет — DNS
«У одного работает, у другого нет»	Разные кэши/TTL. `dig @1.1.1.1` vs `dig @8.8.8.8`
«После миграции некоторые на старом сервере»	TTL не истёк. Подождать или попросить почистить кэш
«Письма не доходят»	`dig example.com MX`, TXT SPF/DKIM/DMARC
«SSL отозвался / не получается выпустить»	`dig example.com CAA` — может, разрешён не тот CA
В K8s pod не видит сервис	CoreDNS жив? `nslookup my-service` из pod-а

10. Чек-лист «понимаю это»

☐ Объясню, зачем нужен DNS
☐ Понимаю, что доменное имя — иерархия справа налево
☐ Различаю root, TLD, authoritative и recursive резолверы
☐ Знаю записи A, AAAA, CNAME, MX, TXT, NS, CAA
☐ Помню разницу между A и CNAME, и почему CNAME нельзя на apex
☐ Понимаю, что такое TTL и зачем его снижают перед миграцией
☐ Использовал dig +trace хотя бы раз
☐ Могу прочитать вывод dig example.com

11. Плейбук: «сайт не открывается» — виноват ли DNS?

Полдиагностики любого «не работает» — быстро понять, на каком слое проблема. Этот плейбук отвечает на первый вопрос: DNS это или нет. Работает на любой системе, занимает две минуты:

Резолвится ли имя вообще?

nslookup example.com (есть везде) или dig example.com. Пришёл IP-адрес — DNS жив, проблема дальше (соединение, сервер — иди в урок 8 и плейбук урока 4). Ошибка NXDOMAIN / «can't find» — имя не резолвится: продолжаем здесь.

Это у тебя или у всех? Спроси другой резолвер

nslookup example.com 8.8.8.8 — тот же вопрос, но напрямую Google DNS (минуя резолвер провайдера). Через 8.8.8.8 отвечает, а по умолчанию нет — проблема в резолвере провайдера (или его кэше): смени DNS в настройках на 8.8.8.8/1.1.1.1. Не отвечает нигде — проблема на стороне домена: смотри шаг 4.

Может, это твой локальный кэш?

ОС помнит старые ответы. Сбрось: Windows — ipconfig /flushdns, macOS — sudo dscacheutil -flushcache, Linux (systemd) — resolvectl flush-caches. И проверь файл hosts (C:\Windows\System32\drivers\etc\hosts) — забытая строчка в нём перебивает любой DNS и порождает мистику «только у меня не работает».

Проблема у всех? Смотри на сам домен

dig example.com NS — живы ли NS-серверы домена; dig @ns1.hoster.com example.com — отвечает ли authoritative напрямую. Молчат/пусто — домен просрочен, NS-серверы лежат или запись удалили. Это уже зона владельца домена.

Резолвится, но «не на тот адрес»?

После переезда сайта часть мира ещё ходит на старый IP — это TTL: кэши по всему интернету держат старую запись, пока не истечёт её срок. Сравни: dig +short example.com @8.8.8.8 vs @1.1.1.1 — разные ответы = переезд ещё «расползается». Лечение — терпение (дождаться TTL); профилактика — снижать TTL заранее.

12. Задачи — реши сам (ответы спрятаны)

Задача 1. ping 8.8.8.8 работает, а ping google.com — «не удаётся разрешить имя». Что сломано и почему это классика?

Связь с интернетом есть (по IP пакеты ходят), а вот DNS не работает — имя не превращается в адрес. Чинить настройки DNS (или резолвер провайдера). Это классический тест «сеть или DNS»: два пинга — и слой проблемы найден.

Задача 2. У домена запись CNAME: shop.example.com → myshop.cdn-provider.net. Клиент спрашивает: «какой IP у shop.example.com?» Что происходит при резолве?

Резолв идёт в два шага: сначала CNAME говорит «настоящее имя — myshop.cdn-provider.net», затем резолвится уже оно (его A-запись) — и клиент получает IP CDN. CNAME — это «псевдоним», удобен тем, что при смене IP у CDN менять свою запись не нужно.

Задача 3. Ты переезжаешь на новый сервер завтра в 12:00. TTL A-записи сейчас 86400 (сутки). Что сделать сегодня и почему?

Снизить TTL до 300 (5 минут) уже сейчас — и подождать, пока старый суточный TTL истечёт у кэшей. Тогда завтра после смены записи весь мир переедет за минуты, а не за сутки. После переезда TTL можно вернуть побольше. Это стандартная процедура любой миграции.

Задача 4. Сайт работает, а письма на адреса @example.com не доходят. Куда смотреть в DNS?

Записи MX (dig example.com MX) — они указывают почтовые серверы домена и не связаны с A-записью сайта. Заодно проверить TXT-записи SPF/DKIM/DMARC — без них письма улетают в спам. Сайт и почта — разные записи: одно может работать без другого.

Задача 5. dig example.com вернул ответ мгновенно и в нём флаг «ANSWER … (cached)». Откуда взялся ответ и в чём подвох кэша?

Из кэша резолвера — по полной цепочке (root → TLD → authoritative) запрос не ходил. Быстро, дёшево… но кэш может быть устаревшим: если запись только что поменяли, кэш будет отдавать старую до истечения TTL. Свежесть проверяют запросом к authoritative напрямую.

Задача 6. В Kubernetes под не может достучаться до сервиса по имени backend, хотя по IP сервиса — может. Какая подсистема под подозрением?

CoreDNS — внутренний DNS кластера: именно он превращает имена сервисов в IP. По IP работает, по имени нет = резолв сломан. Проверка: nslookup backend изнутри пода, живы ли поды CoreDNS. Та же логика «сеть или DNS», что и в задаче 1 — только в облаке.

DNS = телефонная книга интернета, иерархическая и распределённая. Запрос идёт по цепочке: браузер → resolver → root → TLD → authoritative, кэшируясь на каждом шагу на TTL секунд. Главные записи: A (на IP), CNAME (на другое имя), MX (почта), TXT (текст для SPF/DKIM/верификации). Главный инструмент диагностики — dig.

Мост к следующему уроку

Смотри, что у тебя уже есть: имя превратилось в IP (этот урок), пакет доедет до сервера (уроки 2–3), попадёт в нужную программу по порту (урок 4). Соединение установлено… а что по нему говорить? Каким языком браузер просит страницу и как сервер отвечает? Этот язык — HTTP, и читать его глазами ты научишься в следующем уроке. Спойлер: он на удивление человекочитаемый.

← Назад

Урок 4: Порты, TCP и UDP

Дальше →

Урок 6: HTTP — основы