Запуск named
Пакет named обеспечивает DNS на большинстве Unix-машин. Это серверная программа, первоначально разработанная для BSD, чтобы обеспечить сервис имен для клиентов и, возможно, для других серверов имен. BIND Version 4 довольно долго поставлялся почти во всех дистрибутивах Linux. Сейчас вместо него поставляется новая версия 8, которая имеет много отличий от предыдущей. Особо надо отметить введение поддержки динамических модификаций DNS, сообщений изменения DNS, улучшение эффективности и новый синтаксис файла конфигурации.
Этот раздел требует понимания принципов работы DNS. Если такого понимания нет, обратитесь к разделу «Как работает DNS».
Пакет named обычно запускается при начальной загрузке системы. Реализации BIND до Version 8 берут информацию из файла конфигурации /etc/named.boot и различных файлов, которые отображают имена домена к адресам. Последние называются зональными файлами ( zone files). Версии BIND после Version 8 используют /etc/named.conf вместо /etc/named.boot .
Пакет named запустится и прочитает named.boot и заданные в нем зональные файлы. Он пишет свой process ID в файл /var/run/named.pid в ASCII, загружает все зональные файлы с первичного сервера и начинает слушать порт 53 в ожидании запросов DNS.
Файл named.boot
Файл конфигурации BIND до Version 8 был очень прост. BIND Version 8 имеет совсем другую структуру файла настройки, чтобы использовать новые свойства. Имя файла настройки сменилось с /etc/named.boot на /etc/named.conf . Мы сосредоточимся на конфигурировании старой версии, потому что многие дистрибутивы ее еще используют, но рассмотрим и отличия. К тому же мы рассмотрим, как преобразовать старый файл named.conf в новый.
Файл named.boot вообще маленький и содержит мало данных, но указывает на главные файлы, содержащие зональную информацию и хранит указатели на другие серверы имен. Комментарии в файле начинаются с символов # или ; и заканчиваются в конце строки. Прежде чем мы обсудим формат named.boot более подробно, рассмотрим типовой файл для vlager в примере 6-8.
Пример 6-8. Файл named.boot для vlager
Рассмотрим каждую инструкцию индивидуально. Ключевое слово directory сообщает named , что все имена файлов, упоминаемых позже в этом файле, например, зональные файлы, размещены в каталоге /var/named .
Ключевое слово primary загружает информацию в named. Эта информация принимается из главных (master) файлов, определенных как последние параметры. Эти файлы представляют DNS-записи ресурсов, которые мы рассмотрим позже.
В этом примере мы конфигурируем named как первичный ( primary ) сервер имен для трех доменов, как обозначено тремя инструкциями primary . Первая из них предписывает named действовать как первичный сервер для vbrew.com , принимая зональные данные из файла named.hosts .
Ключевое слово cache должно присутствовать фактически на всех машинах, управляющих сервером имен. Оно инструктирует named использовать кэш и загружать имена ( root name server hints) из определенного файла кэша (в нашем примере named.ca ). Это будет рассмотрено чуть позже.
Вот список наиболее важных параметров, которые Вы можете использовать в named.boot :
Опция определяет каталог, в котором расположены зональные файлы. Имена файлов в других параметрах могут быть даны относительно этого каталога. Несколько каталогов могут быть определены несколькими словами directory . Стандарт файловой системы Linux предполагает, что это /var/named .
Эта опция берет имя домена и имя файла как параметры, объявляя локальный сервер авторитетным для заданного домена. Как первичный сервер named загружает зональную информацую из данного главного файла.
Всегда будет по крайней мере одна запись primary в каждом файле boot, используемая для обратного отображения сети 127.0.0.0 , которая является кольцевым интерфейсом (loopback).
Инструкция берет имя домена, список адресов и имя файла как параметры. Это объявляет локальный сервер вторичным главным (secondary master) сервером для заданного домена.
Вторичный сервер хранит авторитетные данные относительно домена, но не собирает их из файлов. Вместо этого он пробует загружать их с первичного сервера. IP-адрес по крайней мере одного первичного сервера должен быть передан named в списке адресов. Локальный сервер входит в контакт с каждыми из них до успешного получения зональной базы данных, которая затем будет сохранена в резервном файле заданном как третий параметр. Если ни один из первичных серверов не отвечает, зональные данные будут восстановлены из резервного файла.
Затем named пытается обновить зональные данные с регулярными интервалами. Этот процесс объясняется позже в связи с типом записи ресурса SOA.
Эта опция берет имя домена и имя файла как параметры. Этот файл содержит root server hints, который является списком записей, указывающих на корневые серверы имен. Будут распознаны только записи NS и A. Параметр domain должен быть именем корневого домена.
Эта информация критична для named. Если инструкции cache нет в файле boot, named не будет использовать локальный кэш вообще. Эта ситуация резко ухудшит эффективность и увеличит сетевую загрузку, если следующий сервер сделает запрос не о машине в локальной сети. Кроме того, named не будет обращаться к корневым серверам, а значит, не сможет преобразовать никакие адреса кроме тех, которые авторитетны для него. Исключение из этого правила: сервера пересылки (см. ниже опцию forwarders ).
Инструкция берет список адресов, разделенных пробелами как параметр. Адреса IP в этом списке определяют список серверов имен, которые named может спросить, если не может найти адрес сам в локальном кэше.
Инструкция делает сервер имен подчиненным ( slave ). Он никогда не выполняет рекурсивные запросы самостоятельно, а только пересылает их на серверы, определенные в инструкции forwarders .
Есть два параметра, которые мы не будем описывать здесь: sortlist и domain . Еще две директивы могут также использоваться внутри этих файлов базы данных: $INCLUDE и $ORIGIN . Так как они редко нужны, мы не будем рассматривать их сейчас.
Файл host.conf в BIND 8
BIND Version 8 имеет много новых свойств, а с ними пришел и новый синтаксис файла конфигурации. Старый named.boot с простыми одиночными инструкциями был заменен на named.conf с синтаксисом, аналогичным gated, похожий на C-синтаксис.
Новый синтаксис более сложен, но есть инструмент, который автоматизирует преобразование старого синтаксиса в новый. В пакете исходников BIND 8 есть perl-программа named-bootconf.pl , которая занимается этим преобразованием. Чтобы использовать этот инструмент, Вы должны иметь установленный интерпретатор perl.
Пример 6-9. Файл для BIND 8, эквивалентный файлу named.conf для vlager
Если Вы внимательно его рассмотрите, то обратите внимание на то, что каждая из инструкций named.boot превратилась в C-инструкцию, взятую в фигурные скобки «< >«.
Комментарии, которые в файле named.boot начинались с точки с запятой (;), теперь обозначены как //.
Инструкция directory превратилась в параграф options с предложением directory .
Команды cache и primary преобразованы в зональные параграфы ( zone ) с типами ( type ) предложений hint и master , соответственно.
Зональные файлы не должны измениться: их синтаксис остается неизменным. Новый синтаксис конфигурации учитывает много новых параметров, которые мы еще не рассмотрели.
Файлы базы данных DNS
Главные (Master) файлы, поставляемые с named, подобно named.hosts, всегда имеют домен, связанный с ними, называемый origin. Это имя домена, указанное с параметрами cache и primary . Внутри главного файла Вы можете определить домен и связанные с ним имена файлов. Имя, заданное в файле конфигурации, рассматривается абсолютно ( absolute), если оно заканчивается одной точкой, иначе оно рассматривается относительно origin. Можно и прямо сослаться на origin знаком ( @ ).
Данные, содержащиеся в главном файле, разделены на записи ресурсов ( resource records, RRs). RRs самые маленькие модули информации, доступные через DNS. Каждая запись ресурса имеет тип. Например, A-записи отображают имя хоста на IP-адрес, а CNAME-записи связывают псевдоним для хоста с его официальным именем. Пример 6-11 показывает главный файл named.hosts для Virtual Brewery.
Поля отделяются пробелами или позициями табуляции. Запись может быть продолжена после перевода строки, если открывающаяся фигурная скобка стоит перед первым переводом строки и последнее поле сопровождается заключительной фигурной скобкой. Все между точкой с запятой и символом перевода строки игнорируется. Описание формата:
Задает имя домена, к которому относится запись. Если никакое имя не задано, RR применяется к домену предыдущей RR.
Чтобы сервер имен обновлял информацию, RR ограничен по времени работы ( ttl). Это поле определяет время в секундах, которое информация имеет силу после того, как была получена с сервера. Это десятичное число из восьми цифр.
Если значение ttl не дано, ему присваивается значение поля minimum предыдущей SOA-записи.
Класс адреса, например, IN для адресов IP или HS для объектов в Hesiod-классе. Для TCP/IP Вы должны определить IN.
Если никакое поле класса не задано, берется класс предшествующей RR.
Описывает тип RR. Наиболее часто встречаются типы A, SOA, PTR и NS. Следующие разделы описывают различные типы RR.
Хранит данные, связанные с RR. Формат этого поля зависит от типа RR. Дальше это будет описано для каждого RR отдельно.
Дальше приведен частичный список RR, которые нужно использовать в файлах DNS.
Описывает зону авторитета (SOA или «Start of Authority»). Эта запись сообщает о том, что записи после SOA RR содержат авторитетную информацию для домена. Каждый главный файл, включенный в инструкцию primary , должен содержать SOA-запись для этой зоны. Данные ресурса содержат следующие поля:
Это каноническое имя хоста основного сервера для этого домена. Обычно задается как абсолютное имя.
Это e-mail адрес человека, ответственного за поддержание домена, со знаком » @ » замененным на точки. Например, если ответственный в Virtual Brewery janet , это поле содержит janet.vbrew.com .
Номер версии зонального файла, выраженный как единственное десятичное число. Всякий раз, когда данные меняются в зональном файле, это число должно быть увеличено.
Серийный номер используется вторичными серверами, чтобы распознать, когда зональная информация была изменена. Чтобы оставаться на уровне современных требований, вторичные серверы запрашивают SOA-запись первичного сервера в определенные промежутки времени и сравнивают порядковый номер с кэшируемой SOA-записью. Если номер изменился, то вторичные серверы перенесут целую зону баз данных из основного сервера.
Определяет интервал в секундах, который вторичные серверы должны использовать между проверками SOA-записей основного сервера. Это десятичное число более, чем с восемью цифрами.
Это число определяет интервалы, за которые вторичный сервер должен повторить соединение с основным сервером, если запрос или зональная регенерация терпит неудачу. Он не должен быть слишком маленьким, потому что даже временный отказ сервера или сетевая проблема могут потратить впустую все сетевые ресурсы. Один час или, возможно, полчаса оптимальное значение.
Определяет время в секундах, после которого сервер должен отбросить все зональные данные, если невозможно было войти в контакт с основным сервером. Этот промежуток времени должен быть очень большим. Craig Hunt рекомендует 42 дня.
Задает по умолчанию значение ttl для исходных записей, которые точно не определяют его. Требует другого сервера, чтобы отбросить RR при проверки после определенного времени.
Ничего нельзя сделать со временем, после которого вторичный сервер попробует модифицировать зональную информацию. Значение minimum должно быть большим, особенно для LAN, где сетевая топология почти никогда не меняется. В случае, когда единственные RR могут часто изменяться, Вы можете приписывать им различные ttl.
Ассоциирует IP-адрес с именем. Содержит адрес в dotted quad notation. Для каждого хоста должна быть только одна запись. Hostname, используемый в этой А-записи, считается служебным или каноническим hostname. Все другие hostname расцениваются как псевдонимы и должны быть отображены на канонический ( canonical) hostname, используя запись CNAME. Если каноническое имя нашего хоста vlager, его и надо вписать в A-запись с его IP-адресом. Если мы связываем с этим адресом другое имя, например news , надо использовать запись CNAME, которая свяжет его с альтернативным именем.
Указывает на главный (primary) сервер подчиненной зоны. Содержит hostname сервера.
Запись NS определяет имена первичного и вторичного серверов для зоны. Эти имена должны быть разрешимы к используемому адресу. Иногда серверы не принадлежат к обслуживаемому домену, что порождает проблему: нельзя обратиться к серверу, пока не получен его адрес, но получить адрес нельзя, пока не обратимся к серверу (неоткуда). Можно конфигурировать специальные записи непосредственно на сервере имен родительской зоны. Они позволяют серверу из родительской области преобразовывать IP-адрес делегированного зонального сервера. Эти записи обычно названы приклеенными записями ( glue records), поскольку они «склеивают» делегированную зону с родительской.
Ассоциирует псевдоним хоста с его каноническим hostname. Каноническиий hostname указан в файле, который обеспечивает А-запись, а псевдонимы просто связаны с этим именем CNAME-записью, но не имеют собственных записей.
Этот тип записи используется, для того, чтобы соединить имена домена in-addr.arpa с именами хостов (hostnames). Это используется для обратного отображения IP-адресов к hostnames. Данное имя должно быть каноническим.
Имя host объявляет преобразователь почты для домена domain . Каждый преобразователь почты имеет целое число preference , связанное с ним. Агент транспортировки почты, желающий доставить почту в домен, будет перебирать все хосты, не имеющие MX-записей в этом домене, пока все не пройдет успешно. Сначала будет проверяться тот хост, у которого самое низкое число, а затем все хосты по возрастанию числа.
Поле hardware идентифицирует аппаратные средства, используемые этим хостом. Имеются специальные соглашения, чтобы точно определить их. Список подходящих имен дан в «Assigned Numbers» (RFС 1340). Если область содержит пробелы, то ее содержимое надо заключить в двойные кавычки. Имена областей software используются операционной системой. Подходящее имя может быть выбрано из «Assigned Numbers» RFC.
Настройка сервера только для кэширования
Это особая конфигурация named . Такой сервер в действительности не обслуживает домен, а просто осуществляет переброску всех запросов DNS, произведенных на Ваш компьютер. Преимущество этой схемы в том, что она создает кэш. Так что только первый запрос для специфического компьютера фактически будет послан серверу имен в Internet. Любой повторный запрос будет обработан из кэша. Такая схема названа caching-only. Это удобно при работе с Internet по модему, как описано в главе 7 и главе 8.
В дополнение к этому файлу named.boot , Вы должны установить файл named.ca со списком корневых серверов имен. Вы можете копировать и использовать для этой цели пример 6-10. Другие файлы не требуются.
Написание главных (Master) файлов
Примеры 6-10, 6-11, 6-12 и 6-13 дают типовые файлы для сервера имен сети brewery, размещенного на машине vlager . Это довольно простая конфигурация для одиночной локальной сети.
Источник
