Всякая всячина
Категория: Система доменных имен | Автор: admin | 30-04-2010, 04:22 | Просмотров: 2627

В этом параграфе собран материал, который должен был появиться раньше, но мы не смогли найти для него нужное место.

 

Файл «подсказок»

 

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

Корневые серверы имен время от времени подвергаются изменениям, но за ними легко следить, так как всем этим серверам присвоены имена в домене root-servers.net. Если в системе уже работает сервер имен, можно посредством программы dig связаться с корневым сервером и сгенерировать файл "подсказок". Главным в настоящее время является сервер a.root-servers.net, но в данном случае подойдет любой из них:

% dig @f.root-servers.net.ns > root.cache

 

Если сервер f.root-servers.net не отвечает, можно вообще не указывать конкретный корневой сервер:

% dig . ns > root.cache

 

B результате будет получен список корневых серверов из кэша локального сервера имен, а не из авторитетного источника. Но ничего страшного в этом нет. Даже если сервер имен не перезагружался или не перезапускался год или два, он периодически сам обновлял записи корневых серверов по мере их устаревания. Когда демон named запускается, он повторно запрашивает "подсказки" от одного из корневых серверов. Таким образом, даже в относительно старом файле содержится по крайней мере одна запись о доступном сервере имен.

Приведем пример файла "подсказок" (использовать его в таком виде не следует):

 

cs.colorado.edu.    IN   NS     anchor.cs.colorado.edu.

cs.colorado.edu     IN   NS     ns.cs.utah.edu.

; «» DiG 8.2 <<>> @f. root-servers.net  . ns

; Lots of detailed dig info formatted as comments here...

.                     1d1h42m   IN   NS   E.ROOT-SERVERS.NET.

.                     1d1h42m   IN   NS   D.ROOT-SERVERS.NET.

.                     1d1h42m   IN   NS   A.ROOT-SERVERS.NET.

.                     1d1h42m   IN   NS   H.ROOT-SERVERS.NET.

E.ROOT-SERVERS.NET.   2dlh42m   IN   A   192.203.230.10

D.ROOT-SERVERS.NET.   2dlh42m   IN   A   128.8.10.90

A.ROOT-SERVERS.NET.   2dlh42m   IN   A   198.4-.0.4

H.ROOT-SERVERS.NET.   2dlh42m   IN   A   128.63.2.53

 

 

Обратите внимание на точки, с которых начинаются записи первого набора. Это не пятна, оставленные типографским станком. На самом деле они определяют домен (корень), к которому относятся записи NS. Некоторые версии программы dig отображают время жизни в секундах, а не в формате дней, часов, минут и секунд.

Текущий файл подсказок, называемый domain/named.root, можно получить через анонимный доступ с FTP-узла rs.intemic.net[1]. В нем имеются комментарии, в которых указываются старые имена корневых серверов. Альтернативный адрес — ftp://ftp.nic.mil/domain/named.root.

 

Конфигурирование домена localhost

 

Прямая привязка к имени localhost или localhost.домен устанавливается в файле зоны прямого преобразования для данного домена. Но каждый сервер обычно является главным для своей собственной зоны обратного преобразо­вания узла localhost. Вот пример зонного файла:

 

@       IN    SOA   cs.colorado.edu. hostmaster.cs.colorado.edu.   (

              1996110801    ; Порядковый номер

              3600          ; Период обновления

              900           ; Интервал между попытками

              3600000       ; Период устаревания

              10800 )       ; Минимальное время жизни

       IN     NS     cs.colorado.edu.

1      IN     PTR   localhost.cs.colorado.edu.

 

 

Обратная привязка к адресу localhost (127.0.01) никогда не меняется, поэтому периоды обновления и устаревания можно делать достаточно большими. Обратите внимание на порядковый номер, в котором закодирована дата: последний раз файл модифицировался в 1996 г. Заметьте также, что для домена "localhost" указан только главный сервер имен. Метасимвол @ здесь раскрывается как "0.0.127.in-addr.arpa.".

Свяжите адрес 127.0.01 с именем "localhost.домен.", а не просто "localhost.". Правда, корневые серверы принимают столько запросов к домену "localhost.", что, возможно, в конце концов появится глобальная запись 0.0.127.in-addr.arpa.

 

Средства управления узлами

 

Файлы базы данных DNS часто бывают распределены по целым регионам, административным или даже политическим. Во многих случаях жесткий централизованный контроль невозможен. Такая ситуация порождает общую проблему администрирования: как управлять важными (и уязвимыми) файлами данных, которые будут постоянно редактироваться множеством неопытных пользователей? Как сделать так, чтобы, например, факультет прикладной математики не мог изменять записи факультета вычислительной техники и наоборот?

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

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

 

Доступ к DNS для систем, не подключенных к Internet

 

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

 

 

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



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page