Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

522

Глава 13. Разрешение проблем TCP/IP

новного сервера путем передачи зоны. Возможно, происходила порча фай-

лов зоны. Мы вывели файл зоны на одном из подчиненных серверов и увиде-

ли такие данные:

% cat /usr/etc/events.wrotethebook.com.hosts

В данном примере мы предписали nslookup обращаться к серверу 24se-

ven.euents.wrotethebook.com, то есть основному серверу домена events.wrotet-

hebook.com. Затем мы запросили запись HINFO одного из тех узлов, для ко-

торых заподозрили порчу данных. Сообщение «packet size error» четко по-

казывает, что nslookup столкнулась с проблемами, пытаясь получить запись

Подробное описание оператора H1NFO приводится в приложении С.

Обратите внимание на странное значение в последнем поле оператора HINFO

каждой из машин.

Эти данные могли быть повреждены при передаче либо

изначально были некорректными на основном сервере. Мы воспользовались

nslookup,

чтобы проверить это обстоятельство:

Проверка службы имен 523

HINFO напрямую с основного сервера. Мы связались с администратором ос-

новного сервера и рассказали ему о проблеме, указав на конкретные записи,

попавшие под подозрение. Администратор обнаружил, что забыл добавить

запись операционной системы в некоторые из записей HINFO. Он исправил

ошибку, и проблема исчезла.

Повреждение кэша

Описанная выше проблема была вызвана порчей кэша сервера имен некор-

ректными данными. Повреждение данных кэша может происходить даже в

случаях, когда ваша система не является подчиненным сервером. Все серве-

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

же получать повреждения. Просмотр образа кэша может способствовать ди-

агностированию подобных проблем.

Например, пользователь сообщил о нерегулярных сбоях в работе сервера

имен. С именами локального домена и некоторыми именами за его предела-

ми проблем не возникало, однако имена ряда удаленных доменов не подда-

вались разрешению. Тестирование посредством nslookup не привело к ре-

зультатам, которые можно было бы уверенно интерпретировать, поэтому мы

перешли к просмотру образа кэша сервера имен. Записи корневых серверов

оказались поврежденными, и демон named был перезагружен в целях очист-

ки кэша и повторного чтения файла корневых указателей named.ca. Опера-

цию мы выполнили следующим образом.

Команда ndc dumpdb или сигнал SIGINT предписывает named создать образ кэ-

ша сервера имен в файле /var/tmp/named_dump.db. В следующем примере

используется сигнал:

# kill -INT 'cat /etc/named.picT

Идентификатор процесса named можно получить из файла /etc/named.pid,

что мы и сделали, поскольку named записывает идентификатор процесса в

этот файл при старте.

Записанный в файл образ можно изучить на предмет проверки корректности

имен и адресов серверов. Файл namedjdump.db состоит из трех разделов:

таблицы зон, кэша и данных, а также указателей.

Раздел таблицы зон

Первый раздел файла образа содержит таблицу зон, отражающую зоны, за-

груженные при запуске сервера. Таблица зон основного сервера для зон wro-

tethebook.com и 16.172.in-addr.arpa имеет следующий состав:

; Dumped at Tue Jul 17 16:08:18 2001

;; ++zone table++

В нашей системе Linux идентификатор процесса записывается в /var/run/na-

med.^pid.

524

Глава 13. Разрешение проблем TCP/IP

Данный раздел начинается с даты и времени создания образа. Метки в начале

и конце таблицы определяют ее границы. Как можно определить по двоето-

чиям, начинающим каждую строку, все эти строки являются комментария-

ми, предназначенными для передачи информации администратору систе-

мы. Ни один из комментариев не является действительной записью базы

данных DNS. Исходя из полученных данных можно сказать, что в файле na-

med.conf этого сервера фигурируют операторы zone для следующих доменов:

. ( точка)

Корневой домен, загруженный из исходного файла named.ca. Это файл

корневых указателей, описанный в главе 8.

0.0.127.in-addr.arpa

Кольцевой домен, загруженный из исходного файла named.local.

wrotethebook.com

Домен wrotethebook.com, загруженный из исходного файла wrotethebo-

ok.com.hosts.

16.172.in-addr.arpa

Обратный домен 16.172.in-addr.arpa, загруженный из исходного файла

172.16.rev.

Кроме того, для каждой зоны отображаются значения из записи SOA. В при-

веденном примере запись SOA есть у каждой зоны, за исключением корне-

вой (.).

Таблица зон включает все зоны, для которых сервер является компетент-

ным. Она позволяет определить, откуда сервер получил информацию о зоне

Проверка службы имен 525

и какие стандартные настройки установлены для зоны записью SOA. Если

зона отсутствует или загружена из неверного источника, исправьте оператор

zone в файле named.conf.

Раздел кэша и данных

Второй раздел файла образа - самый объемный. Именно этот раздел содер-

жит всю информацию DNS, известную серверу. Из-за длины раздела здесь

мы приводим только выдержку из него:

526

Глава 13. Разрешение проблем TCP/IP'

Проверка службы имен 527

Вот такая длинная выдержка, несмотря на то что образ был создан вскоре

после запуска сервера, а из раздела удалены многие строки. Основную часть

данных представляют сведения, загруженные из локальных файлов зон, од-

нако файл образа содержит также серьезный объем кэшированной информа-

ции. Крупные блоки кэша своим существованием обязаны информации, по-

лученной из разделов компетенции и дополнительных разделов ответов на

запросы. Таким путем в кэш попадает, по меньшей мере, столько же дан-

ных, сколько благодаря конкретным ответам на запросы. Это ясно видно из

большого числа NS-записей и сопутствующих им А-записей.

Раздел кэша и данных разбит на части инструкциями $ORIGIN. Все прочие

строки этого раздела однозначно сопоставимы с записями ресурсов DNS. Од-

нако в конце каждой записи добавляется дополнительная информация в ви-

де комментария. В частности, сервер добавляет три следующих коммента-

рия к каждой записи:

С1

Указывает число полей для текущей зоны. Для текущей зоны координат

0.0.127.in-addr.arpa значение С1 равно 5, а для текущей зоны wrotethebo-

ok.com С1 имеет значение 2. Корень (.) получает значение С1, равное 0.

Время отклика для запросов, адресованных указанному серверу имен.

Этот комментарий добавляется только к адресным записям. Время откли-

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

Сг

Тег «достоверности» определяет уровень авторитетности источника кэ-

шированной информации. Уровней авторитетности в BIND три:

auth

Компетентный ответ.

answer

Ответ из некомпетентного источника.

addtnl

Запись, полученная из раздела компетенции или дополнительного

раздела ответа на запрос.

Значение Сг используется named при получении записи, которая уже сущест-

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

528 Глава 13. Разрешение проблем TCP/IP

казатель достоверности, чем хранимая, новая запись заменяет каптирован-

ную. Если новая запись имеет более низкий показатель достоверности, со-

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

стоверность имеет

auth,

а самую низкую - addtnl.

Помимо комментариев в конце записи в разделе кэша и данных файла обра-

за могут встречаться и другие комментарии. Отрицательная кэшированная

информация также отображается в файле образа в виде комментариев.

В приведенном фрагменте нет соответствующих примеров, а в принципе

каждый такой комментарий выглядит как обычная RR-запись, предварен-

ная точкой с запятой. Иначе говоря, отрицательная кэшированная инфор-

мация представлена закомментированными записями ресурсов. Кроме того,

ближе к концу такой записи фигурирует тег NXDOMAIN.

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

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

ки информации, загруженной с удаленного сервера. Локальные данные мож-

но скорректировать самостоятельно. Некорректные данные на удаленном

сервере могут потребовать обращения к администратору удаленного домена.

Раздел указателей

Последний раздел файла образа - раздел указателей. Он содержит список

корневых серверов имен, загруженный из файла указателей. (О создании и

применении файла указателей рассказано в главе 8.) Файл указателей ис-

пользуется только при запуске сервера имен. Когда сервер запущен, он обра-

щается к одному из корневых серверов имен за компетентной информацией

о корневых серверах. Именно компетентный список, полученный от корнево-

го сервера, отображается в разделе кэша и данных после оператора S0RIGIN ..

Раздел указателей для нашей системы приведен ниже. Обратите внимание,

что всем серверам имен раздела указателей присвоены значения Nt. named

опрашивает все серверы с целью определения времени отклика для каждого

и выбора наилучшего сервера для работы.

Проверка службы имен

529

Смысл создания образа кэша DNS - в изучении данных, хранимых DNS, и

их представления. Исследования компетентных сведений, которые вы пере-

даете серверу посредством файлов зон, даст понимание того, как хранятся

эти данные. Изучение прочих данных кэша покажет, как пользователи при-

меняют DNS. Знание того, как обычно используется DNS, позволяет опреде-

лять момент, когда сценарии использования меняются.

Обнаружив проблемы в файле образа, перезагрузите кэш named при помощи

команды ndc reload (в BIND 9 используйте rndc reload) либо при помощи сиг-

нала SIGHUP, как показано ниже:

ft kill -HUP 'cat /etc/named.pid'

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

корневых серверов из файла named.ca.

Если известно, какая система ответственна за повреждения кэша, предпи-

шите своей системе игнорировать обновления от проблемной системы - при

помощи оператора server и параметра bogus со значением yes (в файле /etc/

named.conf). Оператор server перечисляет IP-адреса сервера имен. Установ-

ка параметра bogus в значение yes в операторе server сообщает

named,

что ин-

формации от указанного сервера доверять нельзя. Например, в предшеству-

ющем разделе описана ситуация, когда сервер 24seven.events.wrotetkebo-

ok.com (172.16.16.1) служил причиной повреждения кэша, предоставляя за-

писи HINFO в некорректном формате. Следующая запись файла named.conf

приведет к блокировке ответов от 24seven.events.wrotethebook.com и таким

образом предотвратит повреждение кэша:

server 172.16.16.1 {

bogus yes;

};

Установка параметра bogus в значение yes - мера временная, она позволяет

сохранить работоспособность системы до момента, когда администратор

удаленного домена займется диагностированием и исправлением проблемы.

Когда ошибки в удаленной системе исправлены, удалите оператор server из

файла named.conf.

530 Глава 13. Разрешение проблем TCP/IP

dig, альтернатива nslookup

Альтернативой nslookup в области запросов к службе имен является

dig.

За-

просы dig обычно представляют собой однострочные команды, тогда как

nslookup обычно используется в диалоговом режиме. При этом команды dig

выполняют ту же работу, что и

nslookup.

Выбор того или иного инструмента -

в большой степени просто дело вкуса. Оба работают достойно.

Для примера мы используем dig, чтобы запросить у корневого сервера b.root-

servers.net NS-записи домена mit.edu. Выполните следующую команду:

% dig ®Ь.root-servers.net mit.edu ns

В данном примере @b.root-servers.net - это сервер, к которому обращен за-

прос. Сервер может обозначаться именем или IP-адресом. При отладке проб-

лемы, связанной с удаленным доменом, указывайте компетентный сервер

имен этого домена. В данном примере мы запрашиваем имена серверов доме-

на второго уровня (mit.edu), поэтому обращаемся к корневому серверу.

Если сервер не указан явным образом, dig использует локальный сервер имен

или сервер имен, упомянутый в файле /etc/resolv.conf. (Файл resolv.conf опи-

сан в главе 8.) Кроме того, имя альтернативного файла resolv.conf может быть

указано в качестве значения переменной среды LOCALRES. Этот альтерна-

тивный файл будет использоваться вместо /etc/resolv.conf в запросах dig. Ус-

тановка значения LOCALRES влияет только на dig, прочие программы, ра-

ботающие со службами имен, продолжают использовать /etc/resolv.conf.

Последний элемент в примере команды - ns. Это тип запроса. Тип запроса -

это значение, определяющее тип информации DNS, о которой идет речь в за-

просе. Это аналог значения, устанавливаемого при помощи команды nslo-

okup set

type.

В табл. 13.1 перечислены возможные типы запросов dig и даны

их расшифровки.

Таблица 13.1. Типы запросов dig

Тип запроса Поиск записей DNS

Адресные

any Записи любых типов

mx Записи Mail Exchange (MX)

ns Записи серверов имен (Name Server)

soa Записи начала компетенции (Start of Authority)

hinfo

Записи Host Info

axfr

Все записи зоны

txt

Текстовые записи

Обратите внимание, что команда nslookup Is реализована типом запросов dig

axfr.

Проверка службы имен

531

Чтобы увидеть только строку ответа на данный запрос, передайте вывод dig ко-

манде grep; скажем, так: dig -х 18.72.0.3 j grep PTR.

В dig существует также ключ, полезный для определения имени узла по его

IP-адресу. Имея только IP-адрес узла, вы можете захотеть определить его

имя, поскольку численные адреса более подвержены опечаткам. Работа с

именем вместо адреса может облегчить жизнь пользователя. Домен in-

addr.arpa обеспечивает преобразование адресов в имена, a dig предоставляет

простой способ создания запросов по именам домена in-addr.arpa. Ключ -х

позволяет создавать запросы преобразования адрес-имя и избавляет от необ-

ходимости вручную выполнять обращение номеров и добавлять «in-addr.ar-

ра». К примеру, чтобы выполнить поиск имени узла по IP-адресу 18.72.0.3,

просто введите:

Ответ на наш запрос - BITSY.MIT.EDU, однако dig отображает много другой

информации. Для целей данного конкретного запроса достаточно только

строки ответа

, но дополнительная информация, отображаемая dig, полезна

для обретения понимания формата пакетов ответов DNS и того, откуда появ-

ляются различные элементы информации DNS.

Формат сообщения DNS определен в документе RFC 1035, Domain Names -

Implementation and Specification (Доменные имена, реализация и специфи-

кация). Данный документ гласит, что сообщение стандартного формата мо-

жет включать до пяти разделов: