Dns имя на основе guid не зарегистрировано на одном или нескольких dns серверах

Обновлено: 02.07.2024

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

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

Содержание:

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

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

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

Итеративный и рекурсивный запросы.

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

Клиент обращается к держателю зоны ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

Заголовок состоит из следующих полей:

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

Флаги — 16-битовое поле, поделенное на 8 частей:

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

определяются все зоны, которые должны быть загружены;
из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
начинается обработка запросов и удаленных вызовов процедур (RPC);
создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.

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

После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.

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

Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

В этой статье описываются симптомы, причины и действия по разрешению операций AD, которые не удается с ошибкой Win32 8524:

Операция DSA не может продолжиться из-за сбоя при просмотре DNS.

Применяется к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 2021446

Домашние пользователи: Эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вы ищете помощь с проблемой, спросите microsoft Community.

Симптомы

DCDIAG сообщает, что тест репликации Active Directory не справился со статусом 8524:

Сервер тестирования: <sitename><destination DC>
Начальный тест: репликации
[Репликации Проверить, <destination DC> ] Недавняя попытка репликации не удалась. <source DC><destination DC>
Контекст именования:
CN= <DN path for failing directory partition> ,DC=Contoso,DC=Com
Репликация вызвала ошибку (8524):
Операция DSA не может продолжиться из-за сбоя при просмотре DNS.

REPADMIN сообщает, что попытка репликации не удалась со статусом 8524.

Команды REPADMIN, которые обычно ссылаются на состояние 8524, включают, но не ограничиваются:

REPADMIN /REPLSUM
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL

Ниже показан пример из 8524 сбоев rePADMIN/SHOWREPL:

Default-First-Site-Name\CONTOSO-DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: вызов DSA:
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 через RPC
GUID объекта DSA:
Последняя попытка @ YYYY-MM-DD HH:MM:SS не удалась, результат 8524 (0x214c):
Операция DSA не может продолжиться из-за сбоя при просмотре DNS.
1 последовательный сбой(ы).
Последний успех @ YYYY-MM-DD HH:MM:SS.

Остальные выходные данные /showrepl усечены

Одно из следующих событий со статусом 8524 входит в журнал событий службы каталогов:

Проверка согласованности знаний NTDS (KCC)
NTDS General
Microsoft-Windows-ActiveDirectory_DomainService

События Active Directory, которые обычно ссылаются на состояние 8524, включают, но не ограничиваются:

Контроллеры домена регистрирует событие репликации NTDS 2087 и событие репликации NTDS 2088 в журнале событий службы каталогов:

Имя журнала: служба каталогов
Источник: Microsoft-Windows-ActiveDirectory_DomainService
Дата: <date> <time>
ID события: 2087
Категория задач: клиент RPC DS
Уровень: ошибка
Ключевые слова: Классический
Пользователь: АНОНИМНЫЙ LOGON
Компьютер: <dc name> .<domain name>
Описание:

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

Имя журнала: служба каталогов
Источник: Microsoft-Windows-ActiveDirectory_DomainService
Дата: <date> <time>
ID события: 2088
Категория задач: клиент RPC DS
Уровень: предупреждение
Ключевые слова: Классический
Пользователь: АНОНИМНЫЙ LOGON
Компьютер: <dc name> .<domain name>
Описание:
Службы домена Active Directory не могли использовать DNS для решения IP-адреса контроллера домена, приведенного ниже. Для обеспечения согласованности групп безопасности, групповой политики, пользователей и компьютеров и их паролей службы домена Active Directory успешно реплицировали с помощью NetBIOS или полностью квалифицированного имени компьютера контроллера домена источника.

Недействительная конфигурация DNS может влиять на другие важные операции на компьютерах членов, контроллерах доменов или серверах приложений в этом лесу служб домена Active Directory, включая проверку подлинности логотипов или доступ к сетевым ресурсам.

Вы должны немедленно устранить эту ошибку конфигурации DNS, чтобы этот контроллер домена может разрешить IP-адрес контроллера домена источника с помощью DNS.

Причина

Состояние ошибки 8524 имеет следующую строку ошибок:

Операция DSA не может продолжиться из-за сбоя при просмотре DNS.

Это ошибка для всех возможных отказов DNS, влияющих на Active Directory на контроллерах домена Windows Server 2003 SP1.

Microsoft-Windows-ActiveDirectory_DomainService событие 2087 является партнерским событием для других событий Active Directory, которые ссылаются на состояние 8524, если контроллер домена Active Directory не может разрешить удаленный DC с помощью полностью квалифицированной записи CNAME <object guid for source DCs NTDS Settings object> (._msdcs. ) с помощью <forest root domain> DNS.

Microsoft-Windows-ActiveDirectory_DomainService событие 2088 регистрируется, когда контроллер домена источника успешно разрешен с помощью имени NetBIOS, но такое разрешение имен возникает только при сбое разрешения имен DNS.

Наличие состояния 8524 и событий 2088 или 2087 microsoft-Windows-ActiveDirectory_DomainService 2088 или 2087 указывает на то, что разрешение имен DNS не удается active Directory.

Таким образом, состояние репликации 8524 регистрируется, когда dc назначения не может разрешить источник DC с помощью записей CNAME и Host "A" или Host "AAAA" с помощью DNS. Конкретные корневые причины:

Исходный dc находится в автономном режиме или больше не существует, но его объект Параметры NTDS по-прежнему существует в экземпляре active Directory для DCs назначения.

Источник DC не зарегистрировал записи CNAME или хост-серверов на одном или более DNS-серверах по следующим причинам:

Попытки регистрации не увенчались неудачей.
Параметры клиента DNS в источнике не указывают на DNS Servers, которые либо разодвигают, либо делегируют <forest root domain zone and (or) primary DNS suffix domain zones> _msdcs. .

Параметры клиентов DNS в пункте назначения DC не указывают на DNS Servers, которые либо содержат, либо перенаправлены, либо делегируют зоны DNS, содержащие CNAME или хост-записи для источника DC

Простая задержка репликации
Сбой репликации
Сбой передачи зоны

Недействительные forwarders или делегирования. Они препятствуют разрешению доменных записей CNAME или Host для DCs в других доменах в лесу.

DNS Servers, используемые для dc назначения, источника dc или промежуточных DNS Servers, не работают должным образом.

Решение

Проверьте, вызвана ли 8524 автономной dc или устаревшими метаданными DC

Если ошибка/событие 8524 относится к dc, который в настоящее время отключен, но по-прежнему действителен в лесу, сделайте его рабочим.

Если ошибка/событие 8524 относится к неактивному DC, удалите устаревшие метаданные для этого DC из копии active Directory для DCs назначения. Неактивный DC — это установка dc, которая больше не существует в сети, но ее объект Параметры NTDS по-прежнему существует в экземпляре active Directory для DCs назначения.

Поддержка Майкрософт регулярно находит устаревшие метаданные для несуществуют DCs или устаревшие метаданные из предыдущих рекламных акций DC с тем же именем компьютера, которое не было удалено из Active Directory.

Удаление устаревших метаданных DC, если они присутствуют

Очистка метаданных GUI с помощью сайтов и служб Active Directory (DSSITE). MSC)

Запустите Windows Server 2008 или Windows Server 2008 R2 Active Directory Sites and Services snap-in (DSSITE). MSC).

Это также можно сделать путем запуска сайтов и служб Active Directory на компьютере Windows Vista или Windows 7, который был установлен в рамках пакета средств администрирования удаленного сервера (RSAT).

Сосредоточься на DSSITE. MSC snap-in on the destination DCs' copy of Active Directory.

После запуска DSSITE. MSC, щелкните правой кнопкой мыши "Сайты и службы Active Directory [ <DC Name> ]

Выберите пункт назначения, в который веется журнал ошибки 8524/event из списка DCs, видимого в "Изменение контроллера домена. ". список

Удалите исходный объект DCs NTDS Параметры, на который ссылается в 8524 ошибках и событиях. Пользователи и компьютеры Active Directory (DSA. MSC) оснастки и удаления либо источника DCs NTDS Параметры объекта.

Появляется объект DCs NTDS Параметры

Ниже контейнера Sites, Site Name, Servers и %server name%
Выше входящий объект подключения, отображаемого в правой области сайтов и служб Active Directory.

На красном снимке экрана ниже показан объект NTDS Параметры CONTOSO-DC2, расположенный ниже сайта Default-First-Site-Name.

Щелкните правой кнопкой мыши устаревший объект NTDS Параметры, который необходимо удалить, а затем выберите "Удалить".

Очистка метаданных также может быть сделана из оснастки W2K8 /W2K8 R2 Active Directory Users and Computers, как описано в TECHNET.

Очистка метаданных командной строки с помощью NTDSUTIL

Устаревший или командный метод удаления устаревших объектов NTDS Параметры с помощью команды очистки метаданных NTDSUTIL задокументирован в MSKB 216498.

Запуск DCDIAG /TEST:DNS на источнике DC + dc назначения

DCDIAG /TEST:DNS делает семь различных тестов для быстрого проверки состояния DNS контроллера домена. Этот тест не является частью выполнения DCDIAG по умолчанию.

Войдите с Enterprise учетными данными администратора на консоль контроллеров домена назначения, которые регистрют события 8524.

Откройте управленский привилегированный запрос CMD, а затем запустите в журнале DC состояние 8424 и исходный DC, из чего реплицируется dc DCDIAG /TEST:DNS /F назначения.

Чтобы запустить DCDIAG со всеми DCs в лесу, введите DCDIAG /TEST:DNS /V /E /F:<File name.txt> .

Чтобы запустить DCDIAG TEST:DNS для определенного DC, введите DCDIAG /TEST:DNS /V /S:<DC NAME> /F:<File name.txt> .

Найдите сводную таблицу в конце DCDIAG /TEST:DNS вывода. Определение и согласование условий предупреждения или сбоя в соответствующих DCs отчета.

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

Проверка разрешения имен Active Directory с помощью PING

DCS назначения устраняют исходные DCS в DNS с помощью полностью квалифицированных записей CNAME, полученных из объекта GUID удаленного объекта DCS NTDS Параметры (родительский объект для подключения объектов, видимых в оснастке Сайтов и служб Active Directory). С помощью команды PING можно протестировать способность данной DCS разрешить полностью квалифицированную запись CNAME источника DC.

Найдите объектGUID источника DCs NTDS Параметры в копии источника DCS Active Directory.

На консоли источника DC, в журнале 8524 ошибки/события, введите:

repadmin /showrepl <fully qualified hostname of source DC cited in the 8524 error (event)>

Поле GUID объекта DSA в заглавной части команды содержит объектGUID объекта текущих repadmin /SHOWREPl NTDS исходных DCs. Используйте представление исходных DCs о его объекте Параметры NTDS в случае медленной репликации или сбоя. Заглавная часть repadmin вывода будет выглядеть так:

Default-First-Site-Name\CONTOSO-DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: 8a7baee5-cd81-4c8c-9c0f-b10030574016 < правой кнопкой мыши + скопируйте эту строку в Windows
<-буфер обмена & вклеить в него команду PING в
< шаг 4

Найдите объектGUID источника постоянного тока в копии DCs назначения Active Directory.

На консоли конечного dc для ведения журнала ошибки/события 8524 введите:

repadmin /showrepl <fully qualified hostname of destination DC>

REPADMIN /SHOWREPL вывод показан ниже. Поле GUID объекта DSA перечислены для каждого источника DC, из которых реплицируется входящий dc назначения.

Если объект GUIDS одинаковый, то источник DC и dc назначения знают об одном и том же моментации (той же рекламе) источника DC. Если они отличаются, то рисуй, какой из них был создан позже. Объект настройки NTDS с более ранней датой создания, скорее всего, устарел и должен быть удален.

PING источник DC по его полностью квалифицированной CNAME.

На консоли конечной dc протестировать разрешение имен Active Directory с помощью PING-записи исходных компьютеров с полной квалификацией CNAME:

c:\>ping <ObjectGUID> from source DCs NTDS Settings object._msdcs.<DNS name for Active Directory forest root domain>

Если ping работает, повторно обнажь невыполнение операции в Active Directory. В случае сбоя PING перенаправляйся в "Устранение сбоя при проверке 8524 DNS", но повторно проверьте тест PING после каждого шага, пока он не разрешит.

Устранение сбоя в оккупате DNS 8524: долгий путь

Если ошибка/события 8524 не вызвана устаревшими метаданными DC, а тест CNAME PING сбой, проверьте состояние DNS:

Исходный DC
Пункт назначения DC
DNS Servers, используемые в DCS-источника и назначения

В общем, убедитесь, что:

Убедитесь, что исходный dc указывает на допустимые DNS Servers

Основной домен Суффикса DNS для компьютеров, если он отличается от доменного имени Active Directory (см. статью Technet Disjoint Namespace).

Параметры проверки того, что в DNS Server размещены, переадтрансаторы или делегаты (то есть "можно разрешить") такие зоны.

Запустите средство управления DNS для DNS и убедитесь, что DNS Servers, на которые указывает источник DC для разрешения имен, являются зонами, о которых идет речь.

Используйте NSLOOKUP, чтобы убедиться, что все DNS Servers, на которые указывает источник DC, могут решать запросы для зон DNS, о чем идет речь.

Запуск IPCONFIG /ALL на консоли источника DC

Запустите следующие запросы NSLOOKUP:

Убедитесь, что исходный dc зарегистрировал запись CNAME

Используйте шаг 1 из "Проверьте разрешение имен active Directory с помощью PING", чтобы найти текущий CNAME источника DC.

Запустите на консоли источника постоянного тока, чтобы определить, на какой ipconfig /all DNS Servers указывает источник dc для разрешения имен.

Используйте NSLOOKUP для запроса текущих DNS-серверов для записи CNAME источника DCS (найденной с помощью процедуры в "Проверьте разрешение имен Active Directory с помощью PING").

Если источник DC не зарегистрировал запись CNAME на DNS Servers, на что указывает для разрешения имен, запустите следующую команду из источника DC. Затем перепроверять регистрацию записи CNAME:

Убедитесь, что исходный dc зарегистрировал свои записи хост-кодов

На консоли источника постоянного тока запустите, чтобы определить, на какой ipconfig /all DNS Servers указывается источник разрешения имен.

Используйте NSLOOKUP для запроса текущих DNS Servers для хост-записи.

Повторите команду NSLOOKUP с исходным IP-адресом DNS Server.

Чтобы динамически зарегистрировать записи "A", введите следующую команду с консоли компьютера:

Windows 2000 через Windows Сервер 2008 R2 все зарегистрировать IPv4 хост "A" записей.
Windows На компьютерах Server 2008 и Windows Server 2008 R2 все регистрируются записи IPv6 хост "AAAA".
Записи хостов "A" и "AAAA" регистрируются в зоне первичного суффикса DNS на компьютерах.
Отключать ники, не подключенные к сетевым кабелям.
Отключение регистрации записей хост-записей в НИКАх, недоступных для компьютеров-членов и компьютеров-членов в сети.
Отключение протокола IPv6 не поддерживается путем отключки почтового ящика IPv6 в свойствах сетевых карт.

Убедитесь, что пункт dc назначения указывает на допустимые DNS Servers

Параметры проверки того, что DNS Server хостов, переадтрансаторов или делегатов (то есть "можно разрешить") такие зоны включают в себя:

Запустите IPCONFIG /ALL на консоли конечного DC:

Запустите следующие запросы NSLOOKUP с консоли dc назначения:

Убедитесь, что DNS Server, используемый центром назначения, может разрешить исходные записи ЦНС CNAME и HOST

На консоли конечной dc запустите, чтобы определить DNS Servers, в какую точку назначения dc указывает разрешение ipconfig /all имен:

На консоли конечной dc используйте для запроса DNS Servers, настроенных в пункте назначения DC для исходных NSLOOKUP DCs CNAME и записей хостов:

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

Если DNS Servers используются исходными и принимающими AD-интегрированными копиями _msdcs.<forest root> и <primary DNS suffix> зоны, проверьте:

Если зоны DNS, используемые источником и центром назначения, хранятся в первичных и вторичных копиях зон DNS, проверьте:

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

Если DNS-серверы, используемые источником и центром назначения, имеют родительские и детские связи, проверьте:

IP-адрес DNS-сервера: xxx.xxx.xx.90
Возвращенный код ответа (RCODE): 5
Возвращенный код состояния: 9017

Чтобы компьютеры и пользователи могли определять местоположение этого контроллера домена, необходимо зарегистрировать запись в DNS.

Дополнительные сведения
Значение с ошибкой: Неверный раздел DNS.

Domain Controller Diagnosis

Performing initial setup:
Done gathering initial info.

Doing initial required tests

Doing primary tests

Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
. ForestDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. ForestDnsZones passed test CheckSDRefDom

Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
. DomainDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. DomainDnsZones passed test CheckSDRefDom

Running partition tests on : Schema
Starting test: CrossRefValidation
. Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
. Schema passed test CheckSDRefDom

Running partition tests on : Configuration
Starting test: CrossRefValidation
. Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
. Configuration passed test CheckSDRefDom

Running partition tests on : xxx
Starting test: CrossRefValidation
. crism passed test CrossRefValidation
Starting test: CheckSDRefDom
. xxx passed test CheckSDRefDom

Вы пытаетесь зарегистрироваться во внешнем домене ? На клиенте необходимо указать "серый" адрес Вашего ДНС, а не "белый".

характеристи карты непосред для доступа в интернет.
IP-адрес xx.xxx.178.66
IP-адрес DNS-сервера: xxx.xxx.xx.90

ADMINDM
спасибо за совет, но он не подойдет, главный админ не разрешил такие изменения - цитирую-
"потому, что я не знаю к чему это приведет. "

Если администратор, да ещё и главный, не знает к чему ведет повторная регистрация на DNS сервере, то я бы посоветовал Вам поискать лучшее место для работы и для "набить руку".

серый, означает частный адрес (из разряда 192.168.0.1 и тд)
белый, означает интернет адрес интерфейса (по типу 216.239.59.104)

вобщем на эту тему (DDNS ) можно написать энциклопедию 3-4 тома - при этом затронуться и DHCP и WINS и BIND VS MS DNS и фаерволы и еще много много всего.

IP-адрес DNS-сервера: 195.234.42.1
Возвращенный код ответа (RCODE): 5
Возвращенный код состояния: 9017

Дополнительные сведения
Значение с ошибкой: Неверный раздел DNS.

Performing initial setup:
Done gathering initial info.

Doing initial required tests

address (172.17.17.2) and was pingable. Check that the IP address is

registered correctly with the DNS server.
. SERVER failed test Connectivity

Doing primary tests

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

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

Однако это не всегда так, и пользователи со всего мира сталкиваются с проблемами подключения.

Стоит отметить, что эта ошибка появилась в Microsoft Edge, а не в других браузерах.

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

DNS-имя не существует? Вот решения!

2. Используйте DNS-сервер Google

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

Откройте « Сетевые подключения» , найдите ваше подключение, щелкните его правой кнопкой мыши и выберите « Свойства» .
Здесь выберите Протокол Интернета версии 4 (TCP / IPv4) и откройте Свойства .
Выберите Использовать следующие адреса DNS-серверов и установите 8.8.8.8 в качестве предпочитаемого DNS-сервера и 8.8.4.4 в качестве альтернативного DNS-сервера .
Как только вы закончите, нажмите ОК .
В качестве альтернативы, некоторые пользователи предлагают использовать 208.67.222.222 в качестве предпочитаемого DNS-сервера и 208.67.222.220 в качестве альтернативного DNS-сервера .

3. Используйте другой браузер

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

Вы можете выбрать Google Chrome, Firefox или другой браузер. Мы рекомендуем UR Browser для улучшенной защиты конфиденциальности и первоклассной надежности.

UR — это легкий браузер, который защитит ваши данные. Кроме того, вы будете иметь безошибочный опыт онлайн.

Узнайте больше о UR Browser, прочитав наш подробный обзор .

Вывод

Если вы не хотите терять свои закладки из Microsoft Edge, выберите один из этих инструментов в нашем новом списке, чтобы импортировать ваши любимые страницы.

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