Создание новой dns зоны ps kz
Продолжая тему сайтостроения поговорим о таком важном аспекте, как работа системы доменных имен - DNS. С настройкой и расположением DNS-зоны связаны многие вопросы, касающиеся первоначального размещения, а также переноса сайтов между различными серверами и хостингами. Понимание принципов работы системы доменных имен позволяет с легкостью управлять собственными доменами и связанными с ними сайтами и прочими службами.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
В общем понимании домен - это символьное имя, позволяющее однозначно адресовать автономную область имен в сети интернет. И не только адресовать, но и позволить любому клиенту быстро найти необходимый узел, даже не имея ни малейшего представления о его размещении. Можно без преувеличения сказать, что система DNS - основа современной сети интернет в том виде, в которой мы все ее знаем и привыкли.
Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:
Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru, сom, org и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.
Домены первого уровня являются привычными нам доменными зонами и могут управляться как национальными, так и международными организациями и иметь свои условия использования. Каждая доменная зона первого уровня позволяет размещать неограниченное количество доменов второго уровня, которые знакомы каждому пользователю интернета как адреса сайтов.
Это очень важный момент. В повседневном использовании завершающую точку принято отбрасывать, но в записях DNS отсутствие последней точки обозначает, что данное доменное имя принадлежит текущей доменной зоне, т.е. DNS-сервер прибавит к такому имени собственную доменную зону и все вышестоящие зоны вплоть до корня.
Еще один момент. Все записи для доменной зоны вносятся администраторами зон на собственных DNS-серверах, каким образом данные записи становятся известны системе DNS? Ведь мы же не оповещаем вышестоящие DNS-сервера, что изменили какую-либо запись.
Любая DNS-зона содержит записи только о входящих в нее узлах и дочерних зонах. Информация об узлах нижестоящей зоны хранится на ее собственных серверах. Это называется делегированием и позволяет снизить нагрузку на корневые сервера и предоставить необходимую автономию владельцам дочерних доменных зон.
В этом случае в доменной зоне org будет добавлена запись:
Теперь разберем, каким образом происходит поиск необходимой нам DNS-записи и почему запись, сделанная на вашем сервере, позволяет попасть на ваш сайт посетителям из любой точки земного шара.
В свою очередь DNS-клиент проверяет записи в файле hosts, затем в локальном кэше и, не обнаружив там нужных записей, передает запрос указанному в сетевых настройках DNS-серверу. Скорее всего это будет локальный кэширующий DNS-прокси, например, dnsmasq или локальный DNS-сервер предприятия. Данные решения обычно не являются полноценными серверами глобальной системы DNS и не входят в нее, обслуживая только локальную зону и кэшируя DNS-запросы, поэтому такой запрос, если данных не оказывается в кэше, передается вышестоящему DNS-серверу, как правило это сервер провайдера.
Получив запрос, сервер провайдера проверит собственные записи, затем собственный кэш, и, если результат будет найден, сообщит его клиенту, в противном случае сервер вынужден будет прибегнуть к рекурсии - поиску в глобальной системе DNS. Чтобы лучше понять механизм данного процесса мы подготовили следующую схему:
Выяснив адрес сервера, отвечающего за зону ru, сервер провайдера передаст запрос ему, но данный сервер также не имеет нужных записей, но сообщит, что за зону yandex отвечает сервер ns1.yandex.ru и обязательно сообщит его адрес. Иначе рекурсию завершить не удастся, так как за зону yandex отвечает сервер, находящийся в зоне yandex. Для этого в вышестоящей зоне, кроме NS-записи об обслуживающих зону серверах имен, создается "связанная" А-запись, которая позволяет узнать адрес такого сервера.
Наконец, отправив запрос серверу, обслуживающему зону yandex, сервер провайдера получит адрес искомого домена и сообщит его клиенту. Также он поместит полученный результат в кэш на время, предусмотренное значением TTL в SOA-записи этого домена. На практике, так как рекурсивные запросы весьма затратны, время кэширования записей у провайдеров может игнорировать значения TTL домена и достигать значений от двух-четырех часов до нескольких дней или даже недели.
Так как рекурсивные запросы являются достаточно ресурсоемкими большинство серверов сети DNS обрабатывают рекурсивные запросы нерекурсивно. Либо могут делать это выборочно, например, DNS-сервера провайдера выполняют рекурсивные запросы только для своих клиентов, а остальные нерекурсивно.
В нашем случае клиент послал серверу провайдера рекурсивный запрос, который, в свою очередь, последовательно отправлял нерекурсивные запросы пока не нашел требуемый сервер, который дал необходимый ответ. При этом в кэш сервера провайдера помещаются не только результаты пользовательского запроса, но и результаты промежуточных запросов, что позволяет выполнять следующие такие запросы нерекурсивно или с минимальным количеством запросов.
Управление 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 в домене, выполните команду:
Выведем список записей в новой DNS зоне (она пуста):
Get-DnsServerResourceRecord -ComputerName dc01 -ZoneName contoso.local
Для удаления зоны воспользуйтесь командой:
Remove-DnsServerZone -Name contoso.local -ComputerName dc01
Эта команда также удалит все существующие DNS записи в зоне.
От теории к практике
Когда вы приобретаете у регистратора домен, вам будет предложено его делегировать, т.е. указать DNS-сервера, на которых будет расположена доменная зона. Это могут быть сервера регистратора (обычно бесплатно), сервера хостера, публичные DNS-сервисы или собственные сервера имен, если он будет расположен в этой же доменной зоне, то вам потребуется также указать IP-адреса. Например, так выглядит окно делегирования домена у одного известного регистратора:
Что именно туда указывать? Это зависит от того, где и как вы будете размещать свой сайт. Если вы используете виртуальный хостинг, то все необходимые записи создаются хостером автоматически, при добавлении в панели управления хостингом вашего сайта, все что вам надо - это делегировать домен на NS-сервера хостера, т.е. указать их в данном окне. Этот способ хорошо подходит начинающим, благодаря своей простоте, но есть и обратная сторона, возможность управления DNS-зоной со стороны пользователя отсутствует или минимальна. Кроме того, на виртуальном хостинге IP-адрес сайта может быть изменен администраторами без уведомления пользователя, поэтому, если вы не хотите использовать NS-сервера хостера, то этот вопрос следует обязательно обсудить с техподдержкой.
Если вы переносите сайт к другому хостеру, то вам потребуется перенести сайт и поменять у регистратора сервера имен старого хостера на сервера нового. Но учтите, что информация в кэше DNS-серверов обновляется не мгновенно, а, как минимум, по истечении значения TTL-домена, поэтому в течении некоторого времени ваш сайт может быть доступен еще по старому адресу. Если вам надо срочно с ним работать, то можете, не дожидаясь обновления DNS-кэша вашего провайдера, добавить в файл hosts запись следующего содержания:
Если у вас свой VPS или вы хотите полностью контролировать доменную зону, то следует воспользоваться серверами регистратора или публичными сервисами. Создание собственного сервера имен, на наш взгляд, не оправдывающая себя затея, если только вы не делаете собственный хостинг.
В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:
Символ "собачки" в DNS-записях обозначает сам домен, кроме того обязательно следует создать запись для поддомена www, чтобы пользователи, набравшие адрес сайта с www, также могли получить к нему доступ.
Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье: Почтовый сервер для начинающих. Настраиваем DNS зону.
При переносе сайта вам потребуется изменить только IP-адреса в A-записях и дождаться обновления DNS информации. Обычно, это самый неприятный момент - вроде бы все сделано, но ничего изменить вы не можете, остается только ждать. Но если выполнить некоторые рекомендации, то данный процесс можно провести максимально безболезненно и незаметно для посетителей.
Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:
В нашем случае это 4 часа:
Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.
После успешного переноса значение TTL следует увеличить до прежних значений, чтобы не создавать лишней нагрузки на сервера имен.
Мы рассмотрели самую простую схему, но на практике, кроме сайта, обычно есть еще офисная сеть, многие ресурсы которой должны быть также доступны извне. Рассмотрим следующую схему:
Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com, которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.
Теперь клиент, вне зависимости от своего местоположения, может использовать для доступа к ресурсам одно и тоже имя, но результат получать при этом будет разный. В локальной сети он получит реальный адрес сервера и подключится напрямую, а за ее пределами будет направлен на шлюз сети.
Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.
Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:
Правильно будет так:
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Бесплатно всем клиентам на каждый домен в Личном кабинете. Узнайте как получить
Наша компания является одним из крупнейших хостинг-провайдеров в Казахстане. Мы поможем подобрать оптимальный вариант хостинга для вашего сайта и обеспечим круглосуточную техническую поддержку.
Мы первыми среди казахстанских хостинг-провайдеров внедрили протокол IPv6 наряду с распространенным IPv4. И всем клиентам наших услуг виртуального хостинга, VPS, Colocation и Dedicated мы готовы предоставлять бесплатные IPv6-адреса.
Простой в работе и с большим выбором адаптивных шаблонов — более 200 вариантов дизайна
Классический Office, облачное хранилище и почта, а также возможность доступа с планшетов и смартфонов.
Стоимость подписки от 2850 тг/мес.
Мы давно и профессионально занимаемся администрированием серверов. Наши услуги обойдутся дешевле, чем системный администратор в штате и это не скажется на качестве.
Сохраняйте конфиденциальные данные ваших пользователей в безопасности и влияйте на поисковую выдачу вашего сайта.
Стоимость SSL-сертификатов от 5000 тг/год.
Для того чтобы подключить Ваш домен к хостингу на наших серверах достаточно выполнить несколько простых шагов.
Есть несколько вариантов решения данной проблемы:
Выбираем чекбокс прописываем наши актуальные NS сервера из письма полученного на электронную почту или из раздела «Мой хостинг» в вашем личном кабинете.
Как правило это:
После того как произведете соответствующие корректировки нажмите Сохранить NS-серверы, ожидайте применение новых настроек, как правило на это требуется от 2 до 24 часов.
Рассмотрим вариант настройки доменного имени посредством DNS хостинга регистратора:
Переходим в раздел «Личный кабинет» — » Ваши домены »
В открывшемся разделе кликаем на интересующий нас домен
Модуль 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 команд):
Переходим в раздел «Управление DNS-зоной»
Производим требуемые корректировки значений для данного домена.
На данной странице нам необходимо в каждой строке изменить текущее значение IP адреса на актуальный IP адрес нашего сервера, его Вы можете взять из личного кабинета в разделе «Мой хостинг» или из письма которое Вам было отправлено на электронную почту при активации хостинга.
После внесения изменений IP адреса в каждой строке необходимо нажать «Сохранить» для применения изменений.
Так же Вы можете добавить новые записи, например если Вы планируете использовать суб.домены при помощи кнопки «Добавить запись».
Если у Вас имеются сомнения в плане настроек или Вы боитесь выполнить их сами, то Вы всегда можете обратиться в нашу службу поддержки посредством тикет системы, мы совершенно бесплатно произведем требуемые настройки либо дадим Вам консультацию как это сделать лучше всего.
29.08.2019
itpro
DNS, PowerShell
комментария 4
Администратор DNS сервера на Windows для управления сервером, DNS зонами и записями может использовать старую добрую утилиту Dnscmd , или воспользоваться возможностями PowerShell модуля DNSServer. В этой статье мы рассмотрим основные операцию по массовому созданию, модификации и удалению различных DNS записей и зон с помощью PowerShell.
Убеждаемся что у нас отмечен чекбокс » Использовать ДНС регистратора » если он не отмечен то отмечаем и применяем настройки.
Переходим к основному моменту настроек — это пропись записей домена на наш хостинг:
Переходим в раздел «Управление DNS-зоной»
Создаем новую DNS зону на базе IP адреса полученного в письме которое Вы получили на электронную почту при активации хостинга либо из личного кабинета в разделе «Мой хостинг»
Прописываем IP и нажимаем «Создать зону» на этом все!
Ели требуется изменение или добавление записей то читаем дальше…
Управление 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
Теперь изменим 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”
От теории к практике
Когда вы приобретаете у регистратора домен, вам будет предложено его делегировать, т.е. указать DNS-сервера, на которых будет расположена доменная зона. Это могут быть сервера регистратора (обычно бесплатно), сервера хостера, публичные DNS-сервисы или собственные сервера имен, если он будет расположен в этой же доменной зоне, то вам потребуется также указать IP-адреса. Например, так выглядит окно делегирования домена у одного известного регистратора:
Что именно туда указывать? Это зависит от того, где и как вы будете размещать свой сайт. Если вы используете виртуальный хостинг, то все необходимые записи создаются хостером автоматически, при добавлении в панели управления хостингом вашего сайта, все что вам надо - это делегировать домен на NS-сервера хостера, т.е. указать их в данном окне. Этот способ хорошо подходит начинающим, благодаря своей простоте, но есть и обратная сторона, возможность управления DNS-зоной со стороны пользователя отсутствует или минимальна. Кроме того, на виртуальном хостинге IP-адрес сайта может быть изменен администраторами без уведомления пользователя, поэтому, если вы не хотите использовать NS-сервера хостера, то этот вопрос следует обязательно обсудить с техподдержкой.
Если вы переносите сайт к другому хостеру, то вам потребуется перенести сайт и поменять у регистратора сервера имен старого хостера на сервера нового. Но учтите, что информация в кэше DNS-серверов обновляется не мгновенно, а, как минимум, по истечении значения TTL-домена, поэтому в течении некоторого времени ваш сайт может быть доступен еще по старому адресу. Если вам надо срочно с ним работать, то можете, не дожидаясь обновления DNS-кэша вашего провайдера, добавить в файл hosts запись следующего содержания:
Если у вас свой VPS или вы хотите полностью контролировать доменную зону, то следует воспользоваться серверами регистратора или публичными сервисами. Создание собственного сервера имен, на наш взгляд, не оправдывающая себя затея, если только вы не делаете собственный хостинг.
В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:
Символ "собачки" в DNS-записях обозначает сам домен, кроме того обязательно следует создать запись для поддомена www, чтобы пользователи, набравшие адрес сайта с www, также могли получить к нему доступ.
Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье: Почтовый сервер для начинающих. Настраиваем DNS зону.
При переносе сайта вам потребуется изменить только IP-адреса в A-записях и дождаться обновления DNS информации. Обычно, это самый неприятный момент - вроде бы все сделано, но ничего изменить вы не можете, остается только ждать. Но если выполнить некоторые рекомендации, то данный процесс можно провести максимально безболезненно и незаметно для посетителей.
Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:
В нашем случае это 4 часа:
Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.
После успешного переноса значение TTL следует увеличить до прежних значений, чтобы не создавать лишней нагрузки на сервера имен.
Мы рассмотрели самую простую схему, но на практике, кроме сайта, обычно есть еще офисная сеть, многие ресурсы которой должны быть также доступны извне. Рассмотрим следующую схему:
Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com, которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.
Теперь клиент, вне зависимости от своего местоположения, может использовать для доступа к ресурсам одно и тоже имя, но результат получать при этом будет разный. В локальной сети он получит реальный адрес сервера и подключится напрямую, а за ее пределами будет направлен на шлюз сети.
Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.
Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:
Правильно будет так:
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Бесплатно всем клиентам на каждый домен в Личном кабинете. Узнайте как получить
Наша компания является одним из крупнейших хостинг-провайдеров в Казахстане. Мы поможем подобрать оптимальный вариант хостинга для вашего сайта и обеспечим круглосуточную техническую поддержку.
Мы первыми среди казахстанских хостинг-провайдеров внедрили протокол IPv6 наряду с распространенным IPv4. И всем клиентам наших услуг виртуального хостинга, VPS, Colocation и Dedicated мы готовы предоставлять бесплатные IPv6-адреса.
Простой в работе и с большим выбором адаптивных шаблонов — более 200 вариантов дизайна
Классический Office, облачное хранилище и почта, а также возможность доступа с планшетов и смартфонов.
Стоимость подписки от 2850 тг/мес.
Мы давно и профессионально занимаемся администрированием серверов. Наши услуги обойдутся дешевле, чем системный администратор в штате и это не скажется на качестве.
Сохраняйте конфиденциальные данные ваших пользователей в безопасности и влияйте на поисковую выдачу вашего сайта.
Стоимость SSL-сертификатов от 5000 тг/год.
Для того чтобы подключить Ваш домен к хостингу на наших серверах достаточно выполнить несколько простых шагов.
Есть несколько вариантов решения данной проблемы:
Как добавить сразу несколько A / PTR записей в DNS зону с помощью PowerShell?
Допустим, вам нужно создать сразу множество A записей в определенной DNS зоне прямого просмотра. Вы можете завести их по-одной с помощью команды Add-DnsServerResourceRecordA, но гораздол проще и быстрее массово завести A записи по списку из файла.
Создайте текстовый файл NewDnsRecords.txt ч именами и IP адресами, которые вы хотите завести. Формат файла такой:
Чтобы завести 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 файл со следующей структурой
Затем запустите такой скрипт:
Import-CSV "C:\PS\NewDnsPTRRecords.txt" | %Add-DNSServerResourceRecordPTR -ZoneName $_."zoneName" -Name $_."octet" -PTRDomainName $_."hostName"
>
Вся сеть Интернет, которая описывается зоной «.» (точка) делится на так называемые TLD (Top Level Domains – домены верхнего уровня), распределяемые либо по функциональному, либо по географическому признаку. Существует также термин primary domain – «первичный домен», или «домен первого уровня», но этот термин используется значительно реже. Распределение по географическому признаку осуществляется в соответствии с ISO 3166, устанавливающему для всех стран мира двух- и трехбуквенные коды. Распределение по функциональному признаку осуществляется по мере необходимости создания нового TLD. Здесь следует отметить, что всеми вопросами по отношению к TLD занимается ICANN (Internet Corporation for Assigned Names and Numbers), и именно этот орган решает – создавать ли новый TLD.
Корневые сервера сами по себе содержат только ссылки на сервера, содержащие информацию о зонах второго уровня, которые в свою очередь содержат информацию о серверах, содержащих информацию о зонах третьего уровня и т. д. В большинстве случаев иерархия исчерпывается на третьей-четвертой зоне. Но не потому, что здесь заложено какое-то ограничение. Просто запоминать сложные имена ничуть не проще IP-адресов.
Данный процесс проиллюстрирован на рис. 1, где цифры обозначают последовательность запросов.
Рисунок 1. Процесс поиска информации
Как встроить свою информацию в структуру DNS?
Прежде чем включаться в какую-либо систему, нужно иметь некоторое представление о том, куда и каким образом включаться.
За различные TLD отвечают различные сервера, и если за географические домены отвечает, как правило, один сервер (точнее говоря, одна организация), то за домены функциональные может отвечать, вообще говоря, неограниченное количество так называемых регистраторов, то есть компаний, заключивших специальные договоры с ICANN о том, что именно они будут регистрировать имена в некоторых функциональных доменах. Краткое описание функционального домена и адрес его регистратора приведены в [3].
При создании TLD, перечисленных выше, планировалось также создание TLD .xxx для сайтов с тематикой «для взрослых». ICANN отклонила это предложение. Недавно оно было вынесено на повторное голосование, и ICANN снова его отклонила [7]. Зато появился TLD .tel [9], рассчитанный на использование одновременно в компьютерах и мобильных устройствах.
Каким образом встраиваем?
Почему требование к наличию вторичного DNS-сервера является обязательным? Поскольку стабильность работы DNS крайне важна для стабильности работы сети Интернет в целом, то лицо или организация, регистрирующая домен, обязана удовлетворять некоторым условиям, касающимся стабильности работы DNS:
- Должно быть предусмотрено не менее двух серверов, обслуживающих данный домен.
- Эти сервера должны быть доступны не менее 22 часов в сутки.
Каких-либо требований к размещению серверов по новым правилам не выдвигается, хотя ранее требовалось наличие их в разных IP-сетях.
Прежде всего отмечу, что существуют варианты, не предполагающие какого-либо знания DNS – все размещается на площадке провайдера, все обслуживается провайдером, вам предоставляется только веб-интерфейс. Эта услуга чрезвычайно популярна за рубежом, но очень слабо востребована в России. Ее описание выходит за рамки данной статьи, поэтому рассматривать ее я не буду.
Во-первых, нам понадобится программа DNS-сервера. На сегодняшний день только одна программа реализует требуемый набор функций. Это DNS-сервер BIND, распространяемый ISC (Internet System Consortium Inc., [10]) – некоммерческой организацией, которая занимается разработкой серверов BIND, DHCP, INN и NTP. Если он отсутствует в вашей системе, его необходимо скачать и установить. FreeBSD поставляется вместе с BIND 9.3.2, поэтому в данной статье будет рассматриваться именно эта версия. Следует отметить, что для версий BIND 8.x приводимое ниже описание конфигурации совершенно неприемлемо, поскольку формат конфигурационных файлов BIND 8.x коренным образом отличается от формата конфигурационных файлов BIND 9.x.
Во-вторых, понадобится распределить выделенные нам IP-адреса и наделить адресами внутренние компьютеры. Здесь все чрезвычайно просто: пусть 212.20.5.1 – шлюз провайдера, 212.20.5.2 – адрес UNIX- сервера, 10.87.1.0/24 – внутренняя подсеть, в которой с 1-й по 6-й – рабочие станции, 254 – адрес внутреннего интерфейса сервера. Остальные адреса будут зарезервированы для будущего расширения.
Существует достаточно большое количество типов разнообразных записей, которые можно помещать в DNS. Обьем данной статьи позволяет рассмотреть лишь наиболее важные из них, для получения полной информации следует обратиться к соответствующим RFC: RFC 1033 и RFC 1035 определяют форматы основных записей, RFC 1122 – формат записи PTR, RFC 2782 – формат записи SRV. Мы рассмотрим только те записи, которые понадобятся для формирования файлов зон, необходимых для регистрации домена:
- Запись SOA, задающая начало описания зоны.
- Запись NS, определяющая сервера имен зоны.
- Запись A, задающая соответствие между IP-адресом и именем (прямое преобразование).
- Запись MX, описывающая настройки доставки почты для данного компьютера.
- Запись CNAME, задающая альтернативные имена.
- Запись PTR, задающая соответствие между именем и IPадресом (обратное преобразование), употребляется в описании «обратной» зоны.
Формат записей DNS общий для всех типов записей:
- имя – это имя обьекта, с которым ассоциируются данные;
- ttl – время жизни обьекта;
- класс – класс записи;
- тип – тип записи;
- данные – ассоциируемые с данным обьектом данные.
Имя может принимать любое значение, и в таком случае оно считается именем обьекта. Если имя заканчивается на точку, то оно считается полностью определенным, иначе в конец имени подставляется имя зоны, которое может быть задано двумя способами:
- Заданием имени зоны в директиве $ORIGIN, например:
- Заданием имени зоны в директиве zone конфигурационного файла BIND.
Специальный символ «@» обозначает текущее имя зоны. Имейте в виду, что директива $ORIGIN отменяет директиву zone и действует до появления следующей директивы $ORIGIN или до конца файла. До момента появления первой директивы $ORIGIN она считается заданной значению директивы zone конфигурационного файла BIND.
Если имя задано, оно должно начинаться с первой позиции строки.
TTL обычно опускается и задается глобально директивой $TTL. Директива $TTL для BIND 9.x является обязательной и, как правило, задается в самом начале файла. В поле данных этой директивы задается время жизни (в секундах) элемента, в течение которого он может находиться в кэше и считаться достоверным. В данном примере это двое суток (48 часов).
Класс записи может принимать одно из следующих значений:
- IN – запись ресурсов Интернет.
- CH – запись ресурсов ChaosNet – совершенно незнакомой российскому пользователю сети, применявшейся на машинах фирмы Symbolics.
- HS – запись ресурсов Hesiod – служебного протокола BIND.
Тип записи – один из типов, перечисленных выше.
Кроме записей, в файле зоны могут быть команды. Всего команд четыре – $TTL, $ORIGIN, $INCLUDE и $GENERATE. Описание команды $GENERATE приведено в документации на программу BIND, а также в [13] и [14], команда $INCLUDE работает соответственно своему написанию – включает указанный файл в текущий файл.
Примечание: знак «;» (точка с запятой) является признаком комментария.
Эта запись определяет начало зоны. Любая зона должна начинаться с записи SOA. Появление другой записи SOA автоматически заканчивает первую зону и начинает вторую. Формат записи SOA приведен ниже. Фактически запись SOA именует зону и задает для нее некоторые умолчания.
2005122001 ; Serial number
10800 ; Refresh every 3 hours
3600 ; Retry every hour
1728000 ; Expire every 20 days
172800 ) ; Minimum 2 days
Разберем пример. Знак @ в поле имени означает, что необходимо взять имя зоны, заданное ранее директивой $ORIGIN. Класс записи – IN, тип записи – SOA. SOA – это единственная запись, которая имеет такой сложный список параметров.
Второй параметр – это список значений, заключенный в скобки. Теоретически возможно его записать в одну строку, но практически я нигде этого не видел, всюду употребляется форма записи, приведенная в примере. Список состоит из пяти элементов:
- Серийный номер зоны. Этот параметр играет чрезвычайно важную роль в распространении обновления, выполненного на первичном сервере, по всем его вторичным серверам. Необходимо каким-то образом сообщить вторичному серверу о том, что данные на первичном сервере изменились. Если первичный сервер был перезапущен, то он отсылает всем вторичным серверам извещение о возможном изменении (DNS NOTIFY). Получив это извещение, вторичный сервер запрашивает серийный номер – если на первичном сервере серийный номер больше, чем на вторичном, вторичный сервер выполняет команду обновления зоны. Кроме того, вторичный сервер выполняет периодические проверки серийного номера с той же целью. Поэтому следует запомнить одно простое правило: исправил зону – увеличь серийный номер! Среди администраторов DNS распространена практика, в соответствии с которой серийный номер формируется следующим образом: YYYYMMDDv, где:
- YYYY, MM, DD – текущий год (4 цифры), месяц и день соответственно
- v – версия зоны за день. Если вносится несколько изменений в день, это число последовательно увеличивается на единицу.
Эта запись задает имена серверов, поддерживающих зону, т.е. ведущих ее базу. Здесь должны быть перечислены имена первичного и всех вторичных серверов. Обычно эта запись следует непосредственно за записью SOA. В поле данные заносится одно значение – имя или IP-адрес сервера DNS-зоны независимо от того, является ли он главным или подчиненным. Все указанные здесь имена должны быть полностью определенными, то есть заканчиваться точкой!
Запись типа A – это основное содержимое файлов зоны прямого преобразования или же просто «прямой» зоны, то есть выдающей имя компьютера по его адресу. Она составляется для каждого компьютера. Для удобства чтения эти записи обычно группируются в порядке возрастания IPадресов, а также группируются с записями MX, соответствующими данному IP-адресу, хотя это, конечно, не является обязательным. В поле имя заносится имя, назначаемое IP-адресу, в поле данные – IP адрес, которому назначается имя. При наличии у адреса дополнительных имен, имя, назначенное адресу записью типа A, называют основным именем.
tooth1 IN A 10.87.1.1
tooth2 IN A 10.87.1.2
tooth3 IN A 10.87.1.3
tooth4 IN A 10.87.1.4
tooth5 IN A 10.87.1.5
tooth6 IN A 10.87.1.6
В данном примере описано назначение IP-адресов компьютерам внутренней сети, которая имеет адрес 10.87.1.0/24. Для компьютеров внутренней сети, как правило, нет необходимости формирования каких-либо дополнительных записей, за исключением разве что CNAME.
Запись типа CNAME – это дополнительная возможность DNS. Она позволяет назначить одному IP-адресу более одного имени. В поле имя заносится дополнительное имя, назначаемое IP-адресу, в поле данные – основное имя, назначенное ранее записью типа A, или другое дополнительное имя, назначенное записью CNAME. При этом имя, стоящее в поле данных записи, называют каноническим (отсюда и название записи – Canonical Name). Одному IP-адресу можно назначить неограниченное количество дополнительных имен посредством записей CNAME, но в записях другого типа должно быть указано имя, назначенное записью A, а не записью CNAME. Ниже приводится пример правильного и неправильного назначения дополнительных имен.
name1 IN CNAME ns
ns IN A 10.87.1.254
name1 IN CNAME ns
Записи CNAME могут указывать одна на другую, но не более семи уровней, восьмой обязательно должна идти запись, указывающая на имя, назначенное записью типа A. В литературе встречается рекомендация использовать множественные записи типа A вместо назначения адресу множества дополнительных имен. По поводу этого можно сказать, что данный момент упоминается в RFC 2219 в плане «не существует абсолютных рекомендаций по этому поводу, каждый должен решать для себя, что для него лучше». Множественные CNAME проще для администрирования, множественные A-записи легче обрабатываются, поскольку происходит меньше перенаправлений.
Это комплексный пример, он сразу показывает использование записей MX, А и CNAME. Здесь мы:
Это совершенно особый тип записей. В нашем примере мы «специально» взяли полную подсеть, чтобы рассмотреть случай «нормальной» работы с записями PTR. Случай с сетью 212.20.5.0/31 будет рассмотрен чуть позже.
Запись PTR предназначена для осуществления обратного преобразования – имен в IP-адреса. Подобные преобразования очень широко применяются в различных программах, предоставляющих доступ к некоторым сетевым ресурсам: они проверяют соответствие прямого и обратного преобразования и в случае несовпадения или отсутствия записи PTR могут отказать в доступе. Зона, содержащая записи PTR, называется зоной обратного преобразования или же просто «обратной» зоной.
Точно так же, как для использования доменного имени необходимо его зарегистрировать, так и для использования обратного преобразования необходимо зарегистрировать обратную «зону» у координатора обратных зон. В отличие от зон прямого преобразования здесь существует только один координатор, и регистрация у него бесплатная. Регистрацией обратных зон занимается RIPE NCC [11]. Вся информация о регистрации обратной зоны приведена в [12].
Зачем нужно регистрировать обратную зону? Сервер верхнего уровня зоны in-addr.arpa должен знать, что для выполнения запроса обратного преобразования ему следует обратиться к такому-то серверу, в данном случае к нашему 212.20.5.2. Разумеется, где-либо регистрировать обратную зону внутренней подсети не нужно.
Сама запись PTR выглядит очень просто – в поле имя заносится последняя часть IP-адреса, в поле данные – полностью определенное имя прямого преобразования. Обращаю внимание на последнее – имя, заносимое в поле данных, должно быть полностью определенным, поскольку записи PTR сами задают связь между IP-адресом и именем, они не могут получить ниоткуда информацию о том, к какой зоне следует отнести не полностью квалифицированное имя прямого преобразования.
В приведенном выше примере мы задали обратное преобразование для компьютеров внутренней сети. Для сервера мы запишем одну строчку (в реальном примере директивы $ORIGIN указывать не надо, они приведены только, чтобы было понятно, о какой зоне идет речь):
Чем будет отличаться случай, когда провайдер выделяет блок 212.20.5.0/31 вместо полноценной подсети? С точки зрения формирования всех записей, кроме PTR, ничем. Процедура создания прямой зоны и ее регистрации не зависит от количества адресов, тем более что для большинства случаев много адресов и не надо. Однако с точки зрения записей PTR разница есть. В сторону упрощения. А может быть, и нет – в зависимости от провайдера. И заключается она в том, что записи:
будут находиться на вашем сервере и управляться вами, но записи:
должны быть сформированы провайдером, потому что возможность самому регистрировать обратную зону и самому ей управлять предоставляется только при наличии сети класса не менее С. Это, с одной стороны, облегчает работу – не нужно регистрироваться в RIPE, но с другой стороны, осложняет – для внесения изменений в именование сервера нужно каждый раз связываться с провайдером.
Самому BIND, конечно же, все равно, в каком порядке идут записи и как они отформатированы. Это важно только тем, кто будет сопровождать зону, особенно, если изменения в нее будут вноситься часто. Здесь я опишу распределение зон по файлам так, как это используется в тех зонах, которые я сопровождаю. Разумеется, это не единственный возможный порядок и, возможно, не лучший. Но это работает.
Зоны внешние и внутренние
BIND 8.x имел один чрезвычайно крупный недостаток – он не позволял дифференцировать выдаваемую информацию в зависимости от каких-либо факторов – приходилось либо показывать лишнее, либо скрывать нужное. Внешним клиентам совершенно нет никакой необходимости знать о наличии компьютеров внутренней сети, но, поскольку разделить информацию не было возможности, любой компьютер мог установить структуру внутренней сети посредством запросов DNS. BIND 9.x свободен от этого недостатка – он позволяет посредством списков управления доступом (Access Control List, АСL) распределить запросы по «представлениям» (views). Представления могут иметь произвольные имена, обычно создается внутреннее представление «internal», которому удовлетворяют клиенты внутренней подсети, и внешнее представление «extrenal», которому удовлетворяют все остальные. Здесь помните, что это одна и та же зона, просто показывается она по-разному – как правило, в файлах внешних зон присутствует только та информация, которая необходима внешним клиентам, – о внешнем сервере, о путях доставки почты и т. д., а в файлах внутренних зон отражается вся сетевая топология. Кроме того, если сопровождается обратная зона, то необходимо точно так же разделить по файлам информацию об адресах обратного преобразования.
Итак, вернемся к нашему примеру.
Несмотря на обширный список, файлы достаточно короткие, поэтому приводятся здесь полностью, за исключением комментариев.
Сделаем одно замечание относительно имени localhost. RFC 1912 специально упоминает настройку файлов c разрешением имени 127.0.0.1 и localhost. В нашем примере зона localhost соответствует RFC 1912, хотя в жизни вполне можно встретить разрешение имени 127.0.0.1 localhost.domain.tld и соответствующее ему обратное разрешение.
Файл localhost.rev. Использует одну запись SOA вместе с внутренней зоной обратного преобразования:
Рассмотрим вариант настройки доменного имени посредством смены NS записей доменного имени:
Переходим в раздел «Личный кабинет» — » Ваши домены «
В открывшемся разделе кликаем на интересующий нас домен
Читайте также: