Партнёры:
Хостинг:
named - сервер доменных имен Internet
named [ -d уровень отладки ] [ -p номер порта[/номер локального порта] ] [{-b} стартовый файл ] [ -q ] [ -r ]
Named является сервером доменных имен Internet. Более подробно о системе доменных имен Internet см. документы RFC 1033, 1034 и 1035. Будучи запущен без параметров, named читает стартовый файл по умолчанию /etc/named.boot, загружает все первоначальные данные и начинает слушать запросы.
Имеются следующие опции:
Выводит отладочную информацию. Число после ``d'' определяет уровень выводимых сообщений.
Использовать нестандартные номера портов. По умолчанию используется стандартный номер порта, возвращаемый функцией getservbyname(3) для службы ``domain''. В аргументе могут быть указаны два номера портов, разделенных наклонной чертой (``/''). В это случае первый порт используется при соединении с удаленными серверами, а второй назначает себе локальная копия named. Это используется в основном для отладочных целей.
Использовать указанный стартовый файл. Эта опция необязательна и позволяет указывать имя файла, начинающегося с дефиса.
Отслеживать все входящие запросы, если named был скомпилирован с определенной константой компиляции QRYLOG. ПРИМЕЧАНИЕ: вместо этой опции лучше использовать директиву стартового файла ``options query-log''.
Выключает рекурсию в сервере. Ответы могут приходить только от локальных (первичных или вторичных) зон. Эта опция может быть использована на корневых серверах. ПРИМЕЧАНИЕ: вместо этой опции лучше использовать директиву стартового файла ``options no-recursion''.
Каждый дополнительный аргумент воспринимается как имя стартового файла. Если указано несколько стартовых файлов, используется последний из них.
Стартовый файл содержит информацию о том, где сервер имен должен брать начальные данные. Каждая директива стартового файла должна располагаться ровно на одной строке. Ниже приведен небольшой пример стартового файла:
;
; boot file for name server
;
directory /usr/local/adm/named
; type domain source host/file backup file
cache . root.cache
primary Berkeley.EDU berkeley.edu.zone
primary 32.128.IN-ADDR.ARPA ucbhosts.rev
secondary CC.Berkeley.EDU 128.32.137.8 128.32.137.3 cc.zone.bak
secondary 6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak
primary 0.0.127.IN-ADDR.ARPA localhost.rev
forwarders 10.0.0.78 10.2.0.78
limit transfers-in 10
limit datasize 64M
limit files 256
options forward-only query-log fake-iquery
check-names primary fail
check-names secondary warn
check-names response ignore
Директива ``directory'' меняет рабочий директорий сервера на указанный в аргументе этой директивы. Это может быть важно для правильной обработки вложенных директивой $INCLUDE файлов в файлы первичных зон.
Директива ``cache'' указывает, что содержимое файла ``root.cache'' должно быть считано в кэш сервера при старте. Основное его предназначение заключается в указании местоположения корневых серверов. Этот кэш не используется при нормальной работе, но необходим в качестве ``подсказки'' при поиске текущих корневых серверов. Файл ``root.cache'' имеет тот же формат, что и ``berkeley.edu.zone''. Директивой ``cache'' может быть описано более одного файла. Файл ``root.cache'' необходимо регулярно обновлять из FTP.RS.INTERNIC.NET, поскольку он содержит периодически изменяющийся список корневых серверов.
Первая директива ``primary'' указывает, что файл ``berkeley.edu.zone'' содержит авторитетные данные по зоне ``Berkeley.EDU''. Файл ``berkeley.edu.zone'' содержит данные в формате мастер-файла, описанном в RFC 883. Все доменные имена указываются относительно исходного домена (origin), в данном случае ``Berkeley.EDU'' (более подробно см. ниже). Вторая директива ``primary'' указывает, что в файле ``ucbhosts.rev'' находятся авторитетные данные по домену ``32.128.IN-ADDR.ARPA'', который используется для трансляции IP-адресов в сети 128.32 в имена хостов. Какждый из мастер-файлов должен начинаться с записи SOA для указанной в нем зоны (см. ниже).
Первая директива ``secondary'' указывает, что все авторитетные данные по зоне ``CC.Berkeley.EDU'' должны приниматься с сервера по адрему 128.32.137.8. Если эти данные принять не удается, необходимо попытаться принять их с сервера по адресу 128.32.137.3, и так далее, причем в этой директиве может быть указано до 10 таких адресов. Вторичная копия также считается авторитетной для указанного домена. Первое имя в этой директиве, не являющееся IP-адресом (отличное от четырех чисел, разделенных точками), воспринимается как имя файла, в котором будет сохранена резервная копия принятых данных по зоне. Сервер загрузит данные по зоне из этой резервной копии, обеспечивая сервис имен даже в том случае, если первичные сервера будут недоступны. Резервная копия будет обновляться после каждого успешного обновления, полученного автоматически с одного из первичных серверов. Если имя файла резервной копии не указано, данные по зоне будут сохраняться во временном файле, который будет удален после каждого успешного приема зоны. Это не рекомендуется делать из-за неоправданного повышения сетевого траффика. Вторая директива ``secondary'' указывает, что резервные копии файлов для трансляция адресов в имена подсети 128.32.136 должны получаться с тех же серверов, что и для для предыдущей зоны.
Директива ``forwarders'' указывает адреса тех серверов в пределах сети, которые воспринимают рекурсивные запросы от других серверов. Если в стартовом файле указано более одного такого сервера, то основной сервер перенаправит все запросы, для которых нет ответа в кэше, сначала им. В процессе перенаправления запроса будут опрошены все сервера в списке ``forwarders'' до тех пор, пока не будет получен ответ либо исчерпан сам список. Если ответ все-таки не будет получен, основной сервер продолжит работу так, как если бы ни одного сервера с рекурсивным запросом не было указано (если только он не работает в режиме ``forward-only'', то есть ``только перенаправление запросов''). Возможность перенаправления запросов бывает полезна для создания большого кэша в пределах сети на мастер-сервере и, как следствие, уменьшения сетевого траффика при запросах к внешним серверам. Она также может быть полезной для серверов, не имеющих прямого подключения к Internet, но желающих, тем не менее, производить поиск внешних имен.
Директива ``slave'' (в настоящее время устаревшая) используется для обратной совместимости. Ее значение полностью аналогично директиве ``options forward-only''.
Директива ``sortlist'' может использоваться для указания приоритета одних сетей над другими. При этом общий приоритет в просмотре имен распределится следующим образом: сначала при получении запроса сервер просмотрит список имен с адресами локальной сети, затем последовательно список адресов, представленный в директиве ``sortlist'', а затем все остальные адреса.
Директива ``xfrnets'' (в примере не показана) может использоваться для простейшего контроля доступа. При указании этой директивы сервер будет отвечать на запросы передачи зоны только от тех хостов, которые находятся в сетях, указанных в директиве ``xfrnets''. Другое, устаревшее, название этой директивы - ``tcplist''.
Директива ``include'' (в примере не показана) может использоваться для обработки другого файла, как если бы его содержимое было вставлено вместо самой директивы ``include''. Она бывает полезна при наличии большого количества зон либо при логической группировке зон, сопровождаемых разными людьми. Директива ``include'' имеет один аргумент, являющийся именем включаемого файла, при этом само имя файла в кавычки (либо другие ограничители) не заключается.
Директива ``bogusns'' (в примере не показана) сообщает системе BIND, что серверам с указанными в ней IP-адресами нельзя посылать никаких запросов. Это может быть полезным в том случае, когда у какого-либо популярного сервера появляются неверные или испорченные данные в его зоне либо кэше, и Вы хотите избежать обращений к нему до тех пор, пока ситуация не будет исправлена.
Директива ``limit'' используется для изменения внутренних предельных величин системы BIND, причем некоторые из них (datasize, например) реализованы на системном уровне, а другие (вроде transfers-in) на уровне самой BIND. Для чисел, указывающих значения пределов и следующих за именами предельных величин, могут указываться приставки ``k,'' ``m'' или ``g'', означающие килобайты, мегабайты и гигабайты соответственно. Аргумент параметра datasize устанавливает размер блока данных процесса, ограничиваемый сверху ядром. Примечание: этот системный вызов реализован не во всех системах -- на таких системах использование параметра datasize директивы ``limit'' приведет к появлению предупреждающего сообщения. Аргументом параметра transfersin является максимальное количество подпроцессов named-xfer, запускаемых BIND одновременно. Аргументом параметра transfers-per-ns является максимальное количество зонных обменов, инициируемых одновременно с любым заданным удаленным сервером имен. Аргумент параметра files устанавливает максимальное количество дескрипторов файлов, доступных процессу. Примечание: этот системный вызов реализован не во всех системах -- на таких системах использование параметра files директивы ``limit'' приведет к появлению предупреждающего сообщения.
Директива ``options'' определяет логический параметр, изменяющий поведение системы BIND. В одной директиве могут быть указаны несколько параметров. Ниже перечислены опции, определенные в настоящее время. no-recursion - заставляет сервер имен отвечать ссылкой на более авторитетный сервер, нежели точным ответом, при встрече запроса имени, за которое сам сервер не является ответственным. Не устанавливайте эту опцию на сервере, ссылка на который есть в файле resolv.conf любого хоста. no-fetch-glue - заставляет сервер имен не искать части или суффиксы доменного имени при конструировании секции ``additional data'' (дополнительные данные) ответа. Эта опция может использоваться в сочетании с опцией no-recursion с целью предотвращения увеличения кэша BIND или его разрушения. query-log - заставляет фиксировать все запросы в системном журнале посредством syslog(8). Это приводит к быстрому росту системного журнала, поэтому не пользуйтесь этой опцией без необходимости. forward-only - заставляет сервер только перенаправлять запросы другим серверам с возможностью рекурсивного запроса (forwarders). Обычно эта опция используется на машине, на которой запущен сервер имен, но которая по физическим либо административным причинам не может иметь доступа к Internet. fake-iquery - заставляет сервер отсылать обратно бесполезные ответы на ``инверсные запросы''. Это может быть полезным, если Ваша сеть состоит из микрокомпьютеров или машин с SunOS или и тех, и других.
Директива ``check-names'' указывает системе BIND проверять имена в файлах как первичных (``primary''), так и вторичных (``secondary'') зон, а также в сообщениях (``responce''), полученных во время рекурсивного запроса (например, при обработке запроса от хоста, находящегося за сетевым экраном (firewall)). На каждый тип имени BIND может отправить либо ответ типа ``fail'' (неудача), при этом такая зона не будет загружена, а запрос не будет кэширован или отправлен дольше для рекурсивного запроса, либо ответ типа ``warn'' (предупреждение), в результате чего на это имя сервер сгенерирует сообщение в системном журнале, либо ответ типа ``ignore'' (игнорировать), и тогда имя будет обработано обычным порядком, невзирая на его возможную неправильность. Имена считаются правильными, если они отвечают рекомендациям RFC 952 (если это имена хостов) либо состоят только из печатаемых ASCII-символов (если они не являются именами хостов).
Директива ``max-fetch'' (в примере не показана), в настоящее время устаревшая, используется для обратной совместимости. Ее значение полностью аналогично директиве ``limit transfers-in''.
Мастер-файл состоит из управляющей информации и списка записей ресурсов для объектов зоны в следующих форматах:
$INCLUDE <имя_файла> <необяз_домен>
$ORIGIN <домен>
<домен> <необяз_время_жизни> <необяз_класс> <тип> <данные_с_записями_ресурсов>
где domain - это "." для корневого домена, "@" для текущей зоны (origin) или стандартное имя домена. Если domain является стандартным именем домена, не заканчивающемся ``.'', то к его концу добавляется имя текущей зоны. Имена доменов, заканчивающиеся ``.'', остаются неизменными. Поле необяз_домен используется для определения текущей зоны для данных, находящихся во включаемом файле. Она эквивалентна помещению директивы $ORIGIN перед первой строкой включаемого файла. Это поле необязательно. Ни поле opt_domain, ни директива $ORIGIN во включаемом файле не меняют текущую зону для этого файла. Поле необяз_время_жизни является необязательным целым числом, указывающем время жизни зоны. По умолчанию оно устанавливается в ноль, означающий минимальное значение, указанное в записи SOA зоны. Поле необяз_класс указывает на тип адреса объекта; в настоящее время поддерживается только один тип, IN, для объектов, подключенных к DARPA Internet. Поле type содержит одну из приводимых ниже лексем; формат данных, ожидаемых в поле resource_record_data, приведен там же, в скобках.
адрес хоста (четыре числа через точку)
ответственный сервер (доменное имя)
почтовая станция (доменное имя), перед которой указывается уровень приоритета (0..32767), при этом чем ниже числовое значение, тем выше уровень приоритета.
каноническое имя псевдонима (доменное имя)
отмечает начало зоны ответственности (доменное имя ответственного хоста, доменный адрес ответственного лица, серийный номер, а также времена обновления, возобновления запроса, устаревания и минимального TTL (времени жизни) (см. RFC 883), заданные в секундах).
запись пустого ресурса (формат или данные отсутствуют)
ответственное лицо для имени домена (почтовый адрес, текстовая ссылка)
указатель на доменное имя (доменное имя)
информация о хосте (тип_процессора тип_ОС)
Записи ресурсов обычно заканчиваются в конце строки, но Вы можете продолжить их за пределы одной строки, если заключите запись в круглые скобки. Комментарии наинаются символом точки с запятой (``;'') и продолжаются до конца строки.
Заметьте, что существуют и другие типы записей ресурсов, не показанные здесь. Для полного списка типов отсылаем Вас к BIND Operations Guide (``BOG''). Некоторые из типов записей ресурсов могли быть стандартизованы в одном из RFC, но еще не реализованы в этой версии BIND.
Каждый мастер-файл зоны должен начинаться с записи SOA (``start of authority'', начало ответственности) для зоны. Ниже приведен пример записи SOA:
@ IN SOA ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
1989020501 ; серийный номер
10800 ; обновление
3600 ; новая попытка
3600000 ; устаревание
86400 ) ; минимальное время жизни
Запись SOA указывает серийный номер, который должен быть изменен всякий раз при изменении мастер-файла. Заметьте, что серийный номер может состоять из чисел, разделенных точкой, но такой формат настоятельно не рекомендуется, поскольку перевод в обычные числа придется делать конкатенацией, а не простым сложением и умножением. В серийном номере можно указать год, месяц, число и номер версии в пределах 0..99 и все еще остаться в пределах 32-битного беззнакового целого. Да, эту стратегию придется пересмотреть в 4294 году по григорианскому календарю, но пока мы можем об этом не беспокоиться. Вторичные сервера проверяют серийный номер в интервалы, заданные полем ``обновление'' в секундах; если за это время серийный номер изменился, то они инициируют зонный обмен и загружают новые данные. Если мастер-сервер недоступен ко времени обновления, то новая попытка зонного обмена будет предпринята через время, заданное в поле ``новая попытка''. Если мастер-сервер не доступен после времени, указанном в поле ``устаревание'', то данные по зоне удаляются вторичными серверами. Поле ``минимальное время жизни'' (``TTL'') используется теми записями файла, для которых это поле не указано явно.
Вместо директив стартового файла ``domain'' и ``suffixes'' теперь используется более совершенная реализация определения суффиксов частично заданных доменов на уровне клиентской части сервиса имен (resolver-based). Существовавшие до этого механизмы могли не сработать в ряде ситуаций, особенно когда у локального сервера имен не было полной информации по доменному имени.
Вы можете управлять сервером имен следующими сигналами, посылая их с помощью команды kill(1).
Заставляет сервер перечитать файл named.boot и перегрузить базу данных. Если сервер был скомпилирован со включенной опцией FORCED_RELOAD, то по сигналу SIGHUP он также проверит серийные номера на всех вторичных зонах. Обычно серийные номера проверяются только по достижении временных интервалов, указанных в записях SOA.
Сбрасывает содержимое базы данных и кэша в файл /var/tmp/named_dump.db
Если сервер скомпилирован с опцией -DSTATS, то по этому сигналу он сбрасывает статистические данные в файл /var/tmp/named.stats, при этом вывод добавляется в конец файла. На некоторых системах для этой цели используется сигнал SIGABRT.
Если сервер скомпилирован с включенной поддержкой профилирования, то по этому сигналу он сбрасывает данные профилирования в файл /var/tmp (при этом сервер порождает дочерний процесс, меняет текущий директорий и завершается).
Выводит дампы первичной и вторичной базы данных. Обычно используется для сохранения измененных данных при останове системы, при этом сервер должен быть скомпилирован с включенной поддержкой динамического обновления данных.
Включает отладку; каждый последующий сигнал SIGUSR1 увеличивает уровень отладки на единицу (на старых системах без сигнала SIGUSR1 использовался сигнал SIGEMT).
Полностью выключает отладку (на старых системах без сигнала SIGUSR2 использовался сигнал SIGFPE).
Включает/выключает запись всех входящих запросов через syslog(8) (для этого сервер должен быть скомпилирован с опцией QRYLOG).
файл стартовой конфигурации сервера имен
номер процесса (pid) (на старых системах)
номер процесса (pid) (на новых системах)
дамп базы данных сервера имен
вывод отладочной информации
статистические данные по серверу имен
kill(1) , gethostbyname(3) , signal(2) , resolver(3) , resolver(5) , hostname(7) , RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033, RFC 1034, RFC 1035, RFC 1123, Name Server Operations Guide for BIND
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |