Event ID 4011 DNS Server: Серверу DNS не удалось обновить AD
Архитектура интегрированных зон (AD-Integrated DNS)
Событие 4011 логируется в журнале DNS Server. Сообщение: «Серверу DNS не удалось обновить доменные службы Active Directory для зоны [Имя_Зоны]. Ошибка: Отказано в доступе (Access Denied)». Симптомы: новые компьютеры, подключенные к сети, не появляются в DNS, либо их старые IP-адреса не обновляются. Это ломает работу сетевых принтеров, файловых серверов и политик GPO.
Суть конфликта (Secure Dynamic Updates)
Для защиты от спуфинга (когда хакер подменяет IP-адрес сервера 1С на свой), зоны DNS в Active Directory работают в режиме «Только безопасные обновления» (Secure Only). Это значит, что если ПК-01 создал свою A-запись в DNS, он становится её Владельцем (Owner). Никто другой (ни ПК-02, ни DHCP-сервер) не имеет права изменить IP-адрес для ПК-01 в этой записи. Ядро AD блокирует попытку перезаписи и выдает событие 4011.
Пошаговое дерево решений (Разрешения DHCP и DNS)
Сценарий 1: Конфликт DHCP-сервера (Самая частая причина)
Если в сети работает DHCP-сервер Windows, он берет на себя обязанность обновлять DNS-записи за клиентов. Если старый DHCP-сервер был заменен на новый, новый сервер не имеет прав (ACL) на изменение записей, созданных старым сервером.
- Решение (Группа DnsUpdateProxy): Откройте Active Directory Users and Computers (dsa.msc).
- Перейдите в папку Users. Найдите группу DnsUpdateProxy.
- Добавьте учетную запись вашего нового DHCP-сервера (например,
DHCP01$) в эту группу. - Перезапустите службу DHCP Server. Теперь записи, созданные DHCP, не будут иметь жесткого владельца, и любой член этой группы сможет их обновлять.
Сценарий 2: Статические записи и 'Рукопашные' админы
Если администратор вручную создал A-запись (например, для сервера SRV-SQL), а потом сервер настроили на получение IP по DHCP (или он переехал в другой VLAN), сам сервер не сможет обновить свою запись, так как владельцем является учетка Администратора.
- Решение: Откройте консоль DNS (
dnsmgmt.msc). Удалите старую 'ручную' A-запись. На сервереSRV-SQLоткройте CMD от имени админа и выполнитеipconfig /registerdns. Сервер сам создаст динамическую запись и станет её полноправным владельцем.
Сценарий 3: Деградация репликации AD
Поскольку зоны интегрированы в AD, DNS-сервер хранит записи как объекты LDAP. Если на контроллере домена нарушена репликация (>события 2042 или 8606), база NTDS.dit блокируется, и локальная служба DNS теряет право на запись. Почините репликацию (repadmin /showrepl).
Типовые ошибки администраторов
- Включение 'Небезопасных обновлений': Столкнувшись с 4011, сисадмины часто меняют в свойствах зоны DNS 'Динамические обновления' на «Небезопасные и безопасные» (Nonsecure and secure). Это чудовищная дыра в безопасности. Любой смартфон с Wi-Fi или вирус в сети сможет перезаписать A-запись контроллера домена и пустить весь трафик компании через себя (MITM-атака).
Тонкая настройка связки DHCP + DNS + Active Directory требует понимания архитектуры GSS-TSIG. Делегируйте обслуживание инфраструктуры ИТ-инженерам ITSTM: мы настроим группы DnsUpdateProxy, включим правильную очистку устаревших записей (Scavenging), заблокируем небезопасные обновления и обеспечим идеальный порядок в сети.
Частые вопросы (FAQ)
Почему 4011 появляется при миграции с Linux DHCP (ISC DHCP)?
По умолчанию Linux DHCP-серверы обновляют Windows DNS без использования GSS-TSIG (Керберос-авторизации), если не настроены ключи. Windows DNS в режиме 'Secure Only' жестко отбрасывает такие неавторизованные запросы, генерируя 4011. Настройте интеграцию ключей или GSS-TSIG.
Поможет ли Scavenging (Очистка старых записей)?
Да! Если старая запись 'висит' в DNS годами и не дает новому ПК с таким же именем занять её, включение Scavenging автоматически удалит старую запись (например, через 14 дней простоя), освободив имя для нового клиента.
Почему 4011 спамит для имени самого Контроллера Домена (DC01)?
Проверьте сетевой адаптер DC. Если в настройках IPv4 в качестве 'Первичного DNS' указан внешний IP (8.8.8.8) или роутер — контроллер попытается зарегистрировать свои служебные SRV-записи там, получит отказ и выдаст 4011. DC должен смотреть только на себя (127.0.0.1) или на соседа-DC.
Связан ли 4011 с обратной зоной (Reverse Lookup)?
Очень часто. DHCP сервер пытается обновить PTR-запись (IP в Имя) в Обратной зоне, но администратор забыл эту зону создать в оснастке DNS. DHCP получает отказ 'Зона не найдена'.
Как проверить, кто является владельцем DNS записи?
В консоли DNS (dnsmgmt.msc) включите 'Вид -> Дополнительные параметры' (Advanced). Откройте свойства A-записи -> вкладка 'Безопасность' -> 'Дополнительно'. Поле 'Владелец' (Owner) покажет УЗ, которая создала запись.