Меню
ГлавнаяФайлы и папки

Как добавить в dns запись типа txt. Полный текст зоны. Изменение NS-серверов домена

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

Что такое доменное имя? Для многих это синоним адреса сайта, например, www.сайт . Набирая этот адрес вы твердо уверены, что попадете именно на этот сайт, а не куда-нибудь еще. В тоже время доменное имя может обозначать не только сайт, но и сервер электронной почты, обмена короткими сообщениями или иной другой интернет и сетевой сервис. Доменные имена входят в доменные зоны, которые расположены внутри друг друга в иерархическом порядке.

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

Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:

Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru , сom , org и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.

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

В свою очередь домены второго уровня тоже являются доменными зонами и позволяют размещать в себе домены третьего уровня, в которые, как в матрешку, помещать домены четвертого, пятого и т.д. уровней. Для того, чтобы можно было однозначно определять узлы, находящиеся в разных зонах, введено понятие полностью определенное имя домена (FQDN, Fully Qualified Domain Name ), которое включает в себя все имена родительских доменов в иерархии DNS. Например, для нашего сайта FQDN будет: сайт. Именно так, с окончанием на точку, обозначающее корневую зону.

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

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

MailIN CNAMEdomain.mail.yandex.net.

В данном случае имя mail не является FQDN и будет дополнено до mail.сайт. , если же мы забудем поставить точку в конце имени домена Яндекса, то это имя также не будет восприниматься как FQDN и должно быть дополнено до полного имени домена. Ниже показана неправильная запись:

Mail IN CNAME domain.mail.yandex.net

Неподготовленным взглядом разницу заметить сложно, но вместо веб-интерфейса почты Яндекса такая конструкция отправит нас на несуществующий адрес: domain.mail.yandex.net.сайт.

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

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

Итак, вы купили домен, скажем, example.org , после чего вы должны его делегировать, т.е. указать сервера имен (DNS-сервера), которые будут содержать записи данной файловой зоны. Это могут быть как ваши собственные сервера, так и публичные сервисы, например, DNS Яндекса.

В этом случае в доменной зоне org будет добавлена запись:

Example IN NS dns1.yandex.net.

Которая будет указывать, что все записи этой зоны расположены на сервере dns1.yandex.net . По правилам, каждая доменная зона должна иметь не менее двух NS-серверов, расположенных в разных подсетях. На практике часто обходятся одним сервером, приобретая для него два IP-адреса из разных диапазонов.

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

Допустим, пользователь хочет посетить популярный ресурс Яндекс Маркет, он набирает в адресной строке браузера соответствующее имя сайта и нажимает кнопку Enter. Для того, чтобы отобразить пользователю содержимое страницы браузер должен отправить запрос обслуживающему сайт веб-серверу, а для этого нужно знать его IP-адрес. Поэтому браузер обращается к DNS-клиенту с целью узнать, какой адрес соответствует введенному пользователем доменному имени.

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

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

Итак, клиент отправляет DNS-запрос серверу провайдера с целью узнать адрес домена market.yandex.ru , сервер провайдера не располагает подобной информации, поэтому обращается к одному из корневых серверов, передавая ему запрос. Корневой сервер также не имеет нужных записей, но отвечает, что знает сервер, отвечающий за зону ru - a.dns.ripn.net . Вместе с данным именем корневой сервер может сразу сообщить его IP-адрес (и в большинстве случаев сообщит), но может и не сделать этого, если не располагает такой информацией, в таком случае, перед тем как обратиться к данному серверу, нужно будет выполнить еще один рекурсивный запрос, только уже для определения его имени.

Выяснив адрес сервера, отвечающего за зону ru, сервер провайдера передаст запрос ему, но данный сервер также не имеет нужных записей, но сообщит, что за зону yandex отвечает сервер ns1.yandex.ru и обязательно сообщит его адрес. Иначе рекурсию завершить не удастся, так как за зону yandex отвечает сервер, находящийся в зоне yandex . Для этого в вышестоящей зоне, кроме NS-записи об обслуживающих зону серверах имен, создается "связанная" А-запись , которая позволяет узнать адрес такого сервера.

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

Теперь рассмотрим еще один момент. Запросы могут быть рекурсивными или нерекурсивными. Рекурсивный запрос предусматривает получение готового ответа, т.е. IP-адреса или сообщения что домен не существует, не делегирован и т.п. Нерекурсивный запрос предусматривает ответ только о той зоне, за которую отвечает данный сервер или возврат ошибки.

Так как рекурсивные запросы являются достаточно ресурсоемкими большинство серверов сети DNS обрабатывают рекурсивные запросы нерекурсивно. Либо могут делать это выборочно, например, DNS-сервера провайдера выполняют рекурсивные запросы только для своих клиентов, а остальные нерекурсивно.

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

Например, если пользователь после посещения Яндекс Маркета решит воспользоваться почтовым сервисом, то сервер сразу направит запрос к ns1.yandex.ru , так как уже знает, какой сервер содержит записи для зоны yandex .

От теории к практике

Когда вы приобретаете у регистратора домен, вам будет предложено его делегировать, т.е. указать DNS-сервера, на которых будет расположена доменная зона. Это могут быть сервера регистратора (обычно бесплатно), сервера хостера, публичные DNS-сервисы или собственные сервера имен, если он будет расположен в этой же доменной зоне, то вам потребуется также указать IP-адреса. Например, так выглядит окно делегирования домена у одного известного регистратора:

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

Если вы переносите сайт к другому хостеру, то вам потребуется перенести сайт и поменять у регистратора сервера имен старого хостера на сервера нового. Но учтите, что информация в кэше DNS-серверов обновляется не мгновенно, а, как минимум, по истечении значения TTL-домена, поэтому в течении некоторого времени ваш сайт может быть доступен еще по старому адресу. Если вам надо срочно с ним работать, то можете, не дожидаясь обновления DNS-кэша вашего провайдера, добавить в файл hosts запись следующего содержания:

1.2.3.4 example.com

Где 1.2.3.4 и example.com соответственно новый IP-адрес и имя вашего домена.

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

В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:

@ IN A 1.2.3.4
www IN A 1.2.3.4

Символ "собачки" в DNS-записях обозначает сам домен, кроме того обязательно следует создать запись для поддомена www, чтобы пользователи, набравшие адрес сайта с www, также могли получить к нему доступ.

Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье:

При переносе сайта вам потребуется изменить только IP-адреса в A-записях и дождаться обновления DNS информации. Обычно, это самый неприятный момент - вроде бы все сделано, но ничего изменить вы не можете, остается только ждать. Но если выполнить некоторые рекомендации, то данный процесс можно провести максимально безболезненно и незаметно для посетителей.

Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:

Nslookup -typr=soa сайт

В нашем случае это 4 часа:

Поэтому заранее, не менее 4 часов (старое значение TTL) до планируемого переноса, измените значение TTL на более низкое, например, 900 (15 минут). Затем переведите свой сайт в режим "только чтение" и перенесите его на новый сервер. Выключать или переводить на техобслуживание сайт не следует, он может и должен оставаться доступным. Но вы должны исключить изменение и добавление информации пользователями, т.е. запретить регистрацию, комментирование, размещение заказов и т.п. Также не забудьте разместить на видном месте сообщение о технических работах и примерный срок их завершения.

Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.

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

Мы рассмотрели самую простую схему, но на практике, кроме сайта, обычно есть еще офисная сеть, многие ресурсы которой должны быть также доступны извне. Рассмотрим следующую схему:

У нас имеются публичные сервера для сайта и электронной почты и офисная сеть, для которой мы выделили поддомен office . Если с почтой и веб-сервером особых вопросов нет, то с офисной зоной есть варианты. Обычно локальная зона обслуживается собственным DNS и никак не связана с материнской зоной. Для глобальной системы DNS зона office.example.com не существует, но существует одноименный хост. Это оправдано, если сеть предприятия находится за NAT и ее узлы имеют только серые адреса, а доступ извне осуществляется только к шлюзу, на который проброшены соответствующие порты от внутренних узлов.

В этом случае DNS записи зоны example.com могут выглядеть следующим образом:

@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8

Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com , которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.

В локальной сети DNS-запросы клиентов обслуживает локальный сервер, которые имеет соответствующие записи, за ее пределами запросы будут направлены серверу, обслуживающему зону example.com . При этом все корпоративные ресурсы, которые в локальной сети представлены различными серверами, извне доступны по единственному адресу: office.example.com . Поэтому самое время вспомнить о записи псевдонима или CNAME. Данная запись позволяет связывать с реальным именем хоста дополнительные мнемонические имена или псевдонимы. При этом учтите, что использовать в других записях псевдонимов недопустимо. В нашем случае следует добавить записи:

Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.

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

Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.

Еще одно применение псевдонимов - это сокращение адреса. Допустим, в качестве почтового сервера для всего домена example.com мы хотим использовать сервер, который расположен в московском офисе и имеет адрес mail.office.msk.example.com , согласитесь, выглядит не слишком привлекательно. Гораздо удобнее был бы адрес вида mail.example.com , нет ничего проще, добавим следующую запись:

Mail IN CNAME mail.office.msk.example.com.

Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:

Example.com. IN MX 10 mail

Правильно будет так:

Example.com. IN MX 10 mail.office.msk

Напоследок поговорим о делегировании доменных зон. В примере выше мы рассмотрели ситуацию, когда внутри домена различным подразделениям выделены свои поддомены, так как у каждого подразделения имеется своя инфраструктура, то есть смысл делегировать им управление собственными доменными зонами. Для этого в зоне example.com следует разместить NS и связанную с ней A-запись для каждой зоны. Например:

Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.

ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Теперь при обращении по адресу, скажем mail.office.msk.example.com сервера имен зоны example.com будут выдавать имя и адрес сервера, обслуживающего зону msk.example.com . Это позволяет администраторам зоны самостоятельно вносить необходимые изменения, не затрагивая при этом функционирования вышестоящей зоны и не обращаясь к ее администраторам по любому вопросу, требующему изменения записей.

  • Теги:

Please enable JavaScript to view the

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

Зачем нужно подтверждение

Подтвердив право собственности на домен, вы сможете пользоваться своим сервисом Google, например G Suite, Drive Enterprise или Cloud Identity. Аккаунт G Suite открывает доступ к Gmail, Google Диску и другим службам.

Примечание. Если вы приобрели домен при регистрации аккаунта G Suite, вам не нужно подтверждать право собственности на него.

Подтверждение права собственности на домен Google

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

Google предоставит вам проверочную запись TXT , которую нужно добавить в записи DNS регистратора домена. Наличие этой записи подтверждает, что домен действительно принадлежит вам. Это действие не отразится на работе электронной почты или сайта.

Как добавить проверочную запись TXT (инструкции для популярных регистраторов домена)

  1. Определите своего регистратора домена (например, с помощью этой статьи).
  2. Воспользуйтесь пошаговыми инструкциями (они доступны для некоторых регистраторов домена).

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

Как добавить проверочную запись TXT (общие инструкции для разных регистраторов домена)

1. Получите проверочную запись.

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

Если вы ещё не вышли из мастера, перейдите к пункту 3. В противном случае начинайте с пункта 1.

2. Откройте записи DNS своего домена.

  1. В новом окне или вкладке откройте сайт регистратора домена. Подробнее о том, как определить своего регистратора …
  2. Откройте записи DNS своего домена. Соответствующая страница может называться DNS Management (Управление DNS) , Name Server Management (Управление серверами доменных имен) , Control Panel (Панель управления) или Advanced Settings (Расширенные настройки) .
  3. Выберите команду для добавления новой записи.

3. Добавьте проверочную запись.

  1. В качестве типа записи выберите TXT .
  2. В поле Name/Host/Alias (Имя/хост/псевдоним) введите @ или оставьте его пустым. У некоторых регистраторов в этом поле нужно добавить домен, например vash-domen.com (правильный вариант можно посмотреть в других записях DNS).
  3. В поле Time to Live (TTL) (Время жизни) введите 86400 или оставьте значение по умолчанию.
  4. В поле Value/Answer/Destination (Значение/ответ/назначение) вставьте скопированную запись подтверждения из мастера настройки.
  5. Сохраните изменения.

Примечание. Если появится предупреждение об изменении настроек DNS, игнорируйте его. Добавление записи TXT не затронет ваш сайт и настройки DNS.

Любой пользователь Интернет имеющий домены на серверах хостинг-провайдеров могут создавать и редактировать свои DNS записи. DNS записи имеют Имя, Тип записи и Адрес. Эти названия в различных панелях могут меняться. Например, может быть так:

Имя/Хост/Псевдоним; Тип записи ; Значение/Ответ/Назначение/Адрес.

Во всех вариантах «Тип записи» остается неизменным.

Имя записи

Имя записи, оно же хост/псевдоним это доменное имя, к которому принадлежит или привязана создаваемая запись.

При создании записи в поле «Имя» доменное имя указывается полностью. Имя субдомена или псевдонима не нужно указывать полностью. Достаточно указать имя третьего уровня: mail, www, ftp. Если вводите полное имя, обязательно поставьте точку в конце. То есть имя mail и mail.example.ru. это одно и то же имя в поле Имя/хост/псевдоним.

DNS записи- типы

Рассмотрим основные типы DNS записей, с которыми предстоит сталкиваться при обслуживании своих доменов.

Тип записи А

Тип записи: А (address record) или (адрес Internet 4) . Этот тип записи привязывает конкретное доменное имя на определенный, точный IP-адрес.

Можно добавить больше одного IP адреса для одного домена (имени хоста). Это нужно если используется firewall. Для этого нужно добавить вторую запись типа A, аналогично первой. Указав только другой IP.

В теории можно для одного IP адреса, указать более одного домена. Но этого делать не нужно, так как система доменных имен (DNS) имеет запись специально предназначенную для создания псевдонимов. Называется эти запись типа CNAME.

Тип записи АААА

Тип записи: AAАA (address record для IPv6) или (адрес Internet 6) . Тоже. Что и тип записи А, но IP адрес имеет внешний вид по протоколу IPv6. Например: IPv6-2a03:4900:0:3::99:155

Тип записи CNAME

CNAME (каноническое имя -canonical name record) . Запись типа CNAME позволяет иметь и использовать на сервере более одного имени домена (хоста).

Сначала создается одна запись типа А, для одного IP адреса. Имя домена в записи типа А, называется каноническим именем. Другие домены называют мнемонические. Мнемонические имена могут быть псевдонимами (произвольными именами) или субдоменами. Здесь пример CNAME записи:

popov.example.ru. CNAME example.ru. (не забываем точки в конце).

Сервер может иметь любое количество псевдонимов. Для каждого псевдонима нужно создать запись типа CNAME.

Еще пример записи CNAME:

hosting-1 IN A 8.8.8.8

www IN CNAME hosting-1

ftp IN CNAME hosting-1

Покупаем второй IP и на второй IP переводим поддомен ftp:

hosting-1 IN A 8.8.8.8

hosting-2 IN A 8.8.8.9

www IN CNAME hosting-a

ftp IN CNAME hosting-b , переносим на второй хостинг FTP –сервер.

Еще пример записи CNAME:

hosting-1 IN A 8.8.8.8

peter IN CNAME hosting-1

oleg IN CNAME hosting-1

Следующими записями CNAME привязываем псевдонимы:

example.com. IN CNAME example.ru.

www.example.com. IN CNAME example.ru.

test.example.com. IN CNAME example.ru.

тем самым мы связываем домены example.com, www.example.com, test.example.com с каноническим доменом example.ru. Точки в конце обязательны.

Еще пример переадресация (редирект) с помощью записи типа CNAME

www.example.ru. IN CNAME example.ru.

Обычно, сервера по умолчанию создают записи CNAME только для поддоменов основного домена и не делают их для других доменов (как на фото).

Тип записи MX

MX (почтовый сервер). Эта запись создает поддомен, который обслуживается внутренним (своим) почтовым сервером.

Например: Имя/хост/псевдоним — example.ru; Тип записи -MX (почтовый сервер); Значение/ответ/назначение/Адрес – mail. Этой записью вы создаете почтовый поддомен mail.example.ru. Если используется внутренний почтовый сервис сервера, то для поддомена mail.example.ru нужно создать тип записи «А». Имя:mail- A (тип записи)- Адрес: IP сервера.

В качестве почтового сервиса можно использовать сторонние почтовые сервера. Для этого вам нужно привязать свой домен к стороннему почтовому серверу. На нем вам создадут, автоматом, MX запись. Если не создадут, то дадут адрес почтового сервера. После этого вам нужно создать записи типа CNAME и MX на своем сервере.

Записью CNAME переадресуйте почтовый домен mail.example.ru. на адрес почтового домена. А записью типа MX для самого домена example.ru. задайте адрес вашего стороненого почтового ящика. В качестве примера можно использовать почтовый сервер Яндекс.

  • Для Яндекс тип записи MX будет такой:

Имя/хост/псевдоним — example.ru; Тип записи -MX (почтовый сервер); Значение/ответ/назначение/Адрес – mx.yandex.ru. Приоритет 10.

  • Тип CNAME такой:

Имя/хост/псевдоним – mail; Тип записи –CNAME; Значение/ответ/назначение/Адрес –domain.mail.yandex.ru. Приоритет 10.

На почтовом сервере Яндекс , можно без делегирования домена, подключить его только к почтовому серверу Яндекс, создав там, почтовый ящик.

Кроме Яндекс, с помощью MX записей можно привязать домен к почтовым серверам Google, Mail.ru и другим:

Тип записи NS

Тип записи NS (сервер имён). Это, пожалуй, самый важный тип записи. Он определяет домены (адреса) DNS серверов, обслуживающих этот домен.

Тип записи TXT

TXT (текстовая запись) . Это информационная запись. Она не несет функциональной нагрузки.

Запись типа SOA (Start Of Authority)

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

  • Произвольный серийный номер версии данных (Serial). При запросе вторичного сервера на обновление данных, он, прежде всего, проверяет серийный номер;
  • Периодичность запроса для обновления данных со стороны вторичного (Secondary) сервера (Refresh), в секундах;
  • Период повторного запроса вторичного сервера при первичной неудаче (Retry);
  • Срок действия (годности) данных (Expire), иначе истечение времени, через которое вторичный сервер перестанет обслуживать запросы, если ему не получиться восстановить связь с первичным сервером, в секундах;
  • И последнее, время жизни данных зоны DNS в кэше сервера (TTL), запросившего их, в секундах.

Приведу пример записи SOA, для Microsoft DNS

Как редактировать DNS записи в панели ISPManager

В панели ISPManager DNS записи редактируются на вкладке: Доменные имена→ «Клик» по домену.

Как редактировать DNS записи в панели DirectAdmin

В панели DirectAdmin DNS записи редактируются на вкладке: Управление DNS.

На странице DNS-зоны представлен перечень зон, которые вы можете редактировать (изменения, внесенные вами, обновятся на нашем сервере в течение 30-40 минут, однако то, как скоро это будет заметно пользователям — напрямую зависит от настроек сервера интернет-провайдера, через которого производится подключение к сети). При нажатии на имя зоны (пусть в нашем примере это будет domain.tld ) открывается страница DNS-редактора. Рассмотрим по отдельности каждое из представленных на этой странице полей.

    Поле «имя» предполагает несколько вариантов заполнения:

    • @ — символ «@» означает, что действие записи будет распространяться на ту зону, на странице редактирования которой вы находитесь. В нашем случае — это domain.tld.
    • abc — набор букв и цифр («abc» было выбрано в качестве примера — вы можете указать свое имя) означает, что действие записи будет распространяться на зону более низкого уровня, чем та, на странице редактирования которой вы находитесь. В нашем примере — действие записи будет распространяться на зону abc.domain.tld.
    • * — символ «*» означает, что действие записи будет распространяться на все варианты зон ниже той, на странице редактирования которой вы находитесь. В нашем случае — это 123.domain.tld, abc.domain.tld, qwe.rty.domain.tld и т.д.

  • В поле «тип» вам предлагается несколько вариантов. Рассмотрим по-отдельности каждый из них:

    • A — используется для указания соответствия имени хоста IP-адресу.
    • MX — используется для указания почтового сервера для домена.
    • CNAME — используется для перенаправления имени хоста на другое имя.
    • SRV — используется для указания сервера, предоставляющего услуги определенной службы. В грубом приближении это аналог MX-записи, которая указывает, куда должна доставляться электронная почта, которая адресована определенному домену. Штатно поддерживается такими протоколами как XMPP(Jabber), SIP, LDAP. За счет использования этого вида записи можно разместить Jabber-сервер на отдельной машине, а не на той же, куда указывает A-запись DNS.
    • TXT — используется для указания дополнительной текстовой информации, которую хочет сообщить владелец домена.
  • Поле «MX preference» доступно для заполнения только в случае создания/редактирования записей типа MX. Указанное в этом поле числовое значение определяет приоритет использования почтового сервера. Поскольку для одного домена может быть указано несколько почтовых серверов — то, в какой последовательности на эти серверы будут осуществляться попытки доставить письмо, определяется именно приоритетом соответствующей MX-записи. Чем меньше число в поле «MX preference» — тем выше приоритет самого сервера.

  • Поле «значение (IP/host.)» заполняется в зависимости от выбранной записи:

    • Для A-записи указывается IP-адрес.
    • Для MX-записи указывается имя почтового сервера. В случае, если вы прописываете имя полностью, в конце нужно обязательно поставить точку!
    • Для CNAME-записи указывается имя хоста, на которое устанавливаем перенаправление. В конце имени должна быть обязательно точка!
    • Для SRV-записи указывается строка вида «приоритет вес порт значение», где приоритет, вес и порт должны состоять только из цифр, а значение — полное имя хоста с точкой на конце.
    • Для TXT-записи указывается произвольная текстовая строка. Ограничение — запись может состоять только из букв латинского алфавита, цифр, пробелов и следующих символов: . , ; : - = " / ~ ?

Характерные DNS-записи

Рассмотрим несколько наиболее популярных ситуаций:

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

  • Если это нужно сделать

    • @ IN A <серверы.masterhost>
    • имя: @
    • тип: A
  • Если это нужно сделать для поддомена домена, указанного в разделе «DNS-зоны»
    • abc.domain.tld в зоне домена domain.tld.
    • тип: A
    • значение (IP/host.): IP-адрес сервера

MX-запись: необходимо, чтобы почта домена обслуживалась другим сервером

    Если вам неизвестно имя сервера, но вы знаете его IP-адрес — необходимо сначала в зоне домена создать новую запись со следующими параметрами:

    • имя: mail-server
    • тип: A
    • значение (IP/host.): IP-адрес почтового сервера

  • Если вы хотите изменить почтовый сервер для домена, указанного в разделе «DNS-зоны», кликните на него мышкой и, в случае если на новой странице существует запись:

    • @ IN MX 10 <серверы.masterhost>

      отключите ее. После того как запись будет отключена, нажмите на ссылку «добавить новую запись» и создайте запись вида:

    • имя: @
    • тип: MX
  • Если вы хотите изменить почтовый сервер для поддомена домена, указанного в разделе «DNS-зоны» , кликните на имя домена мышкой, и добавьте новую запись со следующими параметрами:
    • имя: abc («abc» указано в качестве примера. Работает, если вы хотите создать запись для домена abc.domain.tld в зоне домена domain.tld. В вашем случае будет какое-то другое имя)
    • тип: MX
    • MX preference: числовое значение, допустим, 10.
    • значение (IP/host.): mail-server

SRV-запись

Для внесения SRV-записи необходимо получить от владельца службы следующие данные:

  • Служба (service)
  • Протокол (proto)
  • Приоритет (priority)
  • Вес (weight)
  • Порт (port)
  • Сервер (target)

* TTL не изменяется, поэтому его указывать не нужно;

Имя записи формируется из имени службы и протокола: _служба._протокол

Значение записи имеет следующий формат: приоритет вес порт сервер. (в конце имени обязательно должна быть точка!)

Список NS-серверов поддомена

Если основной домен делегирован на сервера masterhost, то смена NS-серверов поддомена третьего уровня производится через редактор .

Если поддержка основного домена оказывается на сторонних серверах, то изменение списка NS-серверов для его поддоменов производится в панели управления этими серверами.

PTR-запись: вы выделили мне IP-адрес , и я хочу установить соответствие между этим IP-адресом и именем определенного хоста

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

SPF-запись

Достаточно распространенным приемом, используемым организаторами СПАМ-рассылок , является подделка обратного адреса письма. В этом случае на Ваши почтовые ящики иногда могут приходить служебные сообщения об ошибках (bounce message), если одно или несколько таких СПАМ-писем с обратным адресом Вашего почтового ящика были заблокированы серверами получателей.

Есть несколько технологий, которые помогут защитить Ваш почтовый домен от использования злоумышленниками: SPF , DKIM , DMARC

В данный момент на наших почтовых серверах поддерживаются технологии SPF и DKIM. Если отправка почты от имени адресов Вашего домена осуществляется только с наших почтовых серверов, мы рекомендуем добавить в DNS зону этого домена следующую TXT-запись с нашим SPF правилом, которое не позволит использовать Ваш домен на сторонних почтовых серверах.

  • имя: @
  • тип: TXT
  • значение: v=spf1 include:_spf.сайт -all

Это правило заставит серверы получателей блокировать все СПАМ-письма , которые используют в качестве адресов отправителя Ваше доменное имя. .

Уважаемые пользователи, убедительно просим Вас быть особо внимательными при редактировании DNS-зон, некорректная конфигурация DNS-зоны может привести к неработоспособности Ваших ресурсов на достаточно длительный срок!

DKIM

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

С помощью этой записи вы можете указать удостоверяющие центры, имеющие право выпускать SSL/TLS-сертификаты для данного домена. Запись CAA позволяет избежать несанкционированной выдачи сертификатов по ошибке или с целью мошенничества.

Это только пример, точную информацию по содержанию поля "Значение" следует уточнять у Вашего удостоверяющего центра.

Изменение NS-серверов домена

Для изменения списка DNS-серверов следует:

  • Зайти в ;
  • Указать логин cXXXXX и пароль;
  • Открыть раздел «Общие услуги» и нажать «изменить» напротив нужного домена;
  • Нажать на ссылку «Изменить настройки делегирования»;
  • Чтобы указать сторонние серверы, выберите «Делегировать на сторонние серверы»;
  • Впишите адреса DNS серверов по одному на строке;
  • Для отмены предварительного тестирования DNS-серверов , отметьте свойство «Без тестирования»;
  • Нажмите кнопку «Сохранить».

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

Важно:

  1. Изменение списка DNS-серверов возможно только после завершения мобильной авторизации.
  2. С момента делегирования домена (изменения его списка NS-серверов) потребуется от 6 до 72 часов прежде чем он будет доступен в сети Интернет.

Вы можете управлять DNS-записями . В подразделе Полезная информация можно увидеть список наших DNS-серверов . Значение А-записи по умолчанию можно посмотреть у технического домена.

Редактирование DNS-серверов

Если Ваш домен находится на нашем обслуживании, то в данном разделе Вы сможете изменить для него DNS-сервера . Для этого Вам необходимо выбрать нужный домен из выпадающего списка и напротив него нажать кнопку "Редактирование DNS-серверов ".

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

Добавить подзону xxx.yourdomain.ru

Вы можете добавить подзону для Вашего домена прямо из раздела DNS без создания поддомена. Созданная подзона появится в общем списке.

При создании подзоны возможно выбрать настройки MX-записей для работы почты через такие сервисы, как Яндекс , Google или Mail.ru , а также указать код верификации (в виде TXT-записи), подтверждающий право владения доменом для поисковых систем.

Полный текст зоны

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

Редактирование зоны

В подразделе Быстрое добавление Вы можете буквально в "пару кликов" добавить нужную запись в нужную подзону. Для этого выберите в выпадающем списке нужную подзону, тип записи (A , AAAA , MX , SRV , TXT ) и введите саму запись, после чего нажмите "Добавить "

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

Для редактирования нужной зоны (подзоны) необходимо нажать на кнопку . Здесь можно как посмотреть, изменить и удалить текущие DNS-записи, так и добавить новые.
Для удаления записи необходимо напротив неё нажать кнопку


При нажатии на кнопку можно восстановить все DNS-записи по умолчанию:

  • В качестве А-записи будет установлен IP-адрес сервера, на котором находится Ваш аккаунт
  • MX-записи изменятся на mx1.сайт и mx2.сайт

Напротив каждой подзоны есть кнопка , позволяющая удалить подзону. При этом сам поддомен удалён не будет.

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

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