Tw-city.info

IT Новости
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Репликация доменов 2020

Репликация доменов 2020

1. репликация с ошибкой и на одном и на другом. Ссылается на проблему поиска DNS

DCDIAG 1 КД (ADREPLICA)

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = ADREPLICA
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Сервер проверки: Default-First-Site-NameADREPLICA
Запуск проверки: Connectivity
Узел 60aee3c5-f6b8-4474-96b2-3f3e3a286d2f._msdcs.co1858.com не удается
разрешить в IP-адрес. Проверьте DNS-сервер, DHCP, имя сервера и т. д.
Получена ошибка при проверке подключения LDAP и RPC. Проверьте
параметры брандмауэра.
. ADREPLICA — не пройдена проверка
Connectivity

Выполнение основных проверок

Сервер проверки: Default-First-Site-NameADREPLICA
Пропуск всех проверок, поскольку сервер ADREPLICA не отвечает на запросы
службы каталога.

Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
. ForestDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. ForestDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: DomainDnsZones
Запуск проверки: CheckSDRefDom
. DomainDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. DomainDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
. Schema — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. Schema — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
. Configuration — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. Configuration — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: co1858
Запуск проверки: CheckSDRefDom
. co1858 — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. co1858 — пройдена проверка
CrossRefValidation

Выполнение проверок предприятия на: co1858.com
Запуск проверки: LocatorCheck
. co1858.com — пройдена проверка LocatorCheck
Запуск проверки: Intersite
. co1858.com — пройдена проверка Intersite

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = ADNACH
* Определен лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Сервер проверки: Default-First-Site-NameADNACH
Запуск проверки: Connectivity
. ADNACH — пройдена проверка Connectivity

Выполнение основных проверок

Сервер проверки: Default-First-Site-NameADNACH
Запуск проверки: Advertising
. ADNACH — пройдена проверка Advertising
Запуск проверки: FrsEvent
. ADNACH — пройдена проверка FrsEvent
Запуск проверки: DFSREvent
. ADNACH — пройдена проверка DFSREvent
Запуск проверки: SysVolCheck
. ADNACH — пройдена проверка SysVolCheck
Запуск проверки: KccEvent
. ADNACH — пройдена проверка KccEvent
Запуск проверки: KnowsOfRoleHolders
. ADNACH — пройдена проверка
KnowsOfRoleHolders
Запуск проверки: MachineAccount
. ADNACH — пройдена проверка MachineAccount
Запуск проверки: NCSecDesc
. ADNACH — пройдена проверка NCSecDesc
Запуск проверки: NetLogons
. ADNACH — пройдена проверка NetLogons
Запуск проверки: ObjectsReplicated
. ADNACH — пройдена проверка ObjectsReplicated
Запуск проверки: Replications
. ADNACH — пройдена проверка Replications
Запуск проверки: RidManager
. ADNACH — пройдена проверка RidManager
Запуск проверки: Services
. ADNACH — пройдена проверка Services
Запуск проверки: SystemLog
. ADNACH — пройдена проверка SystemLog
Запуск проверки: VerifyReferences
. ADNACH — пройдена проверка VerifyReferences

Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
. ForestDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. ForestDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: DomainDnsZones
Запуск проверки: CheckSDRefDom
. DomainDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. DomainDnsZones — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
. Schema — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. Schema — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
. Configuration — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
. Configuration — пройдена проверка
CrossRefValidation

Выполнение проверок разделов на: co1858
Запуск проверки: CheckSDRefDom
. co1858 — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
. co1858 — пройдена проверка
CrossRefValidation

Выполнение проверок предприятия на: co1858.com
Запуск проверки: LocatorCheck
. co1858.com — пройдена проверка LocatorCheck
Запуск проверки: Intersite
. co1858.com — пройдена проверка Intersite

Управление репликацией Active Directory

Обеспечение корректной репликации в лесу Active Directory – это одна из главных задач администратора AD. В этой статье попытаемся понять базовые принципы репликации базы Active Directory и методики диагностики неисправности. Стоит отметить, что репликации — один из основополагающих принципов построения современной корпоративной сети на базе AD, так, например, мы уже говорили о репликации групповых политик в домене AD и репликации зон DNS.

Для мониторинга репликации Active Directory в корпоративной среде Microsoft рекомендует использовать продукт SCOM (либо другие продукты мониторинга с похожим функционалом). Кроме того, для мониторинга репликации AD можно использовать утилиту repadmin (repadmin /showrepl * /csv) совместно с самописными скриптами анализа вывода этой утилиты. Типичные проблемы, связанные с ошибками репликации Active Directory, — ситуации, когда объекты не появляются в одном или нескольких сайтах (например, только что созданный пользователь, группа или другой объект AD не доступны на контроллерах домена в других сайтах).

Хорошая отправная точка для поиска неисправности в механизме репликации Active Directory – анализ журнала «Directory Services» на контроллерах домена. Конкретные действия будут зависеть от того, какие ошибки будут обнаружены в журнале, однако для разрешения проблем нужно достаточно четко понимать процессы репликации Active Directory.

Одним из базовых элементов управлением трафиком репликации между контроллерами домена являются сайты Active Directory. Сайты связаны между собой особыми связями, называемыми «site link», которые определяют стоимость маршрутизации данных AD (элементы леса, домена, папка SYSVOL и т.д.) между различными сайтами. Расчет алгоритма управления и маршрутизации трафика репликации в лесу ведется службой KCC.

KCC определяет партнеров по репликации для всех контроллеров домена в лесу. Для межсайтовой репликации KCC автоматически выбирает специальные сервера-плацдармы (bridgehead server), помимо этого, администратор домена может вручную указать контролеры домена, которые будут выполнять роль сервера-плацдарма для того или иного сайта, именно эти сервера и управляют межсайтовой репликацией. Сайты и сервера bridgehead нужны для того, чтобы удобно управлять трафиком репликации Active Directory, и чтобы уменьшить объем передаваемого трафика по сети.

Читать еще:  Корневой домен это

Межсайтовую топологию в лесу можно проанализировать при помощи команды:

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

В вышеприведённом логе видно, что в домене winitpro.ru существует 3 сайта, которые называется соответственно Site(0), Site(1) иSite(2). Каждый из сайтов имеет 3 набора репликационной информации, по одной для каждого сайта в лесу. Например, настроена связь между Sites(2) (LAB-Site3) и Site(0) (LAB-Site1), параметры этой связи — 10:30:0, что означает: 10 – стоимость репликации, и интервал репликации 30 минут. Также обратите внимание, что для сайта Site(2) задан сервер-плацдарм (bridgehead) – это контроллер домена с именем testlabdc2.

Контроллеры домена, партнеры по репликации – могут быть идентифицированы при помощи графического Gui или при помощи утилит командной строки. Откройте консоль MMC «Active Directory Sites and Services», разверните узел Sites, в нем найдите интересующий ваш сайт. В этом узле будут содержатся контроллеры домена, относящиеся к этому сайту. Развернув контроллер домена и выбрав пункт NTDS Settings, вы увидите всех партнеров по репликации данного контроллера домена.

В командной строке при помощи команды nslookup можно получить список контроллеров домена, относящихся к нашему сайту (естественно для этого необходимо, чтобы все DC имели корректные записи SRV). Формат команды такой:

на выходе получаем примерно следующее:

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

Стоит отметить, что служба DNS – это важный компонент службы репликации Active Directory. Контроллеры домена регистрируют свои SRV записи в DNS. Каждый контроллер домена в лесу регистрирует записи CNAME вида dsaGuid._msdcs.forestName, где dsaGuid –GUID видимый у объекта в пункте NTDS Settings в консоли «AD Sites and Services». Если в журнале Directory Services есть ошибки, связанные со службой DNS, для проверки корректных записей типа CNAME и A для контроллера домена.

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

Команда repadmin имеет специальный параметр /replsummary, который позволяет быстро проверить состояние репликации на конкретном контроллере домена (указывается его имя) или на всех контроллерах (опция wildcard).

В том случае, если ошибки репликации отсутствуют, в выводе этой команды будет видно, что ошибок – 0.:

В том случае, если ошибки все-таки будут, при помощи утилиты Repadmin можно получить более полную информацию. Каждый контроллер домена имеет собственный уникальный USN (Update Sequence Number), который инкрементируется каждый раз при успешном изменении обновлении объекта Active Directory. При инициализации репликации, партнеру передается USN, который сравнивается с USN, полученным в результате последней успешной репликации с данным партнером, тем самым определяя сколько изменений произошло в базе AD со времени последней репликации.

При помощи ключа /showutdvec, можно получить список текущих значений USN, хранящихся на указанном DC.

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

Тестирование репликации Active Directory при помощи утилиты repadmin можно осуществить несколькими способами:

  • replmon /replicate (позволяет запустить репликацию определенного раздела на указанный контроллер домена)
  • replmon /replsingleobj (репликация конкретного объекта между двумя DC)
  • replmon /syncall (синхронизация указанного контроллера домена со всем партнерами по репликации)

При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..

Репликация Hyper-V без домена

Саму установку роли гипервизора в этой статье рассматривать я не буду, так как делается это довольно просто, а вот репликация без домена не совсем тривиальная задача.
Репликация виртуальных машин в Hyper-V на базе Windows Server 2016 и Windows Server 2019 без контроллера домена доступна только с использованием сертификатов. Вот и рассмотрим, как создать самоподписанный сертификат и подключить его в Hyper-V.
В workgroup наиболее распространенным способом создания сертификатов для узлов Hyper-V было использование утилиты makecert, но эта утилита устарела и вместо нее в Windows Server 2016 появился новый командлет в powershell New-SelfSignedCertificate.
Как вы уже знаете, существует два типа проверки подлинности в Hyper-V: сертификаты Kerberos и HTTPS. Учитывая, что Kerberos доступен только в доменных средах, у нас нет другого выбора, кроме как использовать аутентификацию на основе сертификатов. Необходимые условия для этого типа аутентификации довольно просты: поле субъекта сертификата должно быть установлено в Hyper-V server name (либо первичный сервер, либо сервер-реплика), а расширенное использование ключа должно быть аутентификацией клиента и сервера.
Конечно, трафик https должен быть разрешен на брандмауэрах сервера (я отключил брандмауэры на своих серверах хоста, поэтому я не буду публиковать соответствующие скриншоты).

Читать еще:  Как сделать контроллер домена

Репликация виртуальных машин в Hyper-V на базе Windows Server 2016 и Windows Server 2019 без контроллера домена доступна только с использованием сертификатов. Вот и рассмотрим, как создать самоподписанный сертификат и подключить его в Hyper-V.
В workgroup наиболее распространенным способом создания сертификатов для узлов Hyper-V было использование утилиты makecert, но эта утилита устарела и вместо нее в Windows Server 2016 появился новый командлет в powershell New-SelfSignedCertificate.
Как вы уже знаете, существует два типа проверки подлинности в Hyper-V: сертификаты Kerberos и HTTPS. Учитывая, что Kerberos доступен только в доменных средах, у нас нет другого выбора, кроме как использовать аутентификацию на основе сертификатов. Необходимые условия для этого типа аутентификации довольно просты: поле субъекта сертификата должно быть установлено в Hyper-V server name (либо первичный сервер, либо сервер-реплика), а расширенное использование ключа должно быть аутентификацией клиента и сервера.
Конечно, трафик https должен быть разрешен на брандмауэрах сервера (я отключил брандмауэры на своих серверах хоста, поэтому я не буду публиковать соответствующие скриншоты).

Еще одно замечание: виртуальная машина для репликации не должна иметь никаких контрольных точек – для репликации должен быть доступен только один файл vhdx.

  1. Заходим на сервер с виртуальной машиной которую будем реплицировать и указываем основной DNS суффикс
    • Мой компьютерСвойстваДополнительные параметры системыИмя компьютераИзменитьДополнительно
    • После чего перезагружаем сервер
    • То же самое проделываем с сервером репликаций
  2. После изменения DNS суффиксов и перезагрузки сервером можем приступать к созданию сертификатов.
    • New-SelfSignedCertificate -DnsName “srv-hv1.Test.ru”
      -CertStoreLocation “cert:LocalMachineMy” -TestRoot
    • New-SelfSignedCertificate -DnsName “srv-hv2.Test2.ru”
      -CertStoreLocation “cert:LocalMachineMy” -TestRoot
  3. В результате будут созданы три сертификата: один для каждого сервера с ключом расширенного использования, установленным на проверку подлинности клиента и сервера, хоть это явно и не указано, и тестовый корневой сертификат CA — Certreq Test Root – который по умолчанию будет помещен в промежуточные центры сертификации.
  4. Поскольку корневой сертификат CertReq не находится в доверенных корневых центрах сертификации эти сертификаты будут ненадежными.
  5. Поэтому переместим сертификат в группу Доверенные корневые центры сертификации.
  6. Экспортируем сертификат корневой сертификат и для сервера репликаций
  7. Заходим на сервер репликаций
  8. В оснастке mmc импортируем два сертификата на сервер репликаций
  9. Включаем сервер для приема реплик виртуальных машин в свойствах Hyper-V
  10. Далее на сервере с виртуальной машиной уже создаем реплику
    • Для тех, кто не знает, нажимаем правую кнопку мыши на виртуальной машине и выбираем пункт включить репликацию
    • После чего жмем далее, выбираем сертификат и необходимые настройки и все.

Репликация Hyper-V без домена : 2 комментария

Отлично, только не сказано что надо отключить проверку отзывов. Иначе сертификат не принимает.

Только работать это все не будет, т.к. при первой же проверке выскочит ошибка проверки сертификата на сервере репликаций.
Нужно добавить в реестр соответствующий ключ:
reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Добавление дополнительного контроллера домена в существующий домен AD

Как вы знаете, службы Active Directory Domain Services (AD DS) устанавливаются на сервере, который называется контроллер домена (DC). В активный каталог домена AD можно добавить десятки дополнительных контроллеров для балансировки нагрузки, отказоустойчивости, уменьшения нагрузки на WAN каналы и т.д. Все контроллеры домена должны содержать одинаковую базу учетных записей пользователей, учетных записей компьютеров, групп и других объектов LDAP каталога.

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

В этой статье мы покажем, как добавить дополнительный контроллер домена в существующий домен Active Directory (Установка домена AD на примере Windows 2016).

Добавление дополнительного контроллера домена в существующий домен AD

Прежде всего, нам нужно установить роль Active Directory Domain Services на сервере, который будет новым DC.

Установка роли ADDS

Прежде всего, откройте консоль Server Manager. Когда откроется Server Manager, нажмите «Add roles and features», чтобы открыть консоль установки ролей сервера.

Пропустите страницу «Before you Begin». Выберите «Role-based or featured-based installation» нажмите кнопку «Next». На странице «Server Selection» снова нажмите кнопку «Next».

Выберите роль Active Directory Domain Services. В открывшемся окне нажмите кнопку «Add Features», чтобы добавить необходимые инструменты управления Active Directory Management Tools.

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

Настройка дополнительного контроллера домена

Теперь в мастере установки ролей нажмите ссылку «Promote this server to a domain controller».

Выберите «Add a domain controller to an existing domain», ниже укажите имя вашего домена AD. Если вы авторизованы под обычным пользователем, вы можете изменить учетные данные на администратора домена. Нажмите кнопку «Select», откроется новое окно, выберите имя вашего домена и нажмите «Ok», затем «Next».

Читать еще:  Блокируется учетная запись в домене определить

На странице Domain Controller Options, можно выбрать, что нужно установить роль DNS-сервера на вашем DC. Также выберите роль Global Catalog. Введите пароль администратора для режима DSRM и подтвердите его, затем нажмите кнопку «Next».

На странице Additional options укажите сервер, с которым вы хотите выполнить первоначальную репликацию базы Active Directory ( с указанного сервера будет скопирована схема и все объекты каталога AD). Вы можете сделать снимок (snapshot) текущего состояния Active Directory на одном из контроллеров домена и применить его на новой машине. После этого база AD этого сервера будет представлять собой точную копию имеющегося контроллера домена. Подробнее о функции Install From Media (IFM) – установки нового DC с носителя в одной из следующих статей (https://vmblog.ru/razvertyvanie-kontrollera-domena-s-pomoshhyu-install-from-media-ifm/):

На страницах «Paths and Review options» нам ничего не придется настраивать, пропустите их, нажав кнопку «Next». На странице «Prerequisite», если вы видите какую-либо ошибку, проверьте и выполните все указанные требования, затем нажмите кнопку «Install».

Настройка репликации между новым и имеющимся контроллером домена

Мы почти закончили, теперь проверим и запустим репликацию между первичным DC (DC01.vmblog.ru) и новым DC (DC02.vmblog.ru). При копировании информации между этими двумя контроллерами домена данные базы Active Directory будут скопированы из DC01.vmblog.ru в DC02.vmblog.ru. После завершения процесса все данные корневого контроллера домена появятся на новом контроллере домена.

В «Server Manager» выберите вкладку «Tools» затем пункт «Active directory sites and services».

В левой панели разверните вкладку Sites -> Default-First-Site-Name -> Servers. Оба новых DC находятся в одном сайте AD (это подразумевает, что они находятся в одной подсети, либо сетях, соединенных высокоскоростным каналом связи). Затем выберите имя текущего сервера, на котором вы сейчас работаете, затем нажмите «NTDS Settings». В моем случае DC01 является корневым контроллером домена, в данный момент консоль запущена на DC02, который будет дополнительным контроллером домена.

Щелкните правой кнопкой мыши по элементу с именем «automatically generated». Нажмите «Replicate now». Появится предупреждение о запуске репликации между корневым контроллером домена и новым контроллером домена.

Сделайте то же самое для DC01. Разверните вкладку DC01 и нажмите «NTDS Settings». Щелкните правой кнопкой мыши на «automatically generated», затем нажмите «Replicate now». Оба сервера реплицируются друг с другом, и все содержимое DC01 будет скопировано в DC02.

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

Обзоры и рейтинг лучших регистраторов доменных имен

В этом рейтинге 1187 реальных отзывов о 33 компаниях, а также наши эксперты (5) выполнили тестов/обзоров (23)

  • Страна: Россия
  • На рынке : c 2006 года
  • Клиентов: 1600000 (

3.46 % рынка)

  • Серверы: Россия
  • Промокод: 0E72-BC86-9AA9-47BC 5% скидки на заказ домена и/или хостинга
  • Панель управления: ISPManager, cPanel, Parallels
  • Тестовый период : 14 дней
    • Страна: США
    • На рынке : c 1999 года
    • Клиентов: 48000000 (

    • Страна: США
    • На рынке : c 2002 года
    • Клиентов: 1500000 (

    • Страна: Россия (Лицензия)
    • На рынке : c 2001 года
    • Клиентов: 750000 (

    1.62 % рынка)

  • Серверы: Россия
  • Промокод: DVCSPTFST1 Для первого заказа скидка -10% на все услуги, кроме регистрации «доменов мира», услуг «seo-продвижение», «регистрация освобождающегося домена», «статус клубной программы», «страхование ответственности администратора» и услуг продления.
  • Панель управления: Собственная, ISP Manager
  • Тестовый период : 14 дней
    • Страна: США
    • На рынке : c 2000 года
    • Клиентов: 3000000 (

    3.57 % рынка)

  • Серверы: Великобритания, Европа, США
  • Панель управления: cPanel
  • Тестовый период : 14 дней
    • Страна: США
    • На рынке : c 1999 года
    • Серверы: США
    • Панель управления: Собственная

    • Страна: Россия (Лицензия)
    • На рынке : c 2006 года
    • Клиентов: 150000 (

    0.32 % рынка)

  • Серверы: Россия
  • Панель управления: Собственная, ISP Manager
  • Тестовый период : 10 дней
    • Страна: Россия
    • На рынке : c 2005 года

    • Страна: Россия (Лицензия)
    • На рынке : c 2009 года
    • Клиентов: 165000 (

    0.36 % рынка)

  • Серверы: Россия
  • Панель управления: Собственная
  • Тестовый период : 30 дней
    • Страна: Россия
    • На рынке : c 2008 года
    • Клиентов: 53000 (

    0.11 % рынка)

  • Серверы: Россия
  • Панель управления: собственная
  • Как правило, домены регистрируют либо у хостинг провайдера, у которого размещается веб-проект, либо у специализированной компании, которая отдельно занимается регистрацией доменов (большинство крупных хостинг-компаний имеют своих собственных регистраторов, которые работают под другим брендом).

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

    К преимуществам регистраторов доменов можно отнести более широкий выбор доменных имен и различные акционные предложения (например «два домена — по цене одного!»).

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

    Наш вам совет: знаете хорошие хостинг-компании — регистрируйте домен у них. Не знаете — смотрите наши обзоры хостинг-провайдеров России, Украины или США и выбирайте наиболее подходящих для Вас.

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

    Ссылка на основную публикацию
    ВсеИнструменты 220 Вольт
    Adblock
    detector
    ×
    ×