Рашид Ачилов

Создаём зоны DNS

Domain Name System – своеобразная «нервная система» сети Интернет. Именно благодаря ей вы, набирая , попадаете на сайт журнала «Системный администратор», а не куда-нибудь еще. Как создать, настроить и запустить DNS-сервер для небольшого предприятия?

Структура DNS

В настоящее время Интернет – это огромная сеть, в которую входят миллионы узлов, расположенных по всему миру. Для того чтобы запрос, сделанный с одного компьютера, мог достичь цели, расположенной на другом компьютере, нужно прежде всего эту цель задать. Можно, конечно, указать IP-адрес напрямую. Если он вам известен, конечно. Но здесь существует возможность очень просто ошибиться – информация о том, где находится нужный вам адрес уже могла измениться, и в лучшем случае вы увидите сообщение о том, что адрес не найден, а в худшем – окажетесь на сайте, совершенно не имеющем никакого отношения к тому, что было нужно. Надежней и проще будет обратиться к системе, которая хранит соответствие между символическими именами типа www.сайт и IP-адресам, соответствующими им в данный момент (в нашем случае 217.144.98.99). DNS и является такой системой. Поскольку от ее успешного функционирования зависит работа всей сети Интернет, эта система функционирует по принципу распределенной базы данных – есть «хорошо известные» серверы, числом 13, их еще называют «корневыми» (root servers), содержащие информацию о серверах, содержащих информацию о серверах и т. д. Как дом, который построил Джек.

Вся сеть Интернет, которая описывается зоной «.» (точка) делится на так называемые TLD (Top Level Domains – домены верхнего уровня), распределяемые либо по функциональному, либо по географическому признаку. Существует также термин primary domain – «первичный домен», или «домен первого уровня», но этот термин используется значительно реже. Распределение по географическому признаку осуществляется в соответствии с ISO 3166, устанавливающему для всех стран мира двух- и трехбуквенные коды. Распределение по функциональному признаку осуществляется по мере необходимости создания нового TLD. Здесь следует отметить, что всеми вопросами по отношению к TLD занимается ICANN (Internet Corporation for Assigned Names and Numbers), и именно этот орган решает – создавать ли новый TLD.

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

Таким образом, процесс поиска информации, допустим, о веб-сервере www.granch.ru, будет выглядеть следующим образом:

• Клиент обращается к своему серверу DNS, адрес которого был задан системным администратором с запросом «Скажи мне адрес, соответствующий имени www.granch.ru».
• Сервер DNS знает адреса серверов, с которых ему следует начинать поиск в том случае, если в его кэше не хранится запрошенная информация, поэтому он обращается к одному из них.
• Корневой сервер присылает ему адрес сервера, отвечающего за зону.ru
• Сервер DNS обращается к серверу зоны.ru
• Сервер зоны.ru присылает ему адрес сервера, который отвечает за зону granch внутри его зоны.
• Сервер DNS обращается к серверу зоны granch.ru.
• И наконец, сервер зоны granch.ru сообщает ему адрес, соответствующий имени www. В данном случае это будет 81.1.252.58.

Данный процесс проиллюстрирован на рис. 1, где цифры обозначают последовательность запросов.

Как встроить свою информацию в структуру DNS?

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

Куда встраиваем?

За различные TLD отвечают различные сервера, и если за географические домены отвечает, как правило, один сервер (точнее говоря, одна организация), то за домены функциональные может отвечать, вообще говоря, неограниченное количество так называемых регистраторов, то есть компаний, заключивших специальные договоры с ICANN о том, что именно они будут регистрировать имена в некоторых функциональных доменах. Краткое описание функционального домена и адрес его регистратора приведены в .

Если регистраторов несколько, то дается адрес основного (например, VeriSign для домена.com). Домены.gov и.mil зарезервированы исключительно за американским правительством и американскими же военными организациями, причем резервирование.gov оформлено соответствующим RFC – RFC 2146 . Полный список всех существующих в настоящий момент географических же TLD с указанием регистратора домена и необходимой контактной информации можно посмотреть в . Хотя если, скажем, в зоне.com можно выбирать из огромного списка, то для зон.ru и.su РУЦЕНТР, , без вариантов.

Здесь надо отметить несколько моментов. Фактически зона.su относится к несуществующему государству Советский Союз (Soviet Union), хотя тем не менее продолжает обслуживаться и открыта для регистрации. Регистрация там достаточно дорогая – 100 долларов за регистрацию или поддержку в год.

Не существует никакого приоритета, согласно которому одна организация или человек имеет преимущество при регистрации домена над другим. Один американский бизнесмен, занимавшийся производством пластиковых окон, зарегистрировал домен windows2000.com. Когда то же самое попыталась сделать Microsoft, она с удивлением обнаружила, что это имя уже занято, и за него компании пришлось выложить крупную сумму. Существует даже понятие «киберсквоттерство» – процесс регистрации доменов с целью их последующей перепродажи. РУЦЕНТР тоже решил приложить к этому руку, и по новым правилам, которые вводятся с 1 июня 2006 года, освобождающиеся домены выставляются на «аукцион доменных имен» и передаются тому, кто даст больше. Имена удерживаются на «аукционе» в течение года, если за этот срок никто на него не претендует, имя выводится в свободную регистрацию.

При создании TLD, перечисленных выше, планировалось также создание TLD .xxx для сайтов с тематикой «для взрослых». ICANN отклонила это предложение. Недавно оно было вынесено на повторное голосование, и ICANN снова его отклонила . Зато появился TLD .tel , рассчитанный на использование одновременно в компьютерах и мобильных устройствах.

Существует RFC 1480, описывающий правила регистрации имен в домене.us. Правила эти чрезвычайно громоздки и запутанны и предполагают создание имен из 6-7 уровней типа Hamilton.High.LA-Unified.K12.CA.US

Каким образом встраиваем?

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

Сейчас все стало гораздо проще. И Network Solutions, и РУЦЕНТР обзавелись веб-интерфейсами, с помощью которых все вышеперечисленное (за исключением, конечно, составления файла зоны) можно сделать несколькими кликами мыши. Все данные можно исправить, дополнить или удалить в любой момент. Ранее с РУЦЕНТРом требовалось заключать договор на обслуживание, но начиная с 1 июня 2006 года в действие вводятся новые правила, согласно которым достаточно зарегистрироваться на их сайте. Зарубежные регистраторы, как правило, обходятся кредитными картами, но если домен по какой-либо причине не может быть зарегистрирован, деньги будут возвращены не ранее чем через три дня.

Регистратору потребуется указать IP-адрес и маску подсети сервера, на котором будет запущена программа DNS-сервера, и который будет содержать основную базу данных, создаваемую и редактируемую вами по мере необходимости. Этот сервер будет называться первичным сервером (master server). Кроме того, потребуется указать как минимум один IPадрес сервера, содержащего резервную копию базы на случай отказа первичного сервера. Такие серверы называют вторичными серверами (slave servers). Чтобы долго не размышлять о том, где разместить вторичный DNS, РУЦЕНТР предлагает разместить его на их площадке. Стоимость услуг РУЦЕНТРа составляет 15 долларов в год за домен в зонах.ru, .net, .com, .org, 50 долларов за домен в зонах.biz, .info, 100 долларов за домен в зоне.su и 5 долларов в год за поддержку вторичного DNS в любой (в том числе и зарегистрированной не у них) зоне.

Почему требование к наличию вторичного DNS-сервера является обязательным? Поскольку стабильность работы DNS крайне важна для стабильности работы сети Интернет в целом, то лицо или организация, регистрирующая домен, обязана удовлетворять некоторым условиям, касающимся стабильности работы DNS:

• Должно быть предусмотрено не менее двух серверов, обслуживающих данный домен.
• Эти сервера должны быть доступны не менее 22 часов в сутки.

Каких-либо требований к размещению серверов по новым правилам не выдвигается, хотя ранее требовалось наличие их в разных IP-сетях.

www.krokodil.ru

Итак, допустим, мы хотим создать сайт www.krokodil.ru (на момент написания статьи это имя было свободно), посвященный разведению крокодилов в домашних условиях. Подключение по выделенной линии есть, сеть класса С, а именно 212.20.5.0 – 212.20.5.255 (этот диапазон в настоящее время свободен) провайдером выделена. Этот пример несколько нехарактерен для нынешнего времени с его дефицитом IP-адресов, но он взят специально для того, чтобы рассмотреть создание обратной зоны. Также будет рассмотрен вариант с подключением через сеть 212.20.5.0/31. Внутренняя сеть нашей крокодиловодческой конторы состоит из шести компьютеров и будет отделена от Интернет firewall-proxy и т. д. под управлением FreeBSD. Что нам понадобится для осуществления задуманного?

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

Во-первых, нам понадобится программа DNS-сервера. На сегодняшний день только одна программа реализует требуемый набор функций. Это DNS-сервер BIND, распространяемый ISC (Internet System Consortium Inc., ) – некоммерческой организацией, которая занимается разработкой серверов 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 – адрес внутреннего интерфейса сервера. Остальные адреса будут зарезервированы для будущего расширения.

В-третьих, потребуется заранее подготовленный файл описания зоны, который будет определять небольшое количество внешних адресов: krokodil.ru – корневой сервер зоны, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru и ns.krokodil.ru. Имя ns (nameserver) является практически традиционным наименованием компьютеров, на которых работает служба DNS, хотя, конечно, никто не помешает вам назвать его, например jaws.krokodil.ru. Будут определены также имена для компьютеров внутренней сети, доступные только изнутри: tooth1.krokodil.ru – tooth6.krokodil.ru.

Записи DNS

Существует достаточно большое количество типов разнообразных записей, которые можно помещать в DNS. Обьем данной статьи позволяет рассмотреть лишь наиболее важные из них, для получения полной информации следует обратиться к соответствующим RFC: RFC 1033 и RFC 1035 определяют форматы основных записей, RFC 1122 – формат записи PTR, RFC 2782 – формат записи SRV. Мы рассмотрим только те записи, которые понадобятся для формирования файлов зон, необходимых для регистрации домена:

• Запись SOA, задающая начало описания зоны.
• Запись NS, определяющая сервера имен зоны.
• Запись A, задающая соответствие между IP-адресом и именем (прямое преобразование).
• Запись MX, описывающая настройки доставки почты для данного компьютера.
• Запись CNAME, задающая альтернативные имена.
• Запись PTR, задающая соответствие между именем и IPадресом (обратное преобразование), употребляется в описании «обратной» зоны.

Формат записей DNS общий для всех типов записей:

[имя] [класс] <тип> <данные>

• имя – это имя обьекта, с которым ассоциируются данные;
• ttl – время жизни обьекта;
• класс – класс записи;
• тип – тип записи;
• данные – ассоциируемые с данным обьектом данные.

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

• Заданием имени зоны в директиве $ORIGIN, например:

$ORIGIN krokodil.ru

• Заданием имени зоны в директиве zone конфигурационного файла BIND.

Специальный символ «@» обозначает текущее имя зоны. Имейте в виду, что директива $ORIGIN отменяет директиву zone и действует до появления следующей директивы $ORIGIN или до конца файла. До момента появления первой директивы $ORIGIN она считается заданной значению директивы zone конфигурационного файла BIND.

Если имя задано, оно должно начинаться с первой позиции строки.

TTL обычно опускается и задается глобально директивой $TTL. Директива $TTL для BIND 9.x является обязательной и, как правило, задается в самом начале файла. В поле данных этой директивы задается время жизни (в секундах) элемента, в течение которого он может находиться в кэше и считаться достоверным. В данном примере это двое суток (48 часов).

$TTL 172800

Класс записи может принимать одно из следующих значений:

• IN – запись ресурсов Интернет.
• CH – запись ресурсов ChaosNet – совершенно незнакомой российскому пользователю сети, применявшейся на машинах фирмы Symbolics.
• HS – запись ресурсов Hesiod – служебного протокола BIND.

Тип записи – один из типов, перечисленных выше.

Следует обратить внимание на то, что поля имя, ttl и класс могут быть опущены. При этом в качестве их значений принимается последнее определенное значение (при этом задание @ будет корректным определением), а если значение не было определено нигде, то для поля класс принимается значение по умолчанию «IN», для других полей – приводит к сообщению об ошибке.

Кроме записей, в файле зоны могут быть команды. Всего команд четыре – $TTL, $ORIGIN, $INCLUDE и $GENERATE. Описание команды $GENERATE приведено в документации на программу BIND, а также в и , команда $INCLUDE работает соответственно своему написанию – включает указанный файл в текущий файл.

Примечание: знак «;» (точка с запятой) является признаком комментария.

Запись SOA

Эта запись определяет начало зоны. Любая зона должна начинаться с записи SOA. Появление другой записи SOA автоматически заканчивает первую зону и начинает вторую. Формат записи SOA приведен ниже. Фактически запись SOA именует зону и задает для нее некоторые умолчания.

2005122001 ; Serial number

3600 ; Retry every hour

172800) ; Minimum 2 days

Разберем пример. Знак @ в поле имени означает, что необходимо взять имя зоны, заданное ранее директивой $ORIGIN. Класс записи – IN, тип записи – SOA. SOA – это единственная запись, которая имеет такой сложный список параметров.

Первый параметр – это адрес главного сервера имен зоны. В данном примере это krokodil.ru. Второй параметр – адрес электронной почты лица, ответственного за данную зону. Обратите внимание, что адрес записан как «username.domain», а не «username@domain».

Второй параметр – это список значений, заключенный в скобки. Теоретически возможно его записать в одну строку, но практически я нигде этого не видел, всюду употребляется форма записи, приведенная в примере. Список состоит из пяти элементов:

• Серийный номер зоны . Этот параметр играет чрезвычайно важную роль в распространении обновления, выполненного на первичном сервере, по всем его вторичным серверам. Необходимо каким-то образом сообщить вторичному серверу о том, что данные на первичном сервере изменились. Если первичный сервер был перезапущен, то он отсылает всем вторичным серверам извещение о возможном изменении (DNS NOTIFY). Получив это извещение, вторичный сервер запрашивает серийный номер – если на первичном сервере серийный номер больше, чем на вторичном, вторичный сервер выполняет команду обновления зоны. Кроме того, вторичный сервер выполняет периодические проверки серийного номера с той же целью. Поэтому следует запомнить одно простое правило: исправил зону – увеличь серийный номер! Среди администраторов DNS распространена практика, в соответствии с которой серийный номер формируется следующим образом: YYYYMMDDv, где:
  • YYYY, MM, DD – текущий год (4 цифры), месяц и день соответственно
  • v – версия зоны за день. Если вносится несколько изменений в день, это число последовательно увеличивается на единицу.
Конечно, вас никто не будет обязывать следовать подобной практике. Например, сервера DNS в Windows ее не придерживаются, а просто нумеруют ее 1, 2, 3 и т. д.
• Значение периода обновления, по истечении которого подчиненный сервер должен связаться с главным и проверить, не изменился ли серийный номер зоны . Если серийный номер изменился, подчиненный сервер загрузит новые данные. В данном примере 10800 секунд (3 часа).
• Время, через которое подчиненный сервер будет пытаться обратиться к главному, если попытка получить новый серийный номер закончилась неудачно . В данном примере 3600 секунд (один час).
• Время, в течение которого подчиненные сервера будут обслуживать запросы по данной зоне при длительном отсутствии главного сервера . Система должна работать, даже если главный сервер не работает длительный период времени, поэтому в значении данного параметра задано 1728000 секунд (20 суток).
• Время кэширования отрицательных ответов . В данном примере 172800 секунд (2 суток).

Запись NS

Эта запись задает имена серверов, поддерживающих зону, т.е. ведущих ее базу. Здесь должны быть перечислены имена первичного и всех вторичных серверов. Обычно эта запись следует непосредственно за записью SOA. В поле данные заносится одно значение – имя или IP-адрес сервера DNS-зоны независимо от того, является ли он главным или подчиненным. Все указанные здесь имена должны быть полностью определенными, то есть заканчиваться точкой!

IN NS ns.krokodil.ru.

IN NS ns4.nic.ru.

В приведенном примере описывается сначала главный сервер нашей зоны ns.krokodil.ru, а потом подчиненный сервер – узел РУЦЕНТРа ns4.nic.ru.

Запись A

Запись типа 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

Запись типа CNAME – это дополнительная возможность DNS. Она позволяет назначить одному IP-адресу более одного имени. В поле имя заносится дополнительное имя, назначаемое IP-адресу, в поле данные – основное имя, назначенное ранее записью типа A, или другое дополнительное имя, назначенное записью CNAME. При этом имя, стоящее в поле данных записи, называют каноническим (отсюда и название записи – Canonical Name). Одному IP-адресу можно назначить неограниченное количество дополнительных имен посредством записей CNAME, но в записях другого типа должно быть указано имя, назначенное записью A, а не записью CNAME. Ниже приводится пример правильного и неправильного назначения дополнительных имен.

Правильно:

ns IN A 10.87.1.1

name1 IN CNAME ns

IN MX 10 ns

Неправильно:

ns IN A 10.87.1.254

name1 IN CNAME ns

IN MX 10 name1

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

Запись MX

Запись типа MX – это второй основной элемент файла зоны. Эта запись расшифровывается как «Mail eXchanger», и предназначена для указания IP-адресов или имен компьютеров, которые принимают почту для узла, описанного в поле name. В этом поле может быть пусто, а также указано полностью или не полностью определенное имя. Если в поле name пусто или указано не полностью определенное имя, то имя дополняется из директивы $ORIGIN. Формирование записей MX в сложных случаях, когда настраивается достаточно большая зона с разветвленной схемой приема почты, – весьма нетривиальная задача, которая тесно переплетается с работой программ, использующих протокол SMTP для доставки почты, поэтому мы рассмотрим только наиболее простой случай – вся почта принимается сервером UNIX. В поле данные заносятся два значения – приоритет и имя или IP-адрес компьютера, принимающего почту, направляемую на данный компьютер. С одним IP-адресом может быть связано, вообще говоря, неограниченное количество записей типа MX, и все они должны иметь разный приоритет. Почта направляется в соответствии с приоритетом – почтовый агент сортирует записи в порядке нарастания приоритетов и именно так предпринимает попытки доставить почту. Предположим, мы договорились с админом узла behemot.ru о том, что сможем использовать его сервер как транзитный узел, который будет получать нашу почту с целью последующей доставки ее адресатам, когда связь восстановится. Тогда описание сервера krokodil.ru будет выглядеть следующим образом:

krokodil.ru. IN A 212.20.5.2

IN MX 10 krokodil.ru.

IN MX 50 behemot.ru.

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

Это комплексный пример, он сразу показывает использование записей MX, А и CNAME. Здесь мы:

• Назначаем адресу 212.20.5.2 имя krokodil.ru.
• Указываем, что почту, направляемую по адресам типа [email protected], будут принимать (в указанном порядке):
• сервер krokodil.ru;
• сервер behemot.ru.
• Определяем дополнительные имена www.krokodil.ru, mail.krokodil.ru и ftp.krokodil.ru. Обратите внимание, что все имена в правой части полностью определенны, то есть заканчиваются на точку. Если этого не сделать, то в конец имени будет автоматически подставляться значение текущей директивы $ORIGIN. В данном случае это привело бы к появлению имен типа www.krokodil.ru.krokodil.ru.

Запись PTR

Это совершенно особый тип записей. В нашем примере мы «специально» взяли полную подсеть, чтобы рассмотреть случай «нормальной» работы с записями PTR. Случай с сетью 212.20.5.0/31 будет рассмотрен чуть позже.

Запись PTR предназначена для осуществления обратного преобразования – имен в IP-адреса. Подобные преобразования очень широко применяются в различных программах, предоставляющих доступ к некоторым сетевым ресурсам: они проверяют соответствие прямого и обратного преобразования и в случае несовпадения или отсутствия записи PTR могут отказать в доступе. Зона, содержащая записи PTR, называется зоной обратного преобразования или же просто «обратной» зоной.

Записи PTR не имеют никакого отношения к записям A, MX, CNAME и другим, описывающим прямое преобразование. Сделано это намеренно с целью использовать для обоих преобразований один и тот же набор программных модулей. Здесь, правда, нас ожидает сложность следующего вида – полностью определенное доменное имя вида www.krokodil.ru. «наращивает размерность» слева направо (то есть укрупнение узлов идет по мере продвижения по тексту имени слева направо), а IP-адрес 212.20.5.2 – справа налево. Для унификации программных модулей приняли следующую условность: все IP-адреса – это имена, входящие в специальный TLD in-addr.arpa. «Зонами» в этом домене являются подсети, а имя зоны записывается в виде IP-адреса, читаемого наоборот. Таким образом «имя» нашей обратной зоны будет 5.20.212.in-addr.arpa для обратной зоны, содержащей описание для внешней сети и 1.87.10.in-addr.arpa для обратной зоны, содержащей описание внутренней сети.

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

Зачем нужно регистрировать обратную зону? Сервер верхнего уровня зоны in-addr.arpa должен знать, что для выполнения запроса обратного преобразования ему следует обратиться к такому-то серверу, в данном случае к нашему 212.20.5.2. Разумеется, где-либо регистрировать обратную зону внутренней подсети не нужно.

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

$ORIGIN 1.87.10.in-addr.arpa

1 IN PTR tooth1.krokodil.ru.

2 IN PTR tooth2.krokodil.ru.

3 IN PTR tooth3.krokodil.ru.

4 IN PTR tooth4.krokodil.ru.

5 IN PTR tooth5.krokodil.ru.

6 IN PTR tooth6.krokodil.ru.

В приведенном выше примере мы задали обратное преобразование для компьютеров внутренней сети. Для сервера мы запишем одну строчку (в реальном примере директивы $ORIGIN указывать не надо, они приведены только, чтобы было понятно, о какой зоне идет речь):

$ORIGIN 5.20.212.in-addr.arpa

2 IN PTR krokodil.ru

Здесь необходимо отметить, что записи CNAME для задания множественного обратного соответствия не используются, поэтому при запросе «какое имя соответствует адресу 212.20.5.2» результатом всегда будет krokodil.ru независимо от количества установленных для него псевдонимов.

Чем будет отличаться случай, когда провайдер выделяет блок 212.20.5.0/31 вместо полноценной подсети? С точки зрения формирования всех записей, кроме PTR, ничем. Процедура создания прямой зоны и ее регистрации не зависит от количества адресов, тем более что для большинства случаев много адресов и не надо. Однако с точки зрения записей PTR разница есть. В сторону упрощения. А может быть, и нет – в зависимости от провайдера. И заключается она в том, что записи:

gate.krokodil.ru. IN A 212.20.5.1

krokodil.ru. IN A 212.20.5.2

будут находиться на вашем сервере и управляться вами, но записи:

1 IN PTR gate.krokodil.ru.

2 IN PTR krokodil.ru.

должны быть сформированы провайдером, потому что возможность самому регистрировать обратную зону и самому ей управлять предоставляется только при наличии сети класса не менее С. Это, с одной стороны, облегчает работу – не нужно регистрироваться в RIPE, но с другой стороны, осложняет – для внесения изменений в именование сервера нужно каждый раз связываться с провайдером.

Файловая структура

Самому BIND, конечно же, все равно, в каком порядке идут записи и как они отформатированы. Это важно только тем, кто будет сопровождать зону, особенно, если изменения в нее будут вноситься часто. Здесь я опишу распределение зон по файлам так, как это используется в тех зонах, которые я сопровождаю. Разумеется, это не единственный возможный порядок и, возможно, не лучший. Но это работает.

Зоны внешние и внутренние

BIND 8.x имел один чрезвычайно крупный недостаток – он не позволял дифференцировать выдаваемую информацию в зависимости от каких-либо факторов – приходилось либо показывать лишнее, либо скрывать нужное. Внешним клиентам совершенно нет никакой необходимости знать о наличии компьютеров внутренней сети, но, поскольку разделить информацию не было возможности, любой компьютер мог установить структуру внутренней сети посредством запросов DNS. BIND 9.x свободен от этого недостатка – он позволяет посредством списков управления доступом (Access Control List, АСL) распределить запросы по «представлениям» (views). Представления могут иметь произвольные имена, обычно создается внутреннее представление «internal», которому удовлетворяют клиенты внутренней подсети, и внешнее представление «extrenal», которому удовлетворяют все остальные. Здесь помните, что это одна и та же зона, просто показывается она по-разному – как правило, в файлах внешних зон присутствует только та информация, которая необходима внешним клиентам, – о внешнем сервере, о путях доставки почты и т. д., а в файлах внутренних зон отражается вся сетевая топология. Кроме того, если сопровождается обратная зона, то необходимо точно так же разделить по файлам информацию об адресах обратного преобразования.

Итак, вернемся к нашему примеру.

Файловая структура будет следующей. У нас имеется прямая зона krokodil.ru и обратная зона 5.20.212.in-addr.arpa. Кроме того, обязательно должна присутствовать обратная зона зона 0.0.127.in-addr.arpa для обеспечения корректного обратного преобразования localhost 127.0.0.1. Зона эта нужна для того, чтобы BIND не пытался запрашивать корневые сервера о самом себе, что происходит, когда 127.0.0.1 указывает на «localhost.» Запись прямого преобразования 127.0.0.1 localhost.krokodil.ru будет занесена в файл прямого преобразования внутренней зоны. Для того чтобы не загружать сеть передачей бесполезных данных, для внешних и внутренних зон используются разные записи SOA – записи во внешних зонах меняются весьма редко, а во внутренних довольно часто. Следовательно, мы имеем следующие файлы:

• localhost.rev – файл зоны обратного преобразования 0.0.127.in-addr.arpa. Этот файл существует только для внутреннего представления.
• zone212.rev – файл зоны обратного преобразования 5.20.212.in-addr.arpa.
• zone10.rev – файл внутренней зоны обратного преобразования 1.87.10.in-addr.arpa.
• direct-krokodil-ru.int – файл внутренней зоны прямого преобразования krokodil.ru.
• direct-krokodil-ru.ext – файл внешней зоны прямого преобразования krokodil.ru.
• krokodil-ru-int.soa – файл с записями SOA и NS для внутренних зон.
• krokodil-ru-ext.soa – файл с записями SOA и NS для внешних зон.

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

Сделаем одно замечание относительно имени localhost. RFC 1912 специально упоминает настройку файлов c разрешением имени 127.0.0.1 и localhost. В нашем примере зона localhost соответствует RFC 1912, хотя в жизни вполне можно встретить разрешение имени 127.0.0.1 localhost.domain.tld и соответствующее ему обратное разрешение.

Файл localhost.rev. Использует одну запись SOA вместе с внутренней зоной обратного преобразования:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

1 IN PTR localhost.

Файл zone212.rev:

1 IN PTR gate.krokodil.ru.

2 IN PTR krokodil.ru.

Файл zone10.rev:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

1 IN PTR tooth1.krokodil.ru.

2 IN PTR tooth2.krokodil.ru.

3 IN PTR tooth3.krokodil.ru.

4 IN PTR tooth4.krokodil.ru.

5 IN PTR tooth5.krokodil.ru.

6 IN PTR tooth6.krokodil.ru.

Файл direct-krokodil-ru.int:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

krokodil.ru. IN A 10.87.1.254

IN MX 10 krokodil.ru.

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

proxy IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

ns IN CNAME krokodil.ru.

localhost. IN A 127.0.0.1

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

Файл direct-krokodil-ru.ext:

$INCLUDE /etc/namedb/krokodil-ru-ext.soa

krokodil.ru. IN A 212.20.5.2

IN MX 10 krokodil.ru.

IN MX 50 behemot.ru.

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

gate IN A 212.20.5.1

Файл krokodil-ru-int.soa:

@ IN SOA krokodil.ru. hostmaster.krokodil.ru. (

2006051202 ; Serial number

10800 ; Refresh every 3 hours

3600 ; Retry every hour

1728000 ; Expire every 20 days

172800); Minimum 2 days

IN NS krokodil.ru.

Файл krokodil-ru-ext.soa:

$TTL 172800

@ IN SOA korkodil.ru. hostmaster.krokodil.ru. (

2005122001 ; Serial number

10800 ; Refresh every 3 hours

3600 ; Retry every hour

1728000 ; Expire every 20 days

172800); Minimum 2 days

IN NS krokodil.ru.

IN NS ns4.nic.ru.

Заключение

Как создать, настроить и запустить DNS-сервер для небольшого предприятия? На самом деле не так сложно, как кажется изначально, – достаточно пройти этот путь один раз, дальнейшие действия будут идти «на автомате».

Приложение

Домены верхнего уровня

Первоначально, согласно RFC 920, в списке функциональных TLD присутствовали только.com, .gov, .mil, .edu, .org , которые представляли соответственно коммерческие, правительственные, военные организации, образовательные учреждения и некоммерческие организации. Впоследствии этот список несколько расширился – в 1985 г. добавился TLD .net, представляющий организации-поставщики сетевых услуг, а в 1988 – TLD .int, представляющий международные организации. В 2001-2002 к этому списку добавились практические неизвестные российскому пользователю TLD .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro и.travel. Более подробная информация приведена в . Географические же домены распределены раз и навсегда. Хотя это не значит, что вы не можете зарегистрировать в нем свой домен. Многие географические домены, случайно совпавшие с «хорошо известными» сокращениями, являются чрезвычайно привлекательными. Например, .md (Молдавия) очень привлекательна для медицинских учреждений и жителей штата Мэриленд, США; .tv (Тувалу) – для сайтов, связанных с телевидением; .tm (Туркменистан) совпадает с написанием сокращения «Trade Mark», а.nu (Ниуэ – есть такой остров-колония) – для сайтов в стиле «ню».

http://www.ripe.net .

http://www.ripe.net/rs/reverse/rdns-project/index.html .

Немет Э., Снайдер Г., Сибасс С., Хейн Т.Р. UNIX: руководство системного администратора. Для профессионалов/Пер. с англ. – Спб.:Питер; К.: Издательская группа BHV, 2002 г. – 928 с.: ил.

Cricket Liu, Paul Albitz, DNS and BIND, Third Edition, 1998 (изд-во O’Reilly, ISBN 1-56592-512-2).

Историческая справка : Систему доменных имен разработал в 1983 году Пол Мокапетрис. Тогда же было проведено первое успешное тестирование DNS, ставшей позже одним из базовых компонентов сети Internet. С помощью DNS стало возможным реализовать масштабируемый распределенный механизм, устанавливающий соответствие между иерархическими именами сайтов и числовыми IP-адресами.

В 1983 году Пол Мокапетрис работал научным сотрудником института информатики (Information Sciences Institute, ISI ), входящего в состав инженерной школы университета Южной Калифорнии (USC ). Его руководитель, Джон Постел, предложил Полу придумать новый механизм, устанавливающий связи между именами компьютеров и адресами Internet, - взамен использовавшемуся тогда централизованному каталогу имен и адресов хостов, который поддерживала калифорнийская компания SRI International.

"Все понимали, что старая схема не сможет работать вечно, - вспоминает Мокапетрис. - Рост Internet становился лавинообразным. К сети, возникшей на основе проекта ARPANET, инициированного Пентагоном, присоединялись все новые и новые компании и исследовательские институты".

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

"Как только организация подключалась к сети, она могла использовать сколь угодно много компьютеров и сама назначать им имена", - подчеркнул Мокапетрис. Названия доменов компаний получили суффикс.com, университетов - .edu и так далее.

Первоначально DNS была рассчитана на поддержку 50 млн. записей и допускала безопасное расширение до нескольких сотен миллионов записей. По оценкам Мокапетриса, сейчас насчитывается около 1 млрд. имен DNS, в том числе почти 20 млн. общедоступных имен. Остальные принадлежат системам, расположенным за межсетевыми экранами. Их имена неизвестны обычным Internet-пользователям.

Новая система внедрялась постепенно, в течение нескольких лет. В это время ряд исследователей экспериментировали с ее возможностями, а Мокапетрис занимался в ISI обслуживанием и поддержанием стабильной работы "корневого сервера", построенного на мэйнфреймах компании Digital Equipment. Копии таблиц хостов хранились на каждом компьютере, подключенном к Internet, еще примерно до 1986 года. Затем начался массовый переход на использование DNS.

Необходимость отображения имен сетевых узлов в IP-адреса

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

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

Использование локального файла hosts и системы доменных имен DNS для разрешения имен сетевых узлов

На начальном этапе развития сетей, когда количество узлов в каждой сети было небольшое, достаточно было на каждом компьютере хранить и поддерживать актуальное состояние простого текстового файла, в котором содержался список сетевых узлов данной сети. Список устроен очень просто - в каждой строке текстового файла содержится пара "IP-адрес - имя сетевого узла". В системах семейства Windows данный файл расположен в папке %system root%\system32\drivers\etc (где %system root% обозначает папку, в которой установлена операционная система). Сразу после установки системы Windows создается файл hosts с одной записью 127.0.0.1 localhost.

С ростом сетей поддерживать актуальность и точность информации в файле hosts становится все труднее. Для этого надо постоянно обновлять содержимое этого файла на всех узлах сети. Кроме того, такая простая технология не позволяет организовать пространство имен в какую-либо структуру. Поэтому появилась необходимость в централизованной базе данных имен, позволяющей производить преобразование имен в IP-адреса без хранения списка соответствия на каждом компьютере. Такой базой стала DNS (Domain Name System) - система именования доменов, которая начала массовую работу в 1987 году.

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

Служба DNS: пространство имен, домены

DNS - это иерархическая база данных , сопоставляющая имена сетевых узлов и их сетевых служб IP-адресам узлов. Содержимое этой базы, с одной стороны, распределено по большому количеству серверов службы DNS, а с другой стороны, является централизованно управляемым. В основе иерархической структуры базы данных DNS лежит доменное пространство имен (domain namespace), основной структурной единицей которого является домен, объединяющий сетевые узлы (хосты), а также поддомены. Процесс поиска в БД службы DNS имени некоего сетевого узла и сопоставления этому имени IP-адреса называется "разрешением имени узла в пространстве имен DNS".

Служба DNS состоит из трех основных компонент:

Пространство имен DNS и соответствующие ресурсные записи (RR, resource record) - это сама распределенная база данных DNS;

Серверы имен DNS - компьютеры, хранящие базу данных DNS и отвечающие на запросы DNS-клиентов;

DNS-клиенты (DNS-clients, DNS-resolvers) -компьютеры, посылающие запросы серверам DNS для получения ресурсных записей.

Пространство имен.

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

Рис. 4.8.

Для доменов 1-го уровня различают 3 категории имен:

ARPA - специальное имя, используемое для обратного разрешения DNS (из IP-адреса в полное имя узла);

Общие (generic) имена 1-го уровня - 16 (на данный момент) имен, назначение которых приведено в табл. 4.4 ;

Двухбуквенные имена для стран - имена для доменов, зарегистрированных в соответствующих странах (например, ru - для России, ua - для Украины, uk - для Великобритании и т.д.).

Таблица 4.4.
Имя домена	Назначение
	Сообщества авиаторов
	Компании (без привязки к стране)
	Коммерческие организации, преимущественно в США (например, домен microsoft.com для корпорации Microsoft)
	Кооперативы
	Образовательные учреждения в США
	Правительственные учреждения США
	Домен для организаций, предоставляющих любую информацию для потребителей
	международные организации (например, домен nato .int для НАТО)
	Военные ведомства США
	Глобальный домен для частных лиц
	Домен для Интернет-провайдеров и других организаций, управляющих структурой сети Интернет
	Некоммерческие и неправительственные организации, преимущественно в США
	Домен для профессиональных объединений (врачей, юристов, бухгалтеров и др.)
	Кадровые агентства
	Туроператоры

Для непосредственного отображения пространства имен в пространство IP-адресов служат т.н. ресурсные записи (RR, resource record). Каждый сервер DNS содержит ресурсные записи для той части пространства имен, за которую он несет ответственность (authoritative ). табл. 4.5 содержит описание наиболее часто используемых типов ресурсных записей.

Таблица 4.5.
Тип ресурсной записи	Функция записи	Описание использования
	Host Address Адрес хоста, или узла	Отображает имя узла на IP-адрес (например, для домена microsoft.com узлу с именем www.microsoft.com сопоставляется IP-адрес с помощью такой записи: www A 207.46.199.60)
	Canonical Name (alias) Каноническое имя (псевдоним)	Отображает одно имя на другое
	Mail Exchanger Обмен почтой	Управляет маршрутизацией почтовых сообщений для протокола SMTP
	Name Server Сервер имен	Указывает на серверы DNS, ответственные за конкретный домен и его поддомены
	Pointer Указатель	Используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa
	Start of Authority Начальная запись зоны	Используется для указания основного сервера для данной зоны и описания свойств зоны
	Service Locator Указатель на службу	Используется для поиска серверов, на которых функционируют определенные службы (например, контроллеры доменов Active Directory или серверы глобального каталога )

Полное имя узла (FQDN, fully qualified domain name) состоит из нескольких имен, называемых метками (label) и разделенных точкой. Самая левая метка относится непосредственно к узлу, остальные метки - список доменов от домена первого уровня до того домена, в котором находится узел (данный список просматривается справа налево).

Серверы имен DNS.

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

DNS-клиенты.

DNS-клиент - это любой сетевой узел, который обратился к DNS-серверу для разрешения имени узла в IP-адрес или, обратно, IP-адреса в имя узла.

Служба DNS: домены и зоны

Как уже говорилось выше, каждый DNS-сервер отвечает за обслуживание определенной части пространства имен DNS. Информация о доменах, хранящаяся в БД сервера DNS, организуется в особые единицы, называемые зонами (zones). Зона - основная единица репликации данных между серверами DNS. Каждая зона содержит определенное количество ресурсных записей для соответствующего домена и, быть может, его поддоменов.

Системы семейства Windows Server поддерживают следующие типы зон:

Стандартная основная (standard primary) - главная копия стандартной зоны; только в данном экземпляре зоны допускается производить какие-либо изменения, которые затем реплицируются на серверы, хранящие дополнительные зоны;

Стандартная дополнительная (standard secondary) - копия основной зоны, доступная в режиме "только-чтение", предназначена для повышения отказоустойчивости и распределения нагрузки между серверами, отвечающими за определенную зону; процесс репликации изменений в записях зон называется "передачей зоны" (zone transfer ) (информация в стандартных зонах хранится в текстовых файлах, файлы создаются в папке "%system root%\system32\dns", имя файла, как правило, образуется из имени зоны с добавлением расширения файла ".dns"; термин "стандартная" используется только в системах семейства Windows);

Интегрированная в Active Directory (Active Directory–integrated) - вся информация о зоне хранится в виде одной записи в базе данных Active Directory (такие типы зон могут существовать только на серверах Windows, являющихся контроллерами доменов Active Directory; в интегрированных зонах можно более жестко управлять правами доступа к записям зоны; изменения в записях зоны между разными экземплярами интегрированной зоны производятся не потехнологии передачи зоны службой DNS, а механизмами репликации службы Active Directory);

Зона-заглушка (stub ; только в Windows 2003) - особый тип зоны, которая для данной части пространства имен DNS содержит самый минимальный набор ресурсных записей (начальная запись зоны SOA, список серверов имен, отвечающих за данную зону, и несколько записей типа A для ссылок на серверы имен для данной зоны).

Рассмотрим на примере соотношение между понятиями домена и зоны. Проанализируем информацию, представленную на рис. 4.9 .

Рис. 4.9.

В данном примере пространство имен DNS начинается с домена microsoft.com , который содержит 3 поддомена: sales.microsoft.com , it.microsoft.com иedu.microsoft.com (домены на рисунке обозначены маленькими горизонтальными овалами). Домен - понятие чисто логическое, относящееся только к распределению имен. Понятие домена никак не связано с технологией хранения информации о домене. Зона - это способ представления информации о домене и его поддоменах в хранилище тех серверов DNS, которые отвечают за данный домен и поддомены. В данной ситуации, если для хранения выбрана технология стандартных зон, то размещение информации о доменах может быть реализовано следующим образом:

записи, относящиеся к доменам microsoft.com и edu.microsoft.com , хранятся в одной зоне в файле "microsoft.com.dns" (на рисунке зона обозначена большим наклонным овалом);

управление доменами sales.microsoft.com и it.microsoft.com делегировано другим серверам DNS, для этих доменов на других серверах созданы соответствующие файлы "sales.microsoft.com.dns" и "it.microsoft.com.dns" (данные зоны обозначены большими вертикальными овалами).

Делегирование управления - передача ответственности за часть пространства имен другим серверам DNS.

Зоны прямого и обратного просмотра

Зоны, рассмотренные в предыдущем примере, являются зонами прямого просмотра (forward lookup zones) . Данные зоны служат для разрешения имен узлов в IP-адреса. Наиболее часто используемые для этого типы записей: A, CNAME, SRV.

Для определения имени узла по его IP-адресу служат зоны обратного просмотра (reverse lookup zones), основной тип записи в "обратных" зонах - PTR. Для решения данной задачи создан специальный домен с именем in-addr.arpa. Для каждой IP-сети в таком домене создаются соответствующие поддомены, образованные из идентификатора сети, записанного в обратном порядке. Записи в такой зоне будут сопоставлять идентификатору узла полное FQDN-имя данного узла. Например, для IP-сети 192.168.0.0/24 необходимо создать зону с именем "0.168.192.in-addr.arpa". Для узла с IP-адресом 192.168.0.10 и именем host.company.ru в данной зоне должна быть создана запись "10 PTR host.company.ru".

Алгоритмы работы итеративных и рекурсивных запросов DNS

Все запросы , отправляемые DNS-клиентом DNS-серверу для разрешения имен, делятся на два типа:

итеративные запросы (клиент посылает серверу DNS запрос , в котором требует дать наилучший ответ без обращений к другим DNS-серверам);

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

Обычные DNS-клиенты (например, рабочие станции пользователей), как правило, посылают рекурсивные запросы.

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

Допустим, что пользователь запустил программу Обозреватель Интернета и ввел в адресной строке адрес http://www.microsoft.com . Прежде чем Обозреватель установит сеанс связи с веб-сайтом по протоколу HTTP, клиентский компьютер должен определить IP-адрес веб-сервера. Для этого клиентская часть протокола TCP/IP рабочей станции пользователя (так называемый resolver ) сначала просматривает свой локальный кэш разрешенных ранее имен в попытке найти там имяwww.microsoft.com . Если имя не найдено, то клиент посылает запрос DNS-серверу, указанному в конфигурации TCP/IP данного компьютера (назовем данный DNS-сервер "локальным DNS-сервером" ), на разрешение имени www.microsoft.com в IP-адрес данного узла. Далее DNS-сервер обрабатывает запрос в зависимости от типа запроса.

Вариант 1 (итеративный запрос).

Если клиент отправил серверу итеративный запрос (напомним, что обычно клиенты посылают рекурсивные запросы), то обработка запроса происходит по следующей схеме:

microsoft.com ;

если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

www.microsoft.com в своем кэше разрешенных ранее DNS-запросов;

если искомое имя есть в кэше, то результат поиска возвращается клиенту; если локальный DNS-сервер не нашел в своей базе данных искомую запись, то клиенту посылается IP-адрес одного из корневых серверов DNS;

клиент получает IP-адрес корневого сервера и повторяет ему запрос на разрешение имени www.microsoft.com ;

корневой сервер не содержит в своей БД зоны "microsoft.com", но ему известны DNS-серверы, отвечающие за зону "com", и корневой сервер посылает клиенту IP-адрес одного из серверов, отвечающих за эту зону;

клиент получает IP-адрес сервера, отвечающего за зону "com", и посылает ему запрос на разрешение имени www.microsoft.com ;

сервер, отвечающий за зону com, не содержит в своей БД зоны microsoft.com , но ему известны DNS-серверы, отвечающие за зону microsoft.com , и данный DNS-сервер посылает клиенту IP-адрес одного из серверов, отвечающих уже за зону microsoft.com ;

клиент получает IP-адрес сервера, отвечающего за зону microsoft.com , и посылает ему запрос на разрешение имени www.microsoft.com ;

сервер, отвечающий за зону microsoft.com , получает данный запрос, находит в своей базе данных IP-адрес узла www, расположенного в зоне microsoft.com , и посылает результат клиенту;

клиент получает искомый IP-адрес, сохраняет разрешенный запрос в своем локальном кэше и передает IP-адрес веб-сайта программе Обозреватель Интернета (после чего Обозреватель устанавливает связь с веб-сайтом по протоколу HTTP).

Вариант 2 (рекурсивный запрос ).

Если клиент отправил серверу рекурсивный запрос , то обработка запроса происходит по такой схеме:

сначала локальный DNS-сервер ищет среди зон, за которые он отвечает, зону microsoft.com ; если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

в противном случае локальный DNS-сервер ищет запрошенное имя www.microsoft.com в своем кэше разрешенных ранее DNS-запросов; если искомое имя есть в кэше, то результат поиска возвращается клиенту;

если локальный DNS-сервер не нашел в своей базе данных искомую запись, то сам локальный DNS-сервер выполняет серию итеративных запросов на разрешение имени www.microsoft.com , и клиенту посылается либо найденный IP-адрес, либо сообщение об ошибке.

Реализация службы DNS в системах семейства Windows Server

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

поддержка службой DNS динамической регистрации (dynamic updates);

поддержка службой DNS записей типа SRV.

Служба DNS систем Windows Server удовлетворяет обоим условиям, и реализация служб каталогов Active Directory может быть обеспечена только серверами на базе систем Windows Server.

Рассмотрим несколько простых примеров управления службой DNS:

установка службы DNS;

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

создание зоны обратного просмотра;

выполнение динамической регистрации узлов в зоне.

сеть состоит из двух серверов Windows 2003 Server;

операционная система - ограниченная по времени 120-дневная русская версия Windows 2003 Server Enterprise Edition;

первый сервер установлен на ПК с процессором Intel Pentium-4 3Ггц и оперативной памятью 512 МБ, имя сервера - DC1, IP-адрес - 192.168.0.1/24 ;

второй сервер работает в качестве виртуальной системы с помощью Microsoft VirtualPC 2004, имя сервера -DC2, IP-адрес - 192.168.0.2/24 ;

имя домена в пространстве DNS и соответствующее имя в службе каталогов Active Directory - world.ru (сеть полностью изолирована от других сетей, поэтому в данном примере авторы были свободны в выборе имени домена; в реальной обстановке конкретного учебного заведения преподавателю нужно скорректировать данную информацию).

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

Установка службы DNS

Установка службы DNS (как и других компонент системы) производится достаточно просто с помощью мастера установки компонент Windows:

Откройте Панель управления .

Выберите пункт "Установка и удаление программ" .

Нажмите кнопку "Установка компонентов Windows" .

Выберите "Сетевые службы" - кнопка "Дополнительно" (ни в коем случае не снимайте галочку у названия "Сетевые службы" ).

Отметьте службу DNS.

Рис. 4.10.

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

Выполним данное действие на обоих серверах.

Создание основной зоны прямого просмотра .

На сервере DC1 создадим стандартную основную зону с именем world.ru.

Откроем консоль DNS.

Выберем раздел "Зоны прямого просмотра" .

Запустим мастер создания зоны (тип зоны - "Основная" , динамические обновления - разрешить, остальные параметры - по умолчанию).

Введем имя зоны - world.ru.

Разрешим передачу данной зоны на любой сервер DNS (Консоль DNS - зона world.ru - Свойства - Закладка "Передачи зон" - Отметьте "Разрешить передачи" и"На любой сервер" ).

Создание дополнительной зоны прямого просмотра .

На сервере DC2 создадим стандартную дополнительную зону с именем world.ru.

Откроем консоль DNS.

Выберем раздел "Зоны прямого просмотра"

"Дополнительная" , IP-адрес master-сервера (с которого будет копироваться зона) - адрес сервера DC1, остальные параметры - по умолчанию)

Введем имя зоны - world.ru.

Проверим в консоли DNS появление зоны.

Настройка узлов для выполнения динамической регистрации на сервер DNS .

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

Сервер DNS.

Создать соответствующую зону.

Разрешить динамические обновления.

Это нами уже выполнено.

Клиент DNS.

Указать в настройках протокола TCP/IP адрес предпочитаемого DNS-сервера - тот сервер, на котором разрешены динамические обновления (в нашем примере - сервер DC1).

В полном имени компьютера указать соответствующий DNS-суффикс (в нашем примере - world.ru). Для этого - "Мой компьютер" - "Свойства" - Закладка"Имя компьютера" - Кнопка "Изменить" - Кнопка "Дополнительно" - в пустом текстовом поле впишем название домена world.ru - кнопка "ОК" (3 раза)).

Рис. 4.11.

После этого система предложит перезагрузить компьютер. После выполнения перезагрузки на сервер DNS в зоне world.ru автоматически создадутся записи типаA для наших серверов (рис. 4.12 ).

Рис. 4.12.

Создание зоны обратного просмотра .

Откроем консоль DNS.

Выберем раздел "Зоны обратного просмотра" .

Запустим мастер создания зоны (выбрать: тип зоны - "Основная" , динамические обновления - разрешить, остальные параметры - по умолчанию)

В поле "Код сети (ID)" введем параметры идентификатора сети - 192.168.0.

Выполним команду принудительной регистрации клиента на сервере DNS - ipconfig /registerdns.

Наши серверы зарегистрируются в обратной зоне DNS (рис. 4.13 ):

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

В этом занятии описаны принципы создания и настройки зоны, а также изложены сведения, необходимые для корректного конфигурирования зоны.

Создание зон

Зона DNS представляет собой базу данных, содержащую записи, которые связывают имена с адресами в описываемой области пространства имен DNS . Хотя для ответов на запросы имен DNS -сервер может использовать кэшированную информацию с других серверов, он уполномочен отвечать на запросы лишь в локально управляемой зоне. Для любой области пространства имен DNS , представленной именем домена (например, google .ru ), существует только один полномочный источник данных зоны.
При необходимости создать на DNS -сервере новую зону можновоспользоваться мастером создания новой зоны (New Zone Wizard ) в диспетчере DNS (DNS Manager ). Для запуска мастера щелкните правой кнопкой мыши значок сервера в дереве консоли диспетчера DNS и примените команду Создать новую зону (New Zone ).

Мастер создания новой зоны содержит следующие страницы конфигурации:

■ Тип зоны (Zone Type);

■ Область репликации зоны , интегрированной в Active Directory (Active Directory Zone Replication Scope);

■ Зона прямого или обратного просмотра (Forward or Reverse Lookup Zone );

■ Имя зоны (Zone Name );

■ Динамическое обновление (Dynamic Update ).

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

Выбор типа зоны

На странице Тип зоны (Zone Type) мастера создания новой зоны (New Zone Wizard) можно выбрать создание основной зоны, дополнительной или зоны-заглушки. Создав на контроллере домена основную зону или зону-заглушку, вы сможете хранить данные зоны в Active Directory.

* Основные зоны

Самым распространенным типом зон DNS является основная зона (Primary zone). Она обеспечивает исходные данные чтения/записиисточника, предоставляющие локальному DNS-серверу полномочия отвечать назапросы DNS области пространства имен DNS.

Локальный DNS-сервер, управляющий основной зоной, служит первичным источником данных об этой зоне. Сервер хранит главную копию данных зоны в локальном файле или в доменных службах Active Directory (Active Directory Domain Services , AD DS ). Если зона сохраняется в файле, а не в Active Directory, этот файл но умолчанию получает имя имя_зоны. dns и хранится в папке %systemroot %\System 32\Dns на сервере.

* Дополнительные зоны

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

Дополнительные зоны (Secondary zones ) предоставляют возможностьснизить объем трафика запросов DNS в областях сети, где происходитинтенсивное запрашивание и использование данных зоны. Кроме того, в случаенедоступности сервера, который управляет основной зоной, дополнительная зона может обеспечивать разрешение имен до тех пор, пока основной сервер снова не станет доступным.

Исходные зоны, из которых дополнительные зоны получают информацию, называются мастер-зонами, а процедуры копирования данных, обеспечивающие регулярное обновление информации зоны, называются передачами зон. Мастер-зоной может быть основная зона или другая дополнительная зона. Мастер-зону можно назначить для создаваемой дополнительной зоны в мастере создания новой зоны (New Zone Wizard ). Поскольку дополнительная зона — это копия основной зоны, управляемая еще одним сервером, ее нельзя хранить в Active Directory .

* Зоны-заглушки

Аналогичны дополнительной зоне, однако содержат записи ресурсов, необходимые для идентификации полномочных DNS -серверовглавной зоны. Зоны-заглушки (Stub zone ) часто применяются для того, чтобыродительская зона (например, google .ru ) могла использовать обновляемый список серверов имен, доступных в делегированной дочерней зоне (например: translate .google .ru ). Они также служат для улучшения разрешения имен иупрощения администрирования DNS .

* Хранение зон в Active Directory

При создании основной зоны илизоны-заглушки на контроллере домена, на странице Тип зоны (Zone Type ) мастера можно выбрать опцию сохранения зоны в Active Directory . Данные зон,интегрированных в Active Directory , автоматически реплицируются в Active Directory в соответствии с параметрами, выбранными на странице Областьрепликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope ). Благодаря этой опции нет необходимости настраивать передачу зон на дополнительные серверы.

Интеграция зоны DNS в Active Directory дает несколько преимуществ. Во-первых, поскольку службы Active Directory выполняют репликацию зон, нет необходимости в настройке отдельного механизма передачи зон DNS между основным и дополнительными серверами. Множественная репликация в сети автоматически обеспечивает отказоустойчивость и повышеннуюпроизводительность благодаря доступности множества основных серверов с правом чтения/записи. Во-вторых, службы Active Directory позволяют выполнять обновление и репликацию отдельных свойств записей ресурсов на DNS-серверах.Поскольку не передается множество полных записей ресурсов, снижается нагрузка на сетевые ресурсы во время передачи зон. Наконец, зоны, интегрированные в Active Directory, обеспечивают также опциональные возможности внедрения требований безопасности динамических обновлений, настройка которыхосуществляется на странице Динамическое обновление (Dynamic Update) мастера создания зоны.

ПРИМЕЧАНИЕ: Контроллеры домена с правом чтения и зоны, интегрированные в Active Directory

На традиционных контроллерах доменов копии зоны предоставляется право чтения/записи. На контроллерах доменов с доступом лишь для чтения (Read-O nly Domain Controller, RODC) копии зоны назначается лишь право чтения.

* Стандартные зоны

При создании зоны на контроллере домена опциясохранения зоны в Active Directory на странице Тип зоны (Zone Type ) выбирается по умолчанию. Однако этот флажок можно снять и создать так называемую стандартную зону. На сервере, не являющемся контроллером домена, можно создавать лишь стандартные зоны, а флажок на этой странице неактивен.

В отличие от зоны, интегрированной в Active Directory , стандартная зона сохраняет свои данные в текстовом файле на локальном DNS -сервере. Кроме того, в случае использования стандартных зон можно конфигурировать только основную копию с правом чтения и записи данных зоны. Всем остальнымкопиям зоны (дополнительные зоны) назначено право только для чтения.

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

Выбор области репликации зоны, интегрированной в Active Directory

На странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope ) мастера создания новой зоны (New Zone Wizard ) можно выбрать контроллеры домена в сети для сохранения данных зоны. Эта страница, появляется только при выборе опции сохранения зоны и Active Directory . Опции выбора области репликации зон определяют контроллеры домена, среди которых будет выполниться репликация данных зон.

Па этой странице представлены такие опции:

■ Сохранение зоны на всех контроллерах домена , которые также являются DNS-серверами во всем лесе Active Directory;

■ Сохранение зоны на всех контроллерах домена , которые также служит DNS-серверами и локальном домене Active Directory;

■ Сохранение зоны на всех контроллерах домена и локальном домене Active Directory (используется для совместимости с Windows 2000);

■ Сохранение зоны на всех контроллерах домена , указанных и области настраиваемого раздела каталога Active Directory.

Более подробно эти опции описаны во второй теме.

Создание зон прямого и обратного просмотра

На странице Зона прямого или обратного просмотра (Forward or Reverse Lookup Zone) мастера создания попой зоны (New Zone Wizard) необходимо выбрать тип создаваемой зоны; зона прямого просмотра (Forward Lookup Zone) или зона обратного просмотра (Reverse Lookup Zone).

В зонах прямого просмотра DNS-серверы сопоставляют полные доменные имена FQDN с IP-адресами. В зонах обратного просмотра DNS-серверы сопоставляют I P-адреса именам FQDN. Таким образом, зоны прямого просмотра отвечают на запросы разрешения имен FQDN в IP-адреса, а зоны обратного просмотра отвечают на запросы разрешения IP-адресов в имена FQDN.Отметим, что зоны прямого просмотра получают имя в соответствии с доменными именами D NS, для которых выполняется разрешение, например google .com. Зоны обратного просмотра именуются и обратном порядке первых трех октетов адресного пространства, для которого обеспечивается разрешение имен, плюс, дополнительный тег in-addr.arpa. Например, при разрешении имен для подсети 192.168.1.0/24 зона обратного просмотра получит имя 1.168.192.in-addr.arpa. В зоне прямого просмотра отдельная запись базы данных, сопоставляющая имя узла с адресом, называется записью узел (А). В зоне обратного просмотра отдельная запись базы данных, сопоставляющая IP-адрес, с именем узла, называется указателем или PTR -записью.

Принцип работы мои прямого и обратного просмотра продемонстрирован на рисунке.

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

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

ПРИМЕЧАНИЕ: Мастер настройки DNS-сервера

Для одновременного создания зон прямого и обратного просмотра можноиспользовать мастер настройки DNS-сервера (Configure A DNS Server Wizard). Чтобы запустить мастер, в дереве консоли диспетчера DNS щелкните правой кнопкой мыши значок сервера и примените команду Настроить DNS-сервер (Configure A DNS Server).

Выбор имени зоны

На странице Имя зоны (Zone Name ) мастера создания новой зоны (New Zone Wizard ) можно выбрать имя создаваемой зоны прямого просмотра, Зоны обратного просмотра получают особые имена в соответствии с диапазоном IP -адресов, для которых являются полномочными.

Если зона создается для разрешения имен в домене Active Directory, лучше всего указать имя зоны, соответствующее имени домена Active Directory. Например, если организация содержит два домена Active Directory, с именами google .ru и translate .google .ru , инфраструктура разрешения имен должна включать две зоны с именами, соответствующими именам этих доменов.

В случае создания зоны для пространства имен DNS не в среде ActiveDirectory, нужно указать имя Интернет-домена организации, например wikipedia .org .

ПРИМЕЧАНИЕ: Добавление DNS -сервера на контроллер домена

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

Настройка параметров динамического обновления

Клиентские компьютеры DNS могут регистрировать и динамически обновлять свои записи ресурсов с помощью DNS -сервера. По умолчанию DNS -клиенты со статическими IP -адресами обновляют записи узлов (А или АААА) иуказателей (PTR ), a DNS -клиенты, являющиеся DHCP -клиентами, — лишь записи узлов. В среде рабочей группы DHCP -сервер обновляет записи указателя от лица DHCP -клиента при каждом обновлении конфигурации IP .

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

■ Безопасное обновление (Secure updates )

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

■ Небезопасные обновления (Nonsecure updates )

Позволяет выполнять обновление с любого компьютера.

На странице Динамическое обновление (Dynamic Update ) мастера создания новой зоны (New Zone Wizard ) для создаваемой зоны можно разрешитьбезопасные, небезопасные динамические обновления или вообще запретить обновление.

Анализ встроенных записей ресурсов

При создании новой зоны автоматически создается два типа записей. Во-первых, такая зона всегда включает начальную запись зоны SOA (Start Of Authority ), определяющую основные свойства зоны. Кроме того, новые зоны содержат хотя бы одну запись сервера имен NS (Name Server ), указывающую имяполномочного сервера (серверов) зоны. Далее описаны функции этих двух записей ресурсов.

Начальные записи зоны

При загрузке зоны DNS-сервер использует начальную запись зоны SOA (Start Of Authority) для определения основных свойств и полномочий зоны. Эти параметры также характеризуют частоту передачи зон между основным идополнительным сервером. Если дважды щелкнуть запись SOA, откроется вкладка Начальная запись зоны (SOA) (Start Of Authority (SOA)) диалогового окна свойств зоны.

■ Серийный номер (Serial Number)

Это текстовое поле вкладки Начальная запись зоны (SOA) содержит номер редакции файла зоны. Указанное здесь число увеличивается каждый раз при изменении записей ресурсов в зоне. Его также можно увеличить вручную с помощью кнопки Увеличить (Increment).

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

ПРИМЕЧАНИЕ: Передача зон на основном сервере

Щелчком кнопки Увеличить (Increment) инициируется передача зоны.

■ Основной сервер (Primary Server )

■ Ответственное лицо (Responsible Person)

В это поле вводится имяответственного лица (RP), соответствующее доменному почтовому ящикуадминистратора зоны. Имя, введенное в это поле, всегда должно завершаться точкой. По умолчанию используется имя hostmaster.

■ Интервал обновления (Refresh Interval)

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

■ Интервал повтора (Retry Interval)

■ Срок истекает после (Expires After)

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

■ Минимальный срок жизни TTL (Minimum (Default) T TL)

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

■ Срок жизни (TTL) записи (TTL For This Record)

Значение , указанное в этом иоле, определяет срок жизни текущей записи SOA . Это значение заменяет значение по умолчанию, указанное в предыдущем поле.

Записи серверов имен

Запись сервера имен (NS) указывает полномочный сервер для зоны. Присоздании зоны в Windows Server 2008 каждый сервер, управляющий основной копией зоны, интегрированной в Active Directory, получит собственную запись NS в новой зоне по умолчанию. При создании стандартной основной зоны по умолчанию будет добавлена запись NS локального сервера.

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

Записи NS создаются с помощью иной процедуры, чем в случае создания других типов записей ресурсов. Чтобы добавить записи NS, в диспетчере DNS дважды щелкните любую существующую запись NS. Откроется вкладкаСерверы имен (Name Servers) диалогового окна свойств зоны. На вкладке Серверы имен щелкните кнопку Добавить (Add), чтобы добавить имя FQDN и IP-адрес сервера, управляющего дополнительной зоной локальной основной зоны. Добавив новый сервер, щелкните ОК - в диспетчере DNSпоявится новая запись NS, указывающая этот сервер.

ПРИМЕЧАНИЕ: Включение передачи в дополнительные зоны

Дополнительная зона не распознает эту запись как действительный сервер имен, пока содержит действительную копию данных зоны. Чтобы дополнительная зона получила эти данные, нужно включить передачу зон для этого сервера на вкладке Передача зон (Zone Transfers) диалогового окна свойства зоны. Эта вкладка более детально описана в следующей теме.

Ниже приведен пример записи, созданной в файле стандартной зоны:

@ NS dns1.lucernepublishing.com.

Символ @ представляет зону, определенную записью SOA в файле зоны. Затем полная запись сопоставляет домен wikipedia .org с DNS-сервером dns1.wikipedia .org .

Создание записей ресурсов

Помимо записей SOA и NS автоматически создаются еще некоторые записи ресурсов. Например, во время установки нового DNS -сервера, когда сервер назначается контроллером домена, многие записи SRV доменных служб Active Directory (AD DS ) создаются автоматически в локально управляемой зоне. Помимо этого, посредством динамического обновления многие DNS -клиенты по умолчанию автоматически регистрируют записи узлов (А и АААА) иуказателей (PTR ) в зоне.

Несмотря на то что многие записи ресурсов создаются автоматически, вкорпоративных средах обычно требуется создать некоторые записи ресурсоввручную, например почтовые обменники MX (Mail Exchanger ) для почтовыхсерверов, псевдонимы (CNAME ) для веб-серверов и серверов приложений, а также записи узлов для серверов и клиентов, которые не могут выполнять собственные обновления.

Чтобы вручную добавить запись ресурса для зоны, в консоли Диспетчер DNS (DNS Manager ) щелкните правой кнопкой мыши значок зоны и в контекстном меню выберите тип создаваемой записи.

После выбора записи в контекстном меню откроется диалоговое окно, где можно указать имя записи и связанный с ней компьютер. Отметим, что имя компьютера с IP -адресом связывают толькозаписи узла. Большинство типов записей связывают имя службы или псевдоним с исходной записью узла. Таким образом, запись MX полагается на присутствие в зоне записи узла SRV 12.nwtraders .msft .

Типы записей

Ниже приведены распространенные записи ресурсов, создаваемые вручную:

■ узел (А или АЛАА );

■ псевдоним (CNAME );

■ почтовый обменник (MX );

■ указатель (PTR );

■ расположение службы (SRV ).

Узел (А или АААА)

Для большинства сетей основную часть записей ресурсов в базе данных зоны составляют записи ресурсов узлов. Эти записи используются в зоне для связывания компьютерных имен (имен узлов) с IP -адресами.

Даже при включении динамических обновлений для зон в некоторыхсценариях записи узлов нужно будет добавлять записи в зону вручную. На рисунке далее компания Contoso , Inc . использует доменное имя contoso .com в общедоступном пространстве имен и внутреннем домене Active Directory . В этом случаепубличный веб-сервер www .contoso .com расположен вне домена Active Directory ивыполняет обновления лишь на публичном полномочном DNS -сервере contoso .com . Но внутренние клиенты пересылают свои запросы DNS на внутренние DNS - серверы. Так как запись А сервера www .contoso .com не обновляется динамически на внутренних DNS -серверах, ее добавляют вручную, чтобы внутренниеклиенты могли разрешать имена и подключаться к общественному веб-серверу.

Записи узлов можно добавлять вручную, если в сети используется сервер UNIX. Например, компания Fabrikam, Inc. имеет в своей частной сети один домен Active Directory с именем fabrikam ,com . Эта сеть такжевключает UNIX-сервер App1.fabrikam,com, который запускает важное приложение для выполнения ежедневных операций компании. Так как UNIX-серверы не могут выполнять динамические обновления, придется вручную добавить запись узла сервера Арр1 на DNS-сервер, управляющий зоной fabrikam,com. Впротивном случае пользователи не смогут подключаться к серверу приложений, указывая его имя FQDN.

Псевдоним (CNAME)

Эти записи иногда называют каноническими именами. Они позволяют использовать несколько имен для указания одного узла. Например, известные имена серверов (ftp, www), как правило, регистрируются спомощью записей CNAME. Эти записи сопоставляют имена узлов, соответствующие их службам, с реальной записью Акомпьютера, управляющего службой.

■ Когда требуется переименовать узел , указанный в записи А той же зоны .

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

Почтовый обменник (MX )

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

Часто записи MX создаются для обеспечения отказоустойчивости ещеодного почтового сервера на случай недоступности предпочтительного сервера.

Множеству серверов назначаются значения предпочтений. Чем ниже это значение, тем выше порядок предпочтения сервера.

ПРИМЕЧАНИЕ: Символ @

В данном примере символ @ представляет локальное доменное имя, содержащееся в адресе электронной почты.

Указатель PTR

Эта запись используется лишь в зонах обратного просмотра для поддержки обратного просмотра, который производится при разрешении IP -адресов в имена узлов или имена FQDN . Обратный просмотр выполняется в корневых зонах домена in -addr .arpa . Записи PTR можно добавлять в зоны вручную или автоматически.

Ниже приведен пример текстового представления в файле зоны записи PTR , созданной в диспетчере DNS , которая сопоставляет IP -адрес 192.168.0.99 имени узла server 1.google .ru :

99 PTR server 1. google . ru .

ПРИМЕЧАНИЕ: Номер 99 записи PRT

В зоне обратного просмотра последний октет IPv 4-адреса эквивалентен имени узла. Поэтому число 99 представляет имя, назначенное узлу внутри зоны 0.168.192.in -addr .arpa . Эта зона соответствует подсети 192.168.0.0.

Расположение службы SRV

Записи SRV применяют для указаниярасположения служб в домене. Клиентские приложения, использующие SRV , посредством DNS могут извлекать записи SRV серверов приложений.

В качестве приложения, использующего SRV , можно привести Windows Server 2008 Active Directory . Служба сетевого входа в систему Netlogon использует записи SRV для локализации контроллеров домена, выполняя поискдомена Службы Active Directory облегченного доступа к каталогам (Lightweight Directory Access Protocol , LDAP ). DNS , чтобы повысить отказоустойчивость или устранить неполадки сетевых служб.

Включение DNS для разрешения WINS

На вкладке WINS окна свойств зоны можно указать WINS -сервер, к которому будет обращаться служба DNS -сервер для просмотра имен, не найденных с помощью запросов DNS . При указании WINS -сервера на вкладке WINS диалогового окна свойств зоны прямого просмотра в эту зону добавляется особая запись WINS , ссылающаяся на этот WINS -сервер. При указанииWINS -сервера на вкладке WINS диалогового окна свойств зоны обратного просмотра в зону добавляется особая запись WINS -R , определяющая этот WINS -сервер.

Например, если DNS -клиент запрашивает имя ClientZ .contoso .com ипредпочитаемый DNS -сервер не может найти ответ в обычных источниках (кэше, данных локальной зоны и с помощью опроса других серверов), серверзапрашивает имя CLIENTZ . на WINS -сервере, указанном в записи WINS . Если WINS -сервер отвечает на запрос, DNS -сервер возвращает его ответ клиенту.

Очистка и удаление устаревших записей

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

Включение очистки

Чтобы включить очистку для отдельной зоны, нужно включить эту функцию на уровне сервера и уровне зоны.

Чтобы включить очистку на уровне сервера, в дереве консоли Диспетчера DNS (DNS Manager ) щелкните правой кнопкой мыши значок сервера ипримените команду Установить свойства очистки для всех зон (Set Aging /Scavenging For All Zones ). Затем в открывшемся диалоговом окне Свойства очистки сервера (Server Aging /Scavenging Properties ) установите флажок Удалять устаревшие записи ресурсов (Scavenge Stale Resource Records ). Хотя этот параметр включает на уровне сервера штампы времени и очистку для всех новых зон, он не включает штампы времени и очистку существующих зон, интегрированных в Active Directory .

Чтобы задействовать их, щелкните ОК, а затем в открывшемся диалоговом окне Подтверждение очистки сервера от устаревших ресурсов (Server Aging/ Scavenging Confirmation) установите флажок для применения этих параметров к существующим зонам, интегрированным в Active Directory.

Чтобы включить штампы времени и очистку на уровне зоны, откройте Свойства зоны, а затем на вкладке Общие (General) щелкните кнопку Очистка (Aging). В открывшемся диалоговом окне Свойства очистки для зоны (Zone Aging/Scavenging Properties) установите флажак Удалять устаревшие записи ресурсов (Scavenge Stale Resource Records ).

Штампы времени DNS-сервер выполняет очистку с помощью штампов времени, установленных для записей ресурсов в зоне. Зоны, интегрированные в Active Directory, устанавливают значения штампов времени для динамически регистрируемых записей по умолчанию еще до включения очистки, Однако основные стандартные зоны устанавливают штампы времени для динамически регистрируемых записей в зоне лишь после включения очистки. Записям ресурсов, создаваемым вручную для всех типов зон, назначается штамп времени 0; это означает, что их возраст определяться не будет. — это время между последним обновлением штампа и его возможным следующим обновлением. Блокирование не позволяет серверу обрабатывать ненужные обновления и снижает объем трафика. По умолчанию назначается интервал блокирования 7 дней.

■ Модификация интервала обновления

Интервал обновления — это промежуток между самым ранним временем обновления штампа времени и самым ранним временем начала очистки записи. По истечении интерваловблокирования и обновления записи могут удаляться из зоны. По умолчаниюинтервал равен 7 дням. Поэтому при включении штампов времени динамически регистрируемые записи ресурсов могут быть удалены через 14 дней.

Выполнение очистки

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

Если эта опция не включена, вы можете выполнить очистку в зонах вручную, щелкнув правой кнопкой мыши значок сервера в дереве консоли Диспетчер DNS (DNS Manager) и применив команду Удалить устаревшие записи (Scavenge Stale Resource Records).

Зона GlobalNames

В Windows Server 2008 включен новый компонент, позволяющий всем DNS-клиентам в лесу Active Directory использовать имена из одной метки, например Mail, для подключения к ресурсам сервера. Этот компонент удобноиспользовать, если список просмотра DNS-суффиксов по умолчанию для DNS-клиентов не позволяет пользователям быстро подключаться (или подключаться вообще) к ресурсу с помощью такого имени из одной метки.

DNS-сервер в Windows Server 2008 позволяет создавать зону GlobalNames. По умолчанию зона GlobalNames не существует, однако, развернув зону с этим именем, можно обеспечить доступ к выбранным ресурсам с помощью имен из одной метки, не используя WINS. Как правило, имена из одной меткиназначаются важным и широко используемым серверам, которым уже назначены статические IP-адреса. GlobalNames на удаленном сервере, вместо точки введите имя удаленного сервера.

■ Создание з оны GlobalNames

Следующий шаг а развертывании зоныGlobalNames состоит в создании зоны для DNS-сервера, служащегоконтроллером домена Windows Server 2008. Зона GlobalNames представляет собой не особый тип зоны, а всего лишь интегрированную в Active Directory зону прямого просмотра с именем GlobalNames. При создании зоны выберите репликацию данных зоны для всех DNS-серверов в лесу. Эта опциянаходится на странице Область репликации зоны, интегрированной в Active Directory (обеспечить возможность разрешения имен из одной метки, создайте и зоне G lobalNames запись псевдонима (CNAME ) ресурса. Имя, назначенноекаждой записи CNAME , представляет имя из одной метки, с помощью которого пользователи смогут подключаться к ресурсу. Отметим, что каждая запись CNAME указывает запись узла в еще одной зоне.

Система доменных имён - основа современного интернета. Люди не желают затруднять себя запоминанием набора цифр 63.245.217.105, а хотят чтобы по имени mozilla.org компьютер соединил их с указанным узлом. Этим и занимаются DNS-серверы: переводят запросы людей в понятный им цифровой формат. Однако в некоторых случаях может потребоваться обратное (reverse) преобразование IP-адрес → DNS-имя. О таких именах и пойдёт речь ниже.

Для чего нужно?

Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера корпоративной почты . Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером будет, скорее всего, указана такой:
550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."

или
550-There"s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.

или просто
550 Your IP has no PTR Record

Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

Как настроить и использовать?

Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило этим владельцем оказывается провайдер, владеющий собственной автономной системой. Подробнее о регистрации своей автономной системы (AS) и блока IP-адресов можно прочитать в этой статье . Если кратко, то оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) - запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса в имя хоста.

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

Примеры хороших имён для сервера почты:

mail.domain.ru
mta.domain.ru
mx.domain.ru

Примеры плохих имён:

host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru

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

С успехом использовать запросы к обратным зонам DNS можно и нужно сразу после запуска почтового сервера. Для этого необходимо произвести лишь небольшую настройку ПО. В разных почтовых серверах настройка проверки rDNS делается по-разному:

так для почтового сервера Postfix необходимо включить опцию
reject_unknown_client

в другом популярном почтовом сервере Exim
verify = reverse_host_lookup

MS Exchange Server
В оснастке Exgange Server перейти в раздел Servers далее выбрать сервер в развернутом списке, выбрать Protocols, далее протокол SMTP, в правом окне выделить SMTP сервер и по клику правой клавишей мыши выбрать из списка Properties. Далее закладка Delivery → Perform reverse DNS lookup on incoming messages

Теперь все сообщения с IP-адресов не имеющих обратной записи в DNS (записей типа PTR) будут отвергаться, поток спама, значительно сократится. Пожалуй, это самый простой, действенный и наименее ресурсоёмкий из всех методов фильтрации спама: проверкой reverse DNS отсекается подавляющее большинство спама, рассылаемого с заражённых компьютеров обычных пользователей, составляющих ботнеты спамеров.

При перепубликации статьи установка активной индексируемой гиперссылки на источник - сайт сайт обязательна!

Основы

Что такое запись обратной зоны DNS?

Обычные DNS-запросы определяют неизвестный IP-адрес для известного имени хоста. Это необходимо когда, например, браузеру нужно установить TCP-соединение с сервером по введённому в адресном поле URL.

Forum.hetzner.de --> 213.133.106.33

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

213.133.106.33 --> dedi33.your-server.de

Как вы видите, именам хоста при прямом и обратном запросах необязательно совпадать!

Каково предназначение записи обратной зоны DNS?

• traceroute показывает не только IP-адреса, но и человекочитаемые имена узлов. Это значительно облегчает диагностику ошибок.
• Большое количество почтовых серверов принимает письма только если у IP-адреса отправителя есть обратная DNS-запись.
• Обратные DNS-записи могут использоваться в SPF-записях (Sender Policy Framework ; технология, предотвращающая рассылку спама и вирусов с поддельных email-адресов).

Как технически работает обратное преобразование на DNS-серверах?

Практика

Как я могу назначить несколько имён на мой IP-адрес, если различные домены размещены на моём сервере?

Это невозможно. Только одно имя назначается на каждый IP-адрес.

Более того, неважно какие обратные зоны прописаны для сервера. Для обращения к сайту браузеру достаточно провести лишь прямое преобразование (Имя --> IP). Здесь, конечно, может быть несколько имён, например несколько записей типа A или несколько записей типа CNAME, которые указывают на A-запись.

Для работы почтовых серверов необязательно иметь несколько имён хоста на один IP-адрес. Обратная DNS-запись должна соответствовать имени хоста SMTP-сервера (обратитесь к настройками соответствующего SMTP-сервера).

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

• Обратная DNS-запись должна соответствовать имени почтового сервера или строиться на основании IP-адреса.
• Обратная DNS-запись должна также резолвиться "вперёд" - на тот-же IP-адрес.
• Обратная DNS-запись не должна быть похожа на автоматические-сгенерированную, например "162-105-133-213-static.hetzner.de", так так часто такие имена отрицательно оцениваются спам-фильтрами.
• Даваемое имя должно существовать. Пожалуйста, не используйте несуществующие доменные имена.

Пример хорошей записи:

Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.grossefirma.de ESMTP ready

Я задаю PTR на моём DNS-сервере. Почему это не работает?

Ваш DNS-сервер отвечает лишь за прямое преобразование.

Владелец блока IP-адресов (например, Hetzner Online GmbH) является ответственным за поддержание авторитативных DNS-серверов для обратных записей.

Обратные DNS-записи можно создавать только при помощи соответствующей функции панели Robot (левое меню -> "Servers" -> щелчок по серверу -> "IPs" -> щелчок по текстовому полю рядом с IP-адресом).

Обратная запись для моего сервера отличается от HELO моего почтового сервер. Является ли это проблемой?

Пример: обратная DNS-запись для IP-адреса сервера "www.grossefirma.de". В ответ на команду HELO почтовый сервер отвечает "mail.grossefirma.de".

Некоторые спам-фильтры расценивают письма от таких отправителей как "спам". Подобные несоответствия должны быть исправлены. Обратная DNS-запись и имя почтового сервера должны быть одинаковыми. В примере выше они могут быть, например, "srv01.grossefirma.de". Имя "www.grossefirma.de" может быть безо всяких последствий перенаправлено на srv01.grossefirma.de" при помощи CNAME-записи.

Подробное тестирование DNS-записей можно провести воспользовавшись