Обычные DNS-запросы определяют неизвестный IP-адрес для известного имени хоста. Это необходимо когда, например, браузеру нужно установить TCP-соединение с сервером по введённому в адресном поле URL.
Forum.hetzner.de --> 213.133.106.33
Обратный DNS работает в другом направлении - запрос определяет имя хоста, принадлежащее IP-адресу.
213.133.106.33 --> dedi33.your-server.de
Как вы видите, именам хоста при прямом и обратном запросах необязательно совпадать!
Это невозможно. Только одно имя назначается на каждый IP-адрес.
Более того, неважно какие обратные зоны прописаны для сервера. Для обращения к сайту браузеру достаточно провести лишь прямое преобразование (Имя --> IP). Здесь, конечно, может быть несколько имён, например несколько записей типа A или несколько записей типа CNAME, которые указывают на A-запись.
Для работы почтовых серверов необязательно иметь несколько имён хоста на один IP-адрес. Обратная DNS-запись должна соответствовать имени хоста SMTP-сервера (обратитесь к настройками соответствующего SMTP-сервера).
Если несколько доменов управляются через IP-адрес (достаточно частый случай), можно использовать нейтральное имя, не связанное с доменами пользователей. Спам-фильтры всего-лишь проверяют соответствует ли обратная DNS-запись имени в ответе на команду HELO. Это никак не влияет на доменные имена и почтовые адреса в передаваемых письмах.
Пример хорошей записи:
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
Ваш DNS-сервер отвечает лишь за прямое преобразование.
Владелец блока IP-адресов (например, Hetzner Online GmbH) является ответственным за поддержание авторитативных DNS-серверов для обратных записей.
Обратные DNS-записи можно создавать только при помощи соответствующей функции панели Robot (левое меню -> "Servers" -> щелчок по серверу -> "IPs" -> щелчок по текстовому полю рядом с IP-адресом).
Пример: обратная DNS-запись для IP-адреса сервера "www.grossefirma.de". В ответ на команду HELO почтовый сервер отвечает "mail.grossefirma.de".
Некоторые спам-фильтры расценивают письма от таких отправителей как "спам". Подобные несоответствия должны быть исправлены. Обратная DNS-запись и имя почтового сервера должны быть одинаковыми. В примере выше они могут быть, например, "srv01.grossefirma.de". Имя "www.grossefirma.de" может быть безо всяких последствий перенаправлено на srv01.grossefirma.de" при помощи CNAME-записи.
Подробное тестирование DNS-записей можно провести воспользовавшись
Рашид Ачилов
Создаём зоны 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, будет выглядеть следующим образом:
Данный процесс проиллюстрирован на рис. 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:
Каких-либо требований к размещению серверов по новым правилам не выдвигается, хотя ранее требовалось наличие их в разных 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. Мы рассмотрим только те записи, которые понадобятся для формирования файлов зон, необходимых для регистрации домена:
Формат записей DNS общий для всех типов записей:
[имя] [класс] <тип> <данные>
Имя может принимать любое значение, и в таком случае оно считается именем обьекта. Если имя заканчивается на точку, то оно считается полностью определенным, иначе в конец имени подставляется имя зоны, которое может быть задано двумя способами:
$ORIGIN krokodil.ru
Специальный символ «@» обозначает текущее имя зоны. Имейте в виду, что директива $ORIGIN отменяет директиву zone и действует до появления следующей директивы $ORIGIN или до конца файла. До момента появления первой директивы $ORIGIN она считается заданной значению директивы zone конфигурационного файла BIND.
Если имя задано, оно должно начинаться с первой позиции строки.
TTL обычно опускается и задается глобально директивой $TTL. Директива $TTL для BIND 9.x является обязательной и, как правило, задается в самом начале файла. В поле данных этой директивы задается время жизни (в секундах) элемента, в течение которого он может находиться в кэше и считаться достоверным. В данном примере это двое суток (48 часов).
$TTL 172800
Класс записи может принимать одно из следующих значений:
Тип записи – один из типов, перечисленных выше.
Следует обратить внимание на то, что поля имя, 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».
Второй параметр – это список значений, заключенный в скобки. Теоретически возможно его записать в одну строку, но практически я нигде этого не видел, всюду употребляется форма записи, приведенная в примере. Список состоит из пяти элементов:
Запись 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. Здесь мы:
Запись 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. 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 (Ниуэ – есть такой остров-колония) – для сайтов в стиле «ню».
Зона представляет собой базу данных, содержащую полномочную информацию об области пространства имен 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 указывает запись узла в еще одной зоне.
Продолжая тему сайтостроения поговорим о таком важном аспекте, как работа системы доменных имен - DNS. С настройкой и расположением DNS-зоны связаны многие вопросы, касающиеся первоначального размещения, а также переноса сайтов между различными серверами и хостингами. Понимание принципов работы системы доменных имен позволяет с легкостью управлять собственными доменами и связанными с ними сайтами и прочими службами.
Что такое доменное имя? Для многих это синоним адреса сайта, например, www.сайт . Набирая этот адрес вы твердо уверены, что попадете именно на этот сайт, а не куда-нибудь еще. В тоже время доменное имя может обозначать не только сайт, но и сервер электронной почты, обмена короткими сообщениями или иной другой интернет и сетевой сервис. Доменные имена входят в доменные зоны, которые расположены внутри друг друга в иерархическом порядке.
В общем понимании домен - это символьное имя, позволяющее однозначно адресовать автономную область имен в сети интернет. И не только адресовать, но и позволить любому клиенту быстро найти необходимый узел, даже не имея ни малейшего представления о его размещении. Можно без преувеличения сказать, что система DNS - основа современной сети интернет в том виде, в которой мы все ее знаем и привыкли.
Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:
Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru
, сom
, org
и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.
Домены первого уровня являются привычными нам доменными зонами и могут управляться как национальными, так и международными организациями и иметь свои условия использования. Каждая доменная зона первого уровня позволяет размещать неограниченное количество доменов второго уровня, которые знакомы каждому пользователю интернета как адреса сайтов.
В свою очередь домены второго уровня тоже являются доменными зонами и позволяют размещать в себе домены третьего уровня, в которые, как в матрешку, помещать домены четвертого, пятого и т.д. уровней. Для того, чтобы можно было однозначно определять узлы, находящиеся в разных зонах, введено понятие полностью определенное имя домена (FQDN, Fully Qualified Domain Name ), которое включает в себя все имена родительских доменов в иерархии DNS. Например, для нашего сайта FQDN будет: сайт. Именно так, с окончанием на точку, обозначающее корневую зону.
Это очень важный момент. В повседневном использовании завершающую точку принято отбрасывать, но в записях DNS отсутствие последней точки обозначает, что данное доменное имя принадлежит текущей доменной зоне, т.е. DNS-сервер прибавит к такому имени собственную доменную зону и все вышестоящие зоны вплоть до корня.
Например, на нашем сервере в зоне сайт мы добавляем запись типа CNAME, которая будет указывать на сторонний сервер, скажем, Яндекс-почты. Правильно запись должна выглядеть так:
MailIN CNAMEdomain.mail.yandex.net.
В данном случае имя mail не является FQDN и будет дополнено до mail.сайт. , если же мы забудем поставить точку в конце имени домена Яндекса, то это имя также не будет восприниматься как FQDN и должно быть дополнено до полного имени домена. Ниже показана неправильная запись:
Mail IN CNAME domain.mail.yandex.net
Неподготовленным взглядом разницу заметить сложно, но вместо веб-интерфейса почты Яндекса такая конструкция отправит нас на несуществующий адрес: domain.mail.yandex.net.сайт.
Еще один момент. Все записи для доменной зоны вносятся администраторами зон на собственных DNS-серверах, каким образом данные записи становятся известны системе DNS? Ведь мы же не оповещаем вышестоящие DNS-сервера, что изменили какую-либо запись.
Любая DNS-зона содержит записи только о входящих в нее узлах и дочерних зонах. Информация об узлах нижестоящей зоны хранится на ее собственных серверах. Это называется делегированием и позволяет снизить нагрузку на корневые сервера и предоставить необходимую автономию владельцам дочерних доменных зон.
Итак, вы купили домен, скажем, example.org , после чего вы должны его делегировать, т.е. указать сервера имен (DNS-сервера), которые будут содержать записи данной файловой зоны. Это могут быть как ваши собственные сервера, так и публичные сервисы, например, DNS Яндекса.
В этом случае в доменной зоне org будет добавлена запись:
Example IN NS dns1.yandex.net.
Которая будет указывать, что все записи этой зоны расположены на сервере dns1.yandex.net . По правилам, каждая доменная зона должна иметь не менее двух NS-серверов, расположенных в разных подсетях. На практике часто обходятся одним сервером, приобретая для него два IP-адреса из разных диапазонов.
Теперь разберем, каким образом происходит поиск необходимой нам DNS-записи и почему запись, сделанная на вашем сервере, позволяет попасть на ваш сайт посетителям из любой точки земного шара.
Допустим, пользователь хочет посетить популярный ресурс Яндекс Маркет, он набирает в адресной строке браузера соответствующее имя сайта и нажимает кнопку Enter. Для того, чтобы отобразить пользователю содержимое страницы браузер должен отправить запрос обслуживающему сайт веб-серверу, а для этого нужно знать его IP-адрес. Поэтому браузер обращается к DNS-клиенту с целью узнать, какой адрес соответствует введенному пользователем доменному имени.
В свою очередь DNS-клиент проверяет записи в файле hosts, затем в локальном кэше и, не обнаружив там нужных записей, передает запрос указанному в сетевых настройках DNS-серверу. Скорее всего это будет локальный кэширующий DNS-прокси, например, dnsmasq или локальный DNS-сервер предприятия. Данные решения обычно не являются полноценными серверами глобальной системы DNS и не входят в нее, обслуживая только локальную зону и кэшируя DNS-запросы, поэтому такой запрос, если данных не оказывается в кэше, передается вышестоящему DNS-серверу, как правило это сервер провайдера.
Получив запрос, сервер провайдера проверит собственные записи, затем собственный кэш, и, если результат будет найден, сообщит его клиенту, в противном случае сервер вынужден будет прибегнуть к рекурсии - поиску в глобальной системе DNS. Чтобы лучше понять механизм данного процесса мы подготовили следующую схему:
Итак, клиент отправляет DNS-запрос серверу провайдера с целью узнать адрес домена market.yandex.ru
, сервер провайдера не располагает подобной информации, поэтому обращается к одному из корневых серверов, передавая ему запрос. Корневой сервер также не имеет нужных записей, но отвечает, что знает сервер, отвечающий за зону ru
- a.dns.ripn.net
. Вместе с данным именем корневой сервер может сразу сообщить его IP-адрес (и в большинстве случаев сообщит), но может и не сделать этого, если не располагает такой информацией, в таком случае, перед тем как обратиться к данному серверу, нужно будет выполнить еще один рекурсивный запрос, только уже для определения его имени.
Выяснив адрес сервера, отвечающего за зону ru, сервер провайдера передаст запрос ему, но данный сервер также не имеет нужных записей, но сообщит, что за зону yandex отвечает сервер ns1.yandex.ru и обязательно сообщит его адрес. Иначе рекурсию завершить не удастся, так как за зону yandex отвечает сервер, находящийся в зоне yandex . Для этого в вышестоящей зоне, кроме NS-записи об обслуживающих зону серверах имен, создается "связанная" А-запись , которая позволяет узнать адрес такого сервера.
Наконец, отправив запрос серверу, обслуживающему зону yandex , сервер провайдера получит адрес искомого домена и сообщит его клиенту. Также он поместит полученный результат в кэш на время, предусмотренное значением TTL в SOA-записи этого домена. На практике, так как рекурсивные запросы весьма затратны, время кэширования записей у провайдеров может игнорировать значения TTL домена и достигать значений от двух-четырех часов до нескольких дней или даже недели.
Теперь рассмотрим еще один момент. Запросы могут быть рекурсивными или нерекурсивными. Рекурсивный запрос предусматривает получение готового ответа, т.е. IP-адреса или сообщения что домен не существует, не делегирован и т.п. Нерекурсивный запрос предусматривает ответ только о той зоне, за которую отвечает данный сервер или возврат ошибки.
Так как рекурсивные запросы являются достаточно ресурсоемкими большинство серверов сети DNS обрабатывают рекурсивные запросы нерекурсивно. Либо могут делать это выборочно, например, DNS-сервера провайдера выполняют рекурсивные запросы только для своих клиентов, а остальные нерекурсивно.
В нашем случае клиент послал серверу провайдера рекурсивный запрос, который, в свою очередь, последовательно отправлял нерекурсивные запросы пока не нашел требуемый сервер, который дал необходимый ответ. При этом в кэш сервера провайдера помещаются не только результаты пользовательского запроса, но и результаты промежуточных запросов, что позволяет выполнять следующие такие запросы нерекурсивно или с минимальным количеством запросов.
Например, если пользователь после посещения Яндекс Маркета решит воспользоваться почтовым сервисом, то сервер сразу направит запрос к ns1.yandex.ru , так как уже знает, какой сервер содержит записи для зоны yandex .
Когда вы приобретаете у регистратора домен, вам будет предложено его делегировать, т.е. указать DNS-сервера, на которых будет расположена доменная зона. Это могут быть сервера регистратора (обычно бесплатно), сервера хостера, публичные DNS-сервисы или собственные сервера имен, если он будет расположен в этой же доменной зоне, то вам потребуется также указать IP-адреса. Например, так выглядит окно делегирования домена у одного известного регистратора:
Что именно туда указывать? Это зависит от того, где и как вы будете размещать свой сайт. Если вы используете виртуальный хостинг, то все необходимые записи создаются хостером автоматически, при добавлении в панели управления хостингом вашего сайта, все что вам надо - это делегировать домен на NS-сервера хостера, т.е. указать их в данном окне. Этот способ хорошо подходит начинающим, благодаря своей простоте, но есть и обратная сторона, возможность управления DNS-зоной со стороны пользователя отсутствует или минимальна. Кроме того, на виртуальном хостинге IP-адрес сайта может быть изменен администраторами без уведомления пользователя, поэтому, если вы не хотите использовать NS-сервера хостера, то этот вопрос следует обязательно обсудить с техподдержкой.
Если вы переносите сайт к другому хостеру, то вам потребуется перенести сайт и поменять у регистратора сервера имен старого хостера на сервера нового. Но учтите, что информация в кэше DNS-серверов обновляется не мгновенно, а, как минимум, по истечении значения TTL-домена, поэтому в течении некоторого времени ваш сайт может быть доступен еще по старому адресу. Если вам надо срочно с ним работать, то можете, не дожидаясь обновления DNS-кэша вашего провайдера, добавить в файл hosts запись следующего содержания:
1.2.3.4 example.com
Где 1.2.3.4 и example.com соответственно новый IP-адрес и имя вашего домена.
Если у вас свой VPS или вы хотите полностью контролировать доменную зону, то следует воспользоваться серверами регистратора или публичными сервисами. Создание собственного сервера имен, на наш взгляд, не оправдывающая себя затея, если только вы не делаете собственный хостинг.
В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:
@ IN A 1.2.3.4
www IN A 1.2.3.4
Символ "собачки" в DNS-записях обозначает сам домен, кроме того обязательно следует создать запись для поддомена www, чтобы пользователи, набравшие адрес сайта с www, также могли получить к нему доступ.
Мы не будем рассматривать добавление записей для электронной почты, об этом можно прочесть в нашей статье:
При переносе сайта вам потребуется изменить только IP-адреса в A-записях и дождаться обновления DNS информации. Обычно, это самый неприятный момент - вроде бы все сделано, но ничего изменить вы не можете, остается только ждать. Но если выполнить некоторые рекомендации, то данный процесс можно провести максимально безболезненно и незаметно для посетителей.
Прежде всего измените значение TTL в SOA-записи. По-умолчанию оно равно нескольким часам и именно столько вам придется ждать обновления вашей записи в кэше DNS-серверов. Чтобы узнать текущее значение TTL можно выполнить команду, указав нужное доменное имя:
Nslookup -typr=soa сайт
В нашем случае это 4 часа:
Поэтому заранее, не менее 4 часов (старое значение TTL) до планируемого переноса, измените значение TTL на более низкое, например, 900 (15 минут). Затем переведите свой сайт в режим "только чтение" и перенесите его на новый сервер. Выключать или переводить на техобслуживание сайт не следует, он может и должен оставаться доступным. Но вы должны исключить изменение и добавление информации пользователями, т.е. запретить регистрацию, комментирование, размещение заказов и т.п. Также не забудьте разместить на видном месте сообщение о технических работах и примерный срок их завершения.
Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.
После успешного переноса значение TTL следует увеличить до прежних значений, чтобы не создавать лишней нагрузки на сервера имен.
Мы рассмотрели самую простую схему, но на практике, кроме сайта, обычно есть еще офисная сеть, многие ресурсы которой должны быть также доступны извне. Рассмотрим следующую схему:
У нас имеются публичные сервера для сайта и электронной почты и офисная сеть, для которой мы выделили поддомен office
. Если с почтой и веб-сервером особых вопросов нет, то с офисной зоной есть варианты. Обычно локальная зона обслуживается собственным DNS и никак не связана с материнской зоной. Для глобальной системы DNS зона office.example.com
не существует, но существует одноименный хост. Это оправдано, если сеть предприятия находится за NAT и ее узлы имеют только серые адреса, а доступ извне осуществляется только к шлюзу, на который проброшены соответствующие порты от внутренних узлов.
В этом случае DNS записи зоны example.com могут выглядеть следующим образом:
@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8
Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com , которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.
В локальной сети DNS-запросы клиентов обслуживает локальный сервер, которые имеет соответствующие записи, за ее пределами запросы будут направлены серверу, обслуживающему зону example.com . При этом все корпоративные ресурсы, которые в локальной сети представлены различными серверами, извне доступны по единственному адресу: office.example.com . Поэтому самое время вспомнить о записи псевдонима или CNAME. Данная запись позволяет связывать с реальным именем хоста дополнительные мнемонические имена или псевдонимы. При этом учтите, что использовать в других записях псевдонимов недопустимо. В нашем случае следует добавить записи:
Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.
Теперь клиент, вне зависимости от своего местоположения, может использовать для доступа к ресурсам одно и тоже имя, но результат получать при этом будет разный. В локальной сети он получит реальный адрес сервера и подключится напрямую, а за ее пределами будет направлен на шлюз сети.
Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.
Еще одно применение псевдонимов - это сокращение адреса. Допустим, в качестве почтового сервера для всего домена example.com мы хотим использовать сервер, который расположен в московском офисе и имеет адрес mail.office.msk.example.com , согласитесь, выглядит не слишком привлекательно. Гораздо удобнее был бы адрес вида mail.example.com , нет ничего проще, добавим следующую запись:
Mail IN CNAME mail.office.msk.example.com.
Но помните, что в остальных ресурсных записях следует использовать только реальные имена, поэтому такая запись будет неверной:
Example.com. IN MX 10 mail
Правильно будет так:
Example.com. IN MX 10 mail.office.msk
Напоследок поговорим о делегировании доменных зон. В примере выше мы рассмотрели ситуацию, когда внутри домена различным подразделениям выделены свои поддомены, так как у каждого подразделения имеется своя инфраструктура, то есть смысл делегировать им управление собственными доменными зонами. Для этого в зоне example.com следует разместить NS и связанную с ней A-запись для каждой зоны. Например:
Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.
ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8
Теперь при обращении по адресу, скажем mail.office.msk.example.com сервера имен зоны example.com будут выдавать имя и адрес сервера, обслуживающего зону msk.example.com . Это позволяет администраторам зоны самостоятельно вносить необходимые изменения, не затрагивая при этом функционирования вышестоящей зоны и не обращаясь к ее администраторам по любому вопросу, требующему изменения записей.
Добрый день, уважаемые читатели и постоянные подписчики, IT блога сайт. В прошлый раз мы разобрали, что такое DNS-сервер , его принципы работы, основные записи и много другое. Кто пропустил заметку, советую ознакомиться. В сегодняшней публикации я хочу рассмотреть вопрос, о обратных зонах и их применении.
Обратный запрос DNS - особая доменная зона, предназначенная для определения имени узла по его IPv4-адресу c помощью PTR-записи. Адрес узла AAA.BBB.CCC.DDD переводится в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов . Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.
PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.in-addr.arpa
in-addr.arpa - специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.
В целях уменьшения объёма нежелательной почтовой корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
