Задний план:
У меня есть среда с двумя разными доменами AD, каждый в своем собственном лесу, каждый с двумя контроллерами домена Windows Server 2008 R2, выступающими в качестве DNS-серверов. Между доменами нет доверия.
Каждый DNS-сервер управляет основной зоной DNS для своего домена AD, а затем некоторыми другими зонами, включая зону обратного просмотра для его IP-подсетей; все зоны интегрированы в AD; все DNS-серверы, управляющие зоной, правильно указаны как полномочные серверы имен для этой зоны.
Итак, ситуация такая (с использованием поддельных имен и IP-адресов):
Домен А:
Домен DNS: domainA.dom
IP-подсеть: 192.168.1
DC / DNS-серверы: serverA1.domainA.dom
(192.168.1.1
), serverA2.domainA.dom
(192.168.1.2
)
Авторитетные зоны: domainA.dom
, 1.168.192.in-addr.arpa
, somezone.local
Домен B:
Домен DNS: domainB.dom
IP-подсеть: 10.0.0
DC / DNS-серверы: serverB1.domainB.dom
(10.0.0.1
), serverB2.domainB.dom
(10.0.0.2
)
Авторитетные зоны: domainB.dom
, 0.0.10.in-addr.arpa
, someotherzone.local
DNS-серверы в домене A имеют условных серверов пересылки, определенных для каждой зоны, управляемой DNS-серверами в домене B, перенаправляя на оба DNS-сервера домена B. DNS-серверы в домене B имеют противоположную конфигурацию. Все серверы пересылки хранятся в Active Directory.
Все работает отлично, и компьютеры в каждом домене могут разрешать прямые и обратные DNS-запросы для обоих доменов, используя DNS-серверы своего домена.
Эта проблема:
У меня SCOM 2012 развернут в домене A, а агент SCOM установлен на обоих контроллерах домена; пакеты управления для Active Directory и DNS-сервера установлены и обновлены.
У меня есть ряд предупреждений, подобных следующим, на обоих контроллерах домена; каждое предупреждение генерируется для каждой перенаправленной зоны и для каждого перенаправленного сервера:
Forwarder someotherzone.local (10.0.0.1) cannot resolve the host name 192.168.1.1,someotherzone.local for serverA1.domainA.dom
Forwarder someotherzone.local (10.0.0.2) cannot resolve the host name 192.168.1.1,someotherzone.local for serverA1.domainA.dom
Forwarder someotherzone.local (10.0.0.1) cannot resolve the host name 192.168.1.2,someotherzone.local for serverA2.domainA.dom
Forwarder someotherzone.local (10.0.0.2) cannot resolve the host name 192.168.1.2,someotherzone.local for serverA2.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.1) cannot resolve the host name 192.168.1.1,0.0.10.in-addr.arpa for serverA1.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.2) cannot resolve the host name 192.168.1.1,0.0.10.in-addr.arpa for serverA1.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.1) cannot resolve the host name 192.168.1.2,0.0.10.in-addr.arpa for serverA2.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.2) cannot resolve the host name 192.168.1.2,0.0.10.in-addr.arpa for serverA2.domainA.dom
Единственным исключением является основная зона AD DNS, управляемая DNS-серверами домена B («domainB.dom»): для этого сервера условной пересылки не генерируется никаких предупреждений, а монитор доступности пересылки имеет зеленый цвет.
Хорошо, что это значит?
Что эти мониторы пытаются мне сказать?
Что они проверяют?
Что на самом деле не так?
И почему нет ошибки для зоны "domainB.dom", которая настроена точно так же как и другие, и как зона на DNS-серверах домена B, и как перенаправитель на DNS-серверах домена A?
Ответ найден, и это немного неприятно (по крайней мере, если вы ожидали, что люди, создающие пакеты управления, действительно знают, что они делают).
Выдержано из описания монитора:
Этот монитор проверяет доступность сервера пересылки, выполняя NSLOOKUP на целевом сервере пересылки.
Скрипт выполняет
nslookup -timeout=<value> -querytype=<type> <name> <server>
<type>
это A, NS, SOA.
<name>
- это целевое DNS-имя, которое необходимо разрешить. В случае безусловного сервера пересылки используется значение переопределения, в противном случае используется доменное имя сервера пересылки.
<server>
- это имя сервера, на котором выполняется запрос NSLOOKUP.
Ценность$Target/Property[Type="DNS!Microsoft.Windows.DNSServer.Library.Server"]/ListeningIP$
который предоставляет список всех IP-адресов, которые прослушивает текущий DNS-сервер.
<value>
это время ожидания в секундах / 3, поскольку время ожидания в секундах используется для установки максимального времени, в течение которого сценарий может работать.Пример безусловного перенаправителя:
NSLOOKUP -timeout=30 -querytype=a www.microsoft.com 10.0.0.5
будет запрашивать у сервера 10.0.0.5 DNS-имя для www.microsoft.com. В этом случае вы должны установить фактическое время ожидания в секундах на 90 переопределений монитора.Пример условного пересылки:
NSLOOKUP -timeout=30 -querytype=a www.msn.com 10.0.0.5
будет запрашивать у сервера 10.0.0.5 фактическое имя сервера условной пересылки, на который нацелен этот монитор.
Это означает, что агент SCOM попытается выполнить такие запросы:
nslookup -timeout=30 -querytype=a domainB.dom <server>
nslookup -timeout=30 -querytype=a someotherzone.local <server>
nslookup -timeout=30 -querytype=a 0.0.10.in-addr.arpa <server>
Это будет работать для зоны DNS основного домена AD (поскольку контроллеры домена автоматически регистрируют себя как пустые A
записей для этой зоны), но не удастся для someotherzone.local, у которого не было пустых A
запись (я могу подтвердить, что после создания вручную предупреждение исчезло, а монитор вернулся к зеленому).
Третий запрос, конечно, всегда терпит неудачу, потому что он просто вообще не имеет смысла искать A
запись в зоне обратного просмотра.
Решение: переопределите монитор доступности DNS Forwarder для выполнения NS
или SOA
запрос для перенаправленной зоны вместо A
запрос.
Это то, что он должен был делать с самого начала.