Когда вы вводите в браузер адрес, скажем, example.com, ваш компьютер не знает, где этот сайт физически находится. Он знает только IP-адреса — числовые идентификаторы вроде 93.184.216.34. Но запомнить такие адреса невозможно, особенно когда их миллиарды. Поэтому была создана DNS — распределённая база данных, которая сопоставляет человекочитаемые имена (домены) с машинночитаемыми IP-адресами.
Эта система работает иерархически. На вершине — корневые серверы (их 13 логических групп, физически размещённых по всему миру). Ниже — серверы доменов верхнего уровня (TLD): .com, .ru, .org и так далее. Ещё ниже — авторитетные DNS-серверы для конкретных доменов, например example.com. Именно на этих серверах хранится DNS-зона — набор записей, определяющих, куда направлять запросы, связанные с этим доменом.
DNS-зона — это административная единица в системе доменных имён, представляющая собой файл или набор записей, содержащих информацию о домене и его поддоменах. Это не просто список имён и адресов. Это — карта маршрутов, инструкция для всей сети: «Если кто-то спрашивает про mail.example.com — отправляй его туда-то. Если про www.example.com — туда-то. Если про сам example.com — вот сюда».
Зона может управляться владельцем домена напрямую (если он настроил собственные DNS-серверы) или через стороннего провайдера — регистратора домена, хостинг-компанию или специализированный DNS-хостинг (например, Cloudflare, Yandex DNS, или AWS Route 53).
Важно понимать: зона — это не домен. Домен — это имя. Зона — это техническое представление этого имени в DNS. Один домен — одна зона (если не используются делегированные подзоны, но об этом позже).
Структура DNS-зоны
DNS-зона состоит из записей. Каждая запись — это строка данных, имеющая определённый тип, имя, значение и параметры. Вот основные типы записей, с которыми вы столкнётесь:
A-запись — сопоставляет доменное имя с IPv4-адресом. Например: example.com → 93.184.216.34.
AAAA-запись — то же самое, но для IPv6.
CNAME (Canonical Name) — создаёт псевдоним. Например: www.example.com → example.com. Это не перенаправление, а указание, что www — это то же самое, что и корень домена.
MX-запись (Mail Exchange) — указывает, какой сервер принимает почту для домена. Без неё почта не будет работать.
TXT-запись — текстовая запись, используемая для различных целей: подтверждение владения доменом, настройка SPF/DKIM/DMARC (механизмы защиты почты от подделки).
NS-запись (Name Server) — указывает, какие серверы являются авторитетными для этой зоны. Это критически важные записи.
SOA-запись (Start of Authority) — служебная запись, содержащая метаданные о зоне: email администратора, серийный номер, время обновления и т.д.
PTR-запись — используется для обратного DNS (IP → имя), но обычно управляется владельцем IP-адреса, а не домена.
Каждая запись имеет TTL (Time To Live) — время в секундах, в течение которого другие DNS-серверы могут кэшировать эту информацию. Именно TTL отвечает за то, сколько времени займёт распространение изменений по интернету.
Где хранится DNS-зона?
DNS-зона хранится на авторитетных DNS-серверах. Это серверы, которые отвечают за конкретный домен. Когда вы регистрируете домен, регистратор автоматически назначает ему свои DNS-серверы (например, ns1.registrator.ru, ns2.registrator.ru). Вы можете оставить их — тогда зону вы будете редактировать в панели регистратора. Или вы можете делегировать управление зоной другому провайдеру — например, хостингу или Cloudflare. Для этого нужно изменить NS-записи у регистратора.
Важно: делегирование — это не перенос домена. Домен остаётся у регистратора. Просто теперь за ответы на DNS-запросы отвечают другие серверы.
Технически зона может быть представлена в виде текстового файла (в формате BIND, который де-факто стал стандартом), но большинство пользователей взаимодействуют с ней через веб-интерфейс панели управления.
Как вносить изменения в DNS-зону?
Процесс внесения изменений зависит от того, где вы управляете зоной. Но общий алгоритм одинаков:
- Авторизация в панели управления (у регистратора, хостинга или DNS-провайдера).
- Поиск раздела «DNS-зона», «Управление DNS», «Записи DNS» и т.п.
- Добавление, редактирование или удаление записей.
- Сохранение изменений.
Казалось бы — просто. Но именно здесь начинаются ошибки. Потому что DNS — система без отката. Нет «кнопки отмены». Нет «черновика». Изменение вступает в силу немедленно на ваших серверах, а затем постепенно распространяется по миру.
Давайте разберём типичные сценарии.
Перенос сайта на новый хостинг
Вы решили сменить хостинг-провайдера. Новый хостинг дал вам IP-адрес, например, 192.0.2.1. Что делать?
- Войдите в панель управления DNS (у регистратора или текущего DNS-хостинга).
- Найдите A-запись для example.com (иногда она обозначена как «@»).
- Измените её значение с текущего IP на 192.0.2.1.
- Если у вас есть запись для www, измените и её (либо убедитесь, что она является CNAME на example.com).
- Сохраните.
Что происходит дальше? Все DNS-резолверы (включая те, что у провайдеров и у Google — 8.8.8.8) постепенно обновят кэш. Если TTL был 3600 секунд (1 час), то в течение часа часть пользователей будет видеть старый сайт, часть — новый. Если TTL был 86400 (24 часа) — ждите сутки.
Совет: за сутки до переноса уменьшите TTL до 300–600 секунд. Это ускорит распространение изменений. После переноса можно вернуть TTL обратно — чтобы снизить нагрузку на DNS-серверы.
Настройка почты
Вы хотите принимать почту на user@example.com . Для этого нужно:
- Убедиться, что у вас есть почтовый сервер (свой или сторонний — например, Яндекс 360, Mail.ru для бизнеса, Google Workspace).
- Получить MX-адреса от провайдера. Например, для Яндекса это mx.yandex.net с приоритетом 10.
- В DNS-зоне удалите старые MX-записи (если есть).
- Добавьте новую MX-запись: имя — example.com (или «@»), значение — mx.yandex.net, приоритет — 10.
- Обязательно добавьте TXT-запись для SPF: v=spf1 redirect=_spf.yandex.net — это защитит вашу почту от спама и подделок.
- Возможно, потребуется DKIM и DMARC — тоже через TXT-записи.
Подключение CDN или защиты от DDoS
Сегодня почти все сайты используют CDN (Content Delivery Network) — например, Cloudflare. Чтобы подключить:
- Регистрируетесь в Cloudflare.
- Добавляете домен.
- Cloudflare сканирует текущую DNS-зону и предлагает импортировать записи.
- Вы подтверждаете.
- Cloudflare даёт вам новые NS-адреса.
- Вы идёте к регистратору и меняете NS-записи на lara.ns.cloudflare.com и rick.ns.cloudflare.com (пример).
Теперь весь трафик идёт через Cloudflare. Это даёт защиту, ускорение, кэширование. Но: если вы не скопировали все записи правильно — сайт упадёт. Особенно часто забывают про TXT, MX, CAA (записи для сертификатов SSL).
Ошибки, которые нельзя допускать
За 15 лет работы с инфраструктурой я видел одни и те же ошибки снова и снова:
- Удаление SOA или NS-записей. Это убивает зону. Без NS-записей никто не знает, кто отвечает за домен. Без SOA — нарушается механизм обновления.
- Синтаксические ошибки в записях. Например, в CNAME указать IP-адрес (нельзя — CNAME должен указывать только на имя). Или в MX — имя без точки на конце (в BIND-формате это критично).
- Игнорирование TTL. Меняют IP и удивляются, почему сайт «не работает» у части пользователей.
- Попытка редактировать зону не там, где она управляется. Например, домен делегирован на Cloudflare, а человек пытается менять записи у регистратора — они не применяются.
- Отсутствие резервных MX или A-записей. Один сервер упал — и всё упало. Профессионалы всегда дублируют сервисы.
Инструменты для диагностики
Прежде чем вносить изменения — проверьте текущее состояние. И после — убедитесь, что всё работает.
- dig — консольная утилита (в Linux/macOS). Например:
dig example.com A
dig example.com MX
dig @8.8.8.8 example.com — запрос через Google DNS. - nslookup — аналог в Windows.
- whois — покажет, какие NS-серверы указаны для домена.
- org, viewdns.info — онлайн-сервисы для проверки распространения DNS по миру.
- MXToolbox — отличный инструмент для проверки почтовых записей и SPF/DKIM.
Никогда не меняйте DNS вслепую. Всегда смотрите, что есть сейчас. Всегда проверяйте результат.
Делегированные подзоны
Иногда крупные организации делят зону. Например, основной домен company.com управляется центральным IT-отделом, а поддомен dev.company.com передаётся команде разработчиков. Для этого создаётся делегированная подзона.
Как это работает? В основной зоне добавляются NS-записи для dev.company.com, указывающие на DNS-серверы команды разработчиков. Теперь вся ответственность за dev. лежит на них. Это мощный, но опасный инструмент — требует чёткой координации.
Безопасность DNS
DNS изначально создавался без шифрования и аутентификации. Поэтому возможны атаки: подмена записей, кэш-отравление, перехват трафика.
Современные меры защиты:
DNSSEC (DNS Security Extensions) — цифровая подпись записей, чтобы гарантировать их подлинность. Поддерживается не всеми регистраторами, но крайне рекомендуется для банков, госсайтов, критической инфраструктуры.
Регулярный аудит записей — кто имеет доступ к панели управления? Нет ли подозрительных CNAME или TXT?
Двухфакторная аутентификация в панели регистратора — иначе злоумышленник может захватить домен и перенаправить всё куда угодно.
Помните: кто контролирует DNS — контролирует интернет-присутствие. Это серьёзнее, чем доступ к хостингу.
Жизненный цикл DNS-записи
Каждая запись проходит путь:
- Создание (в панели управления).
- Публикация на авторитетных серверах.
- Запрос от рекурсивного резолвера (например, у вашего провайдера).
- Кэширование с учётом TTL.
- Истечение TTL — повторный запрос.
- Удаление или обновление.
Этот цикл повторяется миллиарды раз в секунду. И он должен быть безотказным. Потому что когда DNS ломается — ломается всё.
В заключение позвольте сказать не как техник, а как человек, который десятилетиями наблюдает за эволюцией интернета.
DNS — это не просто протокол. Это социальный договор. Мы доверяем корневым серверам, операторам TLD, регистраторам, хостингам. Мы верим, что когда вводим bank.ru, нас не перенаправят на фишинговый сайт. Это доверие хрупко. Оно строится годами и рушится за минуты — если администратор допустит ошибку или если система будет скомпрометирована.
Поэтому работать с DNS — значит нести ответственность. Не за «сайт», не за «почту», а за доступность, целостность и доверие.
Когда вы вносите изменения в DNS-зону, вы не просто тыкаете в кнопки. Вы участвуете в глобальной системе координат, которая позволяет людям, машинам и идеям находить друг друга в бескрайнем пространстве сети.
