wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Создать зону dns: Создание и управление DNS записями и зонами из PowerShell

alexxlab
No Comments

Содержание

Создание и управление DNS записями и зонами из PowerShell

Администратор DNS сервера на Windows для управления сервером, DNS зонами и записями может использовать старую добрую утилиту Dnscmd, или воспользоваться возможностями PowerShell модуля DNSServer. В этой статье мы рассмотрим основные операцию по массовому созданию, модификации и удалению различных DNS записей и зон с помощью PowerShell.

Модуль PowerShell — DNSServer

PowerShell модуль DNSServer входит в состав RSAT. В Windows 10 RSAT устаналивается отдельно, а в Windows Server вы можете установить модуль через Server Manager (Role Administration Tools -> Dns Server Tools).

Проверим, что в системе имеется модуль PoSh DNSServer:

Get-Module DNSServer –ListAvailable

Можно вывести список команд в нем (в версии модуля на Windows Server 2012 R2 доступно более 100 команд):

Get-Module DNSServer

Управление DNS зонами из PowerShell

Выведем список зон на DNS сервере (в нашем случае это контроллер домен):

Get-DnsServerZone –ComputerName dc01

Чтобы добавить новую первичную DNS зону с именем contoso. local, выполните команду:

Add-DnsServerPrimaryZone -Name contoso.local -ReplicationScope "Forest" –PassThru

Как вы видите, была создана первичная DNS зона, интегрированная в Active Directory (isDsIntegrated=True).

Можно создать зону обратного просмотра (Lockup Zone):

Add-DnsServerPrimaryZone -NetworkId "192.168.1.0/24" -ReplicationScope Domain

Чтобы синхронизировать новую зону с другими DC в домене, выполните команду:

Sync-DnsServerZone –passthru

Выведем список записей в новой DNS зоне (она пуста):

Get-DnsServerResourceRecord -ComputerName dc01 -ZoneName contoso.local

Для удаления зоны воспользуйтесь командой:

Remove-DnsServerZone -Name contoso.local -ComputerName dc01

Эта команда также удалит все существующие DNS записи в зоне.

Управление DNS записиями с помошью модуля DNSServer

Чтобы создать новую A запись в указнаной DNS зоне, воспользуемся командой:

Add-DnsServerResourceRecordA -Name rds1 -IPv4Address 192. 168.1.30 -ZoneName contoso.local -TimeToLive 01:00:00

Чтобы добавить PTR запись в обратной зоне, в предыдущей команде можно добавить параметр –CreatePtr или создать указатель вручную командлетом Add-DNSServerResourceRecordPTR:

Add-DNSServerResourceRecordPTR -ZoneName 1.168.192.in-addr.arpa -Name 30 -PTRDomainName rds1.contoso.local

Для добавления алиаса (CNAME) для определенной A записи, воспользуйтесь командой:

Add-DnsServerResourceRecordCName -ZoneName contoso.local -Name RDSFarm -HostNameAlias rds1.contoso.local

Чтобы изменить IP адрес данной A записи нужно воспользоваться довольно сложной схемой, т.к. вы не можете напрямую изменить IP адрес у DNS записи.

$NewADNS = get-DnsServerResourceRecord -Name rds1 -ZoneName contoso.local -ComputerName dc01
$OldADNS =get-DnsServerResourceRecord -Name rds1 -ZoneName contoso.local -ComputerName dc01

Теперь изменим свойство IPV4Address у объекта $NewADNS

$NewADNS. RecordData.IPv4Address = [System.Net.IPAddress]::parse('192.168.1.230')

Теперь изменим IP адрес A записи с помощью Set-DnsServerResourceRecord:

Set-DnsServerResourceRecord -NewInputObject $NewADNS -OldInputObject $OldADNS -ZoneName contoso.local -ComputerName dc01

Проверим, что IP адрес A записи изменился:

get-DnsServerResourceRecord -Name rds1 -ZoneName contoso.local

Можно вывести список DNS записей одного типа, указав тип в аргументе –RRType. Выведем список записей CNAME в зоне:

Get-DnsServerResourceRecord -ComputerName DC01 -ZoneName contoso.local -RRType CNAME

Также вы можете использовать фильтр по различным параметрам DNS записей с помощью Where-Object. Например, выведем список A записей, у которых в имени есть фраза rds.

Get-DnsServerResourceRecord -ZoneName contoso.local -RRType A | Where-Object HostName -like "*rds*"

Для удаления записей в DNS используется командлет Remove-DnsServerResourceRecord.

Например, для удаления CNAME записи, выполните:

Remove-DnsServerResourceRecord -ZoneName contoso.local -RRType CName -Name RDSFarm

Для удаления A записи:

Remove-DnsServerResourceRecord -ZoneName contoso.local -RRType A -Name rds1 –Force

Для удаления PTR записи в обратной зоне:

Remove-DnsServerResourceRecord -ZoneName “1.168.192.in-addr.arpa” -RRType “PTR” -Name “30”

Как добавить сразу несколько A / PTR записей в DNS зону с помощью PowerShell?

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

Создайте текстовый файл NewDnsRecords.txt ч именами и IP адресами, которые вы хотите завести. Формат файла такой:

HostName, IPAddress

Чтобы завести A записи в зоне contoso.local по данным из TXT/CSV файла, воспользуйтесь следующим скриптом PowerShell:

Import-CSV "C:\PS\NewDnsRecords. txt" | %{
Add-DNSServerResourceRecordA -ZoneName contoso.local -Name $_."HostName" -IPv4Address $_."IPAddress"
}

Если нужно сразу завести записи в обратной зоне, добавьте в команду Add-DNSServerResourceRecordA параметр –CreatePtr.

Теперь с помощью консоли DNS Manager (dnsmgmt.msc) или команнды Get-DnsServerResourceRecord -ZoneName contoso.local убедитесь, что все A записи успешно созданы.

Если нужно массово завести PTR записи в зоне обратного просмотра создайте текстовый/csv файл со следующей структурой

octet,hostName,zoneName
65,rds5.contoso.local,1.168.192.in-addr.arpa
66,rds6.contoso.local,1.168.192.in-addr.arpa
67,rds7.contoso.local,1.168.192.in-addr.arpa.

Затем запустите такой скрипт:

Import-CSV "C:\PS\NewDnsPTRRecords.txt" | %{
Add-DNSServerResourceRecordPTR -ZoneName $_."zoneName" -Name $_."octet" -PTRDomainName $_."hostName"
}

Убедитесь, что PTR записи появились в указанной Reverse зоне DNS.

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

Настройка DNS сервера производится в несколько этапов:

Установка DNS сервиса в систему¶

Поддержка DNS сервиса появилась в пакете calculate-server 2.1.4.
В качестве сервера используется наиболее распространенный DNS сервер BIND.

Перед установкой убедитесь что BIND скомпилирован с поддержкой sdb-ldap.

Перед установкой, убедитесь что у вас в системе установлен сервис ldap, если он не был установлен, выполните установку командой:

cl-setup ldap

Установка dns сервиса выполняется командой

cl-setup dns

Установка сервиса с установкой доверительных сетей:

cl-setup -a dns

Примечание: Интервал времени жизни DNS записи — ttl, составляет 178600 секунд.

Управление DNS сервисом¶

Термины:

  • DNS зона — сегмент пространства доменных имен.
  • master DNS зона — основная зона хранения записей.
  • slave DNS зона — подчиненная основной зона хранения записей.
  • Прямая DNS зона — зона хранения записей соответствия доменного имени ip адресу.
  • Обратная DNS зона — зона хранения записей соответствия ip адреса доменному имени.
  • Авторитативный сервер — сервер для хранения DNS зоны, записи которого считаются авторитетными для других DNS серверов.
  • SOA запись — запись описания зоны.
  • NS запись — доменное имя авторитативного сервера.
  • A запись — соответствие доменного имени ip адресу.
  • PTR запись — соответствие ip адреса доменному имени.
  • CNAME запись — соответствие одного доменного имени другому.
  • MX запись — соответствие доменного имени доменным именам почтовых серверов.

Создание DNS зоны¶

Для создания DNS зоны используется команда cl-dns-zoneadd.

Создание master DNS зоны

Cоздание зоны с авторитативным сервером в создаваемой зоне.

cl-dns-zoneadd -n <имя зоны> --server <имя авторитативного сервера> --ipserver <ip авторитативного сервера>

Cоздание зоны с авторитативным сервером в другой зоне.

cl-dns-zoneadd -n <имя зоны> --server <имя авторитативного сервера>

Примеры:

cl-dns-zoneadd -n test.ru --server test.ru --ipserver 10.0.0.34
  • Будет создана прямая зона test.ru
  • Если не существует, будет создана обратная зона 0.0.10.in-addr.arpa
  • Будет создана в записи зоны test.ru, A запись — test.ru соответствует 10.0.0.34
  • Будет создана в записи зоны test.ru NS запись — test.ru
  • Если обратная зона 0.0.10.in-addr.arpa была создана, для нее будет создана NS запись — test.ru
cl-dns-zoneadd -n test.ru --server ns.test.ru --ipserver 10.0.0.34
  • Будет создана прямая зона test.ru
  • Если не существует, будет создана обратная зона 0. 0.10.in-addr.arpa
  • Будет создана в зоне test.ru, A запись — ns.test.ru соответствует 10.0.0.34
  • Будет создана в записи зоны test.ru NS запись — ns.test.ru
  • Если обратная зона 0.0.10.in-addr.arpa была создана, для нее будет создана NS запись — test.ru
  • В обратной зоне 0.0.10.in-addr.arpa будет создана PTR запись — 10.0.0.34 соответствует ns.test.ru, если такая запись не существует.
cl-dns-zoneadd -n 10.0.10.0/24 --server test.ru

* Будет создана обратная зона для сети 10.0.10.0/24 — 10.0.10.in-addr.arpa
* Будет создана в записи зоны 10.0.10.in-addr.arpa NS запись — test.ru

Создание slave DNS зоны

Создание DNS зоны.

cl-dns-zoneadd -t slave -n <имя зоны> --servers <ip серверов хранения master зоны для этой зоны>

Примеры:

cl-dns-zoneadd -t slave -n slave.ru --servers 10.0.0.3,10.0.10.5
  • Будет создана подчиненная прямая зона slave.ru, данные для которой будут получены из основной зоны slave. ru находящейся на DNS серверах с адресами 10.0.0.3, 10.0.10.5
cl-dns-zoneadd -t slave -n 10.0.0.0/24 --servers 10.0.0.3

* Будет создана подчиненная обратная зона для сети 10.0.0.0/24 — 0.0.10.in-addr.arpa, данные для которой будут получены из основной зоны 0.0.10.in-addr.arpa находящейся на DNS сервере с адресом 10.0.0.3

Модификация DNS зоны¶

Для модификации DNS зоны используется команда cl-dns-zonemod.

Модификация параметров зоны возможна только для master зоны.

cl-dns-zonemod  -n <имя зоны или сеть> <параметры>

имя зоны — модификация прямой зоны

сеть — модификация обратной зоны

Параметры модификации зоны:

  • —server — изменение доменного имени главного авторитативного сервера зоны
  • —ip — изменение или добавление в случае отсутствия, ip адреса для зоны (модификация или добавление A записи)
  • —mx — замена или добавление в случае отсутствия, MX записей для зоны (модификация или добавление доменных имен почтовых серверов)
  • —mxmod — замена одного доменного имени почтового сервера на другой в MX записи для зоны (модификация доменного имени почтового сервера)
  • — email — изменение почтового адреса администратора зоны (по умолчанию root@имя_зоны)
  • —servers — изменение списка всех авторитативных серверов зоны (NS записи зоны)
  • —refresh — интервал времени после которого будет обновлена зона в секундах или число + (M — минуты, H — часы, D — дни, W — недели).
    По умолчанию 8H — 8 часов.
  • —update — интервал времени после неудачного обновления зоны после которого будет сделано новое обновление зоны.
    По умолчанию 2H — 2 часа.
  • —expiry — интервал времени после которого данные зоны устареют на вторичных DNS серверах в случае невозможности соединения с главным DNS сервером.
    По умолчанию 2W — 2 недели.
  • —minimum — интервал времени хранения данных неудачных запросов для этой зоны.
    По умолчанию 2H — 2 часа.

Примеры:

cl-dns-zonemod -n test.ru --email [email protected]

Модификация почтового адреса администратора зоны

cl-dns-zonemod -n test.ru --refresh 10H

Модификация интервала времени обновления зоны (10 часов)

Удаление DNS зоны¶

Для удаления DNS зоны используется команда cl-dns-zonedel.

cl-dns-zonedel -n <имя зоны или сеть>

имя зоны — удаление прямой зоны
сеть — удаление обратной зоны

Примеры:

cl-dns-zonedel -n test. ru

Будет удалена прямая зона test.ru

сl-dns-zonedel -n 10.0.0.0/24

Будет удалена обратная зона 0.0.10.in-addr.arpa

Удаление MX записей для зоны¶

Пример.

cl-dns-zonedel --mx -n test.ru

Будут удалены MX записи для зоны test.ru (доменные имена почтовых серверов для зоны)

Удаление A записи для зоны¶

Пример.

cl-dns-zonedel --ip -n test.ru

Будет удалена A запись для зоны test.ru (ip зоны)

Создание DNS записи¶

Для создания DNS записи используется команда cl-dns-recadd.

Для создания записи необходимо создание master зоны в которую будет добавлена эта запись.

Для A записи (host.test.ru —> 10.0.0.4 ) необходимо создание master прямой зоны test.ru.

Для PTR записи (10.0.0.4 —> host.test.ru) необходимо создание master обратной зоны 0.0.10.in-addr.arpa

Cоздание A записи

Примеры создания записей:

Создание A записи и PTR записи. Сначала должны быть созданы прямая и обратная зоны, test.ru и 0.0.10.in-addr.arpa.

cl-dns-recadd --host host.test.ru --ip 10.0.0.66
  • Будет создана запись в прямой зоне test.ru, host.test.ru соответствует 10.0.0.66.
  • Будет создана запись в обратной зоне 0.0.10.in-addr.arpa, 10.0.0.66 соответствует host.test.ru

Создание только A записи. Сначала должна быть создана прямая зона test.ru.

cl-dns-recadd --autoptr off --host host.test.ru --ip 10.0.0.66
  • Будет создана запись в прямой зоне test.ru, host.test.ru соответствует 10.0.0.66.
Создание A записи, MX записи и PTR записи

Пример создания A записи, MX записи и PTR записи. Сначала должны быть созданы прямая и обратная зоны, test.ru и 0.0.10.in-addr.arpa.

cl-dns-recadd --mx mail1.test.ru,mail2.test.ru --host host2.test.ru --ip 10.0.0.69
  • Будет создана запись в прямой зоне test.ru, host2.test.ru соответствует 10. 0.0.69.
  • Будет создана MX запись в прямой зоне test.ru, host2.test.ru соответствует двум почтовым серверам mail1.test.ru (приоритет 10), mail2.test.ru (приоритет 20)
  • Будет создана запись в обратной зоне 0.0.10.in-addr.arpa, 10.0.0.69 соответствует host2.test.ru

Создание в Windows Server обратной DNS-зоны с нестандартной маской

Привет.
 
Оригинальная статья написана Димой Макаровым несколько лет назад – и, увы, при смене домена и переезде иллюстрации от неё потерялись. Поэтому я (Ruslan V. Karmanov) чуть актуализовал материал, добавил дополнительный и сделал новые картинки. Материал статьи работоспособен на всех серверных версиях Windows, от 2000й до Windows 10, которая Threshold (на ней и сделаны скриншоты).
 
Давайте представим ситуацию, когда провайдер делегирует управление доменом клиенту. Плюс, чтобы не заморачиваться, сразу же и делегирует ему же управление обратной зоной – ну, выделил клиенту диапазон IP-адресов, и не хочет постоянно менять или исправлять записи в reverse lookup зоне. Клиент ведь может легко делать это сам – достаточно просто перенаправлять reverse lookup-запросы, которые приходят к провайдеру снаружи, но относятся к клиентскому диапазону, на клиентский DNS-сервер(а). Казалось бы, всё просто – бери да делай. Вот так например:

Но вот незадача, клиент использует Windows Server, а подсеть клиента – не классовая, а, допустим, /26. Т.е. маска – VLSM-ная. В штатном интерфейсе создать такую зону не получится никак. Давайте смоделируем эту ситуацию и посмотрим, что можно сделать.
 
Для организации тестового полигона воспользуемся Microsoft Windows Server 2012 R2 со всеми обновлениями на январь 2015 года. Нам понадобится 2 сервера. Первый – dc1 мы будем считать провайдером. IPv4 адрес у него будет 192.168.160.1 / 24. Второй, dc2, будем считать NS-сервером клиента, которому провайдер делегирует кусочек адресного пространства. IPv4 адрес 192.168.160.2 / 24.
 
Будем считать, что AS провайдера содержит сеть 10. 11.12.0 / 24, а клиенту необходимо делегировать обработку второй четвертинки этой сети – т.е. 10.11.12.64 / 26.
 
Создадим reverse lookup-зону на провайдере:

Замечу, что размер зоны некритичен – просто штатным способом в Microsoft DNS Server мы сможем создать только зону с “классовой” маской – 8, 16 или 24 бита. Остальные параметры так же некритичны – поэтому я создал её как файл, и без динамических обновлений (забегая вперёд, динамические обновления для PTR-записей, находящихся в reverse-зонах с нестандартной маской, все равно не работают). Вот что у меня вышло:

 
Теперь нам надо создать в этой “провайдерской” зоне запись о том, что все запросы про адреса с 10.11.12.64 по 10.11.12.127 (именно так, ведь это с точки зрения DNS будет просто диапазоном адресов, а не сетью, поэтому никакой спец.обработки адреса сети и широковещательного адреса не планируется) будут передаваться на сервер dc2.
 
Через штатный механизм (MMC-оснастку DNS Server и меню New Delegation…) создаём в reverse lookup-зоне 12. 11.10.in-addr.arpa новое делегирование. Его параметры будут следующими – NS-сервер, на который будут перенаправляться запросы – dc2, а вот имя делегируемой зоны мы можем выбрать различное. Microsoft обычно предлагает что-то вида:
 
последний октет ID подсети–количество бит в маске подсети
 
или
 
последний октет ID подсети/количество бит в маске подсети
 
Мне нравится первый вариант, потому что всё ж слэш – он не входит в любимые всеми DNS-серверами символы, а минус – вполне.
 
Так как мы договорились отдавать клиенту вторую четвертинку сети 10.11.12.0 / 24, а это 10.11.12.64 / 26, то результат в нашем случае таков:

ОК, заготовка на сервере есть. Отдельно остановлюсь на простом и неприятном моменте. Суть в том, что никакой хитрой фильтрации запросов, уходящих в делегированные зоны, сервер Microsoft DNS не производит совсем. То есть то, что мы создали – это просто некая именованная дочерняя DNS-зона, самостоятельно перенаправлять в неё запросы сервер не будет. Чтобы он их перенаправлял, и именно в неё, и именно нужные, надо регистрировать CNAME-записи – столько, сколько будет делегированных адресов. Я создам одну такую запись и на её примере покажу, какой все они будут иметь вид:

Т.е. это CNAME, указывающий на то, что если кто-то запросит rev

Краткое руководство: создание зоны и записи DNS — портал Azure — Azure DNS

  • 3 минуты на чтение

В этой статье

Вы можете настроить Azure DNS для разрешения имен узлов в вашем общедоступном домене. Например, если вы приобрели доменное имя contoso.xyz у регистратора доменных имен, вы можете настроить Azure DNS для размещения contoso.xyz и разрешите www.contoso.xyz IP-адресу вашего веб-сервера или веб-приложения.

В этом кратком руководстве вы создадите тестовый домен, а затем создадите запись адреса для преобразования www в IP-адрес 10.10.10.10 .

Важно

Все имена и IP-адреса в этом кратком руководстве являются примерами, не отражающими реальных сценариев.

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

Для всех шагов портала войдите на портал Azure.

Предварительные требования

Войдите на портал Azure

Войдите на портал Azure, используя свою учетную запись Azure.

Создание зоны DNS

Зона DNS содержит записи DNS для домена. Чтобы начать размещение своего домена в Azure DNS, вы создаете зону DNS для этого доменного имени.

Для создания зоны DNS:

  1. В левом верхнем углу выберите Создать ресурс , затем Сеть , а затем Зона DNS .

  2. На странице Создать зону DNS введите или выберите следующие значения:

    • Имя : Введите contoso. xyz для этого примера быстрого запуска. Имя зоны DNS может быть любым значением, которое еще не настроено на DNS-серверах Azure. Реальная ценность — это домен, который вы купили у регистратора доменных имен.
    • Группа ресурсов : выберите Создать новый , введите MyResourceGroup и выберите OK .Имя группы ресурсов должно быть уникальным в рамках подписки Azure.

  3. Выберите Создать .

Создание зоны может занять несколько минут.

Создать запись DNS

Вы создаете записи DNS или записи для своего домена внутри зоны DNS. Создайте новую запись адреса или запись A для преобразования имени хоста в адрес IPv4.

Чтобы создать запись A:

  1. На портале Azure под Все ресурсы откройте contoso.xyz DNS-зона в группе ресурсов MyResourceGroup . Вы можете ввести contoso.xyz в поле Фильтр по имени , чтобы его было легче найти.

  2. В верхней части страницы DNS zone выберите + Record set .

  3. На странице Добавить набор записей введите или выберите следующие значения:

    • Имя : Тип www . Имя записи — это имя хоста, которое вы хотите преобразовать в указанный IP-адрес.
    • Тип : выберите A . Наиболее распространены записи «A», но существуют и другие типы записей для почтовых серверов («MX»), IP-адресов v6 («AAAA») и т. Д.
    • TTL : Тип 1 . Время жизни DNS-запроса указывает, как долго DNS-серверы и клиенты могут кэшировать ответ.
    • Блок TTL : выберите часов . Это единица времени для значения TTL .
    • IP-адрес : для этого примера быстрого запуска введите 10. 10.10.10 . Это значение — IP-адрес, в который разрешается имя записи. В реальном сценарии вы должны ввести общедоступный IP-адрес своего веб-сервера.

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

Проверить разрешение имен

Теперь, когда у вас есть тестовая зона DNS с тестовой записью «A», вы можете проверить разрешение имен с помощью инструмента nslookup .

Для проверки разрешения имен DNS:

  1. На портале Azure в разделе Все ресурсы откройте зону contoso. xyz DNS в группе ресурсов MyResourceGroup . Вы можете ввести contoso.xyz в поле Фильтр по имени , чтобы его было легче найти.

  2. Скопируйте одно из имен серверов имен из списка серверов имен на странице Обзор .

  3. Откройте командную строку и выполните следующую команду:

      nslookup www.contoso.xyz <имя сервера имен>

    Например:

      nslookup www.contoso.xyz ns1-08.azure-dns.com.

    Вы должны увидеть что-то вроде следующего экрана:

Имя хоста www.contoso.xyz преобразуется в 10.10.10.10 , как вы его настроили. Этот результат подтверждает, что разрешение имен работает правильно.

Очистить ресурсы

Если вам больше не нужны ресурсы, созданные в этом кратком руководстве, удалите их, удалив группу ресурсов MyResourceGroup . Откройте группу ресурсов MyResourceGroup и выберите Удалить группу ресурсов .

Следующие шаги

Windows Server: создание зоны обратного просмотра DNS с меньшими зонами — статьи TechNet — США (английский)

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

Сегодняшняя статья расскажет вам об этом опыте, а также о возможном решении.

Наша среда основана на контроллерах домена Windows Server 2012 R2, и мы используем интегрированные зоны DNS AD.Все контроллеры домена в нашей среде — это DNS-серверы, и наоборот.

У нас есть зона обратного просмотра 168.192.in-addr.arpa. Это интегрированная зона AD.

Эта зона содержит все обратные записи для сети 192.168.x.x.

Есть записи для подсети 192.168.1.x и для подсети 192.168.2.x.

Для записей 192.168.2.x:

  1. Некоторые записи создаются во время создания записей хоста путем выбора опции «Создать связанные записи PTR».

    В эту категорию попадают

    192.168.2.10, 192.168.2.11 и 192.168.2.12. Таким образом, для этих записей существуют соответствующие записи хоста.

  2. Некоторые записи создаются непосредственно как обратные записи, и для этих записей PTR не существует записей хоста.

    В эту категорию попадают

    192.168.2.2, 192.168.2.3, 192.168.2.4 и 192.168.2.5.

Схема, приведенная ниже, лучше поясняет сценарий.

Теперь по какой-то причине мы хотим разбить эту зону на более мелкие зоны.Это означает, что мы собираемся создать такие зоны:

  • 168. 192.1.in-addr.arpa.
  • 168.192.2.in-addr.arpa… .и так далее.

После создания меньших зон мы хотели бы переместить все существующие записи из большей зоны (192.168.x.x) в соответствующую меньшую зону.

Итак, теперь давайте создадим новую зону обратного просмотра: 2.168.192.in-addr.arpa.

Итак, новая зона обратного просмотра создана.

Это самая важная часть статьи.

После создания новой зоны и перехода к исходной зоне 168.192.in-addr.arpa. Мы заметили, что все записи, соответствующие подсети 192.168.2.x, исчезли. Нам нужно обновить зону, чтобы подтвердить это.

Мы также заметили, что для 2.168.192 создается новая делегированная зона, но эта делегированная зона также не содержит этих недостающих записей. Эти записи теперь нигде не существуют, ни в исходной зоне, ни в новой зоне,
и ни в делегированной зоне.Рекорды просто исчезли!

Для тех записей PTR, которым были соответствующие записи хоста, записи хоста остаются нетронутыми и не удаляются. Но записи PTR исчезли.

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

Мы протестировали это в контроллере домена Windows Server 2012 R2, который также является DNS-сервером. Тестирование проводилось в нескольких средах, и каждый раз мы получали один и тот же результат.

Динамические записи

До сих пор мы наблюдали такое поведение только для статических записей, но как насчет динамических записей PTR? Их тоже удаляют?

Посмотрим.

У нас есть 3 записи для подсети 192.168.1.X:

  1. 192.168.1.2: статический
  2. 192.168.1.5: статический
  3. 192.168.1.88 (динамический, зарегистрированный системой, имеет соответствующую запись хоста)

Теперь давайте создадим новую зону 1. 168.192.in-addr.arpa и проследим за поведением:

Как мы видим, динамическая запись также исчезла вместе со статическими записями.

Перезапуск службы DNS-сервера и перезапуск всего DNS-сервера не помогли решить проблему. Рекорды ушли!

Мы также протестировали и обнаружили, что невозможно восстановить записи из корзины AD, даже если зона интегрирована с AD.

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

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

Согласно
это артикул , записи помечены как «dNSTombstoned». Некоторые идентификаторы событий создаются в журналах событий DNS-сервера: 4010 и 4013.

Это уязвимость?

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

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

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

При таком поведении никому не нужно удалять разрешение в этой зоне. Все, что им нужно сделать, это создать меньшую обратную зону, и все записи из соответствующей подсети будут автоматически удалены из исходной зоны. Кто-то может сделать это случайно
или намеренно.Мы протестировали этот сценарий в нашей тестовой лаборатории, и записи удаляются там, где большинство учетных записей (прошедшие проверку пользователи, все, администраторы домена, администраторы DNS, администраторы предприятия) имеют доступ «Запретить» для удаления любой записи.

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

В идеале удаленные записи должны попадать в корзину AD, поскольку в интегрированной зоне DNS AD каждая запись является объектом AD.Однако мы не нашли этих записей в корзине AD. Конечно, AD Recycle Bin была включена раньше
удаление записей.

Единственное возможное решение, которое мы нашли (и применили), — это быстро воссоздать записи во вновь созданной зоне. Для большого количества записей нам нужно реализовать некоторую автоматизацию, что мы и сделали. Мы
использовал сценарий PowerShell.

Хотя это решение хорошо подходит для статических записей, для динамических записей мы рекомендуем перерегистрировать эти записи, а не создавать их вручную или с помощью скриптов.Потому что, когда вы создаете записи вручную (или через
какой-нибудь скрипт) тип записи будет статическим.

Я создал
Сценарий PowerShell в галерее Tech Net, который называется PowerDNS. Это многоцелевой сценарий, который может создавать, удалять и запрашивать массовые записи DNS.

Когда вам нужно создать такую ​​меньшую обратную зону, где существует родительская обратная зона и которая содержит несколько записей, соответствующих (создаваемой) меньшей зоне (ам), которую мы собираемся создать, вы должны выполнить следующие шаги:

  1. Экспорт всех записей из родительской зоны в текстовый файл.
  2. Теперь поместите все содержимое в Excel и примените «Текст в столбец» для разделения IP-адресов и значений записи.
  3. Фильтр с диапазоном IP-адресов. Например, вы собираетесь создать зону 168.192.3.in-addr.arpa., Чтобы оценить все существующие записи для подсети 192.168.3. будут удалены и немедленно созданы заново. Итак, из этого
    Excel, фильтруйте только те IP-адреса, начинающиеся с 192.168.1.3.

  4. Теперь, когда это будет сделано, создайте входной файл, как показано ниже.Формат файла должен быть CSV.

Важно:

  • Поддерживайте точный формат заголовка (IP, FQDN), поскольку сценарий будет принимать входные данные из этого файла.
  • Кроме того, при указании значения записи укажите только октеты хоста.
  • Пожалуйста, не упоминайте сетевые октеты, так как сетевые октеты будут указаны при запуске скрипта.
  • Ставьте запятую (,) между значениями.
  • Не ставьте точку с запятой или другой разделитель.
  • Упомяните полное доменное имя записи.

Выполнение скрипта

Теперь, когда входной файл готов, давайте запустим сценарий. Вы можете запустить его с DNS-сервера или из другой системы, в которой установлены модули AD и DNS PowerShell. Убедитесь, что у вас есть соответствующее разрешение на создание DNS.
записи по указанной зоне.

Когда вы запустите утилиту PowerDNS, вы увидите несколько вариантов. Для создания записей PTR нажмите 3.

Поскольку мы должны создавать массовые записи PTR, выберите 2.

Теперь введите имя DNS-сервера, имя зоны обратного просмотра и расположение входного файла.

Для каждой записи скрипт попросит вас подтвердить.

(Если вам не нужно окно подтверждения, отредактируйте функцию Create-BulkPTREntry и удалите переключатель –confirm)

Когда все записи будут созданы, вы получите сообщение «Нажмите Enter, чтобы продолжить». Нажатие Enter вернет вас в главное меню.

Теперь вы можете проверить, что все обратные записи созданы в правильной зоне.

В этой статье мы исследовали типичное поведение Windows DNS Server, которое, возможно, мало известно многим администраторам.

  • Когда мы разбиваем зону обратного просмотра на более мелкие зоны, все существующие записи, соответствующие этим подсетям меньшей зоны, будут немедленно удалены без какого-либо предупреждения. Если таких записей тысячи, все тысячи записей
    будет немедленно удален.
  • Это поведение верно как для статических, так и для динамических записей.
  • Соответствующие записи хоста не повреждены и не удаляются.
  • Удаленные записи нельзя восстановить из корзины AD или другим способом.
  • Единственное возможное решение, которое мы нашли, — это воссоздать записи. Для динамических записей его необходимо перерегистрировать.
  • Мы использовали сценарий PowerShell для массового создания записей.

И последнее, но не менее важное; пожалуйста, проверьте это поведение и сценарий в тестовой среде, прежде чем что-либо делать в производственной среде.

Страница не найдена

Документы

Моя библиотека

раз

    • Моя библиотека

    «»

    Настройки файлов cookie

    Настройка дополнительной зоны в Windows DNS Server

    Когда добавляет зону DNS , есть возможность создать дополнительную зону . Вторичная зона — это в основном реплика зоны с другого существующего DNS-сервера в сети. Другой реплицируемый сервер называется Master . Любые изменения на Мастере применяются и к вторичной зоне , но не наоборот, так как мы не можем вносить изменения непосредственно во вторичную зону . В этой статье мы покажем вам, как и зачем нужно настраивать вторичную зону на Windows DNS Server .

    Как настроить дополнительную зону на DNS-сервере Windows

    Перед настройкой вторичной зоны в Windows DNS Server мы должны создать новый сервер и установить на нем роль DNS .Затем на следующем этапе мы создадим вторичную зону, ссылаясь на главный сервер . В этом примере у нас есть наш сервер AS-DCO001 в качестве главного сервера и AS-DNS001 , на котором мы создадим дополнительную зону. Обе роли DNS-сервера установлены на Windows Server 2012 R2 . Имя зоны, которое мы будем реплицировать, — mustbegeek.com . Ниже приведены пошаговые инструкции:

    Использование диспетчера DNS

    Сначала откройте DNS Manager в AS-DNS001 (сервер, на котором мы создадим дополнительную зону), перейдя в Server Manager и выбрав Tools> DNS .

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

    Щелкните правой кнопкой мыши либо в зонах прямого просмотра, либо в зонах обратного просмотра, в зависимости от типов зоны, которую вы хотите реплицировать . Поскольку зона mustbegeek.com является зоной прямого просмотра, мы собираемся щелкнуть правой кнопкой мыши Зоны прямого просмотра и выбрать Новая зона .

    Нажмите кнопку Далее , чтобы пропустить экран приветствия.

    При выборе типа зоны выберите Вторичная зона и нажмите Далее , чтобы продолжить.

    В поле имени зоны внимательно введите имя зоны . В нашем случае это mustbegeek.com . Щелкните Next , чтобы перейти к следующему экрану.

    В этом разделе введите полное доменное имя главного сервера или IP-адрес , затем нажмите Enter на клавиатуре. Допустимая запись будет иметь зеленый значок контрольного списка , как показано на рисунке ниже. Вы можете добавить более одного главного сервера . Чтобы переупорядочить , приоритет Master используйте кнопку Up / Down . В нашем случае у нас есть только один главный сервер — AS-DCO001 . Когда вы закончите, нажмите кнопку Далее , чтобы продолжить.

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

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

    Чтобы этого не произошло, мы должны убедиться, что Мастер разрешил передачу зоны на этот сервер . Чтобы настроить передачу зоны , перейдите в зону Свойства на сервере Master .

    Затем на вкладке Перенос зоны отметьте Разрешить зону Опции передачи.Затем вы можете выбрать « На любой сервер », «Только для серверов, перечисленных на вкладке« Серверы имен »» или «Только для следующих серверов ». Если вы выберете второй или третий вариант , вам может потребоваться указать имя сервера , на котором будет создана вторичная зона. В этом примере для простоты мы будем использовать первую опцию , которая равна , позволяя любому серверу реплицировать зону mustbegeek.com.

    Теперь вернитесь к AS-DNS001 и обновите диспетчера DNS , вы должны увидеть все записи в mustbegeek.com зона. Или вы можете ускорить процесс, щелкнув правой кнопкой мыши имя дополнительной зоны и выбрав «Передать из главной».

    Таким образом, мы успешно настроили дополнительную зону.

    Использование PowerShell

    Знаете ли вы, что описанные выше действия также можно выполнить с помощью командлетов PowerShell ? Использование PowerShell для настройки вторичной зоны на DNS-сервере Windows очень просто и может сэкономить вам много времени.

    Ниже приведена команда PowerShell для создания вторичной зоны DNS :

     Add-DnsServerSecondaryZone -Name «ZONE_NAME» —ZoneFile «ZONE_FILENAME» -MasterServers «MASTER_IP»

    Вам нужно только заменить ZONE_NAME на имя фактической зоны, ZONE_FILENAME на имя файла зоны (обычно то же самое с именем зоны, только добавить «. dns ” в конце) и MASTER_IP с IP-адресом главного сервера .

    Кроме того, вы также можете запустить эту команду ниже на главном сервере , если передача зоны еще не настроена.

     Set-DnsServerPrimaryZone -Name «ZONE_NAME» -SecureSecondaries TRANSFER_LIST

    Снова замените ZONE_NAME на имя той же зоны . Также замените TRANSFER_LIST одним из следующих значений в зависимости от ваших потребностей:

    • TransferAnyServer = Разрешить передачу зоны на любой сервер .
    • TransferToZoneNameServer = Разрешить перенос зоны только на серверы, указанные как серверы имен.
    • TransferToSecureServers = Разрешить передачу зоны только серверам, явно указанным в команде . Дополнительное ключевое слово « -SecondaryServers » должно быть включено после этой команды, за которой следует список IP-адресов вторичных серверов.

    Ниже приведена команда, которую мы используем в AS-DNS001 – для создания дополнительной зоны :

    И ниже приведена команда, которую мы используем в AS-DCO001 с по разрешить перенос зоны :

    Результат точно такой же, как мы ранее настраивали в графическом интерфейсе.Просто не забудьте, что запускает PowerShell от имени администратора при выполнении обеих команд.

    Работа с дополнительной зоной в Windows DNS Server

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

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

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

    Следующие две вкладки изменяют содержимое ниже.

    Я практикующий ИТ-специалист со специализацией в сетевой и серверной инфраструктуре. У меня есть многолетний опыт проектирования, анализа, эксплуатации и оптимизации инфраструктурных решений для сетей масштаба предприятия. Вы можете отправить мне сообщение в LinkedIn или электронное письмо по адресу [email protected], чтобы узнать подробнее о материалах, которые я написал, или о возможности сотрудничества в проекте.

    Создание зоны OVH DNS для доменного имени

    Последнее обновление 6 августа 2018 г.

    Объектив

    Зона системы доменных имен (DNS) — это файл конфигурации доменного имени.Он состоит из технической информации, иначе называемой «записями». Зоны DNS обычно используются для привязки вашего доменного имени к серверу (или серверам), на котором размещен ваш веб-сайт и адреса электронной почты.

    По ряду причин вам может потребоваться создать зону DNS для вашего доменного имени в OVH.

    Узнайте, как создать зону OVH DNS для вашего доменного имени с помощью панели управления OVH.

    Требования

    • доменное имя, которое еще не имеет зоны OVH DNS и не является частью операции или заказа, который в настоящее время обрабатывается в OVH

      • .

    • правильная техническая конфигурация вашего доменного имени (статус, SOA и т. Д.)
    • доступ к Панели управления OVH

    Инструкции

    Шаг 1. Создайте зону DNS через панель управления OVH.

    Прежде всего, войдите в Панель управления OVH. Щелкните Order на панели услуг слева, затем DNS zone .

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

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

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

    Разрешить минимальные записи? Детали
    Есть Выберите этот вариант, если вы захотите самостоятельно настроить зону DNS на более позднем этапе.
    № Выберите этот вариант, если вы планируете использовать службы OVH, такие как тарифный план веб-хостинга, поскольку зона уже настроена заранее.

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

    Шаг 2: Отредактируйте зону DNS (необязательно).

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

    Если вы хотите отредактировать эту зону DNS, на панели управления OVH щелкните Домены на панели служб слева, затем выберите нужное доменное имя. Перейдите на вкладку DNS Zone .

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

    Как только он появится, внесите необходимые изменения.Чтобы узнать больше о том, как редактировать зону DNS, прочтите наше руководство по редактированию зоны OVH DNS. После того как вы изменили зону OVH DNS своего доменного имени, вам потребуется от 4 до 24 часов, чтобы изменения полностью вступили в силу.

    Шаг 3: Отредактируйте DNS-серверы для доменного имени.

    Когда зона OVH DNS будет готова к использованию, вы можете связать ее со своим доменным именем. Для этого вам необходимо получить подробную информацию о DNS-серверах OVH, активированных для вашего доменного имени, в Панели управления OVH.Серверы появятся под Name Servers .

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

    Дальше

    Редактирование зоны OVH DNS.

    Присоединяйтесь к нашему сообществу пользователей на https://community.ovh.com/en/.

    Эти руководства также могут вас заинтересовать…

    Windows Server DNS зоны объяснения

    В этом руководстве я дам краткий обзор различных типов зон DNS для Windows Server и Active Directory.

    Это поможет вам лучше понять DNS и Active Directory и управлять ими.

    Зоны DNS хранят информацию о ресурсных записях DNS. Некоторые общие записи DNS включают:

    • A Запись: сопоставление имени и IP-адреса
    • CNAME: сопоставляет псевдоним каноническому имени

      • .

    • Запись MX: используется для идентификации почтовых серверов
    • NS Record: определяет серверы имен для определенной зоны
    • SOA: начало авторитетных записей
    • TXT: Позволяет вставлять любой текст в запись DNS

    Существует много других типов записей, и без этих записей все было бы доступно по IP-адресу.

    Зоны

    DNS предоставляют нам возможность хранить эти записи на одном или нескольких серверах.

    Давайте посмотрим на различные типы зон.

    Интегрированные зоны Active Directory

    Active Directory Integrated Zones хранит данные своей зоны в Active Directory. Интегрированные зоны можно реплицировать на все контроллеры домена в домене и лесу. В интегрированных зонах Active Directory используется репликация с несколькими главными серверами, это означает, что любой контроллер домена, на котором запущена служба DNS-сервера, может записывать обновления в зону, для которой они являются полномочными.

    Преимущества зон, интегрированных в Active Directory

    • Репликация быстрее, безопаснее и эффективнее.
    • Лучшее резервирование благодаря копированию данных зоны на все контроллеры домена
    • Повышенная безопасность, если включено безопасное динамическое обновление
    • Нет необходимости планировать или управлять переносами зон

    Первичная зона

    Это основная зона, в которой имеется копия данных зоны для чтения / записи. Все изменения в зоне вносятся в первичную зону и реплицируются во вторичные зоны.

    Данные зоны хранятся в текстовом файле, расположенном в этой папке c: \ windows \ system32 \ DNS на сервере Windows, на котором работает DNS.

    Вторичная зона

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

    Шлейф

    Тупиковые зоны похожи на вторичную зону, но хранят только частичные данные зоны.Эти зоны полезны для уменьшения передачи зон путем передачи запросов на авторитетные серверы. Эти зоны содержат только записи SOA, NS и A.

    Зона прямого просмотра

    Зона прямого просмотра обеспечивает преобразование имени хоста в IP-адрес.

    Когда вы входите в систему или веб-сайт по имени хоста, например mcirosoft. com, DNS проверяет зону прямого просмотра на наличие IP-информации, связанной с именем хоста.

    Зона обратного просмотра

    Зоны обратного просмотра преобразуют IP-адреса в имена хостов.

    Например, при поиске IP-адреса 8.8.8.8 он преобразуется в google-public-dns-a.google.com. Для преобразования IP в имя хоста необходимо было создать обратную DNS-запись.

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

    Зона трансферов

    Перенос зон происходит, если они не интегрированы с Active Directory. При передаче зоны главные DNS-серверы передают данные зоны от главного к вторичному.

    Передачи зон могут происходить во время любого из следующих

    • По истечении интервала обновления
    • Когда главный сервер уведомляет об изменении
    • После перезагрузки сервера или перезапуска службы DNS
    • Произошла передача вручную с консоли DNS

    Связано: Как использовать NSLookup для проверки записей DNS

    Рекомендуемый инструмент: SolarWinds Server & Application Monitor

    Эта утилита была разработана для мониторинга Active Directory и других важных служб, таких как DNS и DHCP.

    No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *