Адрес DHCP, TTL ответа DNS и aging DNS-записи — три разных времени. Их смешение приводит к двум противоположным проблемам: устаревшее имя долго указывает на чужой адрес или scavenging удаляет запись работающего устройства. Разберём Windows Server DHCP и AD-integrated DNS: кто обновляет A/PTR, когда запись получает timestamp, как определить кандидатов и безопасно проверить настройки. Примеры рассчитаны на лабораторную зону lab.corp.example, DHCP dhcp01.corp.example и DNS dc01.corp.example. Не запускайте очистку всей корпоративной зоны по одному отчёту.
В рабочей среде нужны делегированные права, RSAT DhcpServer/DnsServer, резервная копия конфигурации и проверенный способ восстановления AD-integrated DNS. Export-Clixml сохраняет отчёт, но не заменяет системный backup. Перед изменением проверьте репликацию и действующих владельцев DNS-записей.
1. Различить lease, TTL, timestamp и scavenging cycle
Lease — срок права клиента использовать IP. TTL — сколько resolver может кэшировать DNS-ответ. Timestamp — время, используемое сервером для aging. No-refresh уменьшает частоту обновления timestamp при неизменных данных; Refresh даёт окно для обновления. Период scavenging определяет, как часто сервер ищет просроченные записи.
Изменение TTL не запускает удаление записи на authoritative server. Истечение lease тоже не обязательно немедленно удаляет A/PTR: поведение зависит от DHCP DNS settings, клиента, владельца записи и доступности DNS. Вручную созданная static запись без aging timestamp обычно не удаляется scavenging. При этом устройство со статическим IP может регистрировать динамическую DNS-запись, которую aging затрагивает. Механика DNS aging.
2. Снять настройки до изменения
Все чтения привязаны к конкретному серверу. Сначала перечислите scopes и зоны: одинаковая настройка не обязательно подходит филиалу, Wi-Fi, серверным VM и удалённым ноутбукам.
Import-Module DhcpServer
Import-Module DnsServer
$dhcp = 'dhcp01.corp.example'
$dns = 'dc01.corp.example'
$zone = 'lab.corp.example'
$dir = 'C:\Admin\DnsReview'
New-Item -ItemType Directory -Path $dir -Force
Get-DhcpServerv4Scope -ComputerName $dhcp |
Select-Object ScopeId,Name,State,LeaseDuration |
Export-Csv "$dir\dhcp-scopes.csv" -NoTypeInformation -Encoding UTF8
Get-DnsServerZone -ComputerName $dns | Select-Object ZoneName,ZoneType,IsDsIntegrated,DynamicUpdate
Get-DnsServerZoneAging -ComputerName $dns -Name $zone | Export-Clixml "$dir\aging-before.xml"
Get-DnsServerScavenging -ComputerName $dns | Export-Clixml "$dir\scavenging-before.xml"
Get-DhcpServerv4DnsSetting -ComputerName $dhcp | Export-Clixml "$dir\dhcp-dns-before.xml"
Get-DhcpServerv4DnsSetting -ComputerName $dhcp -ScopeId 10.40.0.0ScopeId — адрес сети, не адрес DHCP-сервера. Проверьте effective настройки scope, server и policy, если политики используются. Get-DhcpServerv4DnsSetting. Зафиксируйте исключения и reservations: резервирование адреса не делает DNS-запись автоматически статической.
3. Понять обновление аренды T1 и T2
Если сервер не задал другие интервалы, T1 обычно составляет половину lease, T2 — 87,5%. На T1 клиент пытается продлить аренду у исходного сервера; на T2 начинается rebinding. Успешное продление сдвигает сроки. Это не означает, что DNS timestamp обязан меняться при каждом DHCP-пакете: no-refresh и модель регистрации имеют собственную логику.
Пример lease 8 суток без нестандартных T1/T2:
T1 около 4 суток
T2 около 7 суток
Окончание аренды около 8 суток, если продления не былоСпящий ноутбук, VPN-клиент или внешняя VM может не выполнять обычный сценарий офисного DHCP. Снимите фактические lease obtained/expires через ipconfig /all и события DHCP, а не рассчитывайте исключительно по defaults. RFC 2131, состояния и таймеры DHCP.
4. Проверить, кто регистрирует A и PTR
Windows-клиент и DHCP могут разделять регистрацию записей через согласование DNS updates. DHCP настраивается обновлять записи только по запросу или всегда, удалять их при завершении аренды и работать с клиентами, которые не запрашивают обновление. Настройки нужны по согласованной модели, а не «включить все флаги».
Для secure dynamic updates владелец и ACL записи определяют возможность её обновить. Если первый DHCP создал запись под своей учётной записью, второй сервер может не иметь доступа. Для отказоустойчивой пары применяется согласованная выделенная DNS-update учётная запись с минимальными правами и контролируемой сменой пароля. Не используйте Domain Admin как универсальное средство регистрации.
Проверьте настройки на обоих DHCP, журналы отказа регистрации и права конкретной проблемной записи через DNS Manager/AD tools. Name Protection и DHCID решают дополнительные вопросы владения именем; включение без анализа существующих клиентов может изменить поведение. Windows DHCP documentation.
5. Рассчитать время, когда запись станет кандидатом
При неизменном timestamp базовый срок stale определяется суммой No-refresh и Refresh. Реальное удаление зависит также от разрешения aging, серверного прохода, защиты зоны, репликации и успешной регистрации. Это не SLA точной минуты удаления.
timestamp записи: 1 октября, 10:00
No-refresh: 7 суток
Refresh: 7 суток
Базовый срок stale: 15 октября, 10:00
Удаление: на допустимом последующем проходе scavenging,
если timestamp не обновился и выполнены условия зоны/сервераВ документации Microsoft встречаются разные общие рекомендации по соотношению суммы интервалов и DHCP lease. В troubleshooting указано Refresh + No-refresh ≥ максимальной lease; в текущей странице настройки есть противоположная краткая формулировка. Поэтому не превращайте одно неравенство в автоматическое правило для всех сред. Наш безопасный учебный вариант 7+7 суток при lease 8 суток оставляет время для обычного обновления, но работоспособность подтверждается регистрацией и наблюдением. Для устройств с более длинным offline-периодом нужен отдельный проект, а не сокращение интервалов. Разбор проблем scavenging и страница настройки.
6. Получить отчёт кандидатов без удаления
Следующий код анализирует только A-записи выбранной зоны. Он не охватывает автоматически PTR, AAAA и другие типы. Статические и неизвестные timestamp не становятся кандидатами. Текущие настройки читаются с сервера: в отчёте нет захардкоженного «всё старше семи дней».
$aging = Get-DnsServerZoneAging -ComputerName $dns -Name $zone
$now = Get-Date
$records = Get-DnsServerResourceRecord -ComputerName $dns -ZoneName $zone -RRType A
$report = foreach ($r in $records) {
$dynamic = ($r.Timestamp -is [datetime]) -and ($r.Timestamp.Year -gt 1601)
$staleAfter = $null
if ($dynamic) {
$staleAfter = $r.Timestamp.Add($aging.NoRefreshInterval).Add($aging.RefreshInterval)
}
[pscustomobject]@{
HostName = $r.HostName
IP = $r.RecordData.IPv4Address.IPAddressToString
Timestamp = $r.Timestamp
TTL = $r.TimeToLive
HasDynamicTimestamp = $dynamic
StaleAfter = $staleAfter
Candidate = $dynamic -and ($now -gt $staleAfter)
}
}
$report | Export-Csv "$dir\a-records-review.csv" -NoTypeInformation -Encoding UTF8
$report | Where-Object Candidate | Format-Table -AutoSizeCandidate здесь означает расчётный срок, а не окончательное решение сервера об удалении. Сверьте каждый объект с DHCP lease, владельцем, инвентаризацией и другими DC. Ping не является достаточным критерием: хост может не отвечать на ICMP, но обслуживать приложение. Get-DnsServerResourceRecord.
7. Подготовить backup и включить aging только в пилоте
Для AD-integrated DNS нужна согласованная процедура резервного копирования AD/system state и восстановления, а также экспорт зоны для анализа. Export-DnsServerZone создаёт файл на DNS-сервере в каталоге DNS, а не на компьютере, где запущен PowerShell. Скопируйте его в защищённое хранилище через утверждённый способ и проверьте содержимое.
Export-DnsServerZone -ComputerName $dns -Name $zone -FileName 'lab-corp-example-before.dns'
# Только лабораторная зона после backup и проверки репликации
Set-DnsServerZoneAging -ComputerName $dns -Name $zone -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00 -WhatIf
Set-DnsServerZoneAging -ComputerName $dns -Name $zone -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00
Get-DnsServerZoneAging -ComputerName $dns -Name $zoneНе используйте массовое aging existing records без инвентаризации: критичные статические записи можно неожиданно включить в очистку. Наличие экспортированного text zone не означает проверенного восстановления AD ACL и всей истории владельцев. Set-DnsServerZoneAging.
8. Определить сервер очистки и проверить цикл
Выберите контролируемый scavenging server для зоны, учитывая доступность и репликацию. Изменение Set-DnsServerScavenging применяется к серверу и может затронуть другие зоны, где aging уже включён. Поэтому сначала инвентаризируйте весь сервер; безопасный пилот — отдельный стенд, а не произвольная новая зона на production DC.
# Только выделенный лабораторный DNS-сервер
Set-DnsServerScavenging -ComputerName $dns -ScavengingState $true -ScavengingInterval 1.00:00:00 -WhatIf
Set-DnsServerScavenging -ComputerName $dns -ScavengingState $true -ScavengingInterval 1.00:00:00
Get-DnsServerScavenging -ComputerName $dns
Get-WinEvent -ComputerName $dns -FilterHashtable @{
LogName='DNS Server'; Id=2501,2502; StartTime=(Get-Date).AddDays(-3)
} | Select-Object TimeCreated,Id,Message2501 сообщает о проходе с удалением, 2502 — о проходе без удалённых записей. Отсутствие событий требует проверки службы, zone eligibility и репликации. Кнопка ручного scavenging не делает static запись stale и не отменяет защиту зоны. Не используйте её как способ немедленно убрать любой «похожий на старый» объект. Set-DnsServerScavenging.
9. Проверить authoritative ответы, кэш и репликацию
Запрашивайте каждый DNS явно: обычный Resolve-DnsName может вернуть кэш и скрыть расхождение. Forward A и reverse PTR — отдельные записи и зоны. Неправильный PTR не исправляется только пересозданием A.
Resolve-DnsName lab-pc01.lab.corp.example -Type A -Server dc01.corp.example -DnsOnly
Resolve-DnsName lab-pc01.lab.corp.example -Type A -Server dc02.corp.example -DnsOnly
Resolve-DnsName 10.40.0.101 -Type PTR -Server dc01.corp.example -DnsOnly
repadmin /replsummary
repadmin /showreplПри расхождении проверьте загрузку зоны, directory partition и состояние AD replication. Очищение клиентского кэша влияет на один resolver, но не чинит серверную запись. Register-DnsClient в лабораторном клиенте запрашивает регистрацию, а результат подтверждается чтением timestamp и authoritative ответом. Не сокращайте aging, пока обновления не работают надёжно.
10. Выполнить приёмку и подготовить возврат
Пилот должен подтвердить: действующий клиент обновляет A/PTR, два DHCP могут обслуживать согласованную модель, static записи защищены, расчётный stale совпадает с наблюдением, очистка не удаляет действующий ресурс. Для долгого цикла нужен журнал наблюдения, а не обещание по одному скриншоту. Ускорять интервалы в production ради быстрого теста нельзя.
Возврат настроек зоны выполняется из сохранённых значений:
$old = Import-Clixml "$dir\aging-before.xml"
Set-DnsServerZoneAging -ComputerName $dns -Name $zone -Aging $old.AgingEnabled -NoRefreshInterval $old.NoRefreshInterval -RefreshInterval $old.RefreshInterval -WhatIf
# После проверки выполнить тот же вызов без -WhatIfСерверные scavenging settings восстановите по отдельному сохранённому состоянию и согласованному перечню зон. Выключение очистки не возвращает уже удалённые записи: нужна регистрация правильного владельца или проверенная процедура восстановления. Не восстанавливайте всей зоной поверх новых легитимных изменений без анализа. По завершении передайте lease policy, интервалы, DNS-update owner, server очистки, backup, исключения и контрольные события в сопровождение.
Нужно сопровождение Windows-инфраструктуры?
Управляемая поддержка включает учёт конфигурации, права, обновления, резервное копирование и контроль изменений.