SiteGuard4 ноября 202615 мин чтения

Что такое DNS и как доменное имя превращается в адрес сервера

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

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

Что такое DNS простыми словами

Аббревиатура DNS расшифровывается как Domain Name System. Удобно представить её распределённым справочником: пользователь знает название, а программа получает сведения, необходимые для обращения к сервису. Так, для имени сайта можно запросить адрес IPv4 или IPv6. Этот базовый принцип описан в объяснении DNS от Cloudflare.

Но DNS не является одним сервером со списком всех сайтов. Разные участники обслуживают разные части пространства имён. Одни серверы публикуют сведения о доменах, другие находят ответы для пользователей и временно сохраняют их. Благодаря разделению ролей владельцу проекта не требуется уведомлять каждый компьютер в интернете о смене своего сервера.

Разберём адрес https://shop.example.com/catalog/?page=2. Для поиска адреса сервера важно имя shop.example.com. Путь /catalog/, параметры страницы и протокол HTTPS относятся к следующим этапам обращения. DNS не выбирает товар в каталоге, не проверяет наличие страницы и не отправляет посетителю её HTML.

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

DNS-сервер: что это такое и какие бывают роли

DNS-сервер — программа или сервис, который принимает DNS-запросы и отвечает на них. За одним адресом сервиса может стоять распределённая инфраструктура. Главное — различать задачи её участников.

Терминология IETF различает рекурсивные резолверы и авторитетные серверы. Резолвер ищет ответ для клиента или использует сохранённый результат. Авторитетный сервер публикует данные зоны, за которую отвечает. Это две разные задачи, даже если их выполняет программное обеспечение одного семейства.

Участник	Что делает	Что важно понимать владельцу сайта
Клиентский резолвер на устройстве	Передаёт запрос от приложения настроенному DNS-сервису	Его настройки могут отличаться у посетителей
Рекурсивный резолвер	Находит ответ, обращаясь к другим серверам, или берёт его из кэша	Обычно это сервис провайдера, компании или публичного DNS-поставщика
Корневые серверы	Публикуют сведения корневой зоны, включая делегирование доменов верхнего уровня	Не содержат готовую страницу каждого сайта
Серверы зоны верхнего уровня	Помогают найти серверы делегированных доменов в своей зоне	Например, участвуют в поиске серверов для имени в .com
Авторитетные серверы зоны сайта	Отдают опубликованные записи обслуживаемой зоны	Именно здесь должны находиться актуальные данные проекта

Корневые серверы и серверы доменов верхнего уровня тоже авторитетны, каждый для своей зоны. В таблице они выделены по месту в иерархии. IANA описывает корневую зону как верхний уровень системы, состоящий прежде всего из делегирований доменов верхнего уровня.

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

Как работает DNS: путь от имени до адреса

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

Приложение запрашивает сведения об имени. Например, браузеру нужны адреса, по которым можно установить соединение.
Запрос получает выбранный рекурсивный резолвер. Он проверяет, есть ли пригодный сохранённый ответ.
При необходимости резолвер обращается к корню. Для имени в .com получает сведения, позволяющие продолжить поиск в этой зоне.
Сервер зоны .com указывает на серверы домена. Резолвер узнаёт, где искать авторитетные сведения для следующего уровня.
Авторитетный сервер возвращает данные. Это может быть адрес, ссылка на другое имя или ответ об отсутствии нужных сведений.
Резолвер передаёт результат клиенту. Полученные данные могут сохраняться на разрешённый срок.
Приложение продолжает работу. Браузер устанавливает соединение с выбранным адресом, проверяет HTTPS и запрашивает страницу.

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

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

Условный результат поиска может содержать несколько адресов. Приложение выбирает, как к ним подключаться, с учётом доступных протоколов и своей логики. Если сайт использует CDN или распределённую инфраструктуру, ответы у пользователей могут различаться. CDN доставляет контент, а DNS помогает найти её узлы. Разные IP-адреса сами по себе не означают поломку.

Что DNS хранит кроме IP-адресов

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

Для первого знакомства достаточно основных типов из документации по DNS-записям:

Тип	Какие сведения задаёт	Типичная задача
A	Адрес IPv4 для имени	Направить обращения к веб-сервису
AAAA	Адрес IPv6 для имени	Обеспечить обращение по IPv6
CNAME	Другое, каноническое имя	Связать имя с адресацией подключённой платформы
MX	Почтовые серверы домена и их приоритеты	Организовать приём почты
TXT	Текстовые сведения для заданного назначения	Подтверждение управления доменом, отдельные почтовые политики
NS	Имена серверов, обслуживающих зону	Указать, где искать авторитетные данные

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

Другой частый случай — CNAME ошибочно принимают за переадресацию страницы. Запись участвует в поиске данных по имени, но сама не формирует HTTP-ответ с перенаправлением браузера на новый URL. Если требуется перенаправлять посетителей, это отдельная настройка веб-сервера, приложения или платформы.

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

Зачем нужен кэш DNS и почему изменения видны не сразу

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

TTL, или Time to Live, задаёт время кэширования DNS-данных. Обычно значение записывается в секундах. Оно относится к конкретной записи или набору записей и не является универсальным сроком выполнения всех действий с доменом.

Как это выглядит при смене сервера

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

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

Кэшируются ли ответы «такого имени нет»?

Да. RFC 2308 описывает отрицательное кэширование: временно сохраняться может и ответ об отсутствии имени или запрошенных данных. Поэтому только что созданный поддомен иногда продолжает выглядеть отсутствующим для резолвера, который проверял его до создания. Настройки отрицательного кэширования отличаются от TTL новой A-записи.

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

Почему нельзя обещать обновление DNS ровно через час

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

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

Где меняют DNS: у регистратора, хостера или интернет-провайдера

Фраза «поменять DNS» неоднозначна. Посетитель может выбирать сервер, который отвечает на его запросы. Владелец сайта — менять записи собственного домена. А при смене DNS-поставщика требуется изменить делегирование и подготовить зону. Одинаковые слова в инструкциях описывают разные действия.

Что вы хотите сделать	Где искать настройку	Какой результат нужен
Выбрать резолвер для своего устройства	Настройки сети, роутера или браузера	Запросы этого клиента обслуживает выбранный DNS-сервис
Изменить адрес сервера сайта	Панель действующего авторитетного DNS-провайдера	Зона публикует требуемые A или AAAA
Передать зону другому DNS-поставщику	Новая DNS-панель и управление делегированием домена	Новые серверы заранее содержат нужные записи
Перенести файлы и приложение	Хостинг, VPS и система развёртывания	Сайт готов принять обращения на новом месте

Регистратор и DNS-провайдер могут быть одной компанией, но это не обязательное условие. Если домен использует внешние NS, изменение неактивной зоны в кабинете регистратора не повлияет на авторитетные ответы. Начните с определения действующего поставщика, а не с первого найденного раздела «DNS».

Публичный резолвер тоже нельзя автоматически назначить авторитетным DNS-хостингом своего домена. Например, Google прямо разделяет Google Public DNS и сервис размещения DNS-зон. Первый помогает клиентам искать существующие ответы, второй публикует данные владельца.

Смена резолвера на устройстве не исправит ошибочную запись в авторитетной зоне. Для исправления данных своего домена нужен доступ к действующему DNS-провайдеру.

Что такое DNS в телефоне, компьютере и роутере

Обычно пользователь получает сетевые настройки автоматически и не выбирает DNS вручную. Роутер может передавать устройствам адрес DNS-сервиса или принимать запросы сам и отправлять их дальше. При переключении с домашнего Wi-Fi на мобильную сеть может измениться и путь DNS-запросов.

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

Частный DNS на Android

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

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

Почему браузер может получать другой результат

Некоторые браузеры используют DNS over HTTPS и выбранного для него поставщика. Например, Mozilla описывает собственные настройки DoH в Firefox. В результате проверка системной утилитой и открытие страницы в браузере могут обращаться к разным DNS-сервисам.

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

Ускорит ли интернет смена DNS-сервера

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

Смена резолвера не увеличивает скорость тарифа и не превращает медленное приложение в быстрое. На результат влияют расстояние по сети, состояние кэша и то, какие адреса возвращаются для распределённых сервисов. Google рассматривает эти факторы в описании производительности Public DNS. Универсального «самого быстрого DNS для всех» из этого не следует.

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

Отдельно различайте DNS и VPN. Выбор резолвера меняет способ получения DNS-ответов, а не обязательно маршрут последующего соединения с сайтом. Он сам по себе не скрывает исходный IP-адрес от посещаемого сервиса и не создаёт туннель для всего трафика. Если приложение объединяет несколько функций, оценивать нужно каждую из них.

DNSSEC, DoH и DoT: какую защиту они дают

В защите DNS нужно различать проверку подлинности опубликованных данных и шифрование соединения с резолвером. Эти задачи решают разные механизмы.

ISC объясняет DNSSEC как механизм проверки целостности и происхождения DNS-данных с помощью криптографических подписей и цепочки доверия. При корректной настройке валидирующий резолвер может обнаружить неподтверждённые изменения. DNSSEC не шифрует сами DNS-данные.

DNS over TLS и DNS over HTTPS защищают транспорт DNS-запросов и ответов: DoT использует TLS, DoH — HTTPS. В привычной клиентской настройке речь идёт о соединении устройства или браузера с выбранным DNS-сервисом. Это не обещание шифрования всей дальнейшей цепочки и не замена HTTPS на сайте.

Механизм	Основная задача	Чего из него нельзя заключить
DNSSEC	Проверять подлинность и целостность подписанных DNS-данных	Что запросы скрыты или сам магазин безопасен
DoH и DoT	Шифровать DNS-обмен на соответствующем соединении	Что весь интернет-трафик идёт через защищённый туннель
HTTPS	Защищать соединение браузера с веб-сервисом	Что автоматически исправлены DNS-записи или подтверждено качество бизнеса

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

Для владельца сайта важна согласованность настроек. Например, после смены DNS-провайдера ошибка в параметрах DNSSEC может привести к отказам у валидирующих резолверов. В такой ситуации требуется исправлять цепочку доверия, а не предлагать всем посетителям отключить проверки.

Как проверить DNS и понять результат

Для диагностики зафиксируйте имя, ответивший DNS-сервис и результат запроса, а также время и сеть проверки. Это позволит сопоставить данные с жалобой клиента.

В Windows для отдельных запросов можно использовать nslookup. Команды ниже ничего не меняют в настройках: они запрашивают сведения. Вместо example.com укажите свой домен; это имя в примере не является вашим сервером.

nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=NS example.com
nslookup -type=MX example.com

В выводе сначала может быть показан сервер, которому отправлен запрос, а затем сведения о проверяемом имени. Не принимайте адрес резолвера за адрес сайта. Пометка Non-authoritative answer означает, что ответ получен не как авторитетный ответ сервера этой зоны; для запроса через рекурсивный сервис это обычная ситуация, а не сообщение о взломе.

Результат	Что означает	Какой следующий вопрос задать
Получены ожидаемые записи	Конкретный запрос разрешён с этим результатом	Открывается ли нужный сервис после получения адреса?
NXDOMAIN	Ответ сообщает об отсутствии запрошенного имени	Верно ли имя, создано ли оно и актуален ли источник ответа?
Нет данных нужного типа	Имя может существовать без запрошенной записи	Должна ли у него быть именно A, AAAA или MX?
SERVFAIL	Резолвер не смог завершить обработку с нормальным ответом	Доступны ли авторитетные серверы, корректны ли делегирование и DNSSEC?
Тайм-аут	Ответ не получен за время ожидания	Доступен ли выбранный резолвер из этой сети?

Обозначения ответов и различия между отсутствием имени, отсутствием данных и ошибкой обработки описаны в словаре DNS IETF. Из одного SERVFAIL нельзя вывести точную причину. Аналогично отсутствие AAAA не доказывает поломку сайта, если IPv6 для него не настроен и IPv4 работает.

Сравните один и тот же запрос из другой сети или через другой доступный резолвер, сохранив исходный результат. Различие помогает локализовать проблему, но не доказывает автоматически, что один сервис «правильный», а другой нет. Один мог использовать кэш, другой — столкнуться с текущей ошибкой или применять иной режим проверки.

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

Что владельцу сайта контролировать на практике

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

Понятная ответственность. Известно, кто управляет доменом и DNS-панелью и кто заменяет основного специалиста.
Сохранённые настройки. Перед изменением есть экспорт зоны или другой актуальный способ восстановить нужные значения.
Контроль связанных сервисов. В списке проверок присутствуют основной сайт, важные поддомены и корпоративная почта.
Проверка результата. После изменения сопоставлены DNS-ответы и фактическая работа сервиса из доступных сетей.
Порядок реакции. Уведомление получает человек, который может связаться с нужным поставщиком и исправить конфигурацию.

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

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

Частые вопросы о DNS

DNS и IP-адрес — это одно и то же?

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

Можно ли открыть сайт без DNS, введя его IP?

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

Чем DNS-кэш отличается от кэша браузера?

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

Нужно ли менять DNS посетителям после переезда сайта?

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

Нужно ли небольшому сайту поднимать собственный DNS-сервер?

Не обязательно. Можно использовать управляемую DNS-услугу и контролировать её настройки, доступы и условия обслуживания. Собственный сервер требует отдельного сопровождения. Выбор зависит от задач команды, а не от одного факта наличия сайта.