6. Файлы

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

6.1. Файл Загрузки

Этот файл считывается первым при запуске named. Он сообщает серверу его тип, за какие зоны он отвечает и где взять свои начальные данные. По умолчанию этот файл находится в /etc/named.boot. Однако это может быть изменено установкой переменной BOOTFILE при компиляции named или указанием места его расположения в командной строке при запуске named.

6.1.1. Домен

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

	domain       Berkeley.Edu

Более старые сервера имен используют эту информацию когда они получают запрос на имя без ". ", которое не известно. Более новые понимают, что библиотека определителя добавит его собственное понимание "домена по умолчанию (default domain) " к любому неопределенному имени. На самом деле сервер имен может быть скомпилирован с поддержкой директивы domain в файле загрузки, по умолчанию пропуская ее, и мы очень рекомендуем не использовать ее. Если вы все же используете это, клиенты находящиеся вне вашего локального домена будут посылать к вам запросы об неопределенных именах и будет происходить столкновения определения вашего домена с их. Наиболее подходящее место для использования этой функции - это клиент, в его файле /etc/resolv.conf (или равнозначном). Использование директивы domain в вашем загрузочном файле сбивает всех с толку.

6.1.2. Каталог

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

     directory        /var/named

Если у вас больше чем пара файлов, с которыми должен работать named, вы можете поместить эти файлы в каталог типа /var/named и применить соответствующую команду directory. Главная цель этой команды - удостовериться, что named находится в соответствующем каталоге, когда пытается включить файлы с относительным путем в $INCLUDE, а также позволить named работать в том месте, где он может отбросить корку (dump core) если ему вдруг станет плохо.

6.1.3. Первичный Сервис

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

	primary        Berkeley.Edu   ucbhosts

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

Вышесказанное подразумевает, что зона, которую вы определяете есть зона класса IN. Если вы хотите определить другой класс, вы можете добавить /class к первому полю, где class - это целое число или стандартное символьное представление класса. Например, строка для первичного сервера зоны класса hesiod выглядит так:

	primary/HS         Berkeley.Edu    hesiod.data

Необходимо заметить, что поддержка классов зон, отличающихся от класса IN включается во время компиляции и может быть отключена вашим поставщиком при построении вашей операционной системы.

6.1.4. Вторичный Сервис

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

	secondary     Berkeley.Edu   128.32.0.10  128.32.0.4  ucbhosts.bak

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

Как и в случае первичного для класса, отличного от IN, вы должны определять вторичный сервер добавлением /class к ключевому слову secondary, например secondary/HS.

6.1.5. Поддельный Сервис

Строка для поддельного сервера аналогична вторичному. (Эта возможность появилась как экспериментальная в версии 4.9.3.)

	stub   Berkeley.Edu       128.32.0.10  128.32.0.4  ucbhosts.bak 

Первое поле говорит о том, что сервер является поддельным сервером для зоны описанной во втором поле.

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

  
  primary        CSIRO.AU       csiro.dat
  stub           dms.CSIRO.AU   130.155.16.1  dms.stub 
  stub           dap.CSIRO.AU   130.155.98.1  dap.stub

6.1.6. Инициализация кэша

Все сервера, включая "только кэширующие " сервера, для инициализации кэша сервера имен должны иметь в загрузочном файле строку типа:

  
  cache       .             root.cache

В ваших файлах кэша не пишите ничего кроме информации о корневом сервере.

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

Вместе с первичным и вторичным, вы можете указать вторичный сервер для класса отличного от IN добавлением к ключевому слову cache слова /class, например class/HS.

6.1.7. Пересыльщики

Любой сервер иожет использовать пересыльщиков. Пересылка - это еще одна возможность сервера при обработке рекурсивных запросов от имени других систем. Команда forwarders указывает пересыльщика по его адресу в internet:

  
  forwarders       128.32.0.10   128.32.0.4

Имеются две большие причины, чтобы так делать.

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

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

6.1.8. Подчиненные сервера

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

  
   options forward-only 

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

Так, в то время как forwardres использует адреса из "списка серверов" для каждого запроса, options forward-only заставляет "список серверов" содержать только те адреса, которые перечислены в объявлении forwarders. Небрежное использование директивы options forward-only может вызывать действительно ужасные циклы пересылки, так как вы могли бы закончить запросы пересылки к некоторому набору хостов, которые также являются подчиненными, а один или несколько из них могли бы пересылать запросы обратно к вам.

Использование директивы options forward-only должно быть очень осторожным. Обратите внимание, что то же самое поведение может быть достигнуто использованием директивы slave.

6.1.9. Нерекурсивные сервера

Разделение данных BIND на авторитативные (зоны) и неавторитативные (кэша) всегда было несколько слабо, и, как известно возможно загрязнение вышеупомянутых через последние. Один из способов предотвратить это, также как и сохранить память на серверах поддерживающих множество авторитативных данных (например корневых серверах) состоит в том, чтобы делать такие сервера " нерекурсивными". Это может быть достигнуто использованием в загрузочном файле директивы

  
   options      no-recursion

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

Нерекурсивный сервер может быть проименован в NS RR, но не может быть указан в файле resolv.conf.

6.1.10. Протоколирование Запросов

Если файловая система, содержащая ваш файл syslog имеет достаточно много места, то вы можете рассмотреть использование в вашем загрузочном файле директивы

	options        query-log

Это заставит ваш сервер имен протоколировать все получаемые запросы, а использование комбинации скриптов на Perl или AWK при последующей обработке файла протокола, может стать полезным средством управления.

6.1.11. Псевдоподдержка Обратных Запросов

BIND по умолчанию не поддерживает обратные запросы, и это, как известно, может вызывать проблемы для некоторых операционных систем микроЭВМ и для более старых версий инструмента nslookup. Вы можете решить, что намного лучше, если вместо ответа "operation not implemented", named должен обнаруживать наиболее общие обратные запросы и отвечать на них поддельной информацией; конечно же лучше произвести обновление ваших клиентов, чтобы прекратить зависимость от обратных запросов, но если это не возможно, вы должны использовать эту директиву в вашем загрузочном файле

	options    fake-iquery

ОБРАТИТЕ ВНИМАНИЕ: ответы фактически поддельны, они содержат квадратные скобки ISO8859 ([ и ]), так что ваши клиенты не будут способны сделать что-нибудь полезное с этими ответами. Наблюдалось, что ни один клиент никогда не делал что-нибудь полезное даже с реальными ответами на обратные запросы.

6.1.12. Установка Ограничений Сервера Имен

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

	limit   <name>   <value>

Ограничения и их значения по умолчанию выглядят так:

	limit  transfers-in  10

При этом число означает количество одновременных процессов named-xfer которые BIND может запустить. Если ваш вторичный сервер имеет сотни или тысячи поддерживаемых зон, то более высокие числа могут привести к более быстрой сходимости к первичным серверам,но установка слишком высокого значения может привести к очень высокой загрузке сервера и пожиранию ресурсов, таких как ширина пропускания сети или свопингового пространства. ОБРАТИТЕ ВНИМАНИЕ: это ограничение может быть выражено пдирективой max-fetch NN.

	limit   transfers-per-ns  2

Это число означает количество процессов named-xfer, которые может инициировать BIND к любому заданному серверу имен. В большинстве случаев вы не должны изменять это число. Если ваш вторичный сервер тащит сотни или тысячи зон с одного первичного сервера, увеличение transfers-per-ns можеть ускорить сходимость. Это число нужно держать как можно меньшим, во избежание большой загрузки и пожирания ресурсов на первичном сервере.

	limit  datasize  <system-dependent>

Большинство систем имеют квоты, ограничивающие размер так называемого "сегмента данных", где BIND держит все авторитативные данные и кэш. BIND будет поступать субоптимально (возможно даже при завершении работы) если он работает при этой квоте. Если ваша система поддерживает системный вызов, изменяющий эту квоту для определенного процесса, вы можете попросить BIND использовать этот системный вызов посредством директивы limit datasize NN. Значение заданное здесь может быть задано добавлением k для 1024X, m для (1024^2)X, и g для (1024^3)X. В 1995г., все корневые сервера использовали limit datasize 64m.

6.1.13. Ограничения в передаче зон

Это может быть случай, который ваша организация не желает выдавать полные списки ваших хостов кому угодно в Inernet, кто может достичь ваших серверов имен. Хотя пока это все еще возможно для людей "итерировать" через ваш диапазон адресов, ища записи PTR и формируя список ваших хостов "медленным " " способом, поэтому все еще выглядит резонным ограничить ваш экспорт зон через протокол передачи зон. Чтобы ограничить список соседей могущих брать зоны с вашего сервера, используйте директиву xfrnets.

Эта директива имеет такой же синтаксис, что и forwarders, за исключением того, сто вы можете перечислить сетевые адреса в добавление к адресам хостов. Например, если вы хотите разрешить доступ к передаче зон с вашего сервера только хостам сети класса A с номером 16, вы можете использовать директиву

	xfrnets   16.0.0.0

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

	xfrnets  16.1.0.2&255.255.255.255

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

Директива xfrnets для совместимости с промежуточными выпусками BIND 4.9. также может быть задана как tcplist.

6.1.14. Сортировка адресов

Если имеется множество адреса, доступных для сервера имен, с которыми захочет контактировать BIND, BIND сначала будет пробовать те, которые он считает "самыми близкими". "Близость" определяется в терминах похожести по адресу; то-есть если один из адресов находится в той же самой подсети что и некоторый интерфейс хоста, то первым будет опробован этот адрес. Если это не получится, то затембудет попробован адрес, находящийся в той же сети. Если и это провалится, и если в файле named.boot не была задана директива sortlist, то адреса будут опробованы в более или менее произвольном порядке. Директива sortlist имеет синтаксис, подобный forwarders, xfrnets, и bogusns - вы задаете ему список сетей в виде xxx.xxx.xxx.xxx, и он использует их при "предпочтении" одних серверов имен перед другими. Если никакая явная маска не обеспечивается каждым элементом sortlist , то будет сделан вывод основанный на битах адреса старшего разряда.

Если вы находитесь в сети класса C, имеющей сеть класса B вами и остальным Internet, вы могли бы попробовать увеличить удачу сервера имен в получении ответов, перечислив сеть класса B в директиве sortlist. Это должно иметь эффект при опробовании "ближайших" серверов перед более "удаленными". Обратите внимание, что это поведение является новым, и появилось начиная с, BIND 4.9.

Другой и более старый эффект директивы sortlist должен заставить, BIND сортировать записи типа A в любом генерируемом ответе, чтобы поместить те, которые имеются в sortlist перед остальными. Это не настолько полезно, как вы могли бы подумать, так как многие клиенты будут пересортировывать записи типа A в произвольном порядке или используя "магазинный порядок" (LIFO); также учтите то, что сервер будет способен догадаться о топологии сети клиента, и таким образом не будет способен точно упорядочить "близость" ко всем возможным клиентам. Выполнение упорядочения в разрешителе ясно выше.

В реальной практике, эта директива используется очень редко, так как это жестко привязывает быстро меняющуюся информацию; сеть, которая "близка" сегодня, может быть "отдалена" уже в следующем месяце. Так как BIND создает кэш времен ответа удаленных серверов имен, то он будет быстро сходиться на "приемлемом" поведении, которое не означает "оптимальное", но почти то же самое. Будущие направления развития BIND, включают выбор адресов, основываясь на метриках локальных интерфейсов (хостах, имеющих больше чем один интерфейс) и, возможно, на информации из таблицы маршрутизации. Мы не собираемся решать обобщенную проблему "multihomed" хостов, но мы должны быть способны сделать что-то получше чем то,что мы имеем сейчас. Аналогично, мы надеемся увидеть библиотеку разрешителя на более высоком уровне, сортирующую ответы на основе информации о топологии, существующей только на клиентском хосте.

6.1.15. Поддельные Сервера Имен

Иногда случается, что некоторый удаленный сервер имен становится "плохим". Вы можете указать вашему серверу имен отказаться слушать или задавать вопросы к конкретным серверам имен, перечислив их в директиве bogusns в вашем файле named.boot. Эта директива имеет тот же синтаксис что и forwarders, xfrnets, и sortlist -вам нужно только задать ему список адресов Internet в виде xxx.xxx.xxx.xxx. Обратите внимание, что зоны, делегируемые на такие сервера не будут доступны для клиентов ваших серверов; таким образом вы должны использовать эту директиву умеренно или вообще не использовать.

6.1.16. Сегментированные загрузочные файлы

Если ваш сервер является вторичным для множества зон, вы можете найти удобным расчленить ваш файл named.boot на статическую часть, которая врядли когда-либо изменится (в нее могли бы войти директивы типа directory, sortlist, xfrnets и cache), и динамические части, которые изменяются достаточно часто (все ваши директивы primary могли войти в один файл, а все директивы secondary - в другой файл - и любой из них, или оба эти файла могли быть вытащены автоматически от некоторого соседа так, чтобы они могли изменить ваш список вторичных зон без вашего активного вмешательства). Вы можете выполнять это посредством директивы include, которая берет в качестве параметра только одно имя файла. Не нужны никакие кавычки вокруг имени файла. Имя файла будет оценено после того, как сервер имен изменит рабочий каталог на тот, что определен директивой directory, поэтому вы можете использовать относительные имена, если ваша система их поддерживает.

6.2. Конфигурация Разрешителя

Файл конфигурации называется /etc/resolv.conf. Этот файл обозначает сервера имен в сети, к которым нужно послать запросы. Разрешитель будет пробовать установить контакт с сервером имен на localhost, если он не сможет найти файл конфигурации. В любом случае вы должны установить файл конфигурации на каждом хосте, так как это - единственный рекомендуемый способ определить домен по умолчанию на системном уровне, и вы можете записать в него адрес локального хоста, если на нем работает сервер имен. Будет вполне резонно создать этот файл в случае если у вас работает локальный сервер, так как его содержимое будет кэшироваться каждым клиентом разрешителя, когда клиент делает первый вызов программы разрешителя.

Файл resolv.conf содержит директивы, по одной в каждой строчке, в следующей форме:

	; комментарий
	# другой комментарий
	domain local-domain 
	search search-list 
	nameserver server-address 
	sortlist sort-list 
	options option-list

Хотя бы одна из директив domain или search должна быть дана, хотя бы один раз. Если дана директива search, то первый элемент в заданном списке поиска (search-list) перевесит любой ранее определенный local-domain. Директива nameserver может быть дана до трех раз; все дополнительные директивы nameserver будут игнорированы. Если строка будет начинаться с ";" или "#", то эта строка будет считаться комментарием; нужно отметить, что комментарии не были позволены в ранних версиях разрешителя (тех что были включены в BIND версий младше 4.9) - так что если версия разрешителя вашего продавца поддерживает комментарии, то он в самом деле очень расторопен.

Local-domain будет добавлен к любому запросу, не содержащему ".". local-domain может быть обойден на уровне процессов установкой переменной окружения LOCALDOMAIN. Нужно отметить, что обработка local-domain может быть отключена установкой опции в разрешителе.

Search-list - это список доменов, которые пробуются, по порядку, для имен, не содержащих ".". Обработка search-list может быть отключена установкой опции в разрешителе. Также отметьте, что переменная окружения "LOCALDOMAIN" может подавить search-list на уровне процессов.

Адреса серверов (server-address) собираются вместе и затем используются как назначение по умолчанию запросов, генерируемых через разрешитель. Другими словами, таким образом вы можете сказать разрешителю, какие сервера имен он должен использовать. Для определенных клиентских приложений существует возможность обойти этот список, и она обычно осуществляется внутри сервера имен (который в то же самое время и есть клиент разрешителя) и в тестовых программах типа nslookup. Нужно отметить, что если вы хотите перечислить локальный хост в файле конфигурации разрешителя, вы лучше всего должны использовать его первичный адрес в Internet, чем псевдоимя локального хоста типа 127.0.0.1 или 0.0.0.0. Это необходимо из-за ошибки в сетевом коде некоторых версий BSD при обработке соединенных сокетов SOCK_DGRAM. Если вы должны использовать псевдоадрес, то лучше всего вместо 127.0.0.1 использовать 0.0.0.0 (или просто "0"), впрочем, вы предупреждены, что в зависимости от типа вашего сетевого кода BSD, оба из них способны на ошибку, какждый по-своему. Если реализация IP на вашем хосте не создает короткозамкнутый маршрут между интерфейсом по умолчанию и петлевым (loopback) интерфейсом, то вы можете добавить статический маршрут (например в /etc/rc.local) это делается так:

	route add myhost.domain.name localhost 1

Sort-list - это список пар IP адресов и сетевых масок. Адреса возвращаемые процедурой gethostbyname сортируются в порядке определенном этим списком. Любые адреса, которые не соответствуют парам адресов и сетевых масок будут возвращены после всего. Сетевая маска опциональна, и если она не определена, будет использована натуральная сетевая маска.

Option-list - это список опций, каждая из которых подавляет какую-либо из внутренних переменных разрешителя. В настоящее время поддерживаются следующие опции:

 
	debug

выставляет бит RES_DEBUG в _res.options.

 
	ndots:n

выставляет более низкий порог (измеряемый в "количестве точек") в именах заданных res query(), так что имена с как минимум этим количеством точек будут опробованы как абсолютные имена, прежде чем будет произведена обработка local-domain или search-list. По умолчанию эта внутренняя переменная равна "1".

6.3. Инициализация Файла Кэша

6.3.1. root.cache

Сервер имен должен знать сервера, которые являются авторитарными серверами имен для корневого домена сети. Чтобы это сделать, мы должны заполнить кэш сервера имен адресами этих авторитарных серверов имен. Расположение этого файла определено в файле начальной загрузки. Этот файл использует Стандартный Формат Записи Ресурса (иначе называемого Masterfile Format) описываемого далее в этом документе.

6.4. Файлы Данных Домена

Имеется два стандартных файла для описания данных для домена. Это hosts и host.rev. Эти файлы используют Стандартный Формат Записи Ресурса, описываемый далее в этом документе. Нужно отметить, что имена файлов выбраны произвольно; многие сетевые администратопы предпочитают называть свои файлы зон по именам содержащихся в них доменов, особенно в усредненном случае, когда данный сервер является первичным и/или вторичным для множества различных зон.

6.4.1. hosts

Этот файл содержит все данные о машинах в этой зоне. Местонахождение этого файла определено в файле начальной загрузки.

6.4.2. hosts.rev

Этот файл определяет домен IN-ADDR.ARPA. Это специальный домен для того, что бы можно было преобразовывать адреса в имена. Так как адреса хостов в Internet не входят в границы домена, этот специальный домен был сформирован для того, чтобы можно было производить обратное преобразование. Домен IN-ADDR.ARPA имеет четыре метки, упреждающие его. Эти метки соответствуют четырем октетам адресов Internet. Все четыре октета должны быть описаны, даже если октет содержит только нули. Адрес Internet 128.32.0.4 находится в домене 4.0.32.128.IN-ADDR.ARPA. Эта перестановка адреса очень неудобна для чтения, но позволяет естественное группирование хостов в сети.

6.4.3. named.local

Этот файл определяет запись PTR для локального петлевого интерфейса (loopback interface), более известного как local-host, чей сетевой адрес 127.0.0.1. Местонахождение этого файла определяется в файле начальной загрузки. Для правильной работы каждого сервера имен жизненно важно, чтобы адрес 127.0.0.1 имел запись PTR указывающую обратно на имя "localhost.". Имя этой записи PTR всегда "1.0.0.127.IN-ADDR.ARPA". Это просто необходимо, если вы хотите, чтобы пользователи могли использовать опознавание имени хоста по имени "localhost" (в hosts.equiv или ~/.rhosts). Как связанная с этой записью PTR, в каждом домене, содержащем хосты должна существовать запись "localhost.my.dom.ain" A (с адресом 127.0.0.1). "localhost." потеряет последнюю точку, которая требутся для 1.0.0.127.in-addr.arpa; тогда опции разрешителя DEFNAMES и/или DNSRCH заставят оценить "localhost" как имя хоста в локальном домене.

Перевод A.S.Plotnikov, 1998

Назад | Содержание | Вперед