Если однажды сайт перестал открываться, письмо внезапно вернулось с ошибкой или домен привязался к новому хостингу, а изменения «не доходят», почти всегда виноваты настройки DNS. Этот текст — подробное руководство по настройкам DNS на человеческом языке: без лишней теории, но с базой, которая поможет спокойно разбираться в доменах, записях и сроках обновления. Например, после чтения вы сможете сами понять, почему новый лендинг по адресу shop.пример-домена.ru видят не все сотрудники, а только часть офиса, или почему корпоративные письма вдруг стали оказываться в спаме.
Я разберу, как устроен сам DNS, какие бывают записи (A, AAAA, NS, MX, CNAME и не только), что означает параметр TTL, как ведут себя резолверы и кэш, почему вообще приходится ждать пропагацию и в каких ситуациях действительно стоит менять DNS настройки, а когда проблема в другом. Цель — чтобы после прочтения вы уверенно управляли доменом и не паниковали при каждом «сайт не найден». В качестве ориентира можно держать типовые сценарии: запуск сайта на новом хостинге, перенос интернет-магазина в облако, подключение почтового сервиса для домена компании или разделение трафика между несколькими серверами.
Что такое DNS и почему без него не обойтись
DNS — это система, которая превращает привычные человеку имена сайтов в числовые адреса серверов. Браузер в итоге общается не с названием домена, а с IP, но ручной набор цифр для каждого визита был бы пыткой, поэтому между пользователем и серверами стоит целая иерархия DNS-компонентов. Чтобы оценить масштаб, можно просто вспомнить, сколько разных сайтов вы открываете за день — и представить, что каждый раз пришлось бы вводить полный IP-адрес вида 185.10.20.30 вместо короткого имени.
У любого домена есть зона — набор записей, где зафиксировано, какие IP-адреса, почтовые серверы и вспомогательные службы с ним связаны. Эти данные хранятся на авторитетных DNS-серверах, которые считают «официальным источником правды» для конкретного домена. Информация о том, какие именно серверы авторитетны, поднимается вверх по дереву до корневых серверов. На практике это выглядит так: вы регистрируете домен у регистратора, выбираете DNS-серверы хостинга или собственного провайдера, и именно туда вносите все записи для сайта, почты и поддоменов.
Чтобы увидеть это на практике, достаточно запросить любую запись с помощью утилиты dig:
dig example.com A
; <<>> DiG 9.18.0 <<>> example.com A
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
;; AUTHORITY SECTION:
example.com. 86400 IN NS ns1.example.net.
example.com. 86400 IN NS ns2.example.net.
Когда вы вводите адрес сайта в браузере, операционная система обращается к резолверу — как правило, это сервис провайдера или DNS-сервер, прописанный в настройках маршрутизатора. Резолвер отвечает за поиск нужной записи: он знает, к каким корневым серверам обратиться, как добраться до DNS-серверов для зоны верхнего уровня (например, .ru или .com), и как в итоге получить данные от авторитетного сервера самого домена. В домашних сетях роль первого «контактного лица» часто играет роутер, который принимает запросы от всех устройств в квартире и пересылает их уже на внешние резолверы.
Чтобы не делать полный путь каждый раз, почти на каждом этапе используется кэширование. Запросы кэшируют и операционная система, и браузер, и домашний роутер, и провайдерский резолвер. Пока срок жизни кэшированного ответа не истёк, повторный запрос обслуживается из локального хранилища, что сильно ускоряет загрузку сайта, но иногда мешает увидеть свежие изменения после правки зоны. Например, вы уже сменили IP сайта в панели хостинга, а коллега по-прежнему видит старую версию, потому что у него ещё не обновился кэш на уровне провайдера или роутера.
Посмотреть, какие DNS-серверы сейчас использует Windows, можно так:
ipconfig /all
Адаптер Ethernet:
DNS-суффикс подключения . . . . . :
Серверы DNS. . . . . . . . . . . . : 192.168.1.1
9.9.9.9
А на Linux это часто задаётся в /etc/resolv.conf:
cat /etc/resolv.conf
nameserver 9.9.9.9
nameserver 1.1.1.1
options edns0 trust-ad
Основные типы DNS-записей и роль TTL
Внутри зоны домена всё построено на записях. У каждой есть своё назначение, и от правильной комбинации зависит, куда будет вести сайт, где окажется почта и как себя поведут дополнительные сервисы. Если представить зону как таблицу, каждая строка в ней — конкретная запись, в которой указано имя (домен или поддомен), тип записи и значение.
Записи типа A связывают доменное имя с IPv4-адресом. Это самый базовый вариант, который отвечает за то, куда именно отправится запрос при попытке открыть сайт. Если сервер поддерживает новый протокол IPv6, рядом добавляют запись AAAA — она указывает на соответствующий адрес в более длинном формате. Один домен может указывать сразу на несколько IP, например для балансировки между серверами или для разных географических регионов. Типичная схема: www.пример-домена.ru указывает на IP веб-сервера, а api.пример-домена.ru — на отдельный IP, где крутится backend для мобильного приложения.
Простейший фрагмент зоны с такими записями в формате BIND может выглядеть так:
$TTL 3600
@ IN A 203.0.113.10
www IN A 203.0.113.10
api IN A 203.0.113.20
@ IN AAAA 2001:db8::10
api IN AAAA 2001:db8::20
Запись CNAME задаёт псевдоним: она говорит, что одно имя на самом деле ссылается на другое. Это удобно, когда несколько поддоменов должны вести на один и тот же ресурс. Вместо того чтобы дублировать A и AAAA, можно сделать один «главный» адрес и несколько CNAME, которые просто наследуют его поведение. С этим типом важно помнить ограничение: совпадающее имя не может одновременно иметь CNAME и другие записи, например A или MX. Практический пример: у вас есть основной хостинг для сайта и поддомен www, который должен вести туда же — тогда основному имени домена задают A-запись, а www делают CNAME, ссылающийся на это имя.
В зоне это будет так:
@ IN A 203.0.113.10
www IN CNAME example.com.
shop IN CNAME www.example.com.
Почта держится на записях MX. В них перечисляются серверы, которые принимают письма для домена, с указанием приоритетов. Чем меньше цифровое значение приоритета, тем выше очередь обработки. Если первый по списку сервер недоступен, отправитель автоматически переходит к следующему. При настройке MX часто приходится добавлять и вспомогательные A или AAAA, чтобы указать IP этих почтовых хостов. Например, для домена компании mx1.пример-домена.ru с приоритетом 10 может быть основным почтовым сервером, а mx2.пример-домена.ru с приоритетом 20 — резервным на другом дата-центре.
Фрагмент зоны с MX-записями:
mx1 IN A 203.0.113.30
mx2 IN A 203.0.113.40
@ IN MX 10 mx1.example.com.
@ IN MX 20 mx2.example.com.
Записи NS описывают, какие DNS-серверы считаются авторитетными для конкретной зоны. Именно они хранят все остальные записи и отвечают на запросы от резолверов. При смене хостинга или регистратора домен зачастую переводят на новые NS — в этот момент фактически меняется источник всей информации о зоне. Например, если вы решили перенести зону с DNS-серверов регистратора на собственный сервер в дата-центре, первым шагом будет смена NS, а уже потом перенос содержимого зоны.
Пример NS-записей:
@ IN NS ns1.example.net.
@ IN NS ns2.example.net.
Кроме базового набора, сегодня активно используют записи TXT. Формально это поле «произвольный текст», но на практике туда помещают важные служебные данные: SPF-правила для авторизации отправителей почты, ключи DKIM, параметры DMARC, коды подтверждения домена для облачных сервисов и многое другое. Есть и специализированные типы, например SRV для описания служб с указанием порта и протокола, а также SOA, где собрана служебная информация о зоне — главный сервер, ответственное лицо, серийный номер и параметры обновления. В TXT-записи вы можете увидеть, к примеру, строку вида v=spf1 include:service.example ~all, которая говорит почтовым серверам, какие источники считают легитимными отправителями для этого домена.
Живой пример набора TXT-записей для почты:
@ IN TXT "v=spf1 ip4:203.0.113.30 include:_spf.mailprovider.com ~all"
@ IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA..."
Отдельного внимания заслуживает TTL — time to live. Это число в секундах, которое говорит кэширующим серверам, как долго можно считать ответ актуальным. Пока TTL не истёк, резолвер использует сохранённый результат и не обращается к авторитетному серверу. Малое значение ускоряет распространение изменений, но увеличивает нагрузку на инфраструктуру, а очень большое повышает стабильность и снижает трафик, зато заставляет долго ждать, если IP сменился внезапно. При плановой миграции сайта часто сначала уменьшают TTL, дают кэшу обновиться, а уже затем переносят домен, чтобы сократить период «старых» записей в чужих резолверах. Например, за сутки до переезда можно временно снизить TTL с 86400 секунд (сутки) до 900 (15 минут), а после успешной миграции вернуть прежнее значение для снижения нагрузки.
В BIND-зоне параметр TTL можно задать сразу в начале файла:
$TTL 86400
@ IN SOA ns1.example.net. admin.example.net. (
2025111901 ; serial
3600 ; refresh
900 ; retry
604800 ; expire
300 ) ; minimum
Как проходит DNS-запрос, зачем менять значения и что такое пропагация
Полезно представить себе путь обычного запроса. Пользователь вводит домен, операционная система спрашивает у локального резолвера: «Куда идти?» Если ответ для этого имени уже лежит в кэше и ещё не просрочен по TTL, резолвер моментально отдаёт IP и история на этом заканчивается. Если нет, начинается последовательный подъём по иерархии: сначала обращение к корневым серверам, затем к серверам для зоны верхнего уровня, затем к авторитетным NS конкретного домена. Полученный результат резолвер записывает в свой кэш и возвращает клиенту. В качестве экспериментального упражнения можно отключить кэш браузера или сменить DNS-сервер и посмотреть, как меняется время первой загрузки сайта по сравнению с последующими заходами.
Наглядно путь запроса видно в dig с опцией trace:
dig +trace example.com
; <<>> DiG 9.18.0 <<>> example.com +trace
. 518400 IN NS a.root-servers.net.
...
com. 172800 IN NS a.gtld-servers.net.
...
example.com. 86400 IN NS ns1.example.net.
example.com. 86400 IN NS ns2.example.net.
...
example.com. 3600 IN A 93.184.216.34
Когда вы меняете настройки DNS для домена в панели регистратора или хостинга — например, обновляете A-запись, переводите почту на другой сервер через MX или прописываете новые NS, — авторитетный сервер обновляет зону почти мгновенно. Но миллионы кэшей по всему миру об этом ещё не знают. Пока у старых ответов не истечёт TTL, многие пользователи будут продолжать ходить по прежнему адресу. Этот период и называют пропагацией: временем, за которое новые записи «разъезжаются» по резолверам. Типичный пример: вы перенесли сайт с одного хостинга на другой, а кто-то уже видит новый дизайн, а кто-то — старый; это и есть следствие того, что одни резолверы обновили данные, а другие всё ещё держат прежний IP.
В разных точках мира картина в момент пропагации может отличаться. Кто-то уже попал на новый сервер, чьи-то запросы всё ещё уходят к старому IP. Это нормально и вытекает из самой идеи распределённого кэширования. В обычной ситуации достаточно заложить несколько часов, иногда — до суток, в зависимости от выставленных значений TTL и поведения конкретных провайдеров. Для критичных запусков иногда используют поэтапную схему: сначала включают новый сервер на тестовом поддомене, проверяют работу, а потом уже переключают основной домен, учитывая, что в течение некоторого времени трафик будет разделён между старой и новой инфраструктурой.
Отдельная группа решений связана не с записями домена, а с выбором самого резолвера. В настройках сети операционной системы, домашнего роутера или отдельного устройства можно указать, каким серверам поручать обработку DNS-запросов. По умолчанию это сервис провайдера, но пользователь может переключиться на альтернативный вариант — например, чтобы получить более строгую фильтрацию вредоносных доменов, родительский контроль или большую конфиденциальность на уровне запросов. В офисе это может быть собственный DNS-сервер, который дополнительно блокирует известные фишинговые сайты или домены с вредоносным содержимым.
На практике смена резолвера в Windows через PowerShell выглядит так:
Set-DnsClientServerAddress `
-InterfaceAlias "Ethernet" `
-ServerAddresses ("9.9.9.9","1.1.1.1")
А в домашнем роутере это обычно отдельное поле «DNS-серверы», куда можно вручную вписать адреса, вместо «получать автоматически от провайдера».
При выборе альтернативного резолвера имеет смысл обратить внимание на политику хранения логов и поддержку современных методов защиты. Всё чаще используются зашифрованные варианты вроде DNS over HTTPS и DNS over TLS, где запросы проходят внутри защищённого канала и не видны в чистом виде по пути от устройства до сервера. Это не превращает подключение в абсолютный щит, но уменьшает объём метаданных, доступных посторонним наблюдателям. Так, домашний пользователь может настроить на роутере профиль, где DNS-запросы от детей проходят через фильтрующий резолвер с шифрованием, а остальные устройства используют более нейтральный профиль.
В браузерах вроде Firefox поддержка DNS over HTTPS включается в настройках сети: достаточно выбрать «Использовать DNS через HTTPS» и указать поставщика, например custom и ввести URL шаблона вида https://dns.example.net/dns-query.
Есть несколько типичных ситуаций, когда правка настроек DNS действительно необходима. Самая очевидная — перенос сайта на новый хостинг или в облако. Тогда домен нужно связать с новым IP через A или AAAA, а иногда ещё и включить дополнительные записи для работы балансировщиков и вспомогательных сервисов. Другая распространённая история — настройка почтовой инфраструктуры: добавление MX, SPF, DKIM и DMARC, чтобы письма доходили до адресатов и не улетали в спам. Ещё один сценарий — привязка поддоменов к отдельным приложениям, API или панелям управления через комбинацию A, AAAA и CNAME. Например, вы делаете blog.пример-домена.ru для CMS-блога, panel.пример-домена.ru для панели управления и api.пример-домена.ru для мобильного приложения.
Простая схема привязки поддоменов в зоне может выглядеть так:
blog IN CNAME example.com.
panel IN A 203.0.113.50
api IN A 203.0.113.60
Иногда причина изменений в политике доступа. Часть пользователей меняет настройки DNS на устройствах или роутере, когда сталкивается с блокировками или нестабильной работой сервера провайдера. Корректный выбор резолвера помогает ускорить ответ, уменьшить количество ошибок «сайт не найден» и расширить набор доступных механизмов защиты, не трогая при этом саму зону домена. Например, если провайдерский DNS периодически «падает», можно временно прописать другой резолвер и проверить, исчезнут ли проблемы с доступом к сайтам.
Важно помнить, что любые правки в зоне домена стоит делать осознанно и аккуратно. Лучше записать текущее состояние или выгрузить конфигурацию, а затем вносить изменения по одному, фиксируя результат. При работе с боевым доменом есть смысл сначала протестировать новую схему на отдельном поддомене: так проще отловить ошибки, не затронув основной проект. Например, перед переносом почты можно завести тестовый домен или поддомен с отдельным пользователем, настроить для него MX и все нужные TXT-записи, отправить туда и оттуда несколько писем и только после успешной проверки переносить основную почту организации.
Для контроля изменений удобно использовать консольные утилиты. Например, проверить актуальное значение MX-записей:
dig example.com MX
; ANSWER SECTION:
example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.
В итоге настройки DNS оказываются не чем-то мистическим, а вполне понятным набором параметров: записи A и AAAA связывают имена с адресами, MX управляют маршрутами для почты, CNAME помогает не дублировать информацию, NS определяет, кто отвечает за зону, TTL задаёт скорость обновления данных, а резолверы и кэш обеспечивают баланс между быстротой и актуальностью. Понимая эту конструкцию, вы можете уверенно менять значения там, где это нужно, планировать пропагацию и использовать систему имён не вслепую, а как инструмент, который работает в ваших интересах. Со временем к этому добавятся и собственные шаблоны: например, набор стандартных записей для типового корпоративного домена или заготовка зоны для тестовых сред, которую можно разворачивать за пару минут.
