DNS: как имя сайта превращается в IP-адрес

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

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

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

Имя читается справа налево, от общего к частному. В shop.example.ru крайняя правая часть ru — домен верхнего уровня, example — домен второго уровня, shop — поддомен. Формально справа есть ещё и корень, просто его точку обычно не пишут.

Что происходит, когда ответа нет в кеше

• Резолвер спрашивает корневые серверы: кто отвечает за зону ru?

• Получает адреса серверов зоны ru и спрашивает уже их: кто отвечает за example.ru?

• Получает адреса серверов домена и наконец спрашивает у них саму запись для shop.example.ru.

• Отдаёт ответ клиенту и кладёт его в кеш.

Всю эту работу за вас делает один рекурсивный сервер: домашний роутер, сервер провайдера или публичный вроде 8.8.8.8 и 1.1.1.1. Клиент задаёт один вопрос и получает один ответ — цепочка скрыта от него полностью. Занимает она обычно десятки миллисекунд, а при попадании в кеш — доли.

Авторитетный и рекурсивный

Эти два слова постоянно встречаются в документации, и разница между ними простая. Авторитетный сервер хранит саму зону и является источником истины для своих доменов. Рекурсивный ничего своего не хранит, а бегает по авторитетным и кеширует то, что нашёл. Публичные 8.8.8.8 и 1.1.1.1 — рекурсивные; серверы, указанные в NS-записях вашего домена, — авторитетные.

Две ловушки с CNAME

Первая: CNAME нельзя поставить на корень домена — там должна быть A-запись. Многие хостинги обходят ограничение собственными нестандартными типами вроде ALIAS, но классический DNS так не умеет.

Вторая: если на имени стоит CNAME, других записей на нём быть не должно. Попытка добавить рядом MX ломает разрешение имени целиком. Обе ошибки встречаются регулярно при переезде сайта на внешний сервис.

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

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

Сколько ставить

Обычное значение для стабильной записи — час или сутки: меньше запросов, быстрее отклик. Для записей, которые могут переехать (балансировка, аварийное переключение), ставят минуты. Совсем маленький TTL вроде 30 секунд имеет смысл только на время переезда: постоянно он лишь увеличивает нагрузку и задержки.

Базовый инструмент — nslookup example.ru, он есть везде. В Linux удобнее dig example.ru: показывает и сам ответ, и остаток TTL, и кто ответил. Проверить конкретный сервер, минуя свой, можно так: nslookup example.ru 8.8.8.8 — приём незаменим, когда нужно понять, проблема у вас или у всех.

Главный диагностический приём

Сравните ping по имени и по адресу. Если по адресу узел отвечает, а по имени нет, сеть в порядке и разбираться нужно с DNS: не тот сервер выдан по DHCP, служба не отвечает, запись не создана или ещё не разошлась по кешам. Локальный кеш сбрасывается командой ipconfig /flushdns в Windows и перезапуском соответствующей службы в Linux.

Классический DNS-запрос идёт открытым текстом по UDP-порту 53. Само содержимое сайта может быть зашифровано, но факт обращения к домену виден всем по пути — и провайдеру, и соседу по публичному Wi-Fi.

Для этого и появились DoH и DoT — тот же DNS, упакованный в шифрованное соединение. Разница между ними в том, что DoT использует отдельный порт и легко отличим в трафике, а DoH маскируется под обычный HTTPS. Браузеры всё чаще включают такое по умолчанию, и об этом стоит помнить админу: локальная фильтрация по DNS в этот момент просто перестаёт работать, потому что запросы уходят мимо неё.

Отдельная история — DNSSEC. Он не шифрует запросы, а подписывает ответы, чтобы по дороге их нельзя было подменить. Задачи у этих технологий разные, и одна другую не заменяет: DoH прячет содержание запроса, DNSSEC гарантирует подлинность ответа.

Как только в сети появляется больше нескольких серверов, обращаться к ним по адресам становится неудобно. Решается это внутренним DNS: небольшая служба вроде dnsmasq или Pi-hole на домашнем сервере раздаёт имена вида nas.home и заодно кеширует внешние запросы.

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

Одно имя — два ответа

Отдельный приём — split-horizon: одно и то же имя отдаёт внутренний адрес для тех, кто в локальной сети, и внешний для всех остальных. Именно так обходят проблему с NAT, когда собственный сервер не открывается по публичному адресу изнутри.

Два предостережения. Не используйте для внутренней зоны выдуманные окончания вроде .local — оно занято протоколом mDNS, и конфликты в работе гарантированы; лучше взять поддомен своего реального домена. И помните, что браузер с включённым DoH ходит мимо системного DNS: внутренние имена в нём перестанут открываться, и это именно настройка браузера, а не поломка сети.

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

Командная строка идёт в системный резолвер — туда, где прописаны DNS-серверы из DHCP или настроек адаптера. Браузер может ходить мимо: при включённом DoH он обращается к собственному серверу по HTTPS, а ещё держит свой кеш, который живёт дольше системного и не сбрасывается вместе с ним.

Отсюда и порядок проверки. Сначала nslookup — он показывает, что видит сама система. Если там всё в порядке, а браузер не согласен, смотрите его настройки безопасного DNS и чистите внутренний кеш, а не сетевые параметры машины.