Как работает DNS: путь от адреса сайта до IP простыми словами
6 мин чтения Обновлено:
Как работает DNS: путь от адреса сайта до IP простыми словами

Как работает DNS: путь от адреса сайта до IP простыми словами

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

DNS (Domain Name System) — это распределённая система, которая превращает доменные имена в IP-адреса. Люди запоминают имена вроде prufen.ru, а сетевое оборудование маршрутизирует пакеты по числовым адресам. DNS — переводчик между этими мирами: гигантский телефонный справочник, разрезанный на миллионы кусочков, которые хранятся на разных серверах по всему интернету.

Путь запроса: четыре остановки

Вы вводите адрес в браузер. Если ответа нет в кэше (о кэшах ниже), запрос отправляется рекурсивному резолверу — обычно это сервер вашего провайдера либо публичный резолвер вроде Яндекс DNS, Google 8.8.8.8 или Cloudflare 1.1.1.1. Резолвер — «личный ассистент», который берёт на себя все дальнейшие переговоры.

Остановка 1 — корневые серверы. Резолвер спрашивает один из 13 корневых серверов (точнее, одну из сотен их копий по всему миру): «Где искать .ru?» Корневой сервер сам адресов сайтов не знает — он знает только, кто отвечает за каждую доменную зону верхнего уровня.

Остановка 2 — серверы зоны .ru. Они отвечают: «Домен prufen.ru обслуживают вот такие авторитативные серверы» — и называют их имена. Это как справочная, которая не знает номер квартиры, но знает адрес дома.

Остановка 3 — авторитативные серверы домена. Это серверы, на которых лежит зона домена — тот самый кусочек справочника с записями: A-запись с IPv4-адресом, AAAA с IPv6, MX для почты и остальные. Какие бывают записи и за что каждая отвечает, мы разбирали в отдельной статье. Авторитативный сервер отдаёт финальный ответ: «prufen.ru — это такой-то IP».

Остановка 4 — обратно к вам. Резолвер возвращает адрес браузеру, попутно запомнив его у себя. Браузер устанавливает соединение с сервером — начинается собственно загрузка сайта.

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

Кэш: почему DNS быстрый и почему из-за этого бывают проблемы

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

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

Запомнить

DNS-изменения не «применяются» в один момент — они расползаются по кэшам постепенно, со скоростью истечения TTL. Планируете переезд — снизьте TTL заранее, за сутки-двое.

Что может сломаться

DNS ломается реже, чем сами сайты, но когда ломается — сайт «исчезает из интернета» целиком, со всей почтой и поддоменами. Типовые сценарии, в порядке убывания частоты:

Что случилось Как выглядит для посетителя
Домен не продлили — записи удалены из зоны Ошибка NXDOMAIN: «сайта не существует»
Ошибка при правке записей (опечатка в IP, удалили A-запись) Сайт не открывается или открывается чужой
Упали авторитативные серверы (у регистратора или DNS-хостинга) Сайт «мигает»: у кого ответ в кэше — работает, у остальных нет
Угон домена или подмена записей после взлома аккаунта Посетители уходят на подставной сервер
Сбой резолвера у конкретного провайдера Сайт недоступен только части аудитории

Коварство DNS-проблем в том, что из-за кэшей они проявляются не сразу и не у всех. После ошибочной правки сайт может «работать» для вас ещё сутки — вы смотрите на кэшированный ответ, а новые посетители уже уходят в никуда. Ошибки резолвинга на стороне посетителя выглядят как DNS_PROBE_FINISHED_NXDOMAIN или ERR_NAME_NOT_RESOLVED — у нас есть разборы обеих.

Кто за что отвечает: регистратор, DNS-хостинг, хостинг сайта

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

Регистратор домена — тот, у кого домен куплен и продлевается. Он записывает в зону .ru, какие серверы авторитативны для вашего домена (NS-записи). Не продлили домен — виноват не хостинг: записи исчезают на уровне регистратора.

DNS-хостинг — тот, чьи авторитативные серверы хранят ваши записи. Часто это тот же регистратор или хостинг сайта, но бывает и отдельный сервис. Правите A-запись или MX — вы делаете это здесь. Если упали эти серверы, домен перестаёт резолвиться у всех, чей кэш успел остыть.

Хостинг сайта — тот, на чьём сервере лежат файлы. К DNS он отношения не имеет, кроме одного: его IP-адрес записан в вашей A-записи. Сайт может «не работать» при живом хостинге (сломан DNS) и «не резолвиться» при живом DNS (сервер лежит) — это разные инциденты с разными ответственными.

Проверьте прямо сейчас: где ваши NS?

Команда dig ваш-домен.ru NS +short покажет, чьи серверы обслуживают домен. Удивительно, как часто владельцы уверены, что DNS «у хостинга», а он остался у старого регистратора с прошлой жизни сайта — и доступ к нему давно потерян. Лучше выяснить это в спокойный день, а не во время инцидента.

DNS и скорость сайта

Резолвинг — первый пункт в хронометраже загрузки страницы: пока имя не превратилось в адрес, не начинается ни TLS-рукопожатие, ни передача данных. У постоянных посетителей он бесплатен (кэш), но для новых — а это весь рекламный трафик — добавляет свои десятки миллисекунд к TTFB. Практические следствия: авторитативные серверы должны быть быстрыми и географически близкими к аудитории (для российской аудитории — с точками в России), а экзотика вроде цепочек CNAME через три сервиса удлиняет резолвинг на ровном месте: каждый CNAME — дополнительный цикл запросов.

Как проверить DNS своего сайта

Разовая диагностика делается командой nslookup или dig:

dig prufen.ru A +short
# сравнить ответы разных резолверов:
dig @77.88.8.8 prufen.ru +short # Яндекс DNS
dig @8.8.8.8 prufen.ru +short # Google

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

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

DNS — слепая зона большинства мониторингов

Пруфен проверяет не только «жив ли сайт», но и сами DNS-записи, срок домена и резолвинг из 13 точек — 11 из них в России — изменения и сбои видны до того, как их заметят посетители. Уведомления приходят в Email, Telegram, Макс или звонком; бесплатного тарифа хватает на 5 проверок.

Была ли статья полезна?

Начните мониторинг прямо сейчас

Бесплатный тариф — до 5 проверок. 150 ₽ на баланс при регистрации.

Создать аккаунт