Планирование устойчивой системы доменных имен

Введение

Во время интенсивной нагрузки Network Node Manager может выполнять сотни операций прямого и обратного поиска, приступая к раскрытию, управлению конфигурацией и проверке состояния. Для этого требуется надежная, точная, высокопроизводительная система доменных имен (DNS). В этой лекции дается обзор функционирования и конфигурации DNS в предположении, что читатель уже знаком с этой системой.

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

До появления DNS поддерживался файл /etc/hosts — простой линейный файл, содержащий имена и IP-адреса сетевых систем. Проблемы, связанные с размером файла и его распространением, заметно ограничивали масштабируемость.

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

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

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

В этой лекции приводятся примеры конфигурационных файлов для клиента и сервера DNS (для ОС UNIX). Предполагается наличие восьмой версии BIND; примеры файлов являются реальными, проверенными на моей системе Red Hat Linux.

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

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

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

Полное руководство по DNS приводится в книге Abitz и Liu DNS and BIND, Third Edition, O’Reilly Associates Inc., ISBN 1-56592-010-4Имеется переводное издание на русском языке: Альбитц П., Ли К.. DNS и BIND. – Пер. с англ. – СПб: Символ-Плюс, 2002. – 696 с. Прим. переводчиков.

Почему служба DNS настолько важна для NNM

NNM раскрывает устройства с помощью IP-адреса, обнаруживаемого в ARP-кэшах, начальных файлах, таблицах маршрутизации и откликах ICMP. В IP-сетях устройствам приписываются имена, и в больших сетях это пространство имен разбивается на иерархию поддоменов. Это устраняет возможность коллизии имен в больших сетях, где поддерживается высокий уровень проверки конфигурации, порождающий высокую интенсивность прямого и обратного DNS-поиска. Такой механизм поиска может стать узким местом производительности.

Распространенной проблемой является объединение системой NNM двух маршрутизаторов в один узел. Это обычно случается из-за дефектных данных DNS.

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

Все крупные компании с большими сетями полагаются на свои реализации DNS, чтобы распределить полномочия по назначению имен и IP-адресов между более мелкими и легко управляемыми официальными поддоменами. Заметим, что основанные на web сервисы в Internet вообще не функционировали бы без DNS. Как бы происходило создание HTML с жестко закодированными IP-адресами? DNS очень хорошо масштабируется к самым большим сетям.

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

Можно использовать команду NNM ovtopodump, чтобы отыскивать устройства, для которых нет записей DNS:

ovtopodump –Lr > report_name

С помощью этой команды можно получить очень полезную однострочную сводку для каждого устройства в базе данных NNM. В системе UNIX можно направить вывод команды ovtopodump в один или несколько фильтров (таких как sort ) с какой-либо особой целью. Например, предположим, что желательно выяснить, для каких устройств домена управления отсутствуют записи DNS. Для этого достаточно выполнить команду

ovtopodump –Lr | sort > report_name

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

История /etc/hosts

Исторически в Internet-системах для распространения информации об IP-адресах и именах хостов использовался файл HOSTS.TXT. Это плоский текстовый файл, который просматривается от начала до конца при каждом прямом поиске (задается имя, а возвращается IP-адрес) или обратном поиске (задается IP-адрес, а возвращается имя). Формат файлов HOSTS.TXT и /etc/hosts приведен на рисунке 2.1.

Поля разделяются пробелами. Поле 1 – это IP-адрес. Поле 2 содержит формальное имя системы. Дополнительные поля (до символа комментария #) являются альтернативными именами для этого устройства. После знака # могут располагаться необязательные комментарии.

HOSTS.TXT должен был всегда содержать самые свежие данные, поэтому он обновлялся в одном узле в соответствии с информацией, обеспечиваемой многими хост-мастерами Internet, и ежедневно загружался всеми системами, которые им пользовались. Эта процедура обеспечивала согласованность содержимого файла HOSTS.TXT в Internet. Со временем размер файла HOST.TXT вырос до нескольких мегабайт, и объем трафика, который требовался для его загрузки, стал слишком велик. Коротко говоря, оказалось, что HOST.TXT не является масштабируемым решением.

Тормозился процесс развития Internet, поскольку у каждого хоста в Internet должно было быть уникальное имя.

Если бы в каких-то узлах не производилось добросовестное обновление HOST.TXT, в них часто возникали бы проблемы связи с узлами, в которых недавно были обновлены или полностью изменены некоторые IP-адреса. Даже одиночная ошибка могла привести к тому, что несколько систем или целых подсетей становились недостижимыми.

Механизм HOST.TXT немного стоил и в отношении информации. Например, чтобы послать e-mail в систему, не подключенную напрямую к Internet, отправителю нужно было знать почтовые системы по всему пути и включать их адреса в качестве части e-mail-адреса.

Таким образом, в Internet требовался сервис имен, который бы:

Этим сервисом стал DNS/BIND (Domain Name Service/Berkeley Internet Nameserver Daemon). Он полностью отвечает каждому из приведенных выше требований, в особенности требованию масштабирования. DNS масштабируется до размеров Internet и абсолютно необходим для работы web-приложений.

Интерфейсы маршрутизаторов и DNS

Маршрутизатор является групповым устройством, поскольку у него имеется несколько сетевых адаптеров. Файл-сервер с двумя адаптерами Fast Ethernet представляет собой другой пример группового устройства. Разным сетевым адаптерам обычно назначаются IP-адреса в разных подсетях. Групповое устройство можно достичь при помощи любого сетевого адаптера путем указания его IP-адреса. Например, предположим, что у маршрутизатора с именем myrouter имеются два сетевых адаптера с IP-адресами — 15.24.44.65 и 192.6.173.101. Войти в myrouter можно с помощью любой из следующих команд:

telnet 15.24.44.65
telnet 192.6. 173.101
telnet myrouter

Обычно никому не хочется заботиться об указании IP-адреса одного из адаптеров. Если адаптер 15.24.44.65 находится в нерабочем состоянии, то команда telnet с этим адресом не поможет достичь маршрутизатора.

DNS предназначается для работы с групповыми устройствами. nslookup – это интерфейс командной строки для обследования DNS. После ввода командной строки

nslookup myrouter

nslookup выдаст список IP-адресов. Всем интерфейсам следует иметь то же имя, что и у маршрутизатора.

Заметим, что нередко для web-серверов имеются записи DNS для адресов, относящихся к логическим узлам. В таких случаях NNM может давать путаное представление.

Некоторые интерфейсы маршрутизаторов, такие как HSSI, конфигурируются с подинтерфейсами, имеющими назначенные IP-адреса. Иногда одному адаптеру маршрутизатора назначаются один или более вспомогательных IP-адресов. Иногда маршрутизаторам приписывается уникальный короткий внутренний IP-адрес возвратной петли (loopback). Все эти логические интерфейсы должны иметь то же самое имя, что и маршрутизатор. Это всего лишь хорошая практика для правильного функционирования NNM. Во многих узлах не придерживаются этой практики и назначают каждому интерфейсу уникальное имя.

Oдно имя для всех интерфейсов маршрутизатора – это замечательное новшество. Но как узнать, какой IP-адрес следует использовать при попытке подключиться к myrouter через telnet? В зависимости от версии DNS возвращает свой список IP-адресов в соответствии с одним из следующих правил:

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

Менеджеру сети часто требуется обращаться к маршрутизатору, когда один или несколько интерфейсов не работают. Если используется команда telnet, то как узнать, какой интерфейс нужен? Дело в том, что telnet и ftp "осведомлены" о DNS. То есть они знают, что следует делать, когда при поиске имени возвращается список IP-адресов. Таким образом, эти команды проверяют каждый интерфейс из списка до тех пор, пока не будет установлен контакт с маршрутизатором.

DNS хорошо подходят для групповых устройств.

Модели надежности для DNS

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

Чтобы понять, каким образом эти архитектурные элементы обеспечивают надежность, рассмотрим сначала клиент-серверную модель DNS. Приложение (такое как telnet, ftp, NNM, Navigator или sendmail ), которое нуждается в подключении к другой системе по имени, является клиентом DNS. Этот клиентский код называется распознавателем (resolver), он управляется редактируемым конфигурационным файлом с именем resolv.conf (как resolve, но без последней буквы) в среде UNIX. В файле resolv.conf определяются следующие параметры:

В клиентских системах Windows для конфигурирования распознавателя DNS обеспечивается GUI (как показано на рис. 2.3).

Три сервера имен указываются для увеличения вероятности того, что, по крайней мере, один сервер имен будет достижим. В реальных сетях возможен аварийный отказ сервера имен или может не работать сетевой маршрут к нему. Например, предположим, что каждый из трех наших серверов обладает надежностью в 99%, и что они независимы один от другого (разные источники питания, разные подсети, разные компоновки, разные маршрутизаторы, разные администраторы, разное программное обеспечение). Следовательно, статистическая надежность сервиса имен в нашем примере 1-(1-0.99)3 = 0.999999 = 99.9999%, что замечательно при заданной для каждого сервера имен надежности в 99%.

NNM настолько интенсивно использует DNS, что представляется целесообразным инсталлировать сервер имен в той же системе. Это снижает связанный с DNS сетевой трафик, а также уменьшает время ожидания сервиса DNS, поскольку устраняется сетевая задержка между системой NNM и системой сервера имен. Поэтому первым сервером имен среди тех, которые перечислены в файле resolv.conf, является 127.0.0.1 — стандартный IP-адрес для localhost, представляющий собой стандартный IP-адрес возвратной петли.

Как следует конфигурировать этот локальный сервер имен? Инсталлировать в системе NNM конфигурационные файлы DNS недопустимо. Это может не согласовываться с существующей архитектурой и реализацией корпоративных серверов имен. Поэтому общей практикой является конфигурирование DNS в системе NNM в виде только кэширующего сервера имен. Каждый раз, когда NNM обращается с запросом к DNS, результат кэшируется в локальной памяти, пока не истечет время жизни записи.

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

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

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

Назначение и использование делегирования

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

Внутри очень большой корпоративной сети могут находиться сотни официальных серверов имен для сотен поддоменов. Например, некоторыми из поддоменов домена acme.com могли бы быть east.acme.com, west.acme.com, north.acme.com, south.acme.com и corp.acme.com. Все эти домены принадлежат узлам, которые являются независимыми организационными единицами. Локальные сетевые администраторы назначают компьютерному и сетевому оборудованию доменов IP-адреса, имена и даже поддомены. Эта ответственность им делегируется. Локальные сетевые администраторы также управляют локальными серверами имен, воспроизводя, таким образом, это делегирование.

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

Заметим, что в каждом из пяти узлов acme.com имеется полная свобода назначения дублирующих имен для оборудования. Например, в каждом узле может поддерживаться почтовый шлюз с именем email. Но здесь нет конфликта имен, поскольку полностью уточненные имена почтовых шлюзов являются уникальными: email.corp.acme.com, email.east.acme.com, email.west.acme.com, email.north.acme.com и email.south.acme.com.

На практике, когда администраторам локальной сети нужно изменить IP-адрес email.west.acme.com, они обновляют локальные официальные серверы имен новыми данными в одно и то же время. Когда почтовому серверу corp.acme.corp.com потребуется переслать сообщения на email.west.corp.com, он будет использовать IP-адрес, который получит от DNS, и этот адрес будет новым.

Примеры конфигурационных файлов DNS

Распознаватель DNS использует файл /etc/resolv.conf для определения локального поддомена: маршрута поиска и до трех серверов имен (см. рис. 2.2). Демон сервера имен named читает конфигурационный файл /etc/named.conf (или /etc/named.boot ), чтобы определить местонахождение каталога (такого как /var/named ) файлов базы данных, как показано на рис. 2.4. Файлы базы данных, такие как db.cache, указывают на другие серверы имен, как показано на рис. 2.5. Два основных типа записей в базе данных – это адрес и указатель. Адресные записи содержат IP-адреса имен в поддомене (см. рис. 2.6). Указательные записи содержат имена, соответствующие IP-адресам (см. рис. 2.7).

В среде операционной системы UNIX для хранения конфигурационных записей распознавателя DNS используется текстовый файл /etc/resolv.conf. В BIND version 8 распознаватель добавляет каждый из поисковых доменов к имени, указанному в запросе, пытаясь получить успешный результат поиска.

Для полноты картины заметим, что эквивалентом /etc/resolv.conf в Windows является GUI, спрятанный в Network Control Panel. Для примера см. рисунок 2.3.

Здесь важно подчеркнуть, что точка в конце доменных имен имеет решающее значение при конфигурировании файлов базы данных собственного сервера имен. При поиске и устранении ошибок в конфигурациях серверов имен следует использовать nslookup, dig или непосредственно демон named (посылая ему сигнал SIGINT для выгрузки базы данных в файл для обследования). Для построения исходного набора файлов базы данных на основе /etc/hosts в системе могут использоваться утилиты hosts2named или h2d.

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

Коэффициенты загрузки систем DNS

Администраторы DNS всегда учитывают критическую важность этих систем. Высокий коэффициент загрузки ЦП на сервере имен послужил бы поводом для беспокойства. Поэтому, естественно, администраторы недовольны любой системой NNM, посылающей сотни пакетов запросов к DNS в секунду на протяжении всего дня. К счастью, DNS реализована очень эффективно. Все сетевые запросы доставляются в облегченных UDP-пакетах, и ответы поступают либо из кэша в основной памяти, либо от другого сервера имен. Выполняются только простые операции, и передается лишь небольшой объем данных. Обмены с дисками происходят лишь тогда, когда named должен обновить домен, перезапуститься, выгрузить свою базу данных, произвести свопинг или поместить сообщение в syslog. Конечно, желательно иметь основную память достаточного объема, чтобы всегда удерживать в ней named.

В Windows эквивалентом /etc/resolv.conf является Network Control Panel. В GUI отслеживается, что максимальное (стандартное) число указываемых DNS-серверов равно трем.

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

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

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

Кэширование в NNM

Кэширование в NNM и кэширование в DNS – это не одно и то же, и я хочу уточнить, что применяются два вида кэширования.

Этот конфигурационный файл сервера имен содержит имена и соответствующие IP-адреса всех систем в домене north.acme.com.

NNM выполняет очень много повторяющихся операций на одних и тех же устройствах. Чтобы избежать потенциально затратного поиска информации от других служб, NNM кэширует эту информацию, чтобы повысить общую производительность. Информация записывается на диск и сохраняется после выполнения команд ovstop и ovstart или перезагрузки. Оборотная сторона такой "живучести" данных заключается в том, что внешние изменения конфигурации сети могут привести к потере контакта NNM с теми устройствами, которые изменились. В этом случае необходимо воспользоваться командой xnmsnmpconf — clearCache для очистки кэша конфигурации SNMP. Эту команду следует выполнять, когда меняются имена и IP-адреса устройств, управляемых SNMP, а NNM не отслеживает изменение. Перед очисткой кэша конфигурации SNMP может потребоваться удалить устройство-нарушитель из всех схем. Когда база данных NNM удаляется в порядке подготовки к "послестартовому" раскрытию, имеет смысл очистить и кэш конфигурации SNMP.

Первичность, вторичность и другие премудрости

С появлением восьмой версии BIND (Berkeley Internet Name Daemon) термины "основной сервер" и "вспомогательный сервер" заменены понятиями "ведущий сервер" и "подчиненный сервер" соответственно. Конфигурационный файл /etc/named.boot теперь именуется /etc/named.conf, и синтаксис файла усовершенствован для большей гибкости и удобочитаемости. Имеется даже Perl-скрипт ( named-bootconf.pl ) для обновления синтаксиса конфигурационного файла.

Этот конфигурационный файл сервера имен содержит IP-адреса и соответствующие имена всех систем в диапазоне 10.121.121.

Восьмая версия BIND является предпочтительной из-за множества новых возможностей. Она способна проверять, соответствуют ли имена в базе данных или в ответах RFC 953. Обеспечивается полное управление журнализацией сообщений. Список доступа разрешенных подчиненных серверов ограничивает возможности взломщиков по выполнению зонных пересылок. Это также означает, что требуется согласование с группой поддержки DNS, если решено запустить NNM в качестве вспомогательного/подчиненного DNS-сервера. Имеется средство синхронизации, позволяющее ведущему серверу уведомлять его подчиненные серверы об обновлении базы данных. Динамические обновления поддерживаются путем разрешения авторизованной системе посылать ведущему серверу сообщения об обновлениях. Это особенно полезно в средах DHCP (Dynamic Host Configuration Protocol).

Система NNM конфигурируется с только кэширующим сервером имен и ссылается на два ведущих сервера в зоне noth.acme.com. Они, в свою очередь, ссылаются на два корневых сервера имен, которые конфигурируются с полномочными записями, указывающими на шесть серверов имен.

Расширенная картина реализации DNS

В этом разделе рассматривается взаимосвязь между различными архитектурными элементами реализации DNS (см. рис. 2.8).