Что такое домен, IP и DNS простыми словами

Пятница, вечер, сайт клиента лежит: домен куплен, сервер оплачен, а по имени страница не открывается. Домен это имя сайта, IP это номер сервера в сети, DNS это служба, которая переводит имя в номер. Ниже разбор той самой задачи от первого захода до рабочего результата.

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

Что за задача стояла и почему сайт не открывался по имени?

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

Сервер сам по себе уже работал. По номеру сайт открывался, страницы отдавались, база отвечала. Если слово «сервер» пока звучит абстрактно, рядом лежит разбор про то, что такое сервер простыми словами. Номер был, имя было, связи между ними не было.

Домен это адрес для человека. Номер IP это адрес для машины. Человеку удобно запомнить короткое слово, машине нужен ряд цифр, и перевод между ними выполняет отдельная служба. Её и называют DNS, системой доменных имён.

У имени есть уровни, и читаются они справа налево. Справа стоит зона верхнего уровня, например ru, левее имя второго уровня, которое и покупают у регистратора, ещё левее поддомены вроде blog. Корневой домен находится в самом конце цепочки, и именно с него начинается любой поиск.

Внутри зоны живут записи, и каждая отвечает за свой вопрос. Запись типа A отдаёт номер IPv4, запись AAAA отдаёт номер новой версии протокола, CNAME делает одно имя псевдонимом другого, MX указывает на почтовый сервер, TXT хранит служебные строки для подтверждений. Записи NS стоят особняком: они сообщают, кто вообще имеет право отвечать за эту зону. На них я и споткнулся.

Как я подошёл к задаче на первом заходе?

Итог раздела: открыл панель регистратора, нашёл раздел с записями, вписал номер сервера в поле записи типа A и нажал «сохранить». План выглядел здраво: имя указывает на сервер, браузер спрашивает у DNS, DNS отдаёт номер, страница открывается. Логика верная, порядок действий тоже, промах прятался в другом месте.

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

Номер сервера взял в панели хостинга. Это обычный адрес IPv4, четыре числа через точку. Кому нужна подробность про адресацию, у нас разложено, как устроен адрес IP и откуда он берётся, а здесь я держу фокус на связке имени с сервером.

Дальше собрал минимальный набор записей: запись типа A для основного имени, такая же для www, запись MX для почты, запись TXT для подтверждения прав на домен. Набор стандартный. В любой панели поля называются похоже, отличается только оформление.

Мысленно я держал такую картинку. Браузер адресов не знает, он спрашивает у резолвера провайдера. Резолвер, если ответа в памяти нет, идёт к корневым серверам, у них узнаёт, кто держит зону ru, у той зоны узнаёт, кто держит наше имя, и уже там забирает номер. Цепочка длинная, отрабатывает за доли секунды и для человека полностью прозрачна.

Что пошло не так на первом заходе?

Итог раздела: сайт не открылся. Я правил записи в панели регистратора, хотя имя было делегировано на серверы хостера, и мои значения уходили в зону, которую сеть даже не спрашивала. Вторым слоем легли кэши: браузер, операционная система и резолвер провайдера держали старый ответ. Третьим промахом стала забытая запись для www.

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

Спас телефон. Я отключил домашнюю сеть, зашёл через мобильный интернет и увидел ту же заглушку. Кэш домашнего роутера отпал как версия, значит дело было в самих записях.

Проверка делегирования всё объяснила. Записи NS у регистратора указывали на серверы имён хостера, а редактор записей в панели регистратора правил свою копию зоны, которую никто не опрашивал. Панель честно показывала мои значения. Отвечал посетителям совсем другой сервер.

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

Как я чинил это по шагам?

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

1. Посмотрел делегирование. Запрос типа NS показывает, какие серверы имён отвечают за зону. Это первый вопрос при любой проблеме с доменом.
2. Перешёл в ту панель, куда делегировано имя. Все дальнейшие правки только там, вторая панель закрыта и забыта.
3. Завёл запись типа A на номер сервера для основного имени и отдельную запись для www. Обе нужны сразу.
4. Укоротил время жизни записи. Пока идут работы, короткое значение экономит нервы: кэши обновляются заметно быстрее.
5. Проверил ответ напрямую. Запросил запись у публичного сервера имён и убедился, что отдаётся нужный номер.
6. Сбросил кэш резолвера на своей машине и перезапустил браузер. Только после этого стал верить тому, что вижу в окне.
7. Вернул время жизни к спокойному значению, когда всё заработало.

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

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

Что получилось в итоге?

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

Работает вся конструкция так. Браузер спрашивает у резолвера, резолвер идёт к корневым серверам, оттуда к серверам зоны, получает номер и отдаёт его обратно. Браузер стучится на этот номер. Сервер отдаёт страницу.

Привычка, которая осталась после того вечера: проверять по списку. Ощущение «вроде открылось» подводит слишком часто, потому что открылось оно у вас, с вашим кэшем и вашим провайдером. Примерно так устроен и путь тестировщика ПО с нуля: сначала сценарий проверки, потом вывод.

Отдельно порадовал сертификат. Пока имя указывает мимо нужного сервера, проверка владения через файл на сайте не проходит, и по ней защищённое соединение не выпустить. Как только записи встали на место, сертификат оформился с первой попытки, и адресная строка перестала ругаться на небезопасное соединение.

Было и стало: что изменилось в настройках

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

Ни одна строка таблицы не про деньги и не про новое оборудование. Все пять про порядок действий.

Что из этого переносится на ваши задачи?

Итог раздела: правьте записи в той панели, куда делегировано имя, и проверяйте делегирование первым делом. Держите время жизни записей коротким, пока идут работы. Проверяйте результат запросом к службе имён, потому что браузер показывает свою память. И записывайте, что меняли: через месяц вы этого точно не вспомните.

• Первый вопрос при любой поломке домена звучит одинаково: какие серверы имён отвечают за зону прямо сейчас.
• Одно имя часто требует нескольких записей. Основная, www, почта, подтверждение прав.
• Кэш врёт по всей цепочке: в браузере, в системе, у провайдера. Три места, три способа сброса.
• Почтовые записи переносят отдельно и проверяют отдельно, письмом на живой ящик.
• Сертификат с проверкой через файл на сайте выпускается после того, как имя начало указывать на сервер. Порядок обратный не работает.

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

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

Кого после такого разбора тянет в разработку, тому пригодится дорожная карта для новичка в Go: там расписано, какой минимум навыков ждут от джуна на первом собеседовании.

Тем, кто ещё выбирает язык под серверную часть, полезно сравнение Python и Go для бэкенда. Сетевая база из этой статьи понадобится в обоих случаях одинаково.

Короткие ответы на частые вопросы

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

Чем домен отличается от адреса IP?

Домен это имя, которое читает человек. Адрес IP это номер, по которому устройство находят в сети. Одно имя может указывать на разные номера в разное время, и один номер может обслуживать много имён сразу. Имя вы арендуете у регистратора и продлеваете, номер выдаёт тот, у кого стоит сервер.

Можно ли открыть сайт без домена?

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

Сколько ждать, пока новые записи разойдутся по сети?

Столько, сколько указано во времени жизни записи, плюс запас на кэши по дороге. Если значение выставлено большим, ждать придётся дольше. Поэтому перед работами его укорачивают заранее, а после проверки возвращают обратно.

Почему сайт открывается у меня и не открывается у коллеги?

У вас разные резолверы и разные кэши. Ваш уже получил свежий ответ, а его резолвер пока держит старый. Проверить просто: попросите коллегу зайти с мобильного интернета, там цепочка кэшей другая.

Что делать, если браузер показывает старую версию сайта?

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

Нужно ли покупать домен и хостинг у одного поставщика?

Необязательно. Имя регистрируют в одном месте, зону можно обслуживать в другом, сайт держать в третьем. Условие одно: записи NS обязаны указывать туда, где вы реально редактируете зону. Иначе повторится ровно та история, с которой начался этот разбор.

Источники

• Координационный центр доменов .RU/.РФ: правила регистрации и делегирования доменных имён в российских зонах.
• ICANN: организация, отвечающая за распределение доменных имён и адресного пространства.
• IANA, корневая зона: реестр зон верхнего уровня и обслуживающих их серверов имён.
• RFC 1034: базовое описание системы доменных имён, понятия зоны, делегирования и кэширования.