Что такое dns делегирование

Обновлено: 04.07.2024

Делегирование домена — это привязка домена к хостингу, после которой его сервера будут отвечать за его работоспособность.

Чтобы делегировать домен: пропишите необходимые ДНС-серверы в кабинете регистратора домена. Чтобы проверить, произошла ли привязка домена, достаточно воспользоваться сервисом Whois, указав в поле урл-сайта.

Как делегировать права на домен

Приведем пошаговую инструкцию:

Информацию о них можно получить в письме, которое пришло вам после заказа услуг хостинга.

На протяжении ближайших 10 минут сайт может быть недоступен. На саму привязку может уйти гораздо больше времени: от нескольких часов до 2-3 дней.

Еще бывает частичное делегирование. К нему прибегают, когда нужно прописать субдомену отдельный DNS-сервер, чтобы им управлял отдельный администратор, при этом не имел доступа к остальным доменам.

Что значит снять домен с делегирования

Причин, по которым доменное имя может быть снято с делегирования много. В этот период он будет недоступен для пользователей, но информация в Whois все равно будет отображаться прежняя.

Делегирование может быть снято тремя лицами: хостер, компания-регистратор и сам вебмастер. При покупке домена вы соглашаетесь с тем, что компания оставляет за собой право снять домен с делегирования, если будут обнаружены нарушения договора сотрудничества или поступят какие-то жалобы.

Столкнувшись с такой проблемой, нужно как можно быстрее написать регистратору, чтобы выяснить причину. После решения проблемы услуги будут восстановлены. Чем быстрее вы это сделаете, тем меньше урона получит ваш ресурс.

Владелец сайта может сам снять делегирование. Сделать это легко:

Авторизоваться в панели управления.
Выбрать подходящий домен и кликнуть «Приостановить делегирование».

Отвязка может произойти не сразу. Время зависит от доменной зоны. Но обычно на это уходит от 1-2 часа.

Хостинг сайта и DNS — две разные услуги, хоть и часто идут в одном пакете. Они никак не связаны между собой, поэтому вы сможете поменять ДНС сервера без всяких последствий для своего ресурса. Он будет все так же доступен.

Можно ли обойтись без делегирования?

Да, такая возможность предоставляется вебмастерам. Делегирование происходит автоматически, если вы сотрудничаете лишь с одним провайдером, то есть покупаете у него и домен и хостинг. Часто такие компании предлагают клиентам выгодные условия: например, делают скидку на регистрацию домена или даже позволяют получить его бесплатно при заказе хостинг услуг на определенный период.

Если же доменное имя и хостинг вы заказывали у разных компаний, то работоспособность сайта без делегирования невозможна. Поисковые боты не проиндексируют его содержимое, страницы не попадут в поиск и их не увидят пользователи.

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Ресурсные записи

Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.

Запись ресурса состоит из следующих полей:

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
Резолверпосылает запрос указанному серверу имен.
Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
и «вложенности» доменных имен.
В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Запись заголовка — служебную информацию о запросе.
Запись запроса — повторяет отправленный запрос.
Запись ответа — собственно, сам ответ.
Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Наглядно приведенную схему можно представить командами:

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

В этой статье я покажу, как делегировать домен, расскажу, что это значит, а также вы узнаете, что такое DNS. Вообще, новичкам это может показаться сложным, однако это придётся сделать для того, чтобы создать сайт. Делать это нужно всего один раз для каждого нового сайта. Потребуется также и при переносе с одного хостинга на другой или с локального сервера на реальный хостинг. В общем, вещь нужная и знать обязательно, хоть и трудно понять.

Для того чтобы рассказать, как делегировать домен, мне придётся начать издалека – с DNS.

Что такое DNS

Английская аббревиатура DNS расшифровывается как domain name system, что на русский язык переводится – система доменных имён. Как известно, домен имеет свой IP. И для того, чтобы пользователям интернета не пришлось вписывать в адресную строку браузера сложный многозначный IP сайта, были введены домены – легко запоминающиеся короткие слова. Так вот, DNS – это как раз таки та система, в которой содержится вся информация о каждом домене, и о том, к какому IP (хостингу) он принадлежит. Подробнее о доменах вы можете узнать в этой статье.

DNS – это система доменных имён, в которой содержатся данные о том, какой IP у домена сайта, а следовательно, в какому хостингу он относится. Отсюда становится понятно – что если DNS настроена неправильно, то сайт работать не будет.

Как делегировать домен на хостинг

Итак, теперь переходим непосредственно к вопросу о том, как делегировать домен. Как вы должны были уже догадаться сами, под делегированием понимается присвоение доменному имени IP адреса сервера хостинга.

Делегирование домена, говоря простыми словами – это направление домена на хостинг. Данный процесс показывает, на каком хостинге находится тот или иной домен и откуда нужно закачивать файлы для отображения их в браузере посетителя.

Направление домена происходит с помощью назначения ему NS серверов хостинга (под NS кроется и IP, но он имеет совершенно иной вид). Перед тем, как делегировать домен, вам следует получить NS своего хостинга. Делается это в персональном кабинете хостинг-аккаунта. Покажу на скриншоте, как это выглядит на хостинге, на котором находится раньше находился мой сайт (Hostinger). Если у вас другой хостинг, то у вас должно быть что-то похожее, но суть одинакова. NS бывает несколько – обычно 4 штуки.

Мои NS выглядят так:

Теперь переходим в персональный кабинет регистратора своего домена и записываем там полученный NS. Опять же, как делегировать домен я покажу на примере своего регистратора (2Domains). Если у вас другой, то кое-что будет отличаться, но суть одна и та же.

Прописывание NS от хостинга в панели управления домена – это и есть направление домена на хостинг. Теперь вы знаете, как делегировать домен, но не знаете ещё кое-чего.

Обновление DNS

Отдельная история – это обновление DNS. Понятно, что каждый день регистрируется множество доменных имён, кроме того, многие переезжают с одного хостинга на другой (с одного NS на другой). Поэтому система DNS должна постоянно обновляться, чтобы оставаться актуальной.

Обновление DNS происходит у каждого интернет-провайдера по-своему и не зависит ни от кого, кроме них самих. То есть, каждый интернет провайдер обновляет в своём собственном кэше информацию о привязанности того или иного доменного имени к какому-то хостингу. Делают это провайдеры редко – у некоторых может доходить до 1 раза каждые 72 часа.

Поэтому, если вы делегировали домен и прописали NS хостинга, сайт будет работать полноценно только через 72 часа. В течение этого времени он может в некоторых регионах уже работать, а в других ещё нет. Ругаться с поддержкой хостера или регистратора нет смысла. Также интернет-провайдер вам ничего не поможет. В этом случае нужно просто подождать, пока заданные вами NS распространятся по всему миру.

Как посмотреть сайт, если делегирование домена ещё не завершилось

После сохранения изменения ваш сайт будет доступен в браузере по своему домену. Однако у вашего друга, на другом конце света или на соседней улице, но который сидит на другом провайдере интернета, сайт ещё может не работать. Когда делегирование домена завершится, можно удалить эту запись из hosts.

Делегировать домен — значит передать управление доменом на выбранный DNS-сервер. Вы можете делегировать домен на DNS-серверы Яндекса — тогда они будут хранить служебную информацию о вашем домене и управлять этой информацией.

Внимание. Перед тем как делегировать домен, подключите его к организации и подтвердите. Если сделать наоборот, вы можете потерять контроль над доменом.

Если вы делегируете домен на серверы Яндекса:

будут автоматически настроены необходимые для работы Почты DNS-записи — MX, SPF, CNAME и DKIM;

вы сможете управлять DNS-записями домена c помощью DNS-редактора Коннекта.

Если на вашем домене находится сайт, в большинстве случаев делегирование домена не повлияет на его работу. Чтобы убедиться, что адрес сайта привязан к имени домена, в DNS-редакторе Коннекта проверьте A-записи домена.

Делегировать домен можно в личном кабинете на сайте вашего регистратора. Для этого в настройках домена нужно изменить NS-записи — адреса DNS-серверов, которые обеспечивают работоспособность домена. Вы можете делегировать только те домены, которые уже подключены к вашей организации в Коннекте.

Чтобы делегировать домен на серверы Яндекса:

На главной странице Яндекс.Коннекта на карточке сервиса Вебмастер нажмите значок .

Убедитесь, что статус вашего домена отображается как Подтвержден. На сайте регистратора вашего домена перейдите в раздел управления DNS-серверами (делегирования).

Если в настройках делегирования есть поля для ввода IP-адресов, оставьте их пустыми.

Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.

На странице управления доменамиубедитесь, что статус вашего домена отображается как Делегирован.

","prev_next":<"prevItem":<"disabled":false,"title":"Подключить домен","link":"/support/connect/add-domain.html">,"nextItem":>,"breadcrumbs":[,],"useful_links":null,"meta":,"voter":","extra_meta":[>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>,>],"title":"Делегировать домен - Яндекс.Коннект. Справка","productName":"Яндекс.Коннект","extra_js":[[,"mods":,"__func137":true,"tag":"script","bem":false,"attrs":,"__func67":true>],[,"mods":,"__func137":true,"tag":"script","bem":false,"attrs":,"__func67":true>,,"mods":,"__func137":true,"tag":"script","bem":false,"attrs":,"__func67":true>],[,"mods":,"__func137":true,"tag":"script","bem":false,"attrs":,"__func67":true>]],"extra_css":[[],[,"mods":,"__func69":true,"__func68":true,"bem":false,"tag":"link","attrs":>,,"mods":,"__func69":true,"__func68":true,"bem":false,"tag":"link","attrs":>],[,"mods":,"__func69":true,"__func68":true,"bem":false,"tag":"link","attrs":>]],"csp":<"script-src":[]>,"lang":"ru">>>'>

Если вы делегируете домен на серверы Яндекса:

будут автоматически настроены необходимые для работы Почты DNS-записи — MX, SPF, CNAME и DKIM;

вы сможете управлять DNS-записями домена c помощью DNS-редактора Коннекта.

Чтобы делегировать домен на серверы Яндекса:

На главной странице Яндекс.Коннекта на карточке сервиса Вебмастер нажмите значок .

Делегирование – это передача права на управлении доменным именем и его поддоменами. При этом обслуживание (оплата) производится на стороне регистратора, а определение ресурсных записей (DNS настроек домена) - на стороне системы, куда домен делегирован.

Например, при делегировании домена в Beget, ресурсные записи по умолчанию ведут на сервер нашего хостинга. То же, актуально для MX-записей – записей определяющих то, где будет производится обработка доменной почты.

Как добавить домен с другого хостинга для последующего делегирования этого домена?

В первую очередь необходимо добавить домен, который Вы делегируете, в Панели Управления в разделе "Домены и поддомены". В подразделе "Список доменов и поддоменов" необходимо ввести имя домена и указать, к какому сайту будет привязан (прилинкован) домен, и нажать кнопку "Добавить".

При добавлении домена можно:

Также обращаем Ваше внимание, что домен начнёт работать от нас в течение 24-х часов. Задержка связана как с самими изменениями на сервере регистратора, так и с кэшированием DNS данных на всем пути до конечных пользователей.

Правильность добавления домена можно проверить, настроив соответствие домена к IP-адресу сервера хостинга на вашем компьютере. Этот шаг не обязателен, но будет полезен для исключения ошибок и проверки того, что сайт добавлен на хостинге и домен можно делегировать. Подробнее об этом можно прочитать в полезной статье: Как добавить соответствие IP-адреса и домена сайта в файл /etc/hosts.

Данную строчку нужно убрать из файла по завершении проверки, результатом которой будет локальная (на вашем устройстве) принудительная замена IP-адреса сервера хостинга на указанный в правиле соответствия IP к доменному имени.

Для того, чтобы Ваш сайт заработал на нашем хостинге на постоянной основе, необходимо в настройках домена, на стороне регистратора, прописать наши ns-сервера:

Как мне узнать, кто регистратор моего домена?

Это информация о Вашем домене. Нас интересует поле REGISTRAR. Именно в этом поле содержится информация о регистраторе. В нашем примере это регистратор R01.

Как мне продлевать домен через Вас?

Для того, чтобы продлевать домен через нас, необходимо перенести Ваш домен под наше обслуживание. Процедура переноса домена зависит от регистратора и зоны домена. Для получения подробной процедуры переноса домена вы можете прочитать нашу статью или обратиться в нашу техническую поддержку.

Как мне сменить администратора домена?

Смена администратора производится на основании официальных писем от текущего администратора и от лица, которому передаются права администрирования, поступивших в адрес регистратора.

Все подробности смены администратора можно получить непосредственно на сайте регистратора. Обратитесь в нашу техническую поддержку, и мы постараемся помочь Вам узнать регистратора и найти инструкции по смене администратора.

Что такое EPP-key, зачем он нужен?

EPP-key - это секретный ключ, который необходим при переносе к другому регистратору домена в международной зоне.

EPP-key нужен для переноса домена на обслуживание к нам. Если Вы хотите перенести домен к нам на обслуживание, Вам нужно будет сообщить секретный ключ (EPP-key).

Что нужно для переноса домена в международной зоне к другому регистратору?

Перенос доменов в международной зоне осуществляется по секретному ключу (EPP-key). Как правило, секретный ключ доступен в Личном Кабинете у текущего регистратора. Если же Вы не можете найти секретный ключ, направьте письмо с электронного ящика, с которого была регистрация данного домена, текущему регистратору домена с просьбой сообщить секретный ключ. При переносе домена, согласно правилам регистрации в международной зоне, необходимо оплатить продление домена на 1 год. Для осуществления переноса домена на обслуживание к нам сообщите ключ и пополните баланс на необходимую сумму.

После того, как мы подадим заявку, Вам на электронный ящик, указанный при регистрации, будет направлено письмо с ссылкой, по которой Вы должны будете перейти и подтвердить перенос, после чего в течение 10 дней домен будет перенесен.

В таких случаях обычно нужно немного подождать. Если по истечении 30 минут ошибка продолжает возникать, обратитесь в службу технической поддержки.

Читайте также: