Как работает 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 (сервер лежит) — это разные инциденты с разными ответственными.
Команда 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-записи, срок домена и резолвинг из 13 точек — 11 из них в России — изменения и сбои видны до того, как их заметят посетители. Уведомления приходят в Email, Telegram, Макс или звонком; бесплатного тарифа хватает на 5 проверок.