Новые книги

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

Книга будет интересна CEO и владельцам бизнеса, менеджерам, аналитикам.
Управление сервисами ИТ (IT Service Management, ITSM) развивается в России на протяжении последних пяти-шести лет, однако этот рынок еще недостаточно велик. Работающие в данной области компании не спешат объединить усилия и создать отечественные , хотя уже обладают квалификацией в сфере организации эффективной работы департаментов информационных технологий в различных отраслях. Между тем за рубежом накоплен солидный опыт в организации ИТ. В 80-х гг. британское Центральное агентство по вычислительной технике и телекоммуникациям (ныне OGC) разработало принципы эффективного использования ресурсов ИТ в государственных учреждениях страны. В результате была создана (IT Infrastructure Library, ITIL), где собраны лучшие методы в сфере услуг ИТ. В настоящее время библиотека представляет собой подробное описание наиболее важных видов деятельности в работе ИТ, перечень сфер ответственности, задач и процедур, которые, как утверждается, можно адаптировать для любого предприятия, большого или малого, использующего услуги аутсорсинга ИТ или реализующего собственные службы. На базе библиотеки ITIL свои структурированные подходы к управлению услугами ИТ разработали такие компании, как HP, IBM и Microsoft.

Книга представляет введение в ИТ Сервис-менеджмент - передовой подход по управлению информационными технологиями (ИТ). Он основан на материалах лучшего мирового опыта, собранного и систематизированного в Библиотеке ITIL (IT Infrastructure Library).

Running named

Запуск 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 скомандуйте:

# /usr/sbin/named

Пакет 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

;
; /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. Так как они редко нужны, мы не будем рассматривать их сейчас.

Файл host.conf в BIND 8

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, соответственно.

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

Файлы базы данных 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.

Записи ресурсов в главных файлах совместно используют общий формат:

[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. Другие файлы не требуются.

Написание главных (Master) файлов

Примеры 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 hostname

Программа nslookup делает запрос сервера имен, определенного в файле resolv.conf для hostname. Если этих серверов много, nslookup выбирает один случайным образом.

Интерактивный режим является намного более удобным. Помимо поиска машин Вы можете сделать запрос для любого типа записи DNS и передачи всей зональной информации для домена.

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

Вы можете искать типы записи:

> set type=type

Здесь 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.