Когда мы ищем информацию в Интернете, то используем понятные нам имена сайтов вроде google.com или realhost.pro. Но это мы "общаемся" названиями, а вот компьютеры для понимания друг друга используют сухие и не слишком запоминающиеся IP-адреса типа 185.72.159.45.
Так вот, чтобы нам не держать в голове эти тысячи чисел, человечество и придумало DNS — своего рода справочник или телефонную книгу интернета. Мы вводим привычное название сайта, а DNS мгновенно (иногда с перебоями, но об этом позже) находит, за каким IP-адресом скрывается нужный ресурс.
DNS (Domain Name System) - это сервис, преобразующий доменные имена в IP-адреса, понятные для компьютеров. Он позволяет людям использовать привычные названия сайтов, а не морочить себе голову цифрами. DNS - это основа работы всего Интернета. Без него браузер просто выдаст: “404. Я не знаю, куда идти".
Предлагаем сейчас разобраться:
- Где хранятся DNS записи?
- Кто этим всем управляет?
- Почему после смены DNS записи часто все еще ничего не работает?
- И что означает то таинственное "TTL", которое вдруг становится главной проблемой?
В этой статье мы разложим все по полочкам - просто, профессионально, с примерами, и (обещаем) без чрезмерного техно-бюрократизма. Хотя будет немного долго, но вы уж точно поймете что ж это за DNS такой.
1. Как работает DNS: пошагово
Представим: вы открываете браузер и вводите example.com. Кажется, что все просто - сайт открывается, и вы переходите к своим делам. Но за кулисами разворачивается небольшой “квест” из нескольких уровней. Вот как это работает:
🔴Шаг 1. Браузер спрашивает: “И где этот example.com?”
Первым делом браузер обращается к операционной системе: "Есть ли у тебя IP-адрес для этого домена? Если ответ “да” (в кэше), на этом все и заканчивается - сайт открывается.
🔴🔴Шаг 2. Нет в кэше? Идем дальше!
Тогда запрос передается к рекурсивному DNS-серверу - обычно это сервер провайдера или Google DNS: 8.8.8.8.8, 8.8.4.4, Cloudflare DNS: 1.1.1.1, 1.0.0.1, OpenDNS: 208.67.222.222, 208.67.220.220.
- Рекурсивный сервер DNS (или рекурсивный резолвер) - отвечает за поиск полного ответа на DNS-запрос пользователя, даже если ему самому этот ответ неизвестен.
- Почему он "рекурсивный"? Потому что не останавливается на полпути. Он "рекурсирует" (бегает за тебя по инстанциям) - то есть выполняет все шаги, пока не найдет окончательный ответ. Тебе не нужно знать, что именно и где он запрашивал - результатом для пользователя является готовый IP-адрес
- Для чего это все?
- Чтобы пользователи не ждали: рекурсивные серверы обычно кэшируют (запоминают) ответы, чтобы в следующий раз не повторять тот же путь.
- Чтобы разгрузить сеть: благодаря кэшу они уменьшают количество обращений к "высшим" DNS-серверам.
- Чтобы унифицировать обработку DNS-запросов - один мощный сервер может обслуживать много пользователей (например, у провайдера или Google DNS).
🔴Шаг 3. Рекурсивный сервер отправляется на поиски.
Если DNS-резолвер сам не имеет ответа относительно нужного IP, он запускает цепочку исследований:
- Запрос к корневым ( . ), то есть,root-серверам: "Кто обладает информацией о домене верхнего уровня (.com)?
- Root отвечает: “обращайся к TLD-серверу .com”.
- TLD-сервер говорит: “вот авторитетный DNS-сервер, отвечающий именно за example.com”.
- Резолвер идет туда — и получает IP-адрес.
- IP возвращается на ваш компьютер - сайт открывается.
🕐 Все это занимает доли секунды, но запрос реально летает по всему миру!
🔴Шаг 4. IP найден, информация кэшируется.
Полученный адрес возвращается обратно в браузер и сохраняется в кэше на определенное время (установленное через TTL). Браузер теперь знает, куда стучать в случае повторного запроса пользователя.
🔴Шаг 5. Соединение установлено.
Браузер наконец-то идет по IP, устанавливает TCP-соединение (и TLS, если HTTPS), и вуаля - сайт на экране.
Кратко о "героях" розыска IP для сайта:
- Браузер/ОС ➡ Запрашивает, кэширует
- Рекурсивный DNS ➡Поисковик: ищет ответ
- Корневой сервер ➡ Говорит, куда идти дальше
- TLD-сервер ➡ Знает, кто управляет доменом
- Авторитетный DNS ➡ Дает окончательный ответ: IP-адрес
2. Обязательные и не очень: разбираемся с основными типами DNS-записей
DNS-записи - это, по сути, инструкции для DNS-серверов: они говорят, куда слать трафик, где искать почту, какой сервер главный, и еще много чего. Вот наиболее распространенные типы:
🔑 Самые необходимые записи: без них — никак:
| Тип записи | Для чего она | Пример |
|---|---|---|
| A (Address) | Указывает IPv4-адрес сервера | example.com → 192.0.2.1 |
| AAAA | То же самое, но для IPv6 | example.com → 2001:db8::1 |
| CNAME (каноническое имя) | Псевдоним для домена | www.example.com → example.com |
| MX (Mail Exchange) | Куда слать почту для домена | example.com → mail.example.com (приоритет: 10) |
| NS (Name Server) | Какие серверы отвечают за домен | example.com → ns1.provider.net |
| SOA (начало полномочий) | Начальная информация о зоне | Контакт администратора, серийный номер, TTL и т.д. |
Без A/AAAA-записи сайт просто не откроется. Без MX - письма не придут. Без NS - DNS вообще не работает. А без SOA - серверы не будут знать, как часто обновлять информацию.
🛠️ Записи, которые пригодятся при настройке или оптимизации:
| Тип записи | Для чего | Комментарий |
|---|---|---|
| TXT | Текстовые данные — SPF, DKIM, Google verification | Можно иметь несколько, особенно для email безопасности |
| SPF (через TXT) | Контроль над разрешенными email-серверами | Борется со спамом |
| DKIM (через TXT) | Криптографическая подпись почты | Часть системы проверки подлинности |
| DMARC (через TXT) | Политика реакции на неаутентичную почту | Контролирует, что делать со спамом |
| CAA (Certification Authority Authorization) | Каким центрам сертификации разрешено выдавать SSL | Дополнительный уровень защиты |
🧙♂️ Для продвинутых, DevOps и VoIP-фанатов
| Тип записи | Призначение |
|---|---|
| SRV | Указывает сервис и порт (например, для VoIP, Microsoft services) |
| NAPTR | Динамические сервисы, VoIP, SIP |
| PTR | Обратный DNS (IP → домен) - часто нужен для почтовых серверов |
| HINFO | Информация о хосте - тип ОС и оборудования (почти не используется) |
| LOC | Геолокация хоста - для интерактивных карт |
| DNSKEY/DS/RRSIG | Часть DNSSEC (криптографическая подпись) |
💡 Краткий итог: минимальный набор записей для корректной работы сайта:
- A или AAAA - чтобы браузер знал, куда идти.
- CNAME - если хотите, чтобы
wwwработало - NS - чтобы DNS работал вообще
- SOA - для синхронизации между DNS-серверами
- MX - для почты.
- TXT - для безопасности и сервисов.
3. DNS-зона: где живут все записи о вашем домене
DNS-записи не витают в воздухе. Они хранятся в так называемых DNS-зонах или зонных файлах (zone files) на авторитетных DNS-серверах. Это просто текстовые файлы (таблицы) со структурированной информацией о домене.
📂 Что такое DNS-зона
DNS-зона - это часть пространства доменов, за которую отвечает конкретный сервер. Она содержит все записи: A, CNAME, MX, TXT, NS, SOA и другие. Например, зона example.com могла бы выглядеть так:
Это пример так называемого zone file. Если вы работаете с BIND, PowerDNS или похожими DNS-серверами - это именно то, с чем вы имеете дело.
💻 Но большинство пользователей видит интерфейсы хостингов
Зачастую провайдеры предлагают простые панели для редактирования DNS - без необходимости писать руками эти файлы.
Записи вводятся в табличках:
- Тип → A
- Имя →
@илиwww - Значение → IP-адрес
- TTTL → например, 3600 (т.е. 1 час)
4. Кто и где управляет DNS-записями
В управлении DNS задействованы несколько игроков:
1. Регистратор домена
Тот, у кого вы купили домен (example.com). Именно он определяет, какие NS-записи указаны для домена, то есть на какие серверы делегировано управление.
2. DNS-хостинг
Это место, где реально хранятся DNS-записи. Это может быть:
- Хостинг-провайдер (у вас на сервере).
- Специализированный DNS-сервис (Cloudflare, AWS Route 53, Google Cloud DNS).
- Регистратор домена (многие из них предоставляют DNS в качестве бонуса).
3. Сисадмин или вы сами
Если вы имеете доступ к DNS-панели, то можете добавлять, изменять или удалять записи. Но - ответственность тоже на вас 😅
🧬 Делегирование
- Вы можете указать другие NS-записи, чтобы передать управление на другую платформу (например, с
ns1.registrar.ua→ns1.cloudflare.com). - Можно делегировать субдомены (например,
shop.example.com) на другой DNS-сервер для микросервисов, SaaS или тестирования.
5. TTL или почему DNS-изменения не работают мгновенно
⏱️ Что такое TTL
TTL (Time To Live) - это время, на которое DNS-запись кэшируется:
- Вы ставите TTL=3600; кэш будет храниться 1 час.
- За это время серверы не проверяют новую версию записи - даже если вы ее уже изменили.
- Указывается в секундах, поэтому TTL=1 означает, что запись может храниться в кэше лишь 1 секунду.
💢 Типичная ситуация:
- Вы изменили A-запись на новый IP, информация верна.
- Но сайт еще 3 часа открывается по-старому.
- Вы проверяете, паникуете, звоните хостеру.
- На самом деле просто TTL еще не отработал свое время, поэтому сохраняется старая версия.
🧠 Совет, что делать:
- Перед важными изменениями уменьшите TTL (например, до 300 секунд).
- Подождите пока TTL старых записей "выгорит" и все кэши обновятся.
- Тогда вносите изменение, оно применится быстро.
📌 Рекомендуемый минимум:
Если вам нужно очень быстрое обновление DNS (например, во время миграции сайта), ставьте TTL в диапазоне 30–300 секунд:
30- для кратковременных критических изменений300(5 минут) - для большинства технических задач
6. Кэш DNS - ваш друг и враг одновременно
Кэш - это хорошо. Но когда вы вносите изменения, он становится вашим врагом.
📦 Где именно хранится кэш DNS:
- Операционная система: Windows, macOS, Linux - держат DNS-записи в памяти.
- Браузеры: Chrome, Firefox имеют собственный DNS-кэш (независимый от ОС).
- Рекурсивные DNS-серверы (провайдера или Google DNS) - кэшируют записи согласно TTL.
- CDN или прокси (Cloudflare, Sucuri, Akamai) - имеют еще свои уровни кэширования.
🤦🤦♂️ Что это означает на практике?
- Вы изменили A-запись, но ваш друг в Германии еще видит старую версию сайта - потому что его DNS-сервер еще не обновился.
- Вы проверяете через VPN - видите другое.
- И так до бесконечности
В таком случае поможет очистка кэша.
7. Как очистить DNS-кэш (для всех систем)
На компьютере:
📌 Windows:
🍏 macOS
Зависит от версии macOS, macOS 10.11 и более новые (включительно с macOS Sonoma):
После ввода придется ввести пароль администратора. Команда запускает очистку кэша и перезапуск службы DNS
🐧 Linux
Очистка кэша зависит от того, какой резолвер используется.
Если используется systemd-resolved (часто в Ubuntu):
Если используется nscd:
Если используется dnsmasq:
🌐 Браузеры (локальний кэш DNS)
Chrome
Введите в адресную строку:
И нажмите “Clear host cache”.
Firefox:
Закройте и откройте браузер, или перезапустите в безопасном режиме.
8. DNS-грабли: на что чаще всего наступают сисадмины
Типичные ошибки при работе с DNS:
- TTTL слишком большой — поставили 86400 (24 часа), а хотите проверить изменения через 5 минут.
- CNAME для root-домена — он там не работает! Для example.com используйте A/AAAA.
- Забыли сохранить или нажать “Apply” — и думаете, что “ничего не работает”.
- Сменили IP — но не обновили DNS-запись.
- Ошибки в TXT-записях (особенно в SPF - одна лишняя кавычка может “убить” всю почту).
- DNSSEC включили - а ключи не настроены — сайт становится недоступным.
9. Важные моменты при работе с DNS: советы сисадмина
- 🧠 Планирование TTL перед миграциями.
- 🔐 DNSSEC - для защиты от подмены записей (но только с правильной настройкой!).
- ⚡ Надежные DNS-серверы - Google (8.8.8.8.8), Cloudflare (1.1.1.1), OpenDNS.
- 🔍 Перепроверка через онлайн-инструменты:
- dnschecker.org
dig,nslookup,hostв терминале- mxtoolbox.com
10. Вывод: без DNS не будет ничего
DNS - это как логистика для сайтов: незаметная, пока все работает. И катастрофическая, когда что-то пошло не так.
🎯 Помните:
- Проверяйте TTL перед изменениями.
- Не забывайте о кэше.
- Пользуйтесь проверенными инструментами.
- И относитесь к DNS с уважением - это ваш первый (и часто единственный) способ попасть к пользователю.
А еще - всегда держите под рукой dig, dnschecker и нервы из стали. Ибо как говорят сисадмины: "Настоящий DevOps сначала чистит DNS-кэш, а потом уже проверяет все остальное".
