Пакет 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 запустится и прочитает
named.boot и заданные в нем зональные файлы. Он пишет
свой process ID в файл /var/run/named.pid в ASCII,
загружает все зональные файлы с первичного сервера и начинает слушать порт
53 в ожидании запросов DNS.
Файл конфигурации 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
;
; /etc/named.boot file for vlager.vbrew.com
;
directory /var/named
;
; domain file
;-----------------
cache . named.ca
primary vbrew.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 16.172.in-addr.arpa named.rev
|
Рассмотрим каждую инструкцию индивидуально. Ключевое слово
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
Опция определяет каталог, в котором расположены зональные файлы. Имена
файлов в других параметрах могут быть даны относительно этого каталога.
Несколько каталогов могут быть определены несколькими словами
directory. Стандарт файловой системы Linux
предполагает, что это /var/named.
- primary
Эта опция берет имя домена и имя файла как параметры, объявляя
локальный сервер авторитетным для заданного домена. Как первичный сервер
named загружает зональную информацую из данного
главного файла.
Всегда будет по крайней мере одна запись
primary в каждом файле boot, используемая для
обратного отображения сети 127.0.0.0, которая
является кольцевым интерфейсом (loopback).
- secondary
Инструкция берет имя домена, список адресов и имя файла как параметры.
Это объявляет локальный сервер вторичным главным (secondary master) сервером
для заданного домена.
Вторичный сервер хранит авторитетные данные относительно домена, но не
собирает их из файлов. Вместо этого он пробует загружать их с первичного
сервера. IP-адрес по крайней мере одного первичного сервера должен быть
передан named в списке адресов. Локальный сервер
входит в контакт с каждыми из них до успешного получения зональной базы
данных, которая затем будет сохранена в резервном файле заданном как третий
параметр. Если ни один из первичных серверов не отвечает, зональные данные
будут восстановлены из резервного файла.
Затем named пытается обновить зональные данные с
регулярными интервалами. Этот процесс объясняется позже в связи с типом
записи ресурса SOA.
- cache
Эта опция берет имя домена и имя файла как параметры. Этот файл
содержит root server hints, который является списком записей, указывающих на
корневые серверы имен. Будут распознаны только записи NS и A. Параметр
domain должен быть именем корневого
домена.
Эта информация критична для named. Если инструкции
cache нет в файле boot,
named не будет использовать локальный кэш вообще. Эта ситуация резко
ухудшит эффективность и увеличит сетевую загрузку, если следующий сервер
сделает запрос не о машине в локальной сети. Кроме того,
named не будет обращаться к корневым серверам, а значит, не сможет
преобразовать никакие адреса кроме тех, которые авторитетны для него.
Исключение из этого правила: сервера пересылки (см. ниже опцию
forwarders).
- forwarders
Инструкция берет список адресов, разделенных пробелами как параметр.
Адреса IP в этом списке определяют список серверов имен, которые
named может спросить, если не может найти адрес сам в
локальном кэше.
- slave
Инструкция делает сервер имен подчиненным (slave
). Он никогда не выполняет рекурсивные запросы самостоятельно, а только
пересылает их на серверы, определенные в инструкции
forwarders.
Есть два параметра, которые мы не будем описывать здесь:
sortlist и domain
. Еще две директивы могут также использоваться внутри этих файлов базы
данных: $INCLUDE и
$ORIGIN. Так как они редко нужны, мы не будем
рассматривать их сейчас.
BIND Version 8 имеет много новых свойств, а с ними пришел и новый
синтаксис файла конфигурации. Старый named.boot
с простыми одиночными инструкциями был заменен на
named.conf с синтаксисом, аналогичным gated,
похожий на C-синтаксис.
Новый синтаксис более сложен, но есть инструмент, который автоматизирует
преобразование старого синтаксиса в новый. В пакете исходников BIND 8 есть
perl-программа named-bootconf.pl
, которая занимается этим преобразованием. Чтобы использовать этот
инструмент, Вы должны иметь установленный интерпретатор
perl.
Вы должны использовать скрипт так:
# cd /etc
# named-bootconf.pl <named.boot >named.conf
|
Скрипт изготовит
named.conf, похожий на приведенный
в
примере 6-9.
Пример 6-9. Файл для BIND 8, эквивалентный файлу named.conf для vlager
//
// /etc/named.boot file for vlager.vbrew.com
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "vbrew.com" {
type master;
file "named.hosts";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "16.172.in-addr.arpa" {
type master;
file "named.rev";
};
|
Если Вы внимательно его рассмотрите, то обратите внимание на то, что
каждая из инструкций named.boot превратилась в
C-инструкцию, взятую в фигурные скобки "{ }".
Комментарии, которые в файле named.boot
начинались с точки с запятой (;), теперь обозначены как //.
Инструкция directory превратилась в
параграф options с предложением
directory.
Команды cache и
primary преобразованы в зональные параграфы
(zone) с типами (
type) предложений hint и
master, соответственно.
Зональные файлы не должны измениться: их синтаксис остается неизменным.
Новый синтаксис конфигурации учитывает много новых параметров, которые мы еще
не рассмотрели.
Главные (Master) файлы, поставляемые с named,
подобно named.hosts, всегда имеют домен, связанный с
ними, называемый origin. Это имя домена, указанное с
параметрами cache и
primary. Внутри главного файла Вы можете
определить домен и связанные с ним имена файлов. Имя, заданное в файле
конфигурации, рассматривается абсолютно (absolute),
если оно заканчивается одной точкой, иначе оно рассматривается относительно
origin. Можно и прямо сослаться на
origin знаком (@).
Данные, содержащиеся в главном файле, разделены на записи ресурсов
(resource records, RRs). RRs самые маленькие модули
информации, доступные через DNS. Каждая запись ресурса имеет тип. Например,
A-записи отображают имя хоста на IP-адрес, а CNAME-записи связывают
псевдоним для хоста с его официальным именем.
Пример 6-11 показывает
главный файл named.hosts для Virtual Brewery.
Записи ресурсов в главных файлах совместно используют общий формат:
[domain] [ttl] [class] type rdata
|
Поля отделяются пробелами или позициями табуляции. Запись может быть
продолжена после перевода строки, если открывающаяся фигурная скобка стоит
перед первым переводом строки и последнее поле сопровождается заключительной
фигурной скобкой. Все между точкой с запятой и символом перевода строки
игнорируется. Описание формата:
- domain
Задает имя домена, к которому относится запись. Если никакое имя не
задано, RR применяется к домену предыдущей RR.
- ttl
Чтобы сервер имен обновлял информацию, RR ограничен по времени работы
(ttl). Это поле определяет время в секундах, которое
информация имеет силу после того, как была получена с сервера. Это
десятичное число из восьми цифр.
Если значение ttl не дано, ему присваивается значение поля
minimum предыдущей SOA-записи.
- class
Класс адреса, например, IN для адресов IP или HS для объектов в
Hesiod-классе. Для TCP/IP Вы должны определить IN.
Если никакое поле класса не задано, берется класс предшествующей RR.
- type
Описывает тип RR. Наиболее часто встречаются типы A, SOA, PTR и NS.
Следующие разделы описывают различные типы RR.
- rdata
Хранит данные, связанные с RR. Формат этого поля зависит от типа RR.
Дальше это будет описано для каждого RR отдельно.
Дальше приведен частичный список RR, которые нужно использовать в файлах
DNS.
- SOA
Описывает зону авторитета (SOA или "Start of Authority"). Эта запись
сообщает о том, что записи после SOA RR содержат авторитетную информацию для
домена. Каждый главный файл, включенный в инструкцию
primary, должен содержать SOA-запись для этой
зоны. Данные ресурса содержат следующие поля:
- origin
Это каноническое имя хоста основного сервера для этого домена. Обычно
задается как абсолютное имя.
- contact
Это e-mail адрес человека, ответственного за поддержание домена, со
знаком "@" замененным на точки. Например,
если ответственный в Virtual Brewery janet,
это поле содержит janet.vbrew.com.
- serial
Номер версии зонального файла, выраженный как единственное десятичное
число. Всякий раз, когда данные меняются в зональном файле, это число должно
быть увеличено.
Серийный номер используется вторичными серверами, чтобы распознать, когда
зональная информация была изменена. Чтобы оставаться на уровне современных
требований, вторичные серверы запрашивают SOA-запись первичного сервера в
определенные промежутки времени и сравнивают порядковый номер с кэшируемой
SOA-записью. Если номер изменился, то вторичные серверы перенесут целую зону
баз данных из основного сервера.
- refresh
Определяет интервал в секундах, который вторичные серверы должны
использовать между проверками SOA-записей основного сервера. Это десятичное
число более, чем с восемью цифрами.
- retry
Это число определяет интервалы, за которые вторичный сервер должен
повторить соединение с основным сервером, если запрос или зональная
регенерация терпит неудачу. Он не должен быть слишком маленьким, потому что
даже временный отказ сервера или сетевая проблема могут потратить впустую все
сетевые ресурсы. Один час или, возможно, полчаса оптимальное значение.
- expire
Определяет время в секундах, после которого сервер должен отбросить
все зональные данные, если невозможно было войти в контакт с основным
сервером. Этот промежуток времени должен быть очень большим. Craig Hunt
рекомендует 42 дня.
- minimum
Задает по умолчанию значение ttl для исходных
записей, которые точно не определяют его. Требует другого сервера, чтобы
отбросить RR при проверки после определенного времени.
Ничего нельзя сделать со временем, после которого вторичный сервер
попробует модифицировать зональную информацию. Значение
minimum должно быть большим, особенно для
LAN, где сетевая топология почти никогда не меняется. В случае, когда
единственные RR могут часто изменяться, Вы можете приписывать им различные
ttl.
- A
Ассоциирует IP-адрес с именем. Содержит адрес в dotted quad notation.
Для каждого хоста должна быть только одна запись. Hostname, используемый в
этой А-записи, считается служебным или каноническим hostname. Все другие
hostname расцениваются как псевдонимы и должны быть отображены на
канонический (canonical) hostname, используя запись
CNAME. Если каноническое имя нашего хоста vlager, его
и надо вписать в A-запись с его IP-адресом. Если мы связываем с этим адресом
другое имя, например news, надо использовать
запись CNAME, которая свяжет его с альтернативным именем.
- NS
Указывает на главный (primary) сервер подчиненной зоны. Содержит
hostname сервера.
Вы встретите записи NS в двух ситуациях:
- Когда Вы делегируете авторитет зависимой зоне.
- Внутри главной зональной базы данных зависимой зоны.
Наборы серверов в родительских и делегированных зонах должны соответствовать
друг другу, иначе опознание имен работать не будет.
Запись NS определяет имена первичного и вторичного серверов для зоны. Эти
имена должны быть разрешимы к используемому адресу. Иногда серверы не
принадлежат к обслуживаемому домену, что порождает проблему: нельзя
обратиться к серверу, пока не получен его адрес, но получить адрес нельзя,
пока не обратимся к серверу (неоткуда). Можно конфигурировать специальные
записи непосредственно на сервере имен родительской зоны. Они позволяют
серверу из родительской области преобразовывать IP-адрес делегированного
зонального сервера. Эти записи обычно названы приклеенными записями
(glue records), поскольку они "склеивают"
делегированную зону с родительской.
- CNAME
Ассоциирует псевдоним хоста с его каноническим hostname.
Каноническиий hostname указан в файле, который обеспечивает А-запись, а
псевдонимы просто связаны с этим именем CNAME-записью, но не имеют
собственных записей.
- PTR
Этот тип записи используется, для того, чтобы соединить имена домена
in-addr.arpa с именами хостов (hostnames).
Это используется для обратного отображения IP-адресов к hostnames. Данное имя
должно быть каноническим.
- MX
-
Эта RR объявляет преобразователь почты (mail
exchanger) для домена. Для чего надо иметь преобразователи почты,
рассказано в главе 17
. Синтаксис MX-записи следующий:
[domain] [ttl] [class] MX preference host
|
Имя host объявляет преобразователь
почты для домена domain. Каждый
преобразователь почты имеет целое число preference
, связанное с ним. Агент транспортировки почты, желающий доставить
почту в домен, будет перебирать все хосты, не имеющие MX-записей в этом
домене, пока все не пройдет успешно. Сначала будет проверяться тот хост, у
которого самое низкое число, а затем все хосты по возрастанию числа.
- HINFO
Эта запись предоставляет информацию относительно аппаратных средств
системы и программного обеспечения. Синтаксис этой записи:
[domain] [ttl] [class] HINFO hardware software
|
Поле hardware идентифицирует
аппаратные средства, используемые этим хостом. Имеются специальные
соглашения, чтобы точно определить их. Список подходящих имен дан в "Assigned
Numbers" (RFС 1340). Если область содержит пробелы, то ее содержимое надо
заключить в двойные кавычки. Имена областей
software используются операционной системой. Подходящее имя может
быть выбрано из "Assigned Numbers" RFC.
Запись HINFO для Intel Linux-машин может
выглядеть примерно так:
tao 36500 IN HINFO IBM-PC LINUX2.2
|
А для Linux-машины на процессоре Motorola 68000 так:
cevad 36500 IN HINFO ATARI-104ST LINUX2.0
jedd 36500 IN HINFO AMIGA-3000 LINUX2.0
|
Это особая конфигурация named. Такой сервер в
действительности не обслуживает домен, а просто осуществляет переброску всех
запросов DNS, произведенных на Ваш компьютер. Преимущество этой схемы в том,
что она создает кэш. Так что только первый запрос для специфического
компьютера фактически будет послан серверу имен в Internet. Любой повторный
запрос будет обработан из кэша. Такая схема названа
caching-only. Это удобно при работе с Internet по
модему, как описано в главе 7 и
главе 8.
Файл named.boot для caching-only сервера имен
выглядит примерно так:
; named.boot file for caching-only server
directory /var/named
primary 0.0.127.in-addr.arpa named.local ; localhost network
cache . named.ca ; root servers
|
В дополнение к этому файлу named.boot, Вы должны
установить файл named.ca со списком корневых
серверов имен. Вы можете копировать и использовать для этой цели
пример 6-10. Другие
файлы не требуются.
Примеры 6-10,
6-11,
6-12 и
6-13 дают типовые файлы
для сервера имен сети brewery, размещенного на машине
vlager. Это довольно простая конфигурация для
одиночной локальной сети.
Файл кэша named.ca в
примере 6-10
показывает типовые записи корневого сервера имен. Типичный файл кэша обычно
описывает около десятка серверов. Вы можете получать текущий список серверов
для корневого домена с помощью команды nslookup. Она
описана чуть ниже.
Пример 6-10. Файл named.ca
; /var/named/named.ca Cache file for the brewery.
; We're not on the Internet, so we don't need
; any root servers. To activate these
; records, remove the semicolons.
;
;. 3600000 IN NS A.ROOT-SERVERS.NET.
;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;. 3600000 NS B.ROOT-SERVERS.NET.
;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;. 3600000 NS C.ROOT-SERVERS.NET.
;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;. 3600000 NS D.ROOT-SERVERS.NET.
;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;. 3600000 NS E.ROOT-SERVERS.NET.
;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;. 3600000 NS F.ROOT-SERVERS.NET.
;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;. 3600000 NS G.ROOT-SERVERS.NET.
;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;. 3600000 NS H.ROOT-SERVERS.NET.
;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;. 3600000 NS I.ROOT-SERVERS.NET.
;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;. 3600000 NS J.ROOT-SERVERS.NET.
;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;. 3600000 NS K.ROOT-SERVERS.NET.
;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;. 3600000 NS L.ROOT-SERVERS.NET.
;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;. 3600000 NS M.ROOT-SERVERS.NET.
;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
|
Пример 6-11. Файл named.hosts
; /var/named/named.hosts Local hosts at the brewery
; Origin is vbrew.com
;
@ IN SOA vlager.vbrew.com. janet.vbrew.com. (
2000012601 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
;
; local mail is distributed on vlager
IN MX 10 vlager
;
; loopback address
localhost. IN A 127.0.0.1
;
; Virtual Brewery Ethernet
vlager IN A 172.16.1.1
vlager-if1 IN CNAME vlager
; vlager is also news server
news IN CNAME vlager
vstout IN A 172.16.1.2
vale IN A 172.16.1.3
;
; Virtual Winery Ethernet
vlager-if2 IN A 172.16.2.1
vbardolino IN A 172.16.2.2
vchianti IN A 172.16.2.3
vbeaujolais IN A 172.16.2.4
;
; Virtual Spirits (subsidiary) Ethernet
vbourbon IN A 172.16.3.1
vbourbon-if1 IN CNAME vbourbon
|
Пример 6-12. Файл named.local
; /var/named/named.local Reverse mapping of 127.0.0
; Origin is 0.0.127.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
1 ; serial
360000 ; refresh: 100 hrs
3600 ; retry: one hour
3600000 ; expire: 42 days
360000 ; minimum: 100 hrs
)
IN NS vlager.vbrew.com.
1 IN PTR localhost.
|
Пример 6-13. Файл named.rev
; /var/named/named.rev Reverse mapping of our IP addresses
; Origin is 16.172.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
16 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
; brewery
1.1 IN PTR vlager.vbrew.com.
2.1 IN PTR vstout.vbrew.com.
3.1 IN PTR vale.vbrew.com.
; winery
1.2 IN PTR vlager-if2.vbrew.com.
2.2 IN PTR vbardolino.vbrew.com.
3.2 IN PTR vchianti.vbrew.com.
4.2 IN PTR vbeaujolais.vbrew.com.
|
Программа nslookup отличный инструмент для проверки
работы сервера имен. Она может использоваться в интерактивном режиме с
приглашением или как одиночная команда с непосредственным выводом. В
последнем случае Вы просто вызываете ее как:
Программа nslookup делает запрос сервера имен,
определенного в файле resolv.conf для
hostname. Если этих серверов много,
nslookup выбирает один случайным образом.
Интерактивный режим является намного более удобным. Помимо поиска машин
Вы можете сделать запрос для любого типа записи DNS и передачи всей зональной
информации для домена.
При вызове без параметров nslookup отображает имя
используемого сервера и входит в интерактивный режим. На приглашение
> Вы можете указать любое имя домена, о котором
хотите сделать запрос. По умолчанию посылается запрос для записей класса A,
содержащих IP-адрес, связанный с именем домена.
Вы можете искать типы записи:
Здесь type является одним из описанных
имен записи ресурса или ANY.
Пример сеанса работы с nslookup:
$ nslookup
Default Server: tao.linux.org.au
Address: 203.41.101.121
> metalab.unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
Name: metalab.unc.edu
Address: 152.2.254.81
>
|
Сначала отображаются данные о сервере DNS, затем результат запроса.
Если Вы пробуете сделать запрос для имени, которое не имеет никакого
адреса IP, связанного с ним, но другие записи для него были найдены в базе
данных DNS, nslookup выдаст сообщение об ошибке
No type A records found. Вы можете заставить
программу сделать запрос для записей, отличных от A, командой
set type. Для получения SOA-записей из
unc.edu введите:
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
*** No address (A) records available for unc.edu
> set type=SOA
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
unc.edu
origin = ns.unc.edu
mail addr = host-reg.ns.unc.edu
serial = 1998111011
refresh = 14400 (4H)
retry = 3600 (1H)
expire = 1209600 (2W)
minimum ttl = 86400 (1D)
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
unc.edu name server = ns.unc.edu
ns2.unc.edu internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1
ns.unc.edu internet address = 152.2.21.1
|
Аналогично Вы можете сделать запрос для записей MX:
> set type=MX
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
unc.edu preference = 0, mail exchanger = conga.oit.unc.edu
unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu
unc.edu name server = ns.unc.edu
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
conga.oit.unc.edu internet address = 152.2.22.21
imsety.oit.unc.edu internet address = 152.2.21.99
ns.unc.edu internet address = 152.2.21.1
ns2.unc.edu internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1
|
Используйте тип ANY, чтобы получить все записи ресурса, связанные с данным
именем.
Практически программа nslookup помимо отладки
позволяет получать текущий список корневых серверов имен. Вы можете получать
этот список запросом всех записей NS, связанных с корневым доменом:
> set type=NS
> .
Server: tao.linux.org.au
Address: 203.41.101.121
Non-authoritative answer:
(root) name server = A.ROOT-SERVERS.NET
(root) name server = H.ROOT-SERVERS.NET
(root) name server = B.ROOT-SERVERS.NET
(root) name server = C.ROOT-SERVERS.NET
(root) name server = D.ROOT-SERVERS.NET
(root) name server = E.ROOT-SERVERS.NET
(root) name server = I.ROOT-SERVERS.NET
(root) name server = F.ROOT-SERVERS.NET
(root) name server = G.ROOT-SERVERS.NET
(root) name server = J.ROOT-SERVERS.NET
(root) name server = K.ROOT-SERVERS.NET
(root) name server = L.ROOT-SERVERS.NET
(root) name server = M.ROOT-SERVERS.NET
Authoritative answers can be found from:
A.ROOT-SERVERS.NET internet address = 198.41.0.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
I.ROOT-SERVERS.NET internet address = 192.36.148.17
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
J.ROOT-SERVERS.NET internet address = 198.41.0.10
K.ROOT-SERVERS.NET internet address = 193.0.14.129
L.ROOT-SERVERS.NET internet address = 198.32.64.12
M.ROOT-SERVERS.NET internet address = 202.12.27.33
|
Для просмотра списка всех команд введите help в
nslookup.
Есть несколько инструментальных средств, которые могут помочь Вам в
решении задач. Здесь кратко описаны два таких средства.
Программа hostcvt помогает Вам построить
конфигурацию с нуля, преобразуя файл /etc/hosts в
главные файлы для named. Она генерирует прямой (A) и
обратный (PTR) коды отображения и заботится о псевдонимах. Конечно, она не
сделает всю работу за Вас, поскольку Вам все еще нужно настраивать значения
времени ожидания в записи SOA или добавить MX-записи. Утилита
hostcvt входит в пакет BIND, но доступна и отдельно
с нескольких Linux FTP-серверов.
После установки сервера имен Вы должны проверить его конфигурацию.
Некоторые хорошие инструментальные средства делают эту работу проще.
Во-первых, это dnswalk, основанный на Perl. Во-вторых,
nslint. Они оба обходят базу данных DNS, ищут общие
ошибки и проверяют, что информация является непротиворечивой. Два других
полезных инструментальных средства, host и
dig, являются универсальными средствами для запроса
базы данных DNS. Вы можете использовать эти инструментальные средства, чтобы
вручную осматривать и диагностировать записи базы данных DNS.
Скорей всего, все эти средства доступны в откомпилированном виде. Утилиты
dnswalk и nslint доступны в
исходниках с
http://www.visi.com/~barr/dnswalk и
ftp://ftp.ee.lbl.gov/nslint.tar.Z. Утилиты
host и dig доступны в
исходниках с ftp://ftp.nikhef.nl/pub/network
и ftp://ftp.is.co.za/networking/ip/dns/dig.
