Сеть работает с адресами, человек — с именами. DNS (Domain Name System) — служба, которая превращает имя в адрес.

Ценность не только в удобстве запоминания. Адрес сервера можно поменять — переехать к другому провайдеру, добавить второй сервер, увести трафик на резервную площадку, — и снаружи ничего не изменится: имя останется тем же. Привязка «имя → адрес» становится точкой управления, а не просто справочником.

DNS устроен как дерево, и читается имя справа налево. В имени www.example.com самая правая часть — не www, а невидимый корень, затем com (домен верхнего уровня), затем example, и только потом www.

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

Такое разделение и позволяет системе работать в мировом масштабе: полного списка имён не существует нигде.

Хост задаёт один вопрос своему резольверу (это тот самый адрес DNS из настроек) — и ждёт готовый ответ. Дальше бегает резольвер:
• спрашивает корневой сервер — получает «иди к серверам com»;
• спрашивает сервер com — получает «иди к серверам example.com»;
• спрашивает сервер example.com — получает адрес.

Запрос хоста называется рекурсивным («принеси готовый ответ»), а запросы самого резольвера — итеративными («скажи, что знаешь, дальше я сам»).

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

A — имя → IPv4-адрес. Самая частая.
AAAA — имя → IPv6-адрес.
CNAME — имя → другое имя (псевдоним). Позволяет держать адрес в одном месте: поменяли его там — поменялось у всех псевдонимов.
MX — куда доставлять почту для домена.
NS — какие серверы отвечают за зону. Именно эти записи делегируют уровень ниже.
PTR — адрес → имя, обратное преобразование.
TXT — произвольный текст; на нём держатся подтверждение владения доменом и почтовые политики.

Одному имени может соответствовать несколько записей A с разными адресами — это простейшая балансировка: резольверы получают их в разном порядке.

Каждая запись отдаётся вместе с TTL — временем, в течение которого её разрешено хранить в кеше. Кеширует резольвер, кеширует операционная система, кеширует браузер.

Отсюда главная практическая особенность DNS: изменение распространяется не мгновенно, а по мере истечения TTL. Поменяли адрес сайта с TTL в сутки — часть мира будет ходить на старый адрес ещё сутки, и никакая перезагрузка сервера этого не ускорит.

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

Обычный запрос отвечает на вопрос «какой адрес у этого имени». Обратный — на противоположный: «чьё имя у этого адреса». Нужен он в трёх ситуациях, и все три встречаются в работе постоянно.

Разбор журналов и диагностика. В логах, в выводе traceroute, в списке подключений вы видите голый адрес. Понять по нему, чей это узел, невозможно — а по имени часто сразу видно и организацию, и роль машины, и даже город. Поэтому утилиты спрашивают обратную зону сами: это ровно та причина, по которой tcpdump без ключа -n подтормаживает, а traceroute показывает не только адреса, но и имена промежуточных роутеров.

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

Подтверждение, что адрес и имя связаны по-настоящему. В прямой зоне владелец домена может назвать свой узел как угодно — объявить mail.google.com у себя никто не мешает. А вот обратную зону заполняет владелец блока адресов, обычно провайдер. Поэтому проверяющая сторона делает два шага: спрашивает имя по адресу, а потом адрес по этому имени — и сверяет, сошлось ли. Совпало — связь подтверждена обеими сторонами, а подделать её в одиночку нельзя.

Как устроено. Обратное преобразование живёт в отдельной зоне in-addr.arpa, а адрес в ней записывается задом наперёд: для 203.0.113.5 это 5.113.0.203.in-addr.arpa. Причина в той же иерархии: доменное имя читается справа налево, от корня к узлу, а у адреса старшая часть слева. Развернув адрес, его приводят к тому же порядку — и обратная зона делится между владельцами так же, как делятся сами блоки адресов.

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

Работает по адресу, не работает по имени. Классика, которая сразу указывает на DNS, а не на сеть. Проверяется одной командой: ping 1.1.1.1 идёт, ping ya.ru — нет.

Сайт «не переехал». У вас открывается новый сервер, у коллеги старый. Никто не виноват — просто у него в кеше запись со старым адресом, и она ещё жива.

Единственный резольвер. Указан один DNS-сервер, он недоступен — и сеть выглядит полностью мёртвой, хотя работает целиком.

Резольвер отвечает, а ответ пустой. Домен не существует (NXDOMAIN) или зона отдана серверам, которые про неё не знают — делегирование настроено, а данных нет.

dig example.com — что отвечает резольвер и с каким TTL. Смотреть на TTL полезно: маленькое значение означает, что ответ только что получен, большое — что лежит в кеше давно.

dig @8.8.8.8 example.com — спросить конкретный сервер в обход своего. Если чужой отвечает, а свой нет — проблема в вашем резольвере, а не в домене.

dig +trace example.com — пройти цепочку от корня целиком и увидеть, на каком уровне она обрывается.

dig -x 203.0.113.5 — обратный запрос.

Первый вопрос при любой жалобе: «по адресу работает?» Ответ на него делит проблему пополам.