У сайта может быть оплаченный домен, работающий сервер и исправный SSL-сертификат, но посетители все равно не смогут его открыть, если перестанет отвечать DNS. Эта часть инфраструктуры обычно остается незаметной именно потому, что большую часть времени работает без участия владельца сайта.
При покупке обычного хостинга DNS чаще всего выдается автоматически. Провайдер сообщает два или несколько NS-серверов, владелец домена прописывает их у регистратора и больше почти никогда к этому вопросу не возвращается. Для небольшого сайта такой вариант совершенно нормален.
Но DNS необязательно должен находиться там же, где лежат файлы сайта. Зону домена может обслуживать регистратор, хостинг-компания, отдельный DNS-провайдер или собственные серверы компании. Более того, физический сайт может несколько раз переехать между хостингами, пока DNS продолжает оставаться у одного и того же поставщика.
Именно это и называется DNS-хостингом: сервис хранит DNS-зону домена и отвечает другим серверам интернета, куда направлять запросы к сайту, почте и другим сервисам этого домена.
DNS-хостинг не хранит страницы WordPress, фотографии каталога или базу данных интернет-магазина. Его задача намного меньше по объему, но фундаментальнее по смыслу. Он сообщает интернету, где все это искать.
Что именно делает DNS-хостинг и почему без него домен практически бесполезен
Когда человек вводит адрес сайта в браузере, компьютер не подключается к доменному имени напрямую. Серверы общаются между собой по IP-адресам. Поэтому сначала нужно выяснить, какой IP соответствует введенному имени.
Для этого существует DNS. Информация о домене хранится в его DNS-зоне. Там находятся записи, которые связывают доменное имя с различными интернет-сервисами.
Например, A-запись может указывать IPv4-адрес веб-сервера, AAAA — IPv6, MX определяет почтовые серверы, TXT используется для множества служебных задач, а CNAME позволяет связать одно имя с другим.
Но сами эти записи должны где-то храниться и быть доступными из интернета круглосуточно. Эту задачу выполняют авторитетные DNS-серверы.
Именно их адреса обычно видит владелец домена в виде ns1.example.net и ns2.example.net. У регистратора домена указывается, какие NS обслуживают конкретную зону, после чего запросы постепенно начинают направляться к ним.
Поэтому DNS-хостинг фактически является хостингом не сайта, а DNS-зоны.
Регистратор домена, DNS-провайдер и обычный хостинг могут быть тремя разными компаниями
Одна из распространенных путаниц возникает из-за того, что домен, DNS и сайт часто покупаются в одном месте. Пользователь регистрирует домен у хостера, там же создает сайт и получает почту. В панели все выглядит как одна большая услуга.
Технически это несколько разных компонентов.
Регистратор отвечает за регистрацию доменного имени и взаимодействие с реестром соответствующей доменной зоны. DNS-хостинг обслуживает DNS-зону. Веб-хостинг хранит сайт и обрабатывает запросы посетителей.
Ничто не мешает зарегистрировать домен у одной компании, DNS держать у второй, сайт разместить на VPS третьей, а почту использовать у четвертой.
Для маленького сайта такое разделение может быть излишним. Для бизнеса оно иногда оказывается очень удобным.
Например, интернет-магазин переезжает с одного сервера на другой. Если его DNS-зона находится у независимого DNS-провайдера, менять NS домена вообще не требуется. Достаточно изменить A-запись на новый IP.
Это значительно проще, чем одновременно переносить сайт, DNS, почту и все остальные сервисы.
Что происходит, если DNS перестает отвечать
Сайт при этом может продолжать идеально работать на своем сервере. Процессор не перегружен, база данных доступна, Nginx исправно принимает запросы. Но новые посетители не знают, по какому IP находится домен.
Часть пользователей некоторое время продолжит открывать сайт благодаря кэшированным DNS-ответам. У других домен перестанет разрешаться практически сразу после истечения сохраненной записи.
Владелец сайта иногда воспринимает такую ситуацию как падение хостинга, хотя сам веб-сервер никуда не исчез.
Проблема особенно неприятна тем, что может затронуть сразу несколько сервисов. Если не разрешается домен, может перестать открываться сайт и одновременно нарушиться доставка почты, работа API, поддоменов и других компонентов, завязанных на DNS.
Поэтому DNS является небольшой, но очень важной частью отказоустойчивости проекта.
DNS у хостера или отдельный DNS-провайдер
Для большинства небольших сайтов DNS, который бесплатно предоставляет обычный хостер, вполне достаточен.
Это удобно. Все находится в одной панели, записи создаются автоматически, при добавлении домена не приходится вручную прописывать IP веб-сервера, а техническая поддержка видит и сайт, и его DNS-зону.
Если на хостинге работает один блог, сайт компании или небольшой интернет-магазин, усложнять инфраструктуру только ради того, чтобы DNS находился в другом месте, необязательно.
Отдельный DNS становится интереснее, когда у проекта появляется несколько серверов, разные сервисы, повышенные требования к доступности или частые миграции.
Главное преимущество отдельного DNS — независимость
Представим, что домен зарегистрирован у регистратора, но его NS указывают на DNS-серверы текущего хостера. Вся инфраструктура фактически связана с одной компанией.
Если владелец решает переехать, он может перенести сайт, а затем изменить записи в старой панели. В нормальной ситуации проблем нет.
Но если аккаунт заблокирован, компания прекратила работу или доступ к панели потерян, одновременно возникает проблема и с сайтом, и с управлением DNS.
При независимом DNS ситуация спокойнее. Новый сервер можно создать у другого провайдера, после чего в DNS-зоне изменить IP. Домен остается под теми же NS, поэтому не нужно ждать смены делегирования.
Это особенно удобно компаниям, которые используют несколько облаков или регулярно меняют инфраструктуру.
DNS становится постоянным слоем, а расположенные под ним серверы можно менять независимо.
Отдельный DNS полезен и при авариях, но он не делает сайт бессмертным
Иногда отдельный DNS преподносят почти как способ защитить сайт от любого падения хостинга. Это преувеличение.
Если основной веб-сервер недоступен, исправно работающий DNS продолжит честно отправлять посетителей на его IP. Сайт от этого не восстановится.
Настоящая отказоустойчивость появляется только тогда, когда есть резервный сервер или другая инфраструктура, на которую можно переключить трафик.
Но независимый DNS делает такое переключение значительно удобнее. Владелец меняет соответствующую запись и направляет домен на резервную площадку.
Более развитые DNS-сервисы могут автоматизировать часть подобных сценариев, но простой DNS-хостинг сам по себе не является балансировщиком или полноценной системой аварийного восстановления.
Его преимущество в другом: DNS не падает вместе с основной площадкой и остается доступной точкой управления маршрутом к сервисам.
Почему у домена несколько NS
Обычно для домена указывают не один авторитетный DNS-сервер, а несколько.
Смысл довольно очевиден. Если один сервер временно недоступен, другой продолжает отвечать на DNS-запросы.
Но две строки NS еще не гарантируют настоящую отказоустойчивость.
Если ns1 и ns2 работают на одной физической машине, в одном дата-центре и зависят от одного сетевого подключения, серьезная авария легко отключит оба сразу.
Поэтому качественная DNS-инфраструктура распределяет серверы между несколькими узлами, сетями и географическими площадками.
Пользователю обычного хостинга редко рассказывают архитектуру в деталях, но для важного коммерческого проекта этим вопросом уже стоит интересоваться.
Anycast позволяет одному DNS-адресу существовать во многих точках мира
У крупных DNS-провайдеров часто используется Anycast. Снаружи несколько серверных узлов могут использовать один и тот же IP-адрес, а интернет-маршрутизация направляет пользователя к подходящей доступной точке сети.
Вместо одного DNS-сервера в условном Франкфурте запрос обслуживается инфраструктурой, распределенной между множеством городов и дата-центров.
Это дает сразу два преимущества.
Первое — меньше зависимость от одной физической площадки. Если отдельный узел перестал работать, маршруты могут переключиться на другие.
Второе — DNS-ответ часто приходит от точки, расположенной сетево ближе к пользователю.
Для небольшого российского сайта разница в нескольких миллисекундах на DNS-запросе сама по себе редко переворачивает производительность. Браузеры и DNS-резолверы активно кэшируют ответы.
Настоящая ценность Anycast чаще заключается в устойчивости и распределенности инфраструктуры.
На что смотреть при выборе DNS-хостинга
Самая простая ошибка — сравнивать DNS-провайдеров только по числу доступных записей. Практически любому обычному сайту хватит очень небольшого количества A, AAAA, MX, TXT и CNAME.
Гораздо важнее надежность авторитетных серверов, удобство управления зоной и то, насколько легко исправить ошибку, если она произошла.
Редактор зоны должен быть понятным
DNS-панель используется редко, и именно поэтому неудобный интерфейс особенно раздражает.
Владелец может полгода не заходить в настройки, а затем срочно менять IP после переноса сервера. В этот момент ему совершенно не хочется вспоминать, где спрятан нужный раздел и почему поле автоматически добавило доменное имя второй раз.
Нормальная панель должна понятно показывать имя записи, тип, значение и TTL.
Хорошо, если система предупреждает о явно ошибочной конфигурации, но при этом не мешает опытному пользователю создавать нестандартные записи.
Для проектов с большим количеством доменов особенно полезны поиск, шаблоны зон, импорт и экспорт.
API становится важным раньше, чем кажется
Для одного домена ручного управления достаточно.
Когда доменов несколько десятков, повторять одинаковые действия в панели становится неудобно. Еще сильнее это чувствуется в инфраструктуре, где серверы создаются и удаляются автоматически.
DNS API позволяет приложениям менять записи без участия человека.
Например, система развертывания создала новый сервер, получила его IP и сразу обновила DNS. Или скрипт автоматически создает TXT-запись, необходимую для подтверждения владения доменом.
Обычному владельцу WordPress API может никогда не понадобиться. Для разработчиков, SaaS и компаний с большим количеством зон его наличие становится важным преимуществом.
TTL определяет не скорость DNS, а время жизни сохраненного ответа
TTL часто воспринимают как загадочную настройку, которую лучше не трогать. По смыслу все проще.
Значение сообщает DNS-резолверам, как долго они могут хранить полученный ответ в кэше прежде, чем запросить его снова.
Большой TTL уменьшает количество повторных DNS-запросов и делает записи более стабильными в кэше. Но изменение IP будет распространяться дольше среди пользователей, у которых сохранено прежнее значение.
Маленький TTL удобен перед миграцией. За некоторое время до переноса сайта его можно снизить, а после завершения вернуть к обычному значению.
Постоянно держать минимальный TTL без причины не обязательно.
И главное — изменение TTL непосредственно перед переносом не заставит мгновенно исчезнуть старые записи, которые уже были закэшированы с прежним большим временем жизни. Поэтому готовиться к важной миграции лучше заранее.
DNSSEC защищает подлинность DNS-ответов, но не шифрует их
DNSSEC является полезной возможностью хорошего DNS-хостинга, но вокруг нее существует много путаницы.
Эта технология добавляет цифровые подписи к данным DNS-зоны. Проверяющий резолвер может убедиться, что полученные данные действительно относятся к нужной зоне и не были незаметно подменены.
DNSSEC не является заменой HTTPS и не шифрует содержимое DNS-запросов.
Его задача — проверка подлинности и целостности DNS-данных.
Если DNS-провайдер поддерживает DNSSEC, включение обычно требует взаимодействия и с регистратором домена, потому что должна существовать корректная цепочка доверия от родительской зоны.
Самая опасная ситуация здесь не отсутствие DNSSEC, а неправильная конфигурация. Ошибочная DS-запись способна привести к тому, что валидирующие резолверы будут считать DNS-ответы недостоверными и домен перестанет открываться у части пользователей.
Поэтому перенос DNS-зоны с включенным DNSSEC нужно выполнять особенно внимательно.
Бесплатный DNS не означает плохой DNS
В отличие от многих других инфраструктурных услуг, хороший DNS действительно может предоставляться бесплатно.
Причина проста: объем данных одной DNS-зоны крошечный по сравнению с хранением файлов, видео или полноценной виртуальной машины. Крупные инфраструктурные компании могут использовать бесплатный DNS как часть своей более широкой экосистемы.
Регистраторы доменов тоже нередко включают DNS-обслуживание без дополнительной платы.
Поэтому платить за DNS только ради того, чтобы он считался профессиональным, не нужно.
Платные тарифы становятся интересны из-за дополнительных возможностей: расширенной аналитики, SLA, дополнительной защиты, сложного управления трафиком, больших лимитов, корпоративной поддержки и специализированных функций.
Для обычного сайта бесплатного авторитетного DNS от надежного провайдера вполне может быть достаточно.
DNS у регистратора тоже может быть хорошим выбором
Есть три распространенных варианта: DNS у регистратора домена, DNS у веб-хостера и отдельная DNS-платформа.
Нельзя сказать, что один из них автоматически правильный.
DNS регистратора особенно удобен тем, что не зависит от веб-хостинга. Сайт можно переезжать между провайдерами, не меняя NS.
DNS хостинга обычно проще для новичка. Добавили домен в панель, записи появились автоматически, поддержка может помочь с настройкой.
Отдельный DNS-провайдер особенно интересен там, где нужна независимая инфраструктура, Anycast, API или расширенные возможности управления.
Выбирать стоит исходя из задачи, а не из идеи, что DNS обязательно нужно куда-то вынести.
Нужно ли переносить DNS при смене хостинга
Нет.
Это одна из самых полезных особенностей раздельной инфраструктуры.
Представим, что DNS находится у регистратора, а сайт работает на VPS. Вы покупаете новый сервер у другого провайдера, переносите туда файлы и базу данных, проверяете проект по временному адресу и затем меняете A-запись на новый IP.
NS-серверы домена остаются прежними.
Почтовые MX-записи тоже можно вообще не трогать, если почта находится у отдельного сервиса.
Такой перенос намного безопаснее попытки одновременно поменять хостинг, DNS и почтовую инфраструктуру.
Каждый компонент изменяется отдельно, поэтому проще понять причину проблемы, если что-то пошло не так.
А нужно ли менять NS при переносе домена к другому регистратору
Тоже не обязательно.
Смена регистратора и смена DNS-провайдера являются разными операциями.
Если новый регистратор позволяет оставить прежние NS, домен может продолжить использовать ту же DNS-зону, что и до трансфера.
Это еще одна причина не воспринимать домен и DNS как одну неразделимую услугу.
Но перед переносом всегда нужно проверить правила конкретной доменной зоны и нового регистратора, а также убедиться, что доступ к действующему DNS-хостингу сохранится после трансфера.
Что проверить перед переносом DNS к другому провайдеру
Самая неприятная ошибка — поменять NS и только потом вспомнить, что в новой зоне отсутствует половина записей.
Перед переключением нужно перенести не только A-запись сайта.
Особенно легко забыть MX для почты, TXT для SPF и различных подтверждений, DKIM, DMARC, поддомены, API, верификационные записи сторонних сервисов и записи, созданные несколько лет назад.
Если старая панель позволяет экспортировать DNS-зону, лучше воспользоваться экспортом и затем внимательно проверить результат.
При ручном переносе полезно сравнить старую и новую зоны строка за строкой.
После этого можно менять NS у регистратора.
Старую DNS-зону не стоит удалять сразу. Часть запросов некоторое время может продолжать приходить к прежним серверам из-за кэширования информации о делегировании.
Несколько дней параллельной работы старой и новой зоны обычно значительно спокойнее мгновенного удаления всего после нажатия кнопки Сохранить.
Когда отдельный DNS-хостинг действительно нужен
Для одного небольшого сайта, который много лет находится у одного надежного хостера, отдельный DNS может ничего заметно не улучшить.
И это нормально. Инфраструктуру не нужно усложнять только потому, что технически это возможно.
Но отдельный DNS становится гораздо интереснее, если сайт критичен для бизнеса, используются несколько серверов, часто происходят миграции или компания не хочет связывать домен, DNS и веб-хостинг с одним аккаунтом.
Он полезен и разработчикам, которым нужен API для автоматического управления записями.
Для международного проекта дополнительным аргументом может стать распределенная Anycast-инфраструктура.
Для компании с множеством доменов важны централизованное управление, роли пользователей, история изменений и возможность массовой работы с зонами.
В таких случаях DNS перестает быть маленьким разделом в панели хостинга и превращается в самостоятельную инфраструктурную услугу.
Когда выносить DNS отдельно не стоит
Есть и обратная сторона.
Чем больше независимых сервисов используется, тем больше аккаунтов, доступов и панелей нужно контролировать.
Новичку гораздо проще обратиться в одну поддержку и сказать сайт не открывается, чем самостоятельно выяснять, проблема находится у регистратора, DNS-провайдера или на VPS.
Если DNS у хостера работает стабильно, есть несколько независимых NS, панель удобна и никаких сложных сценариев не планируется, перенос ради самого факта разделения мало что даст.
Сначала должна появиться причина, а уже потом новая инфраструктура.
Надежный DNS-хостинг вообще хорош тем, что о нем почти никогда не приходится вспоминать. Записи отвечают, домен открывается, почта приходит, а изменение IP выполняется за несколько минут из понятной панели.
Для небольшого сайта такого результата вполне можно добиться DNS-сервисом обычного хостинга или регистратора.
Для крупного проекта отдельная DNS-платформа дает больше независимости и контроля. Сайт можно переносить между серверами без смены NS, разные услуги перестают зависеть от одного провайдера, а распределенная инфраструктура уменьшает зависимость от отдельной площадки.
Но DNS-хостинг не стоит превращать в магическую технологию ускорения сайта. Основное время загрузки страницы по-прежнему зависит от веб-сервера, базы данных, кода, изображений и сети. DNS всего лишь должен быстро и надежно сообщить, куда отправляться за этим сайтом.
И если он делает это круглосуточно, независимо от текущего хостинга и без сюрпризов во время очередного переноса, значит свою небольшую, но критически важную работу DNS-хостинг выполняет правильно.
