Что такое DNS и как он работает на самом деле

К каждому устройству в интернете можно обратиться по числовому адресу, то есть по IP-адресу. Никому не хочется помнить 172.64.80.1, поэтому мы пользуемся именами: example.com. DNS, система доменных имён, — это служба каталога, которая переводит введённое вами имя в адрес, который на самом деле нужен компьютеру. О ней легко забыть именно потому, что она так надёжно работает в фоне почти каждого вашего сетевого запроса.

Поиск шаг за шагом

Когда вы впервые заходите на домен, ваше устройство ещё не знает его IP-адрес. Оно просит узнать его резолвер, как правило принадлежащий провайдеру или публичному сервису вроде Cloudflare или Google. Резолвер тоже не обязательно знает ответ, поэтому проходит по цепочке полномочий:

1. Корневой сервер направляет его к серверам, отвечающим за домен верхнего уровня (.com, .org, .io и так далее).
2. Сервер TLD направляет его к авторитативным серверам имён конкретного домена: тем, которые на самом деле настроил владелец домена.
3. Авторитативный сервер имён возвращает саму запись: IP-адрес (или адреса), на который домен указывает в данный момент.

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

Конкретная трассировка от начала до конца

Допустим, резолверу с пустым кешем нужно разрешить blog.example.com. Сначала он спрашивает корневой сервер, который не знает ответа, но знает, кто отвечает за .com, и направляет резолвер туда. Сервер TLD .com тоже не знает окончательного ответа, но знает, каким серверам имён делегирован сам домен example.com (скажем, ns1.dnshost.com и ns2.dnshost.com), и направляет резолвер уже к ним. Только теперь резолвер обращается к серверу, который действительно хранит записи example.com, и этот авторитативный сервер отвечает настоящим ответом: записью A или CNAME, по которой нужно пройти ещё один шаг. Каждый шаг этой цепочки — тоже DNS-запрос, поэтому самый первый («холодный») запрос по домену заметно медленнее всех последующих, когда промежуточные ответы уже закешированы.

Кеширование происходит не только на уровне резолвера

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

Типы записей, с которыми вы действительно столкнётесь

«DNS-запись» — это не что-то одно: у домена рядом хранится несколько разных типов записей, и каждый отвечает на свой вопрос. Проверка IP-адреса домена затрагивает только два из них; остальные существуют для совершенно других целей.

Почему это важно, даже если вы никогда не правите DNS-записи сами

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

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