Интернет может казаться магией, но под капотом скрываются строгие и логичные алгоритмы. Один из самых важных - это DNS (Domain Name System или Система доменных имён). Если бы не DNS, нам бы пришлось запоминать длинные ряды цифр вместо удобных названий сайтов, таких как www.riopass.ru.
Что такое DNS?
Представьте себе классическую телефонную книгу. Вы знаете имя человека (например, Иван Иванов), но вам нужен его номер телефона, чтобы дозвониться. Вы открываете книгу, находите имя и смотрите соответствующий ему номер.
DNS делает абсолютно то же самое для интернета:
Люди привыкли использовать понятные доменные имена (например, yandex.ru, google.com).
Компьютеры и серверы общаются друг с другом исключительно с помощью IP-адресов (например, 192.0.2.1 или 2a00:1450:4010:c05::8b).
DNS - это глобальная телефонная книга интернета, которая мгновенно переводит человекочитаемые адреса в машинные IP-адреса.
Как происходит преобразование адреса?
Когда вы вводите адрес в строку браузера и нажимаете Enter, начинается увлекательное путешествие, которое обычно занимает миллисекунды. Этот процесс делится на два больших этапа: локальный поиск и поиск в глобальной сети.
Локальное преобразование Прежде чем беспокоить глобальные серверы, ваш компьютер пытается найти ответ у себя "в карманах".
Кэш браузера: Ваш браузер (Chrome, Safari, Firefox) хранит записи о сайтах, которые вы недавно посещали. Первым делом он проверяет свой собственный кэш.
Кэш операционной системы (ОС): Если браузер не нашел IP-адрес, он передает запрос операционной системе (Windows, macOS, Linux). ОС проверяет свой кэш DNS. Также на этом этапе проверяется локальный файл hosts (специальный текстовый файл, где пользователи могут вручную прописать соответствие IP и домена).
Кэш маршрутизатора (Роутера): Если на компьютере ответа нет, запрос уходит на ваш домашний или офисный роутер. У него тоже есть своя небольшая память для DNS-запросов.
Если ни на одном из этих локальных этапов IP-адрес не найден, компьютер обращается за помощью во внешний мир.
Здесь в игру вступает иерархия серверов интернета. Ваш запрос передается рекурсивному DNS-серверу (обычно его предоставляет ваш интернет-провайдер). Его задача - бегать по инстанциям, пока не найдет нужный ответ.
Вот как выглядит его маршрут:
Корневые серверы (Root Nameservers): Рекурсивный сервер не знает, где находится example.com, поэтому он идет к "самым главным" серверам интернета - корневым. Они не знают точного IP-адреса сайта, но знают, кто отвечает за зону .com, .ru или .org.
Серверы доменных зон верхнего уровня (TLD Nameservers): Корневой сервер отправляет запрос к серверу, отвечающему за конкретную зону (например, к TLD-серверу зоны .com). Этот сервер тоже не знает точный IP сайта, но знает, у какого сервера находится эта информация.
Авторитативные серверы (Authoritative Nameservers): Это финальная инстанция. TLD-сервер указывает на авторитативный сервер, который физически хранит нужную DNS-запись для example.com. Этот сервер выдает точный IP-адрес.
Рекурсивный сервер получает IP-адрес, сохраняет его в свой кэш (чтобы в следующий раз ответить быстрее) и отдает вашему браузеру. Браузер подключается к серверу по полученному IP-адресу, и вы видите сайт.
Виды DNS-запросов: Как именно общаются серверы
Рекурсивный запрос (Recursive Query) Это запрос в стиле: "Сделай всю работу за меня и дай готовый ответ". Когда ваш компьютер обращается к DNS-серверу провайдера (или к 8.8.8.8), он отправляет именно рекурсивный запрос. Это означает, что сервер берет на себя обязательство пройти по всем инстанциям (корневые серверы, TLD, авторитативные) и вернуть вашему компьютеру либо готовый IP-адрес, либо сообщение об ошибке (если домена не существует). Ваш компьютер при этом просто ждет.
Итеративный запрос (Iterative / Non-recursive Query) Это запрос в стиле: "Дай мне лучший ответ, который у тебя есть прямо сейчас". Именно так общаются между собой сами DNS-серверы в глобальной сети. Когда рекурсивный сервер провайдера спрашивает корневой сервер: "Где example.com?", он делает итеративный запрос. Корневой сервер не будет искать ответ сам. Он скажет: "Я не знаю точный IP, но я знаю, кто отвечает за зону .com. Вот его адрес, иди спроси у него". Рекурсивный сервер принимает этот ответ и делает следующий итеративный запрос уже к TLD-серверу.
Направления запросов: Прямые, Обратные и Инверсные
Помимо способа поиска, запросы делятся по тому, что именно мы ищем. Здесь важно не путать термины.
Прямой запрос (Forward DNS Query) Это классика, о которой мы говорили выше. У нас есть доменное имя (человекочитаемое), и мы хотим получить его IP-адрес (машинный). Это самый частый сценарий. Допустим, мы хотим узнать, на каком IP-адресе "живет" сайт riopass.ru. В Windows (через cmd или PowerShell): -> Введите команду: -> nslookup riopass.ru, если порт 53 заблокирован то nslookup riopass.ru 8.8.8.8 В ответе вы увидите DNS-сервер, который обработал ваш запрос, и ниже сам IP-адрес сайта.
Обратный запрос (Reverse DNS Query / rDNS) Здесь всё наоборот: у нас есть IP-адрес, и мы хотим узнать, какое доменное имя за ним закреплено. Это часто используется для проверки на спам (почтовые серверы проверяют, совпадает ли IP-адрес отправителя с его доменом) или при трассировке сетей (утилита traceroute). Для этого используется специальная доменная зона in-addr.arpa и записи типа PTR (Pointer).
Теперь попробуем выполнить rDNS-запрос. Возьмем всем известный публичный DNS-сервер от Google с адресом 8.8.8.8 и проверим, какое доменное имя за ним закреплено в глобальной сети. В Windows: ->Просто введите IP вместо домена: -> nslookup 8.8.8.8 -> В ответе в строке Name: вы увидите dns.google.
Инверсный запрос (Inverse Query / IQUERY) А вот здесь кроется технический нюанс, о котором многие забывают. Инверсный запрос - это старый и специфический механизм. В нем клиент просил сервер найти доменное имя, основываясь на любой известной ресурсной записи (не обязательно на IP-адресе). Из-за высокой нагрузки на серверы и сложностей в реализации, инверсные запросы были официально признаны устаревшими (deprecated) еще в 2002 году документом RFC 3425. Сегодня в современном интернете они не используются, их место полностью заняли обратные запросы (rDNS).
Дополнение: По умолчанию утилиты ищут A-запись (IPv4-адрес). Но если вам нужно узнать, какие серверы обрабатывают электронную почту для домена (MX-записи), тип запроса нужно указать явно. Попробуем на примере Яндекса: -> В Windows: -> nslookup -type=MX yandex.ru
В Linux / macOS: -> dig yandex.ru MX +short -> В ответ вы получите список серверов (например, mx.yandex.ru) и их приоритеты - именно туда отправляются письма, когда вы пишете на адрес @yandex.ru.
Часто задаваемые вопросы (FAQ)
1. Почему при переезде сайта на другой хостинг он какое-то время не работает? Это связано с процессом обновления кэша. На каждом этапе (у провайдеров, на роутерах) DNS-записи кэшируются на определенное время (этот параметр называется TTL - Time to Live). Пока это время не истечет, серверы будут отдавать старый IP-адрес. Полное обновление по всему миру может занимать от пары часов до 48 часов.
2. Что значит "Сбросить DNS-кэш" (Flush DNS)? Иногда ваш компьютер запоминает устаревший или ошибочный IP-адрес (например, если сайт недавно сменил сервер). Очистка (сброс) кэша заставляет операционную систему забыть старые данные и выполнить глобальный поиск заново, получив актуальный адрес.
3. Зачем люди меняют DNS-серверы на 8.8.8.8 (Google) или 1.1.1.1 (Cloudflare)? По умолчанию вы используете рекурсивные серверы вашего интернет-провайдера. Иногда они работают медленно, нестабильно или блокируют определенные ресурсы. Переключение на публичные серверы от Google или Cloudflare часто ускоряет загрузку страниц и повышает приватность.
4. Что такое записи типа A, CNAME, MX? На авторитативном сервере данные хранятся в виде разных записей:
A-запись: Связывает домен с IPv4-адресом (самая частая).
CNAME: "Псевдоним", связывает один домен с другим (например, www.site.com с site.com).
MX-запись: Указывает, какой сервер обрабатывает электронную почту для этого домена.
DNS (Domain Name System - Система доменных имён) - это фундаментальная система "поиска адресов" в Интернете. Можно представить, как гигантскую "телефонную книгу" Интернета - где имя(доменное имя сайта, например google.com), а телефон(ip-адрес).
DNSSEC (DNS Security Extensions - Расширения безопасности DNS) - это набор расширений, который делает этот поиск безопасным, защищая от подделки ответов и перенаправления на вредоносные сайты. DNSSEC не заменяет DNS, а защищает его данные. Можно представить, как "систему печатей и проверку их подлинности в телефонной книге", которая гарантирует , что злоумышленник не подменил номера телефонов на свои.
Google Public DNS
У Google Public DNS есть основной адрес 8.8.8.8 и резервный 8.8.4.4 - это бесплатные DNS-сервера, которыми может воспользоваться любой желающий в мире вместо DNS-серверов, предоставляемых по умолчанию его интернет-провайдером (ISP).
Плюсы:
Google Public DNS поддерживает современные стандарты (включая DNSSEC!) и может предоставлять более точные результаты в некоторых случаях.
Иногда провайдеры блокируют доступ к определенным сайтам на уровне своих DNS или их серверы работают медленно или ненадежно.
Серверы Google обычно очень быстрые и обладают высокой доступностью.
О времени NTP.
Настройка NTP-серверов (Network Time Protocol) критически важна для корректной работы компьютеров и сетевых устройств.
Цифровые подписи DNSSEC имеют срок действия (валидности), как и SSL-сертификаты. Они содержат поля: Inception Time (Время начала действия) и Expiration Time (Время окончания действия).
Что делает валидатор (на резолвере): Когда резолвер получает DNS-ответ и подписи DNSSEC, он обязан проверить текущее время (по своим часам) на соответствие этим временным меткам.
Если время отличается: Для пользователя будет указано, например : "Не удается получить доступ к сайту" А детальная информация: text ERR_NAME_NOT_RESOLVED или DNS_PROBE_FINISHED_BAD_CONFIG
MX (Mail Exchange) — указывает серверы для приёма электронной почты. Содержит приоритет (чем меньше число, тем выше приоритет). Пример: example.com. MX 10 mail.example.com example.com. MX 50 backup-mail.example.com
SOA (Start of Authority) - содержит серийный номер зоны, который увеличивается при любом изменении записей зоны. На практике этот номер формируется в формате год-месяц-день – например 20241005.
NS (Name Server) – содержит "официальные" серверы DNS текущей зоны. Пример: example.com. NS ns1.example.com.
RP (Responsible Person) – содержит e-mail лица, ответственного за внесение изменений в записи зоны. Желательно поддерживать этот адрес всегда в актуальном состоянии. Помните, что символ @ в нём заменяется точкой. Например, если admin@example.com, то admin.example.com
A (Host Address) – содержит информацию об имени системы и ее IP-адресе. Эта запись добавляется в DNS-сервер при регистрации узла.
PTR (Pointer, указатель) – запись обратной зоны. Обычно DNS-сервер автоматически создает или изменяет эту запись при создании или изменении записи А в прямой зоне.
CNAME (Canonical NAME) - создаёт псевдоним для другого доменного имени. Пример: www.example.com. CNAME example.com.
SRV (Service) — указывает серверы для определённых сервисов (например, SIP, LDAP). Пример: text _sip._tcp.example.com. SRV 10 60 5060 sipserver.example.com.
Для обновления записей DNS на клиентских компьютерах следует очистить кеш DNS-записей командой: ipconfig /flushdns
Для разрешения имен в DNS предусмотрено два типа запросов: итеративный и рекурсивный.
Итеративный запрос служит для получения от DNS-сервера, которому он направлен, наилучшего ответа, который может быть получен без обращения к другим DNS-серверам.
Рекурсивный запрос предполагает, что сервер DNS должен осуществить все операции для разрешения имени. Обычно для этой цели необходимо выполнить несколько запросов к различным DNS-серверам.
Ранее, когда не было службы DNS, IP-адреса в сети задавались вручную – с помощью файла host. В нём прописывались IP-адреса и символьные имена компьютеров. Затем этот файл тиражировался по всем компьютерам сети, чтобы все они могли разрешать доменные имя и IP-адреса друг друга.
Недостаток этого способа – необходимость вручную контролировать состав сети. В небольшой сети со статическими IP-адресами это сделать относительно просто, особенно если учесть, что состав таких сетей часто не меняется.
Но если в вашей сети используется DHCP-сервер (а где он сейчас не используется?), вряд ли вы будете вручную задавать имена узлов через файл hosts. Но если Windows не может динамически определить имена (IP-адреса) хостов, то система использует содержимое файлов hosts, networks, и lmhosts.
Все три файла находятся в папке %systemroot%\system32\drivers\etc.
Если ранее соединение работало стабильно, высока вероятность, что текущая проблема вызвана изменениями в настройках вашего интернет-провайдера. Основные возможные причины:
1 . Некорректное перенаправление трафика
Внедрения собственных сертификатов для анализа HTTPS-трафика (что может нарушать цепочку доверия SSL). (например, по требованию регуляторов).
2 . Фильтрация или MITM-атаки
В редких случаях провайдеры могут использовать методы типа Man-in-the-Middle (MITM) для анализа трафика, что приводит к ошибкам валидации сертификатов.
Решение:
Попробуйте изменить DNS вашего Интернет-подключения: установить серверы 8.8.8.8 и 8.8.4.4. Не забудьте сбросить кэш DNS после этого: запустите командную строку от имени администратора и используйте команду ipconfig /flushdns
Как изменить DNS-серверы:
Нажмите сочетание клавиш Win + R, введите control и нажмите ОК.
Перейдите в Центр управления сетями и общим доступом.
Выберите активное подключение (Ethernet или Wi-Fi) и откройте его Свойства.
В списке компонентов найдите IP версии 4 (TCP/IPv4) и нажмите Свойства.
Установите переключатель на Использовать следующие адреса DNS-серверов и введите: ```text Предпочитаемый DNS-сервер: 8.8.8.8
