Что такое Microsoft DNS

Обновлено: 20.11.2024

Примечание. На эту функцию распространяются условия Предложений Pre-GA Особых условий службы Chronicle. Функции до GA могут иметь ограниченную поддержку, а изменения в функциях до GA могут быть несовместимы с другими версиями до GA. Дополнительную информацию см. в Руководстве службы технической поддержки Chronicle и Особых условиях службы Chronicle.

Описывает архитектуру развертывания и шаги установки, а также любую необходимую конфигурацию, которая создает журналы, поддерживаемые синтаксическим анализатором хроник для событий DNS Microsoft Windows. Общие сведения о загрузке данных Chronicle см. в разделе Загрузка данных в Chronicle.
Включает информацию о том, как синтаксический анализатор сопоставляет поля исходного журнала с полями унифицированной модели данных Chronicle.

Информация в этом документе относится к синтаксическому анализатору с меткой приема WINDOWS_DNS. Метка приема указывает, какой синтаксический анализатор нормализует необработанные данные журнала в структурированный формат UDM.

Прежде чем начать

Просмотрите рекомендуемую архитектуру развертывания.

На следующей диаграмме показаны рекомендуемые основные компоненты архитектуры развертывания для сбора и отправки DNS-событий Microsoft Windows в Chronicle. Сравните эту информацию с вашей средой, чтобы убедиться, что эти компоненты установлены. Каждое развертывание клиента будет отличаться от этого представления и может быть более сложным. Требуется следующее:

DNS-сервер Microsoft Windows с включенным ведением журнала диагностики DNS.
Все системы настроены на часовой пояс UTC.
NXLog устанавливается на кластерных серверах Microsoft Windows для сбора и пересылки журналов на центральный сервер Microsoft Windows или Linux.
Пересылка хроники, установленная на центральном сервере Microsoft Windows или Linux.

Просмотрите поддерживаемые устройства и версии.

Синтаксический анализатор Chronicle поддерживает журналы следующих версий Microsoft Windows Server. Microsoft Windows Server выпускается в следующих редакциях: Foundation, Essentials, Standard и Datacenter. Схема событий журналов, созданных каждой редакцией, не отличается.

Microsoft Windows Server 2019
Майкрософт Windows Server 2016
Майкрософт Windows Server 2012 R2

Синтаксический анализатор хроник поддерживает журналы, собранные NXLog Community или Enterprise edition.

Просмотрите поддерживаемые типы журналов. Анализатор Chronicle поддерживает следующие типы журналов, генерируемых DNS-серверами Microsoft Windows. Дополнительные сведения об этих типах журналов см. в документации по ведению журналов и диагностике DNS Microsoft Windows. Он поддерживает журналы, созданные с текстом на английском языке, и не поддерживает журналы, созданные на языках, отличных от английского.

Журналы аудита. Описание этого типа журнала см. в документации по журналам аудита Microsoft Windows.
Журналы аналитики. Описание этого типа журнала см. в документации по журналам Microsoft Windows Analytics.

Настройте DNS-серверы Microsoft Windows. Сведения об установке и включении ведения журнала диагностики DNS см. в документации Microsoft Windows.

Установите и настройте центральный сервер Windows или Linux.

Настройте все системы с часовым поясом UTC.

Настройка пересылки NXLog и Chronicle

Установите NXLog на каждый DNS-сервер Microsoft Windows. Следуйте документации NXLog.

Создайте файл конфигурации для каждого экземпляра NXLog. Используйте модуль ввода im_etw для извлечения аналитических журналов DNS и модуль ввода im_msvistalog для журналов аудита.

Дополнительную информацию о модуле ввода im_etw см. в разделе Трассировка событий для Microsoft Windows (im_etw), включая информацию о настройке NXLog для Microsoft Windows DNS.
Дополнительные сведения о модуле ввода im_msvistalog см. в разделе Журнал событий для Microsoft Windows 2008/Vista и более поздних версий (im_msvistalog).

Вот пример конфигурации NXLog. Заменить и

значения с информацией о центральном сервере Microsoft Windows или Linux. Чтобы дополнительно конвертировать и анализировать журналы в JSON, а не в XML, измените строку Exec на_xml(); для выполнения to_json(); . Дополнительные сведения см. в документации NXLog о модуле om_tcp.

Установите сервер пересылки Chronicle на центральный сервер Microsoft Windows или Linux. Информацию об установке и настройке сервера пересылки см. в разделах Установка и настройка сервера пересылки в Linux или Установка и настройка сервера пересылки в Microsoft Windows.

Настройте сервер пересылки Chronicle для отправки журналов в Chronicle. Вот пример конфигурации сервера пересылки.

Справочник по сопоставлению полей: поля событий устройства в поля UDM

В следующем разделе описывается, как синтаксический анализатор сопоставляет поля событий Microsoft Windows DNS с полями событий унифицированной модели данных Chronicle (UDM).

Общие поля

Поле NXLog	Поле UDM	Комментарий
SourceName	metadata.vendor_name = "Microsoft"

Аналитические журналы

< td>target.port / main.port< td>QTYPE

Исходное поле журнала	Поле UDM	Комментарий
AA	network.dns.authoritative
Назначение	target.ip / Principal.ip	Заполнено как в основном, так и в целевом.
InterfaceIP	target.ip / Principal.ip	Сохраняет IP-адрес DNS-сервера в целевом. ip для следующих идентификаторов событий: 256, 259, 261, 263, 266, 268, 270, 272, 273, 275, 278, 279, 280. Хранится в файле primary.ip для всех других идентификаторов событий (ответ DNS) .
Пакетные данные	network.dns.answers.binary_data
Порт
QNAME	network.dns.questions.name
network.dns.questions.type
RCODE	network.dns.response_code
RD	network.dns.recursion_desired
Причина	security_result.summary
Источник	principal.ip / target.ip	Исходный адрес IPv4/IPv6 машины, которая инициировала DNS-запрос. Хранится в target.ip для событий с идентификатором 274. Хранится в target.ip для событий с идентификаторами 265 и 269, . InterfaceIP содержит IP-адрес вторичного сервера (основной), а Source (целевой) — это IP-адрес основного сервера.
TCP	network.ip_protocol
XID	network.dns.id

Журналы аудита

Справочник по сопоставлению полей: идентификатор события для типа события UDM

В следующем разделе описывается, как синтаксический анализатор сопоставляет идентификаторы событий с типами событий Chronicle UDM. Как правило, события сопоставляются с метаданными NETWORK_DNS.event_type, за исключением идентификаторов событий в следующем разделе.

Данные для зоны %1 были перезагружены из %2.

Идентификатор события	Текст события	Тип события UDM	Примечания
275	XFR_NOTIFY_ACK_IN: Source=%1; ИнтерфейсIP=%2; PacketData=%4	GENERIC_EVENT
276	IXFR_RESP_OUT: TCP=%1; ИнтерфейсIP=%2; Место назначения=%3; QNAME=%4; XID=%5; ZoneScope=%6; Зона=%7; RCODE=%8; PacketData=%10	GENERIC_EVENT
512	SETTING_CREATION
513	Зона %1 удалена.	SETTING_DELETION
514	Зона %1 обновлена . Для параметра %2 установлено значение %3.	SETTING_MODIFICATION
515	Запись ресурса типа %1, имя %2, TTL %3 и RDATA %5 были созданы в области %7 зоны %6.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
516	Запись ресурса типа %1, имя %2 и RDATA %5 удалены из области %7 зоны %6.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
517	Все записи ресурсов типа %1, имя %2 были удалены из области %4 зоны %3.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
518	Все записи ресурсов на узле с именем %1 были удалены из области %3 зоны %2.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
519	Запись ресурса типа %1, имя %2, TTL %3 и RDATA %5 создана в области %7 зоны %6 посредством динамического обновления с IP-адреса %8.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
520	Запись ресурса типа %1, имя %2 и RDATA %5 удалена из sc открыть %7 зоны %6 посредством динамического обновления с IP-адреса %8.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
521	Запись ресурса тип %1, имя %2, TTL %3 и RDATA %5 удалены из области %7 зоны %6.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
522< /td>	Область %1 была создана в зоне %2.	SETTING_CREATION
523	Область % 1 был удален в зоне %2.	SETTING_DELETION
525	Зона %1 была подписана со следующими свойствами: DenialOfExistence= %2; Распределить ТрастАнчор=%3; DnsKeyRecordSetTtl=%4; DSRecordGenerationAlgorithm=%5; DSRecordSetTtl=%6; EnableRfc5011KeyRollover=%7; ИсКейМастерСервер=%8; KeyMasterServer=%9; NSec3HashAlgorithm=%10; NSec3Iterations=%11; NSec3OptOut=%12; NSec3RandomSaltLength=%13; NSec3UserSalt=%14; ParentHasSecureDelegation=%15; Время распространения=%16; SecureDelegationPollingPeriod=%17; SignatureInceptionOffset=%18.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
526	Зона %1 не была подписана.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
527	Зона %1 была повторно подписана со следующими свойствами: DenialOfExistence=%2; Распределить ТрастАнчор=%3; DnsKeyRecordSetTtl=%4; DSRecordGenerationAlgorithm=%5; DSRecordSetTtl=%6; EnableRfc5011KeyRollover=%7; ИсКейМастерСервер=%8; KeyMasterServer=%9; NSec3HashAlgorithm=%10; NSec3Iterations=%11; NSec3OptOut=%12; NSec3RandomSaltLength=%13; NSec3UserSalt=%14; ParentHasSecureDelegation=%15; Время распространения=%16; SecureDelegationPollingPeriod=%17; SignatureInceptionOffset=%18.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
528	Роновер запущен для типа %1 с GUID %2 зоны % 3.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
529	Выполнен переход на тип %1 с GUID %2 зоны %3.< /td>	SYSTEM_AUDIT_LOG_UNCATEGORIZED
530	Тип %1 с GUID %2 зоны %3 помечен для удаления. Ключ будет удален после завершения обновления.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
531	Ручное обновление было запущено для типа %1 с GUID %2 зоны %3.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
533	Ключ подписи ключей с GUID %1 в зоне %2 который ожидал обновления лица, подписывающего делегирование (DS), был вынужден перейти к завершению переноса.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
534	Метаданные настройки DNSSEC были экспортированы метаданные %1 ключа подписи ключа из зоны %2.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
535	DNSSEC метаданные настроек были импортированы в зону %1.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
536	Запись типа %1, QNAME %2 была удален из области %3 в кеше.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
537	Список серверов пересылки в области %2 был сброшен на % 1.	SETTING_MODIFICATION	target.resource.name имеет значение «Список серверов пересылки в области видимости: %»
540	Корневые подсказки были изменены.	SETTING_MODIFICATION	target.resource.name, заполненный текстом «Корневые подсказки»
541	Настройка %1 на область %2 была установлена на %3.	SETTING_MODIFICATION
542	Область %1 DNS-сервера была создана.	SETTING_CREATION
543	Область %1 DNS-сервера была удалена.	SETTING_DELETION
544	Ключ DNSKEY с протоколом ключа %2, данными Base64 %4 и алгоритмом шифрования %5 добавлен в точку доверия %1.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
545	DS с ключевым тегом: %2, тип дайджеста: %3, дайджест: %5 и алгоритм шифрования: %6 добавлен в точку доверия %1.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
546	Точка доверия в %1 типа %2 удален.	SYSTEM_AUDIT _LOG_UNCATEGORIZED
547	Добавлен якорь доверия для корневой зоны.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
548	Получен запрос на перезапуск службы DNS-сервера.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
549< /td>	Журналы отладки удалены с %1 на DNS-сервере.	SYSTEM_AUDIT_LOG_WIPE
550	содержимое в памяти всех зон на DNS-сервере было сброшено в соответствующие файлы.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
551	Все статистические данные для DNS-сервера очищены.	SYSTEM_AUDIT_LOG_WIPE
552	Цикл очистки записей ресурсов запущен DNS-сервер.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
553	%1	SYSTEM_AUDIT_LOG_UNCATEGORIZED
554	Цикл очистки записей ресурсов был прерван o n DNS-сервер.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
555	DNS-сервер подготовлен к понижению путем удаления ссылок на него со всех зоны, хранящиеся в Active Directory.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
556	Записана информация о корневых хинтах на DNS-сервере обратно в постоянное хранилище.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
557	Адреса, которые DNS-сервер будет прослушивать, изменены на %1 .	SETTING_MODIFICATION	target.resource.name, заполненный текстом «Адреса прослушивания»
558	Для всех точек доверия запланировано немедленное активное обновление RFC 5011.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
559	Зона %1 приостановлена .	SYSTEM_AUDIT_LOG_UNCATEGORIZED
560	Работа зоны %1 возобновлена.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
561	SYSTEM_AUDIT_LOG_UNCATEGORIZED
562	Данные для зоны %1 обновлены с главного сервера %2.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
563	Срок действия дополнительной зоны %1 истек, и с главного сервера %2 запрошены новые данные.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
564	Зона %1 была повторно загружена из Active Directory.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
565	Содержимое зоны %1 записано на диск, и уведомление отправлено на все серверы уведомлений.	SETTING_MODIFICATION
566	Все записи DNS на узле %1 в зоне %2 будут иметь отметку времени устаревания, установленную на текущее время.% 3	SYSTEM_AUDIT_LOG_UNCATEGORIZED
567	Зона %1, интегрированная в Active Directory, обновлена. Только %2 может выполнять очистку.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
568	Главной ролью для зоны %1 была %2. %3	SYSTEM_AUDIT_LOG_UNCATEGORIZED
569	В зону %3 добавлен дескриптор %1 поющего ключа (%2) со следующими свойствами: KeyId=%4; Тип Ключа=%5; Текущее Состояние=%6; KeyStorageProvider=%7; StoreKeysInAD=%8; КриптоАлгоритм=%9; длина ключа=%10; DnsKeySignatureValidityPeriod=%11; DSSignatureValidityPeriod=%12; ZoneSignatureValidityPeriod=%13; InitialRolloverOffset=%14; Период опрокидывания=%15; RolloverType=%16; NextRolloverAction=%17; LastRolloverTime=%18; NextRolloverTime=%19; CurrentRolloverStatus=%20; АктивКей=%21; Ключ ожидания=%22; СледующийКлюч=%23. Зона будет списана с %2, сгенерированным с этими свойствами.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
570	Поющий ключ %1 ( %2) дескриптор с GUID %3 обновлен в зоне %4. Свойства этого дескриптора %2 были установлены на: KeyId=%5; Тип Ключа=%6; Текущее Состояние=%7; KeyStorageProvider=%8; StoreKeysInAD=%9; КриптоАлгоритм=%10; длина ключа=%11; DnsKeySignatureValidityPeriod=%12; DSSignatureValidityPeriod=%13; ZoneSignatureValidityPeriod=%14; InitialRolloverOffset=%15; Период опрокидывания=%16; RolloverType=%17; NextRolloverAction=%18; LastRolloverTime=%19; NextRolloverTime=%20; CurrentRolloverStatus=%21; АктивКей=%22; Ключ ожидания=%23; СледующийКлюч=%24. Зона будет списана с %2, сгенерированным с этими свойствами.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
571	Поющий ключ %1 ( %2) дескриптор %4 удален из зоны %3.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
572	Состояние % 1 ключ подписи (%2) %3 изменен в зоне %4. Новый активный ключ — %5, резервный ключ — %6, а следующий ключ — %7.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
573	Добавлено делегирование для %1 в области %2 зоны %3 с сервером имен %4.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
574	Запись подсети клиента с именем %1 и значением %2 добавлена в карту подсети клиента.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
575	Запись подсети клиента с именем %1 удалена из карты подсети клиента.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
576	Запись клиентской подсети с именем %1 была обновлена из карты клиентской подсети. Новые клиентские подсети, на которые он ссылается: %2.	SYSTEM_AUDIT_LOG_UNCATEGORIZED
577	Политика уровня сервера %6 для % 1 создан на сервере %2 со следующими свойствами: ProcessingOrder:%3; Критерии:%4; Действие:%5.	SETTING_CREATION
578	Политика уровня зоны %8 для %1 создана в зоне % 6 на сервере %2 со следующими свойствами: ProcessingOrder:%3; Критерии:%4; Действие:%5; Области:%7.	SETTING_CREATION
579	На сервере %2 создана политика переадресации %6 со следующими свойствами : ПроцессингОрдер:%3; Критерии:%4; Действие:%5; Область действия:%1.	SETTING_CREATION
580	Политика уровня сервера %1 удалена с сервера %2.< /td>	SETTING_DELETION
581	Политика уровня зоны %1 удалена из зоны %3 на сервере %2.	SETTING_DELETION
582	Политика переадресации %1 удалена с сервера %2.	SETTING_DELETION

История изменений

В следующем разделе перечислены изменения анализатора WINDOWS_DNS.

Дата	Описание
Декабрь 2021	Обновления картирования полей.
Февраль 2022 г.	Обновлена информация о том, как отображается поле «Политика» в журналах аудита.

Если не указано иное, содержимое этой страницы находится под лицензией Creative Commons Attribution 4.0, а образцы кода распространяются под лицензией Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

Этот шаблон монитора приложений SAM оценивает состояние и общую работоспособность служб, а также производительность DNS-сервера Microsoft.

Доступ WMI к целевому серверу.

Администратор Windows на целевом сервере.

Мониторы компонентов

Нажмите здесь, чтобы просмотреть обзор шаблонов мониторов приложений SAM и мониторов компонентов. Также доступны шаблоны SAM API Poller.

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

Сервис: DNS-сервер

Этот монитор компонента позволяет DNS-клиентам разрешать DNS-имена, отвечая на запросы DNS и динамические запросы на обновление DNS. Если эта служба остановлена или отключена, обновления DNS не будут выполняться, и любые службы, явно зависящие от нее, не запустятся.

Память: кэширование памяти

Этот монитор компонентов возвращает общий объем системной памяти, используемой службой DNS-сервера для кэширования.

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

Память: Память узла базы данных

Этот монитор компонента возвращает общий объем системной памяти, используемой службой DNS-сервера для узлов базы данных.

Память: память Nbstat

Этот монитор компонента возвращает общий объем системной памяти, используемой службой DNS-сервера для Nbtstat.

Память: Запись памяти потока

Этот монитор компонентов возвращает общий объем системной памяти, используемой службой DNS-сервера для потока записей.

Динамическое обновление: NoOperation/сек

Этот монитор компонентов возвращает среднее количество запросов динамического обновления «Нет операций»/«Пусто», полученных DNS-сервером в секунду.

Динамическое обновление: получено

Этот монитор компонентов возвращает общее количество запросов динамического обновления, полученных DNS-сервером.

Отслеживайте этот счетчик после включения динамических обновлений, чтобы определить, пытаются ли DNS-клиенты обновить свои DNS-адреса.

Динамическое обновление: отклонено

Этот монитор компонентов возвращает общее количество динамических обновлений, отклоненных DNS-сервером.

Отслеживайте этот счетчик и сравнивайте его значение с Dynamic Update: Received, чтобы определить, на скольких системах возникают проблемы с обновлением DNS-адресов.

Динамическое обновление: тайм-ауты

Этот монитор компонентов возвращает общее количество тайм-аутов динамического обновления DNS-сервера.

Динамическое обновление: запись в базу данных

Этот монитор компонентов возвращает общее количество динамических обновлений, записанных в базу данных DNS-сервером.

Отслеживайте этот счетчик и сравнивайте его значение с Dynamic Update: Received, чтобы определить, сколько систем успешно обновляют записи DNS.

Этот монитор компонентов возвращает среднее количество рекурсивных запросов, полученных DNS-сервером в секунду.

Рекурсивный: Ошибка запроса/сек

Этот монитор компонентов возвращает среднее количество неудачных рекурсивных запросов в секунду.

Этот монитор компонентов возвращает среднее количество тайм-аутов отправки рекурсивных запросов в секунду.

Безопасное обновление: сбой

Этот монитор компонента возвращает общее количество безопасных обновлений, которые не удалось выполнить на DNS-сервере.

Отслеживайте этот счетчик, чтобы определить, могут ли клиенты выполнять безопасные динамические обновления. Кроме того, сравните это значение с параметром «Безопасное обновление: получено», чтобы определить, сколько систем не могут выполнить безопасные обновления в DNS.

Безопасное обновление: получено

Этот монитор компонентов возвращает общее количество запросов на безопасное обновление, полученных DNS-сервером.

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

TCP: память сообщений

Этот монитор компонентов возвращает общий объем памяти сообщений TCP, используемый DNS-сервером.

TCP: получено запросов/сек

Этот монитор компонента возвращает среднее количество TCP-запросов, полученных DNS-сервером в секунду.

TCP: отправлено ответов/сек

Этот монитор компонента возвращает среднее количество ответов TCP, отправляемых DNS-сервером в секунду.

Всего полученных запросов/сек

Этот монитор компонента возвращает среднее количество запросов, полученных DNS-сервером в секунду.

Отслеживайте этот счетчик, чтобы создавать базовые показатели использования серверов в сетях с интенсивным трафиком.

Всего отправлено ответов/сек

Этот монитор компонента возвращает среднее количество ответов, отправляемых DNS-сервером в секунду.

UDP: память сообщений

Этот монитор компонента возвращает общий объем памяти сообщений UDP, используемой DNS-сервером.

UDP: получено запросов/сек

Этот монитор компонента возвращает среднее количество запросов UDP, полученных DNS-сервером в секунду.

UDP: отправлено ответов/сек

Этот монитор компонентов возвращает среднее количество ответов UDP, отправляемых DNS-сервером в секунду.

Перенос зоны: сбой

Этот монитор компонентов возвращает общее количество неудачных передач зоны главного DNS-сервера.

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

Перенос зоны: успешно

Этот монитор компонента возвращает общее количество успешных передач зоны главного DNS-сервера.

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

Мониторинг взаимодействия с пользователем DNS

Этот монитор компонентов проверяет способность DNS-сервера отвечать на запрос записи, сравнивает ответ на запрос со списком IP-адресов и измеряет время ответа. Монитор компонента проходит успешно, если ответ DNS соответствует ожидаемому IP-адресу.

Разработанный сетевыми и системными инженерами, которые знают, что нужно для управления современными динамичными ИТ-средами, SolarWinds тесно связан с ИТ-сообществом.

Результат? Эффективные, доступные и простые в использовании продукты для управления ИТ.

Перерос Microsoft DNS? BlueCat обладает всеми функциями, необходимыми для корпоративного DDI-решения. Более того, BlueCat предлагает проверенный процесс миграции, призванный свести к минимуму сбои в работе сети.

Общие проблемы при миграции Microsoft DNS

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

Однако неизбежно наступит время, когда стоимость бесплатного управления сетевой инфраструктурой станет слишком высокой. Организации масштабируются, стратегические инициативы усложняются, а рабочие нагрузки растут. И тогда начинают проявляться все недостатки инфраструктуры DNS-серверов Microsoft.

Вот некоторые признаки того, что вы переросли Microsoft DNS:

Таблицы IPAM с высокими ставками

Жонглирование электронными таблицами для управления IP-адресами громоздко и неэффективно.

Время простоя из-за ошибок

Изменения в DNS-записях «толстый палец» регулярно приводят к сбоям в работе сети.

Безумие конфигурации

Управление стеной исправлений и конфигураций в Microsoft DNS — это работа на полную ставку. Не говоря уже о том, что уязвимости Microsoft DNS могут создавать реальную угрозу безопасности.

Чрезмерная нагрузка на DNS

Ваша команда не справляется с важными инициативами, потому что застряла на обработке заявок на обслуживание.

Обновите Microsoft DNS сегодня

Наведите порядок в DNS с помощью централизованного автоматизированного решения

Решения BlueCat Adaptive DNS для DNS, DHCP и IPAM (DDI) создают прочную основу для вашей сетевой инфраструктуры. Адаптивный DNS устраняет большую рабочую нагрузку и системный риск, связанные с использованием Microsoft DNS в сложных глобальных сетях.

Единый источник правды

Поместите все свои данные DDI в единый репозиторий, чтобы исключить ошибки и повысить гибкость.

DNS-брандмауэр

Автоматизация DNS

Развернуть везде

Разместите DNS и DHCP там, где они вам нужны. Сделайте это с помощью устройств, виртуальных экземпляров (VMware, KVM, HyperV) и общедоступного облака (AWS, Azure, Google Cloud Platform).

Отчетность и аудит

Собирайте информацию о пользователях, DNS-серверах, развертываниях и активности RPZ для удобного аудита.

Простая миграция DNS

Очистите свои данные, чтобы ничего не осталось.

Подробные журналы трафика DNS

Видимость без агента на любом устройстве. Отслеживайте исходный IP-адрес, DNS-запросы и данные ответов DNS, авторитетный сервер имен, тип запроса и информацию о протоколе. Сделайте это как для внутренних, так и для внешних запросов DNS-клиентов.

Надежные API

Интегрируйте существующие системы с помощью REST API.

Повышайте эффективность SLA с помощью адаптивных приложений и подключаемых модулей

Соглашение об уровне обслуживания (SLA) устанавливает ожидания клиентов в отношении того, что они могут получить от поставщика услуг. В этой 30-секундной функции вы узнаете о трех надстройках, которые вы можете адаптировать для Adaptive DNS, чтобы превзойти эти ожидания. Улучшите прозрачность и выполнение ИТ-заявок на вашем предприятии с помощью подключаемых модулей, облачных ресурсов или интеграции BlueCat ServiceNow для предоставления полностью автоматических обновлений.

Общие проблемы при миграции Microsoft DNS

Мы поняли.Миграция вашей основной инфраструктуры по своей сути рискованна и представляет собой большое изменение в системе управления DNS, к которой вы, вероятно, привыкли. Вот некоторые темы, которые мы регулярно обсуждаем с клиентами, рассматривающими возможность перехода с Microsoft DNS на BlueCat.

А как насчет Active Directory?

BlueCat легко интегрируется с любой инфраструктурой Active Directory. Вопреки распространенному мнению, Active Directory может использовать любую службу DNS, включая BlueCat — для нее не требуется Microsoft DNS.

Можем ли мы обойтись наложением?

Так называемые "оверлейные" решения могут помочь в обеспечении видимости в процессе миграции. Но они не могут решить архитектурные проблемы, присущие Microsoft DNS. Только корпоративный подход к DNS может окончательно решить эти проблемы.

Как минимизировать риск миграции?

Любое изменение инфраструктуры сопряжено с неотъемлемым риском. Проверенный процесс миграции BlueCat очищает и рационализирует ваши данные DNS, обеспечивая плавный переход.

Как это будет работать в облаке?

Существует множество способов реализации DNS в облаке. BlueCat предлагает широкий спектр поддерживаемых платформ и архитектур.

Признаки системы, перегруженной Microsoft DNS

Каковы признаки того, что система перегружена проблемами Microsoft DNS? На этих диаграммах подробно описаны некоторые проблемы, с которыми сталкиваются клиенты, когда они могут быть готовы отказаться от Microsoft DNS.

Сервер доменных имен Microsoft (DNS) создает журналы аудита, которые определяют ресурсы вашей компании, подключенные к Интернету или вашей частной сети, и преобразовывают доменные имена в IP-адреса.

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

Вы можете настроить этот источник событий двумя способами:

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

Настроить с помощью учетной записи домена

Microsoft DNS будет записывать журналы аудита в определенную папку в вашей сети. Убедитесь, что эта папка доступна как общий сетевой ресурс и имеет учетные данные только для чтения.

Для сбора журналов аудита из Microsoft DNS необходимо:

Шаг 1. Соберите журналы DNS-сервера

Для сбора журналов сервера необходимо настроить целевую папку и файл журнала с возможностью ведения журнала. Rapid7 рекомендует, чтобы папка для ведения журнала DNS находилась на корневом (C) диске сервера, на котором размещена DNS. Например, C:\dnslogs

Чтобы разрешить сборщику InsightIDR включать журналы из DNS:

Перейдите к диспетчеру DNS-сервера и создайте папку для журналов DNS.

C:\dnslogs — рекомендуемый каталог для хранения журналов DNS.

Щелкните папку правой кнопкой мыши и выберите "Свойства" в раскрывающемся меню.
В окне "Свойства" выберите вкладку "Общий доступ" и нажмите кнопку "Расширенный общий доступ".

В окне «Расширенный общий доступ» установите флажок «Поделиться этой папкой» и нажмите кнопку «Разрешения».

В окне «Разрешения на общий доступ» нажмите кнопку «Добавить» и укажите учетные данные для доступа к этому файлу.

Запишите это имя пользователя и учетные данные для последующего использования при настройке DNS в InsightIDR.

Чтобы разрешить вход на DNS-сервер, щелкните правой кнопкой мыши свой DNS-сервер в диспетчере DNS и выберите параметр "Свойства" в раскрывающемся меню.

Выберите вкладку "Журнал отладки" и установите флажок "Журналировать пакеты для отладки". Для остальных флажков можно сохранить значения по умолчанию.

В разделе «Файл журнала» введите общий каталог, созданный на предыдущих шагах. Например, \\dns1.mycompany.cpm\dnslogs\dns.log
Нажмите кнопку "Применить", чтобы сохранить конфигурацию, а затем нажмите кнопку "ОК", чтобы завершить.

Шаг 2. Выберите метод сбора

После настройки журналов DNS на общем сетевом ресурсе вы можете собирать журналы аудита одним из двух способов с помощью InsightIDR:

Rapid7 рекомендует Watch Directory или NXLog

Мы рекомендуем собирать журналы с помощью метода Watch Directory или метода NXLog с чередованием файлов журнала вместо Tail File. Методы Watch Directory и NXLog более надежны в большинстве сред. При сборе журналов с помощью Tail File Microsoft DNS Server создает один файл. Когда этот файл достигает максимального настроенного размера, DNS-сервер очищает файл. Это может вызвать проблемы при чтении InsightIDR файла.

Смотреть каталог

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

Включить ротацию файлов журнала

Чтобы включить ротацию файлов журнала на вашем DNS-сервере:

Откройте командную строку PowerShell от имени администратора на DNS-сервере.
Выполните команду: Set-DNSServerDiagnostics -EnableLogFileRollover $true
Проверьте правильность настроек ведения журнала DNS с помощью команды: Get-DnsServerDiagnostics

Вместо одного файла dns.log в исходном местоположении вы увидите новый файл журнала DNS с отметкой времени, вставленной в имя.

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

Окончательная конфигурация должна выглядеть примерно так:

Включить удаление файла журнала (необязательно)

Вы также можете включить удаление старых журналов DNS, чтобы они не заполняли жесткий диск DNS-сервера. Эта команда должна быть настроена с запланированной задачей или заданием Cron для периодического запуска, поскольку это одна команда задачи, которая должна выполняться по расписанию. Следующая команда удалит в каталоге все, что старше двух дней: Get-ChildItem C:\locallogs\dnslogs | где LastWriteTime -lt ((Get-Date).AddDays(-2)) | Удалить элемент

Настройка DNS в InsightIDR

Чтобы собрать журналы аудита DNS с помощью метода сбора Watch Directory в InsightIDR:

На панели инструментов выберите Сбор данных в меню слева.
Когда появится страница "Сбор данных", щелкните раскрывающийся список "Настройка источника события" и выберите "Добавить источник события".
В разделе «Данные безопасности» щелкните значок DNS. Появится панель «Добавить источник события».
Выберите коллектор и Microsoft DNS в раскрывающемся списке. Вы также можете назвать источник события, если хотите.
Выберите часовой пояс, соответствующий расположению журналов источника событий.
При необходимости выберите отправку нефильтрованных журналов.
Выберите Watch Directory в качестве метода сбора.
Укажите путь к сетевой папке, которую вы настроили.
Введите интервал сканирования в секундах.
При необходимости укажите шаблон файла, за которым будет следить InsightIDR. Шаблон файла dns*.log должен быть достаточным, или вы можете оставить поле шаблона файла пустым для полной видимости.
Нажмите кнопку "Сохранить".

Конечный файл

Вы можете настроить InsightIDR для сбора журналов аудита DNS с помощью метода хвостового файла после завершения настройки на вашем DNS-сервере.

Для этого:

На панели инструментов выберите Сбор данных в меню слева.
Когда появится страница "Сбор данных", щелкните раскрывающийся список "Настройка источника события" и выберите "Добавить источник события".
В разделе «Данные безопасности» щелкните значок DNS. Появится панель «Добавить источник события».
Выберите коллектор и Microsoft DNS в раскрывающемся списке. Вы также можете назвать источник события, если хотите.
Выберите часовой пояс, соответствующий расположению журналов источника событий.
При необходимости выберите отправку нефильтрованных журналов.
Выберите Tail File в качестве метода сбора.
Укажите путь к сетевой папке, которую вы настроили с использованием нотации UNC, и включите имя файла хвоста, например \\dns1.mycompany.cpm\dnslogs\dns.log
Нажмите кнопку "Сохранить".

Настроить с помощью NXLog

Если вы не хотите создавать общую папку на DNS-сервере, вы можете собирать и отправлять журналы с помощью NXLog. Чтобы использовать NXLog, вы устанавливаете его на DNS-сервере. NXLog прочитает журналы DHCP и отправит их на ваш InsightIDR Collector с помощью Syslog. Чтобы настроить с помощью NXLog:

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