Windows Server для самых маленьких. Часть 7: DNS в домене
Все части серии «Windows Server для самых маленьких»Как устроен сам протокол DNS — дерево имён, рекурсивные и авторитативные серверы, типы записей, TTL — разобрано в части 12 сетевой серии, и здесь мы это не повторяем. Эта часть о том, что делает с DNS Active Directory: как зона превращается в объекты каталога, кто и как регистрирует в ней записи, куда сервер отправляет запросы о чужих именах, и какие настройки отличают DNS контроллера от DNS, поднятого на Linux.
Напомним, почему контроллер почти всегда ещё и DNS-сервер. Клиент находит контроллеры по SRV-записям (часть 3), а контроллеры регистрируют эти записи сами и обновляют каждый час. DNS-сервер, который принимает такие обновления, проверяет, кто их прислал, и реплицирует зону вместе с каталогом, не требуя ни зонных передач, ни отдельной настройки, — это DNS-сервер Windows с зоной в Active Directory. Можно держать зону домена на BIND, это поддерживается, но тогда динамические обновления, права на записи и репликацию придётся настраивать руками.
Типы зон
У DNS-сервера Windows четыре вида зон, и Get-DnsServerZone показывает их все в одной таблице:
PS C:\> Get-DnsServerZone | Format-Table ZoneName, ZoneType, IsDsIntegrated, ReplicationScope, DynamicUpdate, IsAutoCreated -AutoSize
ZoneName ZoneType IsDsIntegrated ReplicationScope DynamicUpdate IsAutoCreated
-------- -------- -------------- ---------------- ------------- -------------
_msdcs.corp.example.com Primary True Forest Secure False
0.in-addr.arpa Primary False None True
127.in-addr.arpa Primary False None True
255.in-addr.arpa Primary False None True
corp.example.com Primary True Domain Secure False
TrustAnchors Primary True Forest None False
Primary — основная зона, которую этот сервер хранит и в которой принимает изменения. Хранится либо в файле %SystemRoot%\System32\dns\<имя>.dns (IsDsIntegrated = False; три автоматические обратные зоны для 0., 127. и 255. — именно такие, они нужны, чтобы сервер не ходил в интернет с вопросами про localhost), либо в каталоге.
Secondary — копия чужой основной зоны, полученная зонной передачей (AXFR/IXFR) и только для чтения. В домене она нужна, когда на контроллере хотят держать копию зоны, которой владеет другой DNS-сервер, например BIND у хостера.
Stub — усечённая копия: только SOA, NS и адреса NS-серверов чужой зоны. Сервер с stub-зоной знает, у кого спрашивать про имена в ней, и сам следит за изменением списка NS.
Forwarder (условный форвардер) — не зона, а правило: «запросы про partner.example.net отправлять на такие-то адреса». Хранится в той же таблице, потому что с точки зрения сервера это тоже делегирование ответственности за поддерево.
Зона в каталоге
Зона с IsDsIntegrated = True — это объекты в одном из разделов каталога, и у ReplicationScope три значения:
| Область | Раздел | Куда реплицируется |
|---|---|---|
| Domain | DC=DomainDnsZones,DC=corp,DC=example,DC=com |
на все контроллеры домена, на которых установлен DNS |
| Forest | DC=ForestDnsZones,DC=corp,DC=example,DC=com |
на все контроллеры леса с DNS |
| Legacy | CN=MicrosoftDNS,CN=System,DC=corp,DC=example,DC=com |
на все контроллеры домена, включая те, где DNS нет; совместимость с Windows 2000 |
Поэтому _msdcs.corp.example.com живёт в Forest: записи поиска контроллеров нужны всему лесу. А зона corp.example.com — в Domain: контроллерам других доменов адреса рабочих станций этого домена не нужны. Область меняется на лету: Set-DnsServerPrimaryZone -Name corp.example.com -ReplicationScope Forest.
Внутри раздела зона — объект класса dnsZone, а каждое имя — объект dnsNode с многозначным двоичным атрибутом dnsRecord, где лежат все записи этого имени:
PS C:\> Get-ADObject -SearchBase 'DC=corp.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=corp,DC=example,DC=com' -Filter 'objectClass -eq "dnsNode"' -Properties dnsRecord, whenChanged |
Select-Object Name, @{n='Records'; e={$_.dnsRecord.Count}}, whenChanged | Sort-Object Name | Select-Object -First 8
Name Records whenChanged
---- ------- -----------
@ 4 15.10.2026 9:40:18
_kerberos._tcp 1 15.10.2026 9:40:18
_ldap._tcp 1 15.10.2026 9:40:18
_msdcs 1 01.10.2026 12:05:30
dc1 1 15.10.2026 9:40:18
ForestDnsZones 1 15.10.2026 9:40:18
srv1 1 15.10.2026 8:14:40
ws1 1 15.10.2026 9:02:05
Имя @ — вершина зоны: SOA, NS и A-записи самого имени corp.example.com. Что лежит в dnsRecord, модуль DnsServer декодирует, и дальше мы будем смотреть через него; но полезно знать, что зона — это обычные объекты со всем, что из этого следует: у каждой записи есть владелец и ACL, удалённая запись становится tombstone (dNSTombstoned = TRUE) и живёт в каталоге ещё неделю, а конфликт одновременной правки на двух контроллерах разрешается по правилам репликации каталога, а не DNS.
Следствие, которое объясняет самый частый вопрос про DNS в домене с несколькими сайтами: изменение записи доходит до других контроллеров со скоростью репликации раздела. Внутри сайта — секунды; между сайтами — по расписанию связи сайтов, по умолчанию раз в 15 минут. Пока репликация не прошла, два контроллера отвечают по-разному, и это не ошибка. Точечно подтолкнуть можно: repadmin /replicate dc2.corp.example.com dc1.corp.example.com DC=DomainDnsZones,DC=corp,DC=example,DC=com.
Динамические обновления
Кто создаёт записи srv1 и ws1 в зоне? Сами машины, протоколом динамического обновления DNS (RFC 2136): клиент посылает серверу сообщение UPDATE с инструкцией «в зоне corp.example.com добавить ws1 A 192.168.1.100». Зона с DynamicUpdate = Secure принимает такие сообщения только с подписью, и подпись эта — Kerberos.
Механизм называется GSS-TSIG (RFC 3645) и работает так:
ws1 dc1 (DNS + KDC)
│ │
├─ SOA? corp.example.com ──────────────►│ 1. кто основной сервер зоны
│◄─ SOA dc1.corp.example.com ───────────┤
├─ UPDATE ws1 A 192.168.1.100 ─────────►│ 2. попытка без подписи
│◄─ REFUSED ────────────────────────────┤ зона требует подпись
├─ TGS-REQ DNS/dc1.corp.example.com ───►│ 3. билет на службу DNS контроллера (порт 88)
│◄─ TGS-REP ────────────────────────────┤
├─ TKEY-запрос с AP-REQ внутри ────────►│ 4. установить ключ сеанса по Kerberos (порт 53)
│◄─ TKEY-ответ ─────────────────────────┤
├─ UPDATE ws1 A 192.168.1.100 + TSIG ──►│ 5. то же обновление, подписанное ключом сеанса
│◄─ NOERROR ────────────────────────────┤
Первая попытка без подписи — нормальное поведение клиента Windows: он сначала пробует просто так и, получив отказ, переходит к безопасному обновлению. У контроллера для этого есть SPN DNS/dc1.corp.example.com на учётной записи DC1$.
Запись, созданная безопасным обновлением, получает владельца — учётную запись, чьим билетом подписан запрос:
PS C:\> (Get-Acl 'AD:\DC=ws1,DC=corp.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=corp,DC=example,DC=com').Owner
CORP\WS1$
Изменить или удалить запись ws1 теперь может только WS1$, администраторы DNS и те, кому дали право явно. Это защита от того, чтобы любая машина в сети могла перехватить имя сервера. И это же источник двух классических проблем. Первая: машину переустановили с тем же именем — у новой машины новая учётная запись с новым SID, старая запись принадлежит старому SID, обновление отклоняется, в DNS остаётся старый адрес. Лечится удалением старой записи. Вторая — записи, которые регистрирует DHCP-сервер от имени клиентов, не умеющих обновлять DNS сами; у них владелец — DHCP-сервер, и об этом в следующей части.
Три значения DynamicUpdate и когда какое:
- Secure — только подписанные обновления; единственно правильное для зоны домена.
- NonsecureAndSecure — принимать и неподписанные. Удобно для принтеров и Linux-машин без Kerberos, но любой, кто есть в сети, может перезаписать любую запись. Если очень нужно, делают отдельную зону для таких устройств.
- None — записи только руками. Для зон, где все записи статические: внутренние копии публичных имён, обратные зоны без динамики.
Что регистрирует клиент Windows и когда: A-запись (и AAAA) при старте, при смене адреса, при Register-DnsClient и затем каждые 24 часа; PTR-запись в обратной зоне, если зона есть; регистрацией занимается служба DHCP Client даже при статическом адресе, и если её выключить, записи обновляться перестанут. Настройки — Get-DnsClient (RegisterThisConnectionsAddress, UseSuffixWhenRegistering) и Set-DnsClient.
Контроллер регистрирует вдвое больше: свою A-запись как обычный клиент и несколько десятков SRV-, CNAME- и A-записей через Netlogon. Их список лежит в файле %SystemRoot%\System32\config\netlogon.dns, обновление — каждый час и по команде nltest /dsregdns. Если какие-то записи контроллер регистрировать не должен (например, общие записи _ldap._tcp.corp.example.com у контроллера в удалённом сайте, чтобы клиенты не шли к нему из других сайтов), это настраивается политикой «Specify DC Locator DNS records not registered by the DCs» или параметром реестра DnsAvoidRegisterRecords службы Netlogon.
Куда отправлять чужие запросы
Рабочая станция спрашивает dc1 обо всём: и про srv1.corp.example.com, и про www.vitaliy.org. Про первое dc1 знает сам, про второе — должен спросить кого-то. Три механизма.
Root hints. Файл со списком корневых серверов интернета (Get-DnsServerRootHint), с которого сервер начинает рекурсию, как это описано в сетевой серии. Работает из коробки, если контроллеру открыт исходящий UDP и TCP 53 в интернет, и это наименее удобный вариант: у контроллера свой кеш, и каждый контроллер строит его заново.
Форвардеры. Серверы, которым контроллер пересылает все запросы, на которые не может ответить сам. Обычно это DNS провайдера, роутера или публичный резолвер:
PS C:\> Set-DnsServerForwarder -IPAddress 192.168.1.1, 203.0.113.53 -UseRootHint $true -Timeout 3
PS C:\> Get-DnsServerForwarder
UseRootHint : True
Timeout(s) : 3
EnableReordering : True
IPAddress : {192.168.1.1, 203.0.113.53}
ReorderedIPAddress : {192.168.1.1, 203.0.113.53}
UseRootHint $true — если форвардеры не ответили, попробовать корневые серверы; EnableReordering — отвечавший быстрее поднимается в списке.
Условные форвардеры — форвардеры для конкретного домена. Запросы про partner.example.net отправлять на DNS-серверы партнёра, про eu.corp.example.com — на контроллеры дочернего домена, про internal.example.net соседней компании — на её серверы через VPN:
PS C:\> Add-DnsServerConditionalForwarderZone -Name partner.example.net -MasterServers 198.51.100.53, 198.51.100.54 -ReplicationScope Forest
PS C:\> Get-DnsServerZone partner.example.net | Select-Object ZoneName, ZoneType, MasterServers, ReplicationScope
ZoneName ZoneType MasterServers ReplicationScope
-------- -------- ----------------- ----------------
partner.example.net Forwarder {198.51.100.53, 198.51.100.54} Forest
Условный форвардер тоже можно хранить в каталоге (-ReplicationScope), и тогда он появится на всех контроллерах леса сам. Это основа разрешения имён при доверии между лесами, к которому мы придём в части 22: каждый лес знает, у кого спрашивать про имена другого.
Stub-зона решает ту же задачу иначе: вместо «пересылай запросы на эти адреса» — «вот NS-записи зоны, спрашивай у них напрямую и следи, если они изменятся». Разница практическая: условный форвардер шлёт рекурсивные запросы указанным серверам, и они должны уметь рекурсию; stub-зона шлёт итеративные запросы авторитативным серверам зоны, и список этих серверов обновляется сам. Stub удобнее, когда у партнёра много NS-серверов и они меняются; условный форвардер — когда нужно отправлять запросы в конкретное место, например через VPN на один адрес.
PS C:\> Add-DnsServerStubZone -Name eu.corp.example.com -MasterServers 192.168.2.10 -ReplicationScope Forest
Порядок, в котором сервер решает, куда идти: своя авторитативная зона → кеш → условный форвардер или stub для этого имени → форвардеры → root hints. Отсюда следствие: если в домене зона example.com заведена локально (о чём ниже), ни форвардеры, ни что-либо ещё про example.com спрошено не будет.
Обратные зоны
Повышение контроллера обратных зон не создаёт. Они нужны, чтобы по адресу находить имя: для журналов, для nslookup 192.168.1.20, для sssd на Linux, для почтовых серверов, для отчётов. Windows для Kerberos и аутентификации обратное разрешение не использует, поэтому домен без обратных зон работает, но жить с ними удобнее.
PS C:\> Add-DnsServerPrimaryZone -NetworkId 192.168.1.0/24 -ReplicationScope Domain -DynamicUpdate Secure
PS C:\> Add-DnsServerPrimaryZone -NetworkId 2001:db8:1::/64 -ReplicationScope Domain -DynamicUpdate Secure
PS C:\> Get-DnsServerZone | Where-Object IsReverseLookupZone | Select-Object ZoneName, DynamicUpdate
ZoneName DynamicUpdate
-------- -------------
1.168.192.in-addr.arpa Secure
0.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa Secure
-NetworkId сам строит имя зоны в in-addr.arpa или ip6.arpa. После появления зоны клиенты Windows при следующей регистрации добавят свои PTR-записи; записи контроллеров появятся при ближайшем nltest /dsregdns или перезагрузке.
Старение и очистка
Динамическая регистрация создаёт записи, но кто их удалит? Ноутбук, который получил адрес по DHCP, зарегистрировался и больше в сети не появился, оставляет запись навсегда. Через год в зоне сотни имён, указывающих на адреса, которые давно выданы другим машинам.
Для этого у записей есть временная метка (Timestamp), и есть две настройки, обе по умолчанию 7 дней:
- No-refresh interval — срок после последнего обновления, в течение которого повторная регистрация с теми же данными метку не меняет (чтобы ежедневные регистрации не порождали репликацию);
- Refresh interval — срок после него, в течение которого запись считается живой; клиент, который зарегистрировался в этом окне, обновляет метку.
Запись, не обновлённая дольше суммы интервалов (14 дней), считается устаревшей, и сервер, у которого включена очистка (scavenging), её удаляет. Включается в двух местах: на зоне и на сервере.
PS C:\> Set-DnsServerZoneAging -Name corp.example.com -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00
PS C:\> Set-DnsServerZoneAging -Name 1.168.192.in-addr.arpa -Aging $true
PS C:\> Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones
PS C:\> Get-DnsServerScavenging
NoRefreshInterval : 7.00:00:00
RefreshInterval : 7.00:00:00
ScavengingInterval : 7.00:00:00
ScavengingState : True
LastScavengeTime : 15.10.2026 10:00:00
Очистку включают на одном DNS-сервере домена: зона общая, и достаточно, чтобы её проверял кто-то один. Прежде чем включать, стоит посмотреть, что будет удалено:
PS C:\> Get-DnsServerResourceRecord -ZoneName corp.example.com -RRType A |
Where-Object { $_.Timestamp -and $_.Timestamp -lt (Get-Date).AddDays(-14) } |
Format-Table HostName, Timestamp, @{n='IP'; e={$_.RecordData.IPv4Address}}
HostName Timestamp IP
-------- --------- --
lap-old 02.08.2026 14:00:00 192.168.1.157
printer-3 15.09.2026 9:00:00 192.168.1.31
Записи без метки — статические, их очистка не трогает никогда. Это и есть защита для серверов: A-запись сервера, который зарегистрировался сам, динамическая, и если сервер выключить на месяц, запись исчезнет. Записи важных серверов стоит делать статическими — создать руками Add-DnsServerResourceRecordA -ZoneName corp.example.com -Name srv1 -IPv4Address 192.168.1.20 (без -AgeRecord запись создаётся без метки) или в свойствах записи в оснастке снять флажок «Delete this record when it becomes stale». SRV-записям контроллеров очистка не угрожает: Netlogon обновляет их каждый час.
Внутренние копии публичных имён
Домен назван corp.example.com, а сайт компании — www.example.com, и внутри сети он должен открываться по внутреннему адресу, минуя NAT. Два способа.
Зона на одно имя (pinpoint zone): создать основную зону www.example.com с единственной A-записью в вершине. Запросы про www.example.com сервер ответит сам, а про все остальные имена в example.com по-прежнему отправит форвардерам:
PS C:\> Add-DnsServerPrimaryZone -Name www.example.com -ReplicationScope Forest -DynamicUpdate None
PS C:\> Add-DnsServerResourceRecordA -ZoneName www.example.com -Name '@' -IPv4Address 192.168.1.80
Это лучший вариант, когда внутренних исключений несколько: ни одна запись публичной зоны не дублируется, и регистратор остаётся единственным местом, где её редактируют.
Полная внутренняя копия example.com: основная зона с тем же именем, что у публичной, и всеми записями, которые нужны изнутри. Обязателен, если имя домена AD совпадает с публичным (example.com вместо corp.example.com: контроллеры регистрируют A-записи самого имени домена, и зону всё равно придётся держать), и терпим, когда внутренняя версия сайта должна отличаться от внешней целиком. Цена — каждую новую публичную запись (mail, autodiscover, _dmarc) нужно заводить дважды, и половина загадочных «изнутри не работает, снаружи работает» происходит из-за записи, которую забыли продублировать.
Третий способ, с Windows Server 2016, — политики DNS: одна зона, но разные ответы разным клиентам по подсети, интерфейсу или времени суток (Add-DnsServerQueryResolutionPolicy). Это уже для случаев, когда зоной владеет этот же сервер.
Настройки сервера
Несколько параметров, которые стоит проверить один раз:
Интерфейсы. По умолчанию сервер слушает на всех адресах, включая те, что появятся позже. Если у контроллера несколько адаптеров, стоит ограничить: dnscmd /ResetListenAddresses 192.168.1.10 (у Set-DnsServerSetting этот параметр тоже есть — ListeningIPAddress).
Зонные передачи. У зон в каталоге они по умолчанию запрещены (SecureSecondaries = NoTransfer), и включать их нужно только ради сервера вне домена: Set-DnsServerPrimaryZone -Name corp.example.com -SecureSecondaries TransferToSecureServers -SecondaryServers 192.168.1.53.
Рекурсия. Включена, и у контроллера, обслуживающего клиентов, должна быть включена. Отключают её на серверах, которые только отдают свои зоны в интернет; контроллер в интернет отдавать ничего не должен.
Global Query Block List — список имён, на которые сервер не отвечает, даже если запись есть: wpad и isatap. Защита от того, чтобы любой пользователь, зарегистрировав wpad, не стал прокси для всей сети. Проверить: Get-DnsServerGlobalQueryBlockList.
Кеш. Get-DnsServerCache показывает настройки, включая LockingPercent (100: кешированная запись не перезаписывается ответом до истечения TTL — защита от отравления) и MaxTtl. Содержимое — Show-DnsServerCache, сброс — Clear-DnsServerCache. Не путать с кешем DNS-клиента на той же машине (Get-DnsClientCache, Clear-DnsClientCache): это два разных кеша.
Права. Группа DnsAdmins управляет DNS-сервером, не будучи администраторами домена, и это право сильнее, чем кажется: администратор DNS может подгрузить в службу свою библиотеку, а служба работает с правами SYSTEM на контроллере. Членство в DnsAdmins — то же, что в Domain Admins.
DNSSEC. Сервер умеет подписывать зоны (Invoke-DnsServerZoneSign) и проверять подписи при рекурсии; зона TrustAnchors из первой таблицы хранит доверенные ключи. Для внутреннего домена подпись обычно не нужна, а проверка подписей при рекурсии включена по умолчанию и требует только корневого ключа, который в TrustAnchors уже есть.
Смотрим руками
Записи зоны целиком, с метками и типами:
PS C:\> Get-DnsServerResourceRecord -ZoneName corp.example.com | Where-Object HostName -notlike '_*' |
Format-Table HostName, RecordType, Timestamp, TimeToLive, @{n='Data'; e={ ($_.RecordData.IPv4Address, $_.RecordData.NameServer, $_.RecordData.PrimaryServer) -ne $null | Select-Object -First 1 }} -AutoSize
HostName RecordType Timestamp TimeToLive Data
-------- ---------- --------- ---------- ----
@ A 15.10.2026 9:00:00 00:10:00 192.168.1.10
@ NS 01:00:00 dc1.corp.example.com.
@ SOA 01:00:00 dc1.corp.example.com.
dc1 A 00:20:00 192.168.1.10
DomainDnsZones A 15.10.2026 9:00:00 00:10:00 192.168.1.10
ForestDnsZones A 15.10.2026 9:00:00 00:10:00 192.168.1.10
srv1 A 15.10.2026 8:00:00 00:20:00 192.168.1.20
ws1 A 15.10.2026 9:00:00 00:20:00 192.168.1.100
У @, DomainDnsZones и ForestDnsZones есть метки — их регистрирует Netlogon динамически; у dc1 нет — собственную A-запись мастер повышения создал статической. Запись @ с адресом контроллера — та самая, из-за которой имя домена AD не должно совпадать с сайтом.
Безопасное обновление в пакетах. Снимаем pktmon с фильтром на порт 53 во время Register-DnsClient на ws1:
No. Source Destination Protocol Info
1 192.168.1.100 192.168.1.10 DNS Standard query SOA corp.example.com
2 192.168.1.10 192.168.1.100 DNS Standard query response SOA dc1.corp.example.com
3 192.168.1.100 192.168.1.10 DNS Dynamic update 0x1a2b SOA corp.example.com A ws1.corp.example.com
4 192.168.1.10 192.168.1.100 DNS Dynamic update response 0x1a2b Refused
5 192.168.1.100 192.168.1.10 DNS Standard query TKEY 1234-ms-7.1-abcd.corp.example.com
6 192.168.1.10 192.168.1.100 DNS Standard query response TKEY
7 192.168.1.100 192.168.1.10 DNS Dynamic update 0x1a2c SOA corp.example.com A ws1.corp.example.com TSIG
8 192.168.1.10 192.168.1.100 DNS Dynamic update response 0x1a2c TSIG
Пять шагов из схемы выше. В пакете 5, в записи TKEY, внутри поля Key Data лежит AP-REQ Kerberos с билетом на DNS/dc1.corp.example.com; в пакете 7 — TSIG-подпись алгоритмом gss-tsig. TGS-REQ за билетом в этом захвате нет: он прошёл по порту 88 и в фильтр не попал.
Журнал сервера — DNS Server в Event Viewer, или:
PS C:\> Get-WinEvent -LogName 'DNS Server' -MaxEvents 5 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
События, по которым опознают проблемы:
| Id | Что |
|---|---|
| 2 | служба DNS запущена |
| 4013 | при старте DNS ждёт, пока каталог сообщит о завершении начальной синхронизации; зоны из каталога пока не загружены. Классический след контроллера, у которого DNS-клиент указывает только на себя: каталогу для репликации нужен DNS, DNS ждёт каталог, и так до таймаута. Как это лечится — в части про второй контроллер |
| 4015 | ошибка обращения к каталогу: зона в разделе недоступна |
| 4000 | сервер не смог открыть каталог: обычно он не нашёл контроллер, то есть опять DNS-клиент |
| 7062 | сервер пересылает запрос самому себе: в форвардерах или NS-записях указан его собственный адрес |
| 6527 | зона истекла (для secondary: не удалось получить копию дольше expire из SOA) |
И статистика, по которой видно, чем сервер занят:
PS C:\> (Get-DnsServerStatistics).QueryStatistics | Select-Object TotalQueries, UdpQueries, TcpQueries, Recursions
TotalQueries UdpQueries TcpQueries Recursions
------------ ---------- ---------- ----------
184233 183904 329 61217
Треть запросов ушла в рекурсию: столько раз клиенты спрашивали про имена вне зон сервера, и столько раз он ходил к форвардерам или в кеш. Если эта доля внезапно растёт — кто-то в сети спрашивает много несуществующих имён, и Set-DnsServerDiagnostics -All $true с журналом в файл покажет, кто.
Имена разрешаются, и контроллер регистрирует их сам. Осталось раздать клиентам адреса, чтобы они вообще могли что-то спросить.
Дальше — часть 8: DHCPv4. Установка роли и авторизация сервера в каталоге, области, опции и резервирования, отказоустойчивость через failover в двух режимах, учётная запись для динамических обновлений DNS от имени клиентов и группа DnsUpdateProxy, и как DHCP-запросы доходят до сервера из другой подсети.
Оставить комментарий могут только зарегистрированные пользователи.
Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.