DNS: записи, зоны, диагностика

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

Зачем нужен DNS

Без DNS интернет был бы списком чисел. Адрес 185.199.108.153 запомнить тяжело, имя github.com – легко. DNS переводит человекочитаемые имена в IP-адреса – и попутно решает еще десяток задач: куда слать почту для домена, кто подтверждает владение доменом, какие серверы за него отвечают.

Каждый раз, когда вы делаете curl github.com, ping ya.ru или открываете сайт в браузере, за кулисами сначала происходит DNS-запрос.

Как работает резолв

Когда программе нужен адрес по имени, происходит примерно следующее:

Резолв DNS: рекурсивный резолвер обходит цепочку корни, зона, authoritative-сервер

Ключевое разделение: рекурсивный резолвер – это сервер, который берет на себя всю беготню по цепочке (обычно DNS провайдера или публичный вроде 8.8.8.8). Authoritative-сервер – тот, кто хранит настоящие записи домена и дает окончательный ответ. Вы спрашиваете у резолвера, он бегает по корням и зонам и приносит вам ответ.

Резолв DNS: программа спрашивает рекурсивный резолвер, тот обходит цепочку корни → зона .ru → authoritative-сервер и возвращает A-запись, кешируя ответ на TTL

Типы записей

DNS хранит не только адреса. Запись каждого типа отвечает за свое:

Типы записей DNS: A, AAAA, CNAME, MX, NS, PTR, TXT, SRV

На практике чаще всего нужны A (адрес сайта), MX (куда идет почта), TXT (подтверждение владения доменом, настройка почты), NS (кто отвечает за домен), иногда PTR (обратный поиск, важен для почтовых серверов).

Пара деталей, которые путают новичков. CNAME – это не «второй адрес», а псевдоним: запись говорит «иди спрашивай вон то имя». Поэтому CNAME нельзя вешать на корень домена и нельзя смешивать с другими записями того же имени. TXT – формально просто текст, но именно в нем живут SPF и DKIM (защита почты от подделки) и строки вроде google-site-verification=..., которыми сервисы проверяют, что домен ваш.

TTL и кеширование

У каждой записи есть TTL (Time To Live) – сколько секунд ее разрешено держать в кеше, прежде чем спросить заново.

TTL: компромисс маленького и большого значения

Отсюда – правильная процедура смены адреса. Если просто поменять A-запись с большим TTL, часть пользователей еще полдня будут ходить на старый IP, пока их кеш не протухнет. Поэтому:

Правильная процедура смены адреса: снизить TTL, дождаться, поменять, вернуть

Это классическая причина инцидента «поменяли DNS, у половины пользователей старый сайт». Кеш не виноват – виноват тот, кто не снизил TTL заранее.

/etc/hosts против DNS

/etc/hosts – локальный файл на машине, который проверяется до обращения к DNS. Что бы ни было в нем записано, оно перебивает любой ответ DNS.

IP          имя       [алиасы]
127.0.0.1   localhost
10.0.0.20   backend   backend.local

Чем полезен:

• разработка – 127.0.0.1 my-app.local, чтобы локальное приложение отвечало по красивому имени
• тестирование – прибить конкретный IP к домену и проверить новый сервер, не трогая настоящий DNS
• быстрая блокировка – 0.0.0.0 doubleclick.net, чтобы домен никуда не вел

Обратная сторона: про захардкоженную запись легко забыть. Классика – прописали тестовый IP в /etc/hosts, потестировали, забыли стереть. Через месяц сервер сменил адрес, у всех все работает, а у вас одного – нет, потому что машина упрямо ходит по старому IP из hosts.

Полезный прием при отладке: getent hosts <имя> резолвит через все источники сразу (сначала hosts, потом DNS) – ровно так, как это делают приложения. А dig спрашивает только DNS. Если getent hosts отвечает, а dig молчит – значит, запись сидит в /etc/hosts, а не в DNS.

/etc/resolv.conf

Файл, из которого система берет DNS-серверы для резолва:

nameserver 8.8.8.8
nameserver 1.1.1.1
search local internal
options ndots:1 timeout:2 attempts:2

• nameserver – какие DNS-серверы спрашивать и в каком порядке
• search – домены, которые подставляются к коротким именам: с search local команда ping backend сначала попробует backend.local
• options timeout:2 – сколько секунд ждать ответа, прежде чем идти к следующему серверу

Важный нюанс: на большинстве современных систем этим файлом управляет systemd-resolved или NetworkManager. Если поправить его руками, изменения могут перезатереться при следующем обновлении сети. Чтобы поменять DNS надолго, обычно нужно настраивать тот сервис, который управляет файлом, а не сам файл.

Инструменты диагностики

dig – основной DNS-инструмент. Делает запрос и подробно показывает, что вернулось:

dig prostodevops.ru                # A-запись (по умолчанию)
dig prostodevops.ru +short         # только IP, без шапки — удобно для скриптов
dig prostodevops.ru MX             # почтовые серверы
dig prostodevops.ru TXT            # TXT-записи
dig @8.8.8.8 prostodevops.ru       # спросить конкретный сервер
dig -x 109.71.241.113              # обратный поиск (PTR): IP → имя
dig prostodevops.ru +trace         # пройти всю цепочку от корней вручную

В выводе главное – секция ;; ANSWER SECTION, там сам ответ и его TTL. Флаг +trace показывает всю цепочку резолва (корни → зона → authoritative) – незаменим, когда нужно понять, на каком звене теряется ответ.

getent hosts <имя> – резолв через всю цепочку системы (hosts → DNS), как у приложений. Лучший способ проверить, что увидит ваша программа, а не только DNS.

host – самый лаконичный: host prostodevops.ru выдаст ответ одной строкой.

nslookup – старая утилита, проще dig, но менее информативна. Встретите на машинах, где dig не установлен.

Типичные проблемы и как чинить

Name or service not known – резолв не сработал вообще. Проверяем по шагам:

Name or service not known: проверка резолва по шагам

dig отвечает SERVFAIL – DNS-сервер не смог получить ответ. Часто проблема на стороне authoritative-сервера домена: домен «протух», не оплачен или неправильно настроен. Проверьте, кто за него отвечает: dig <домен> NS.

dig отвечает NXDOMAIN – такого домена не существует. Либо опечатка в имени, либо домен реально удален или не зарегистрирован.

Резолв идет долго – /etc/resolv.conf указывает на недоступный сервер: система ждет timeout секунд, потом пробует следующий. Помогает options timeout:2 attempts:2 или смена DNS на рабочий.

Поменяли A-запись, но видно старый IP – TTL еще не истек. Посмотрите текущий TTL в выводе dig <домен>. Локальный кеш можно сбросить принудительно:

sudo resolvectl flush-caches          # современные системы
# либо устаревший алиас:
sudo systemd-resolve --flush-caches
# либо полный рестарт сервиса:
sudo systemctl restart systemd-resolved

Словарь