Сколько a записей может быть у домена
Перейти к содержимому

Сколько a записей может быть у домена

  • автор:

Сколько доменных имён и субдоменов может быть в одной учётной записи? Почему это значение вообще ограничено?

Количество доменных имен соответствует вашему тарифному плану. Ограничение было введено в связи с тем что в реальности более 20 субдоменов требовалось только для проектов, связанных с web-рекламой, или иначе говоря с поисковым спамом. За поисковый спам (линк-фермы) поисковые системы могут начислять штрафные очки хостинг-серверу, вплоть до полного блокирования показов всех размещенных на нем сайтов. Именно поэтому количество доменных имен и субдоменов в типовых тарифных планах ограничено — мы защищаем наших клиентов от потери рейтинга в поисковых системвх. Если Вам требуется больше доменных имен или субдоменов, пишите на support@hvosting.ua, разберем Вашу ситуацию в индивидуальном порядке.

Украинский хостинг сайтов, аренда серверов, регистрация доменных имён

Позвонить нам
Служба поддержки
support@hvosting.ua
+38 (044) 337-57-89
+38 (068) 304-43-64
+38 (063) 849-75-78
+38 (098) 213-96-12
+38 (050) 903-99-59
Отображать цены в:

Будет ли мне предоставлена возможность установить подкаталог, защищённый паролем?

Ваш сайт растёт и ему требуется больше места под почту, базы данных и файлы?

  • Оплатой квитанции в кассе банка
  • Liqpay
  • Privat24
  • Visa/mastercard
  • Общие вопросы
  • Вопросы связанные с оплатой
  • Настройка скриптов
  • Вопросы связанные с почтой
  • Вопросы по панели управления
  • Вопросы связанные с базами данных
  • Доменные вопросы
  • Работа с FTP
  • Резервное копирование

Хостинг новости

Акція kharkiv.ua !
Харків говорить українською ! Переходь на український домен — ваше_ім’я.kharkiv.ua — і отримай домен за половину вартості ! Замовляй домен тут: https://hvosting.ua/domains.html Вартість домена kharkiv.ua — всього 185 грн . Увага! Ця доменна зона — синонімічна, тобто зареєструвати домен .kharkiv.ua з аналогічним словом може тільки поточний власник домена .kharkov.ua Наприклад: hvosting.kharkov.ua ===> hvosting.kharkiv.ua

Видалення доменів
Повідомляємо, що з 01.11.2023 починається процес остаточного видалення доменних імен, які зберігалися в реєстрі з початку повномасштабного вторгнення (24.02.2022) до 1.05.2023 Після видалення ці доменні імена будуть доступні для реєстрації будь-кому за принципом: перший прийшов — перший отримав. До 31.10.2023 включно реєстранти мають можливість відновити свої доменні імена з redemption period`у! Не втрачайте свої домени !

Акція KYIV.UA
Переходь на український домен — ваше_ім’я.kyiv.ua — і отримай домен за половину вартості ! Тому що: Kyiv — НЕ Kiev ! Замовляй домен тут: https://hvosting.ua/domains.html Вартість домена kyiv.ua — всього 180 грн . Увага! ця доменна зона — синонімічна, тобто зареєструвати домен .kyiv.ua з аналогічним словом може тільки поточний власник домена kiev.ua Наприклад: hvosting.kiev.ua ===> hvosting.kyiv.ua

Зміна умов відновлення доменів із стану RedeptionPeriod з 01.05.2023
Повернення умов реєстрації доменів. З 1.05.2023 RedeptionPeriod становитиме 30 днів в реєстрах Хостмайстер.

Оплата через термінали Ibox
Друзі, ми додали ще один спосіб оплати хостингу та доменів: термінали Ibox. Як оплатити БЕЗ комісії .

З Днем Незалежності, моя Україно!
Добра Бажаю, друзі вам сповна, Тепла і затишку у дім І перемоги нам усім! Нехай в житті вам пощастить, Дарує радість навіть мить, Весніє на душі розмай І мирним буде небокрай!

Збереження даних на VPS
Після численних звернень клієнтів ми запровадили нову послугу: за символічну оплату ми збережемо дані вимкненого VPS на обраний вами строк від 3 до 12 місяців: дані не будуь видалені після закінчення періода оплати та відключення сервера . У подальшому клієнт зможе без проблем відновити нормальну роботу свого сервера. Для отримання цієї послуги прохання звертатися: office@hvosting.ua

Общие сведения о зонах и записях DNS

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

Имена доменов

Система доменных имен — это иерархия доменов. Иерархия начинается с root домена, имя которого просто «.«. Ниже приведены домены верхнего уровня, например com , net или jp org uk . Под доменами верхнего уровня являются домены второго уровня, например org.uk или co.jp . Эти домены в иерархии DNS глобально распределены на DNS-серверах по всему миру.

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

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

Azure DNS в настоящее время не поддерживает приобретение доменных имен. Уплатив ежегодный сбор, можно приобрести имя домена, используя домены Службы приложений Azure или регистратор сторонних доменных имен. Затем можно разместить домены в Azure DNS, чтобы управлять записями. Дополнительные сведения см. в статье Делегирование домена в Azure DNS.

Зоны DNS

Зона DNS используется для размещения записей DNS для определенного домена. Чтобы разместить свой домен в Azure DNS, необходимо создать зону DNS для этого доменного имени. Каждая запись DNS для вашего домена создается внутри этой зоны DNS.

Например, домен contoso.com может содержать несколько записей DNS, включая mail.contoso.com (для почтового сервера) и www.contoso.com (для веб-сайта).

При создании зоны DNS в Azure DNS учитывайте следующее.

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

Для создания зоны DNS с доменным именем в Azure DNS необязательно быть его владельцем. Однако, чтобы настроить серверы доменных имен Azure DNS в качестве правильных серверов для доменного имени с помощью регистратора доменных имен, необходимо быть владельцем домена.

Дополнительные сведения см. в статье Делегирование домена в Azure DNS.

Записи DNS

Имена записей

В Azure DNS записи указываются с помощью относительных имен. Полное доменное имя включает в себя имя зоны, а относительное имя — нет. Например, относительное имя записи www в зоне contoso.com дает запись с полным именем www.contoso.com .

Запись вершины — это запись DNS в корне (или вершины) зоны DNS. Например, в зоне DNS contoso.com записи вершины также присвоено полное доменное имя contoso.com (такое имя иногда называется доменом без префикса). Обычно относительное имя \’\@\’ представляет записи вершин.

Типы записей

У каждой записи DNS есть имя и тип. Записи разделяются на разные типы в зависимости от данных, которые они содержат. Наиболее распространенный тип — запись A, которая сопоставляет имя с IPv4-адресом. Другой распространенный тип — запись MX, которая сопоставляет имя с почтовым сервером.

Azure DNS поддерживает все общие типы записей DNS: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV и TXT. Обратите внимание, что записи SPF, представлены в виде записей TXT.

Наборы записей

В некоторых случаях необходимо создать несколько записей DNS с заданным именем и типом. Например, предположим, что веб-сайт www.contoso.com размещается по двум разным IP-адресам. Для этого веб-сайта требуются две разные записи A — по одной для каждого IP-адреса: Вот пример набора записей:

www.contoso.com. 3600 IN A 134.170.185.46 www.contoso.com. 3600 IN A 134.170.188.221 

Azure DNS управляет всеми записями DNS, используя наборы записей. Набор записей (также называется набором записей ресурсов) — это коллекция записей DNS в зоне, которые имеют одно имя и принадлежат к одному типу. Большинство наборов записей содержат одну запись. Однако встречаются и наборы с несколькими записями (как в примере выше).

Например, предположим, что вы уже создали в зоне contoso.com запись А www, указывающую на IP-адрес 134.170.185.46 (первая запись выше). Чтобы создать вторую запись, не нужно создавать дополнительный набор записей — следует добавить запись в уже имеющийся набор записей.

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

Срок жизни

Время жизни или TTL указывает, сколько времени каждая запись кэшируется клиентами перед запросом. В приведенном выше примере TTL равен 3600 секундам или 1 часу.

В Azure DNS TTL указывается для набора записей, а не для каждой записи, поэтому одно значение используется для всех записей в рамках набора записей. Вы можете указать любое значение TTL — от 1 до 2 147 483 647 секунд.

Записи с подстановочными знаками

Azure DNS поддерживает записи с подстановочными знаками. Эти записи возвращаются в ответ на любой запрос с совпадающим именем, если нет более близкого совпадения из набора записей без подстановочных знаков. Azure DNS поддерживает наборы записей с подстановочными знаками для всех типов записей, за исключением NS и SOA.

Чтобы создать набор записей с подстановочными знаками, используйте знак * вместо имени набора записей. Можно использовать имя со знаком * как крайнюю метку слева, например *.foo.

Записи авторизации ЦС

Запись авторизации ЦС позволяет владельцам доменов указывать, какие центры сертификации уполномочены выдавать сертификаты для их домена. В определенных обстоятельствах эта запись позволяет центрам сертификации избежать ошибочной выдачи сертификатов. Записи авторизации ЦС имеют три свойства:

  • Флаги: это целое число от 0 до 255, используемое для представления критического флага с особым значением для каждого RFC6844
  • Тег: строка ASCII, которая может быть одной из следующих:
    • issue — если необходимо указать ЦС, которые могут выпускать сертификаты (всех типов);
    • issuewild — если необходимо указать ЦС, которые могут выпускать сертификаты (только шаблоны);
    • iodef — адрес электронной почты или имя узла, по которым ЦС может отправлять уведомления о запросах на несанкционированную выдачу сертификатов.

    Записи CNAME

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

    Так как вершина зоны (имя = @) будет всегда содержать наборы записей при создании зоны, невозможно создать набор записей CNAME на вершине зоны.

    Это связано со стандартами DNS, а не ограничениями Azure DNS.

    Записи NS

    Набор записей NS в вершине зоны (имя @) создается автоматически с каждой зоной DNS и автоматически удаляется при удалении зоны. Его невозможно удалить отдельно.

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

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

    Записи SOA

    Набор записей SOA автоматически создается на вершине каждой зоны (имя = @) и автоматически удаляется при удалении зоны. Записи SOA нельзя создавать или удалять отдельно.

    Вы можете изменить все свойства записи SOA, кроме host свойства. Это свойство получает предварительно настроенное для ссылки на имя основного сервера имен, предоставленное Azure DNS.

    Серийный номер зоны в записи SOA не обновляется автоматически при внесении изменений в записи зоны. Его можно обновить вручную, изменив запись SOA, если потребуется.

    Azure DNS в настоящее время не поддерживает использование точки (.) перед записью «@» в записи почтового ящика hostmaster SOA. Например: john.smith@contoso.xyz (преобразовано в john.smith.contoso.xyz) и john\.smith@contoso.xyz не допускается.

    Записи SPF

    Записи инфраструктуры политики отправителей (SPF) используются для указания почтовых серверов, которые могут отправлять электронную почту от имени доменного имени. Правильная конфигурация записей SPF очень важна, чтобы получатели не помечали ваши сообщения электронной почты как «Нежелательная почта».

    В RFC DNS новый тип записи SPF был изначально представлен для поддержки этого сценария. Для поддержки старых серверов доменных имен в них также может использоваться тип записи TXT, чтобы указывать записи SPF. Эта неоднозначность привела к путанице, которую удалось устранить с помощью документа RFC 7208. В нем сказано, что записи SPF должны создаваться с помощью записей типа TXT. Также там сказано, что записи типа SPF являются устаревшими.

    Записи SPF поддерживаются в Azure DNS, и их необходимо создавать с помощью записи типа TXT. Устаревший тип записи SPF не поддерживается. Во время импорта файла зоны DNS все записи SPF, которые используют тип SPF, преобразуются в записи типа TXT.

    Записи SRV

    Различные службы используют записи SRV, чтобы указать расположения сервера. Указание записи SRV в Azure DNS

    • Служба и протокол должны быть указаны как часть имени набора записей, префиксированного символами подчеркивания, например «_sip._tcp.name». Для записи в вершине зоны нет необходимости указывать «@» в имени записи, просто используйте службу и протокол, например «_sip._tcp».
    • Приоритет, вес, порт и целевое значение указываются в качестве параметров каждой записи в наборе записей.

    Записи типа TXT

    Записи типа TXT используются для сопоставления доменных имен с произвольными текстовыми строками. Они используются в разных приложениях, в частности в тех, которые относятся к конфигурации электронной почты, например инфраструктура политики отправителей (SPF) и DomainKeys Identified Mail (DKIM).

    Стандарты DNS позволяют одной записи TXT содержать несколько строк, каждая из которых может содержать до 255 символов. Где используются несколько строк, они объединяются клиентами и обрабатываются как одна строка.

    При вызове REST API Azure DNS необходимо указать каждую строку TXT отдельно. При использовании интерфейсов портал Azure, PowerShell или CLI следует указать одну строку для каждой записи. Эта строка автоматически делится на 255-символьные сегменты при необходимости.

    Не следует путать несколько строк в записи DNS с несколькими записями типа TXT в наборе записей типа TXT. Набор записей типа TXT может содержать несколько записей, каждая из которых может содержать несколько строк. Azure DNS поддерживает общую длину строки до 4096 символов в каждом наборе записей TXT (во всех объединенных записях * ).

    * Поддержка символов 4096 в настоящее время доступна только в общедоступном облаке Azure. Национальные облака ограничены 1024 символами до завершения развертывания поддержки 4k.

    Теги и метаданные

    Теги

    Теги — это список пар «имя — значение», которые используются Azure Resource Manager для пометки ресурсов. Azure Resource Manager использует теги, чтобы обеспечить отфильтрованные представления счетов Azure, а также позволяет задать политику для определенных тегов. Дополнительные сведения о тегах см. в статье Использование тегов для организации ресурсов в Azure.

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

    Метаданные

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

    Теги ETag

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

    Служба Azure DNS использует теги Etag для безопасной обработки параллельных изменений одного ресурса. Теги ETag не связаны с тегами Azure Resource Manager. С каждым ресурсом DNS (зоной или набором записей) связан Etag. При извлечении ресурса также передается его значение Etag. При обновлении ресурса вы можете вернуть Etag, чтобы служба Azure DNS могла сопоставить его с Etag на сервере. Так как каждое обновление ресурса приводит к повторному созданию Etag, несовпадение Etag указывает на параллельное изменение. Теги Etag можно также использовать при создании ресурса для проверки того, что ресурс не существует.

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

    На уровне API REST службы Azure DNS теги Etag указываются с помощью заголовков HTTP. Их поведение описывается в следующей таблице:

    Верхний колонтитул Поведение
    нет PUT всегда завершается успешно (без проверки Etag)
    If-match

    PUT завершается успешно, только если ресурс существует и Etag соответствует
    If-match * PUT завершается успешно, только если ресурс существует
    If-none-match* PUT завершается успешно, только если ресурс не существует

    Ограничения

    При использовании Azure DNS применяются приведенные ниже ограничения по умолчанию.

    Общедоступные зоны DNS

    Ресурс Ограничение
    Общедоступные зоны DNS для каждой подписки 250 1
    Количество наборов записей на общедоступную зону DNS 10 000 1
    Количество записей в наборе записей в общедоступной зоне DNS 20
    Number of Alias records for a single Azure resource 20

    1 Если вам нужно увеличить эти ограничения, обратитесь в Службу поддержки Azure.

    Следующие шаги

    • Чтобы начать работу с Azure DNS, узнайте, как создать зону DNS и записи DNS.
    • Чтобы перенести имеющуюся зону DNS, узнайте, как импортировать и экспортировать файл зоны DNS.

    Несколько IP в DNS (A-запись)?

    Слышал что можно распределять нагрузку выдавая тот или иной IP. Но меня интересует что будет если DNS выдает сразу два или более IP. Как ведут себя браузеры(или ОС)/поисковики, как должны, предусмотрено ли это в каких-либо спецификациях? Может ли это создать проблемы для сайта (те же поисковики)?

    • Вопрос задан более трёх лет назад
    • 77551 просмотр

    Комментировать
    Решения вопроса 0
    Ответы на вопрос 6

    Это называется DNS Round-Robin
    По умолчанию ip-адреса будут выдаваться в карусельном порядке, можно настроить случайный порядок или строгий порядок.

    Ответ написан более трёх лет назад
    Нравится 10 3 комментария
    Как ни странно, просто и понятно рассказано тут.

    Один фиксированный клиент (браузер/ос) в течении сеанса (или времени действия кэша днс?) будет обращаться по одному и тому же адресу или… как?

    Это уровень ДНС-запросов. Если браузеру придется делать несколько ДНС-запросов за ваш сферический сеанс и это время будет короче, чем TTL у А-записи, то браузер будет коннектиться к разным ip.

    При резолве DNS в сишных функциях выдается не 1 айпи а массив из айпи, который зачастую содержит 1 элемент.

    Спецификация DNS допускает определение множества айпи на 1 доменное имя. Да, это называется DNS рулетка.

    Рекомендаций в RFC как должен вести себя клиент, получивший несколько IP я не видел, по этому софт ведет себя весьма произвольно.

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

    Следовательно, как будет себя вести софт — зависит от того, в каком порядке DNS сервер выдает айпишники.

    Насколько я знаю, Bind отдает в том порядке, в котором они записаны в конфиге.

    tinydns делает нормальный round-robin.

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

    Типы ДНС записей.

    Учетная запись «A» отображает имя компьютера в виде числового адреса IP. Другими словами, эта запись указывает имени хоста (домена) с какого адреса IP (IP сервера, будь это Ваш VPS либо наш общий хостинг) необходимо отображать сайт. Ниже представлен пример того, как должна выглядеть запись «A»:

    hostpro.ua. IN A 91.239.232.84.

    Первый столбец содержит имя домена, который нужно направить на сервер, где расположен сайт. Список второго столбца («IN»), это класс записи. Для основной работы DNS Вам нужно только наличие IN обозначения, установленное для интернета. Следующий столбец обозначает тип записи («А»), и последний столбец это IP адрес сервера, где физически расположен сайт.

    Так же с помощью «А» записи можно создать поддомен, который нужно направить на другой сервер. Для этого нужно создавать «А» запись вида:

    support IN A 91.239.232.84

    Справа вписываем IP сервера, с которого будет отображаться сайт на созданном Вами поддомене (при этом основной сайт не пострадает и будет работать с прежнего сервера).

    При направлении поддомена на другой сервер, важно создавать «А» запись следующего вида:

    www.support IN A 91.239.232.84 , что-бы при вводе в адресной строке браузера поддомена с «www» (www.support.hostpro.ua) пользователь попадал на support.hostpro.ua, а не на страницу с ошибкой.

    • Учетная запись канонического имени «CNAME»

    Учетная запись «CNAME» позволяет компьютеру иметь более чем одно имя хоста (проще говоря, при помощи этой записи можно припарковать один домен к другому). Чтобы иметь возможность припарковать к основному домену еще один домен, или для создания поддоменов, должна быть создана основная запись «A» для главного домена (т.е. домен должен быть направлен на какой-то сервер).

    Имя домена, прописанное в записи «A» называется каноническим или основным именем сайта. Другие записи должны указывать на каноническое имя.

    Пример парковки домена при помощи записи CNAME:

    hostpro.ru. IN CNAME hostpro.ua.

    Вы можете увидеть сходство с предыдущей записью. Записи всегда читаются слева направо, слева располагается запрос, а справа ответ на запрос (т.е. при запросе в браузере сайта hostpro.ru будет открыт сайт hostpro.ua). Домен может иметь неограниченное число CNAME записей.

    Так же, при помощи этой записи, через редактор ДНС зоны, можно создавать поддомены. Создать поддомен можно прописав его имя в левой части записи.

    Прописывать необходимо только имя поддомена (в примере ниже это «support»), без имени основного домена, которое прописывается в правой части записи (в примере это «hostpro.ua.»):

    support IN CNAME hostpro.ua.

    Теперь у нас создан поддомен, и при вводе в адресной строке браузера сайта support.hostpro.ua будет отображаться директория support, если таковая была создана в корневой папке сайта hostpro.ua.

    • Учетная запись почтового сервера «MX»

    Учетная запись «MX» — значительно более важная, чем может показаться. Она позволяет всю почту для домена, направлять одному хосту. Это чрезвычайно полезно для уменьшения нагрузки на внутренние хосты, на которые не должна направляться поступающая почта, а также для того, чтобы собирать всю почту, отправленную на любой адрес Вашего домена даже если этот конкретный адрес не имеет никакой связи с компьютером. Например, у Вас есть почтовый сервер, работающий на вымышленном компьютере mail.hostpro.ua. а Вы хотите, чтобы Ваш почтовый адрес был «[email protected]» а не «[email protected]». Это делается с помощью записи, показанной ниже:

    hostpro.ua. IN MX 10 mail.hostpro.ua. (при этом mail.hostpro.ua должен быть направлен на IP почтового сервера при помощи «А» записи).

    Самый левый столбец обозначает адрес, который Вы хотите использовать как почтовый адрес. Следующие два столбца были объяснены подробно в предыдущих записях. Следующий столбец, число «10», отличается от нормального формата записи DNS. Это число приоритета. Часто в больших системах имеются серверы резервной почты, возможно, более чем один. Они предназначены для получения почты, если не работает первичный сервер почты. Вы можете сделать это с помощью записей MX. Более низкое число в записи MX означает более высокий приоритет, и почта будет отправлена на сервер с самым низким числом (самый низкий из возможных — 0). Если что-то случается с этим сервером, то компьютер, доставляющий почту, будет пытаться ее направить на следующий сервер, указанный в таблицах DNS, в порядке приоритета.

    Вы можете иметь столько записей MX, сколько хотите. Использование записи MX полезно, даже если почта отправляется непосредственно на компьютер с записью «A». Некоторые sendmail программы ищут только записи MX.

    Если Вас интересуют другие записи и возможности из создания — пишите нам на [email protected] и мы предоставим Вам всю нужную информацию.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *