Когда человек вводит адрес сайта в браузере, браузер ещё не знает, где находится этот сайт. Ему известны только буквы доменного имени. Чтобы открыть страницу, это имя нужно связать с конкретным сервером в интернете. Эту работу выполняет DNS.
Снаружи всё происходит почти мгновенно. Но за несколько долей секунды браузер, операционная система и DNS-серверы успевают пройти цепочку запросов, найти нужный IP-адрес и только после этого обратиться к веб-серверу. Понимание этой цепочки особенно полезно при переносе сайта, смене сервера или поиске ситуации, когда по IP всё работает, а по домену — нет.
Домен — это имя, а не место
Домен удобно сравнить с названием места в адресной книге. Он позволяет человеку запомнить понятное имя вместо набора цифр IP-адреса.
Но сам домен не содержит страниц сайта и не является сервером. Регистрация доменного имени означает только то, что его владелец получил право управлять этим именем в определённой доменной зоне.
Где находится сайт, определяется отдельно. Для этого у домена существуют DNS-записи. Именно они сообщают остальному интернету, куда нужно обращаться, когда кто-то хочет открыть сайт, отправить ему почту или воспользоваться другим сервисом.
Что происходит после ввода адреса
Представим, что человек набирает в браузере https://example.com. Первым делом браузеру требуется IP-адрес сервера. Без него установить соединение невозможно.
Прежде чем отправлять запрос в интернет, компьютер обычно проверяет, не знает ли он ответ уже сейчас. DNS-данные могут храниться в кэше браузера, операционной системы, домашнего роутера или DNS-сервера интернет-провайдера.
Если готового ответа нет, начинается поиск. Запрос постепенно доходит до DNS-системы, которая знает, какие серверы отвечают за нужную доменную зону и где находятся авторитетные DNS-серверы конкретного домена. В итоге возвращается запись с адресом сервера.
После этого DNS на время отходит в сторону. Браузер уже знает IP и может начать обычное соединение с сервером: установить HTTPS-сессию, отправить HTTP-запрос и получить страницу.
Эта короткая цепочка объясняет значительную часть того, что происходит при открытии любого сайта.
Кто хранит правильный ответ
У DNS нет единственной всемирной таблицы, в которой записаны адреса всех сайтов. Система распределённая.
За разные части пространства имён отвечают разные серверы. В конце цепочки находятся авторитетные DNS-серверы — источник данных именно для конкретного домена.
Их адреса задаются через записи NS. Если управление DNS происходит у регистратора или отдельного DNS-провайдера, именно его серверы обычно становятся авторитетными и хранят созданные владельцем записи.
Основные DNS-записи
Для обычного сайта чаще всего приходится иметь дело всего с несколькими видами записей.
A-запись связывает имя с IPv4-адресом. Например: example.com → 203.0.113.10. Если пользователь открывает example.com, DNS возвращает этот адрес, после чего браузер идёт на нужный сервер.
Для IPv6 существует аналогичная AAAA-запись.
CNAME работает немного иначе. Она сообщает, что одно имя является псевдонимом другого имени. Например: www.example.com → example.com. В этом случае для www.example.com не обязательно отдельно хранить IP: DNS сначала узнаёт, к какому имени относится CNAME, а затем получает адрес уже для него.
Кроме записей, связанных с сайтом, существуют MX для почты, TXT для текстовой информации и подтверждений различных сервисов, а также другие типы.
Почему изменение DNS видно не сразу
Одна из самых неприятных особенностей DNS становится заметна во время переноса сайта. Запись уже изменена, панель управления показывает новый IP, один компьютер открывает новый сервер — а другой всё ещё видит старый.
Чаще всего это не ошибка. DNS активно использует кэширование. Если бы каждый браузер при каждом открытии страницы проходил всю цепочку поиска заново, система работала бы значительно медленнее и создавала огромную лишнюю нагрузку.
Поэтому полученный ответ сохраняется на некоторое время. Срок хранения задаётся параметром TTL — Time To Live.
Если DNS-сервер получил запись с TTL в 3600 секунд, он может использовать её из своего кэша до часа, не обращаясь к авторитетному серверу повторно.
Из-за этого после изменения записи в интернете некоторое время могут одновременно существовать два правильных с точки зрения кэша ответа: старый и новый.
Что на самом деле означает «DNS распространяется»
Часто говорят, что после изменения записи нужно ждать, пока DNS «распространится по интернету». Это удобное выражение, но технически картина немного другая.
Новая запись не путешествует от сервера к серверу, постепенно захватывая интернет. Авторитетный DNS уже может выдавать новый ответ почти сразу после изменения.
Проблема в том, что множество промежуточных DNS-серверов всё ещё имеют старый ответ в своих кэшах и имеют право использовать его до окончания TTL.
По мере истечения этих сроков серверы снова запрашивают информацию и начинают получать новое значение. То, что выглядит как распространение новой записи, во многом является постепенным исчезновением старых кэшированных ответов.
Почему сайт может открываться по IP, но не по домену
Такая ситуация особенно полезна для диагностики. Если сервер доступен напрямую по IP, это означает, что до машины в принципе можно добраться по сети.
Но если домен по-прежнему не работает, проблема может находиться на другом уровне: DNS возвращает старый адрес, используется неправильная запись, кэш ещё не обновился или веб-сервер не настроен обслуживать запросы с этим доменным именем.
То есть успешный ответ по IP ещё не доказывает, что весь сайт настроен правильно. И наоборот: правильная DNS-запись тоже не гарантирует работу страницы. Она лишь приводит пользователя на нужный сервер. После этого должны правильно работать веб-сервер, HTTPS и сам сайт.
DNS и HTTPS связаны, но это разные вещи
Иногда эти две системы воспринимаются как единое целое, потому что проблемы с ними особенно часто появляются во время запуска сайта.
На самом деле их задачи различаются. DNS помогает браузеру найти сервер. HTTPS после этого помогает установить защищённое соединение и удостовериться, что сервер действительно имеет право обслуживать нужный домен.
Поэтому вполне возможна ситуация, когда DNS уже указывает на новый сервер, но браузер показывает ошибку сертификата. В этот момент дальнейшее изменение DNS обычно ничего не исправит: запрос уже приходит туда, куда нужно.
Нужно проверять сертификат и конфигурацию веб-сервера. Такое разделение на уровни — один из самых удобных способов искать сетевые проблемы.
Как безопасно перенести сайт на другой сервер
Предположим, сайт уже работает на старом сервере, но его нужно перенести на новый.
Самый рискованный вариант — сначала изменить DNS, а затем начинать настраивать новую машину. В этот момент часть пользователей уже может попасть на сервер, который ещё не готов.
Надёжнее действовать наоборот. Сначала новая версия сайта полностью готовится на новом сервере. Проверяются файлы, веб-сервер, HTTPS и необходимые маршруты. Желательно убедиться, что сайт правильно работает на новом IP ещё до изменения публичной DNS-записи.
Только после этого домен переключается на новый адрес. Некоторое время старый сервер лучше не выключать. Из-за DNS-кэша часть посетителей всё ещё может приходить именно туда.
Когда становится понятно, что старый IP больше практически не используется и кэшированные записи истекли, прежний сервер можно выводить из эксплуатации.
TTL полезно учитывать заранее
Если известно, что через несколько дней предстоит перенос крупного сайта, TTL можно заранее уменьшить.
Например, запись, которая обычно кэшируется несколько часов, временно настраивается на более короткий срок. Затем нужно дождаться, когда прежний длинный TTL перестанет действовать.
После этого будущее изменение IP начнёт замечаться DNS-серверами значительно быстрее. Когда перенос завершён и работа стабилизировалась, TTL можно вернуть к обычному значению.
Для небольшого сайта такая подготовка не всегда необходима, но сам принцип хорошо показывает важную особенность DNS: скорость переключения определяется не только моментом изменения записи, но и тем, какие данные уже находятся в кэшах.
Как проверять DNS без догадок
При проблемах с доменом лучше не ориентироваться только на то, что показывает один браузер.
Браузер, компьютер, роутер и провайдер могут использовать собственные кэши. Поэтому одна и та же страница в этот момент способна открываться по-разному на двух устройствах.
Надёжнее сравнить несколько уровней. Сначала проверить, что записано на авторитетном DNS-сервере. Затем посмотреть, какой ответ дают независимые публичные DNS-серверы. После этого проверить, на какой IP фактически идёт соединение.
Если авторитетные серверы уже возвращают новый адрес, а отдельное устройство получает старый, причина почти наверняка связана с кэшем, а не с необходимостью снова менять DNS-зону.
Не меняйте несколько уровней одновременно
DNS редко существует сам по себе. Рядом находятся веб-сервер, сертификаты, firewall, IP-адреса и файлы сайта.
Из-за этого появляется соблазн при первой ошибке начать менять всё сразу: A-запись, конфигурацию Nginx, сертификат и настройки сервера.
После такого ремонта даже успешный результат мало что объясняет — неизвестно, какое именно изменение помогло.
Гораздо надёжнее рассматривать путь запроса последовательно:
Если DNS возвращает правильный IP, этот этап можно считать проверенным и двигаться дальше. Если HTTPS-соединение устанавливается, не нужно возвращаться и снова менять DNS. Каждая успешная проверка уменьшает область поиска.
Старый сервер не всегда виноват
После переноса бывает довольно убедительная иллюзия: пользователь видит старую страницу и решает, что новый сервер почему-то продолжает отдавать старые файлы.
Но запрос может вообще не доходить до нового сервера. Если устройство использует закэшированную DNS-запись, оно по-прежнему обращается к старому IP. Изменение файлов на новом сервере в такой ситуации ничего не даст.
Поэтому при неожиданной старой версии страницы стоит сначала определить, на какой IP фактически пришёл запрос. Это простой вопрос, который часто экономит много лишней работы.
DNS должен быть скучным
Хорошо настроенный DNS редко напоминает о себе.
Записи меняются нечасто, структура понятна, ненужные значения не копятся годами, а владелец знает, где находятся авторитетные серверы и какой IP должен получать посетитель.
Именно к такому состоянию стоит стремиться. DNS не обязан быть сложной магией между доменом и сайтом. В основе всё довольно последовательно: имя получает адрес, браузер идёт по этому адресу, а остальные системы уже отвечают за соединение и страницу.
Когда эта граница понятна, переносы серверов и поиск неисправностей становятся заметно спокойнее.
Что дальше
После того как домен привёл браузер на правильный сервер, начинается следующий этап: запрос должен принять веб-сервер.
Именно он решает, какой сайт показать, где находятся его файлы, что делать с HTTP и HTTPS и как обслуживать несколько доменов на одной машине.