WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |

«DNS and BIND Fourth Edition PaulAlbitz and Cricket Liu O'REILLY DNS и BIND Четвертое издание ПолАльбитц и Крикет Ли Пол Альбитц, Крикет Ли DNS и BIND Перевод М Зислиса Главный редактор А Галунов ...»

-- [ Страница 7 ] --

По сути дела - это запись KEY без полей класса и типа. Еще одно отли чие - ключ заключен в кавычки. Доменное имя зоны может быть за ключено в кавычки, но не обязательно. Если бы зона movie.edu имела несколько открытых ключей - скажем, еще и ключ DSA, мы могли бы включить все ключи в оператор:

Нам вспоминается байка про человека, который как-то спросил жреца, что держит Землю. Жрец ответил, что Земля покоится на панцире огромной черепахи. Тогда человек спросил, что держит черепаху. И жрец ответил:

«Черепаха покоится на спине огромного слона». Но что же, спросил чело век, держит слона? Разозленный жрец выпалил «А дальше слоны - до са мого конца!» 426 Глава 11 Безопасность Приведенный оператор trusted-keys позволяет DNS-серверу BIND 9 про изводить проверку подлинности любых записей зоны movie.edu. DNS сервер сможет также осуществлять проверку записей из порожденных зон вроде fx.moмie.edu, в случае если их KEY-записи подписаны закры тым ключом зоны movie.edu, и для внуков movie.edu, в случае наличия корректной цепи доверия, которую можно проследить зо открытого ключа зоны movie.edu. Другими словами, movie.edu становится защи щенным сегментом, в пределах которого DNS-серверы этой зоны мо гут производить проверку подлинности данных из защищенных зон.

Пустые ключи Защищенный сегмент позволяет DNS-серверу зоны производить про верку подлинности подписанных записей, начиная с определенной точки пространства имен Пустые ключи решают совершенно противо положную задачу: они сообщают DNS-серверу, что записи, начиная с определенной точки, не защищены. Допустим, администраторы fx.mo vie.edu еще не занимались вопросами безопасности своей зоны. Когда мы подписываем зону movie.edu, программный модуль BIND 9, от ветственный за подписи, добавляет специальный пустой ключ к зоне movie.edu - для fx.movie.edu:

Обратите внимание, что открытый ключ в этой записи не закодирован в Base 64. Если присмотреться внимательно (или воспользоваться ин женерным калькулятором), можно понять, что поле флагов говорит о том, что ключ нелья применять ни для проверки подлинности, ни для сохранения конфиденциальности;

то есть ключ - пустой. DNS-серве ры, реализующие поддержку DNSSEC, интерпретируют этот факт сле дующим образом: зона fx.movie.edu не является защищенной и не сле дует ожидать, что она содержит подписанные данные.

Если программный модуль BIND 9, ответственный за подписи, обна ружит при запуске файл, содержащий KEY-запись fx.movie.edu, пус той ключ будет удален, поскольку предполагается, что зона fx.mo vie.edu защищена.

Как используются записи Рассмотрим, какие действия совершает DNS-сервер, реализующий ме ханизм DNSSEC, для проверки записи в movie.edu. В частности, инте ресно посмотреть, что происходит при поиске адреса для wormhole.mo vie.edu. Во-первых, DNS-сервер посылает запрос этого адреса:

Расширения системы безопасности DNS Обратите внимание, что следует указать ключ командной строки +dns sec. DNS-серверы BIND версии 9.1.0 и более поздних включают записи DNSSEC (SIG, NXT и KEY) в ответ только в том случае, когда клиент явным образом сообщает, что способен работать с DNSSEC. Как это де лают авторы запросов? Установкой специального флага в «псевдораз 428 Глава 11. Безопасность деле» заголовка. Псевдораздел в действительности не является частью заголовка. В действительности это запись нового типа, ОРТ, которая включается в сообщение DNS. ОРТ-записи обычно сообщают о способ ностях автора запроса.

Заметим также, что ответное сообщение включает четыре SIG-записи:

одну для записей из раздела ответа, одну для записей из раздела авто ритативности, одну для адресной записи terminator.movie.edu из до полнительного раздела, и еще одну для KEY-записи movie.edu из до полнительного раздела. Дополнительный раздел мог бы содержать SIG-запись для outland.fx.movie.edu, адресные записи для wormho le.movie.edu, и SIG-запись для этих адресных записей - в случае, если бы хватило места, и сообщение уместилось в одну UDP-дейтаграмму.

Чтобы произвести проверку SIG-записей, DNS-сервер должен изучить KEY-запись movie.edu, которая включена в дополнительный раздел.

Но прежде чем использовать ключ, DNS-сервер должен проверить SIG запись для этого ключа. Таким образом требуется по меньшей мере один дополнительный запрос: к одному из DNS-серверов зоны edu, на предмет получения открытого ключа - разумеется, только в том случае, когда открытый ключ для movie.edu не указан в операторе trusted-keys.

DNSSEC и производительность Из приведенного вывода dig должно быть ясно, что DNSSEC увеличи вает средний размер сообщений DNS, требует значительно большей вычислительной мощности от DNS-серверов, производящих проверку зональных данных, и что подпись зоны значительно увеличивает ее размер (существующая оценка примерно такова - подпись увеличива ет размер зоны в семь раз). Каждый из этих фактов имеет последствия, причем далеко не всегда очевидные:

• Более крупные сообщения DNS означают учащение случаев усече ния сообщений, то есть больше переходов к использованию TCP.

Использование TCP, разумеется, гораздо более требовательно к ре сурсам, чем использование UDP.

• Проверка данных зоны требует времени и замедляет процесс разре шения.

• Более крупные зоны означают более тяжелые и хуже поддающиеся управлению процессы named.

По сути дела, сложность DNSSEC привела к тому, что архитектура BIND 8 не смогла справиться с этим механизмом. Так что появление механизма DNSSEC послужило толчком для разработки BIND 9, уме ющего использовать преимущества многопроцессорных систем. Если планируется применять подписи для зон, следует убедиться, что авто ритативные DNS-серверы обеспечены достаточными объемами памяти для загрузки крупных зон. Если DNS-серверы в основном занимаются разрешением в защищенных зонах, убедитесь также, что им доступны Расширения системы безопасности DNS соответствующие процессорные мощности, которые позволят осу ществлять проверку цифровых подписей. И помните, BIND 9 способен использовать любой дополнительный процессор узла, на котором ра ботает.

Подпись для зоны Итак, читатели получили теоретическую подготовку, необходимую для создания подписи зоны. Мы рассмотрим процесс на примере зоны то vie.edu. Помните, что мы использовали инструменты BIND 9, которые намного легче в применении, чем инструменты BIND 8, и, конечно, поддержка DNSSEC в BIND 9 намного более совершенна, чем в BIND 8.

Создание пары ключей Итак, во-первых мы создали пару ключей для зоны movle.edu:

Мы выполнили программу dnssec-keygen в рабочем каталоге DNS-cep вера. Это было сделано для нашего же удобства: файлы данных зон расположены в этом же каталоге, и нет необходимости в аргументах использовать полные имена. При этом, если мы собираемся использо вать динамические обновления с DNSSEC, то ключи должны нахо диться в рабочем каталоге DNS-сервера.

Вспомним опции программы dnssec-keygen из раздела TSIG этой главы (как давно это было):

-а Используемый алгоритм шифрования, в данном случае RSA. Мы могли бы также использовать алгоритм DSA, но RSA более эффек тивен.

-b Длина создаваемых ключей, в битах. Ключи RSA могут иметь дли ну от 512 до 2000 битов. Ключи DSA - от 512 до 1024 битов, причем длина должна нацело делиться на 64.

-п Тип ключа. Ключи DNSSEC всегда являются ключами зоны.

Единственный самостоятельный аргумент в данном случае - доменное имя зоны, movie.edu. Программа dnssec-keygen отображает основу имен файлов, в которых записаны ключи. Как мы уже рассказывали в разделе TSIG, числа в в этих строках (001 и 27791) соответствуют но меру алгоритма DNSSEC, использованного для создания KEY-записи (001 соответствует RSA/MD5), а также карте ключа, которая исполь зуется для различения ключей, связанных с одной и той же зоной.

Открытый ключ записывается в файл основа.кеу (Kmovie.edu.+ +27791.key). Закрытый ключ записывается в файл ocнoвa.private (Kmovie.edu.+001+27791.private). Помните, что закрытый ключ следу 430 Глава 11. Безопасность ет хранить в тайне, поскольку любой, кому известен этот ключ, спосо бен официально подделать данные зоны, dnssec-keygen пытается нам помочь, делая файлы.private доступными для чтения и записи только пользователю, который выполняет программу.

Отправка ключей на подпись Теперь следует отправить нашу KEY-запись администратору роди тельской зоны - на подпись. В BIND 9 существует приятная малень кая программа, которая упаковывает ключи для передачи, dnssec-ma kekeyset:

В результате работы dnssec-makekeyset был создан файл keyset-mo vie.edu1, который содержит следующие строки:

Ключ -t позволяет задать параметр TTL для передаваемых записей.

Это предпочтительное значение TTL для наших записей (в секундах), о котором мы и сообщаем администратору родительской зоны. Адми нистратор родительской зоны может, само собой, проигнорировать это значение. SIG-запись содержит подпись, удостоверяющую KEY-за пись нашей зоны, которая была создана с помощью закрытого ключа зоны. Так мы доказываем, что действительно обладаем закрытым ключом, который соответствует открытому ключу из KEY-записи, а не посылаем какую-то KEY-запись, которую только что нашли на улице.

Поля временных отметок создания и устаревания подписи по умолча нию принимают значения «только что» и «через 30 дней». Это пред почтительные значения времени жизни, учитываемые создателем подписи. Можно использовать ключи -s (start, начало) и -е (end, ко нец) для задания собственных временных отметок создания и устаре вания подписи. Оба ключа принимают аргументы в формате YYYY MMDDHHMMSS, либо смещения. Смещение для -s вычисляется отно В версиях dnssec-makekeyset, поставляемых в комплекте BIND 9.0.1 и бо лее ранних версий, имя файла выглядит так: movie.edu.keyset. Однако та кое построение имени вызывало проблемы - имя файла набора ключей корневой зоны было.keyset, такой файл в файловой системе Unix является скрытым.

Расширения системы безопасности DNS сительно текущего времени. Смещение для -е вычисляется относи тельно времени создания подписи (start).

Эти два поля можно также использовать для создания нескольких на боров ключей (keysets) и одновременной передачи их на подпись адми нистратору родительской зоны. К примеру, можно единовременно пе редать администратору родительской зоны наборы ключей, действую щие в январе, феврале и марте, а затем вводить их в действие по одно му каждый месяц.

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

Поскольку сообщение включало подтверждение наших прав1, адми нистратор подписал файл с помощью программы dnssec-signkey:

и вернул нам результат, файл movie.edu.signed.key:

Если бы наличие подписей для KEY-записей не сильно нас беспоко ило, мы могли бы пропустить этот шаг. В таком случае только DNS серверы с записью trusted-keys, включающей movie.edu, смогли бы производить проверку наших данных.

Подписываем зону Прежде чем подписать зону, мы должны добавить KEY-запись к фай лу данных зоны:

Так программа, создающая подпись, будет в курсе, какой ключ следу ет использовать. Она автоматически обнаружит файл movie.edu.signed key и воспользуется его содержимым.

Подпишем зону с помощью dnssec-signzone:

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

432 Глава 11. Безопасность Мы использовали ключ -о для задания суффикса по умолчанию для файла данных зоны, поскольку dnssec-signzone не изучает файл па med.conf и не в состоянии определить, какую зону описывает файл.

Единственный самостоятельный аргумент в данном случае - имя фай ла данных зоны.

В результате мы получаем новый файл данных зоны, db.movie.edu.sig ned, который начинается следующим образом:

Расширения системы безопасности DNS Верьте или нет, все это просто записи, связанные с доменным именем movie.edu. Файл данных зоны в целом в четыре раза длиннее и в пять раз больше. Ух!

И наконец, мы отредактировали оператор zone в файле named.conf, ко торый теперь загружает новый файл данных зоны:

Затем мы перезагрузили зону и проверили вывод syslog.

Вот ключи dnssec-signzone, которые мы еще не применяли:

-s, -е Эти ключи позволяют задать временные отметки создания и уста ревания подписей, которые следует использовать в SIG-записях;

синтаксис аргументов в точности соответствует синтаксису для dnssec-makekeyset.

-i Позволяет задать длину цикла повторной подписи (эту тему мы рассмотрим через минуту). До BIND 9.1.0 вместо этого ключа ис пользовался ключ -с.

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

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

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

Можно заново подписать зону, выполнив dnssec-signzone для подпи санных зональных данных:

Программа достаточно сообразительна, она производит повторное вы числение NXT-записей, подписывает новые записи, а также заново подписывает записи, у которых скоро истекает срок действия подпи си. По умолчанию dnssec-signzone повторно подписывает записи, срок 434 Глава 11. Безопасность действия подписей для которых истекает в пределах 7,5 дней (чет верть стандартного времени действия подписи). Если задать нестан дартные значения для времени создания подписи и ее устаревания, dnssec-signzone соответствующим образом изменит связанные с вре менным циклом значения. Как вариант можно указать длину цикла с помощью ключа -i (ранее - -с).

DNSSEC и динамические обновления Использование dnssec-signzone - не единственный способ подписывать зональные данные. DNS-сервер BIND 9 умеет подписывать динамичес ки обновляемые записи на лету.1 Королева в восхищении!

Если закрытый ключ для защищенной зоны доступен в рабочем ката логе DNS-сервера (и содержится в.private-файле с правильным име нем), DNS-сервер BIND 9 подписывает любые записи, добавляемые по средством динамического обновления. При удалении и добавлении любых записей DNS-сервер исправляет (и подписывает заново) все со седние NXT-записи.

Продемонстрируем на примере. Для начала произведем поиск для до менного имени, которое еще не существует в зоне movie.edu:

(Мы немного сократили вывод.) Обратите внимание на NXT-запись для misery.movie.edu, которая сообщает, что доменное имя не сущест Еще одна возможность DNSSEC, которой нет в BIND 8.

Расширения системы безопасности DNS вует. Используем nsupdate и добавим адресную запись для perfect storm.movie.edu:

Теперь снова произведем поиск для perfectstorm.movie.edu:

(И снова мы подсократили результат.) На этот раз мы не только полу чили адресную запись, но и видим SIG-запись, созданную на основе за крытого ключа movie.edu. Подпись истекает через 30 дней после об новления - по умолчанию, но это значение можно изменить с помо щью предписания sig-validity-interval, которое принимает число дней в качестве аргумента: До BIND 9.1.0 аргумент sig-validity-interval интерпретировался как число секунд, а не дней.

436 Глава 11. Безопасность Момент подписи всегда регистрируется с вычитанием часа из времени обновления, что позволит «собеседникам», часы которых отстают от наших, спокойно выполнять проверку.

Произведя поиск для имени perfectstorm2.mouie.edu (хотя каким обра зом можно снять продолжение к этому фильму, я не знаю1), мы уви дим следующее:

Обратите внимание на NXT-запись: она была автоматически добавлена при добавлении адресной записи perfectstorm.mouie.edu, поскольку до менное имя perfectstorm.movie.edu было новым для зоны. Очень мило!

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

Следует использовать качественную идентификацию (скажем, TSIG) для проверки подлинности обновлений, потому что иначе у взломщи ка появится легкий способ изменить «защищенную» зону. Помимо этого, следует помнить, что сами по себе динамические обновления об рабатываются довольно быстро, но динамические обновления защи щенной зоны требуют повторных вычислений для NXT-записей и, что более важно, ассиметричного шифрования (при вычислении новых SIG-записей). Таким образом, DNS-серверу потребуется больше сис темных ресурсов и больше времени для обработки таких запросов.

Напоминаю, что все узлы гипотетического Университета Кинематографии авторы называют по названиям фильмов. В данном случае речь идет о филь ме, известном в российском прокате как «Идеальный шторм». - Примеч.ред.

Расширения системы безопасности DNS Смена ключей Мы утверждали, что нет необходимости генерировать новый ключ для каждой подписи зоны, однако существуют случаи, в которых придет ся создать новый ключ, либо потому, что закрытый ключ исчерпал свою полезность, либо - что гораздо хуже - был «вычислен».

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

• Чем крупнее зона, тем большие объемы данных шифруются закры тым ключом при ее подписи. Если зона очень крупная, следует ча ще менять ключи.

• Чем длиннее ключ, тем сложнее его подобрать. Длинные ключи можно менять реже.

• Чем чаще обновляются и подписываются данные зоны, тем боль ший объем информации, зашифрованной закрытым ключом, ста новится доступен. Если зона обновляется часто, в особенности если речь идет о динамических обновлениях защищенной зоны, то и ключи следует менять часто.

• Чем большую ценность для взломщика представляет подделка дан ных зоны, тем больше времени и денег он будет тратить на подбор закрытого ключа. Если целостность данных зоны особенно важна, следует менять ключи часто.

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

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

Если сделать это, DNS-серверы, кэшировавшие данные нашей зоны, не будут иметь возможности получить KEY-запись зоны и произвести проверку данных. Поэтому переход к новому ключу разбит на следую щие этапы:

1. Создание новой пары ключей.

2. Создание набора ключей, содержащего новую KEY-запись и старую KEY-запись, и отправка этого набора администратору родитель ской зоны.

3. Создание набора ключей, содержащего только новую KEY-запись, и отправка этого набора администратору родительской зоны.

438 Глава 11. Безопасность 4. В случае использования trusted-keys следует добавить соответству ющую запись к оператору для новой записи KEY. Следует также уведомить всех остальных, кто использует trusted-keys.

5. Следует включить подписанный набор ключей, полученный от ад министратора родительской зоны и содержащий обе записи KEY.

6. Необходимо прописать зональные данные новым закрытым клю чом, но оставить старую запись KEY в зоне.

7. Когда все записи, подписанные предыдущим закрытым ключом, устареют, следует удалить предыдущую KEY-запись из зоны.

8. Следует включить подписанный набор ключей, полученный от ад министратора родительской зоны и содержащий только новую за пись KEY.

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

Выполним эту процедуру. Сначала создадим новую пару ключей:

Теперь создадим набор ключей, содержащий обе записи KEY, и отпра вим его администратору родительской зоны:

и набор ключей, содержащий только новую запись KEY, который так же отправим администратору родительской зоны:

(По правде говоря, потребуется гораздо больше, чем эти два письма, чтобы кто-то наконец подписал наши ключи.) Первый набор ключей содержит обе KEY-записи и SIG-записи для них:

Расширения системы безопасности DNS Обратите внимание, что одна из SIG-записей была создана ключом со старой картой 27791 (прежний закрытый ключ), а вторая ключом с картой 47703 (новый закрытый ключ). Это доказывает, что мы облада ем парой соответствующих закрытых ключей.

Получив ответ от администратора родительской зоны, мы сохраняем данные в каталоге /var/named под именем movie.edu.signe.dkey, то есть в файле, который включаем с помощью директивы $INCLUDE в db.mo vie.edu.signed. Вот так выглядит файл movie.edu.signedkey:

SIG-запись edu относится к обеим KEY-записям, поэтому можно ис пользовать любой из ключей для подписи зональных данных.

Теперь подпишем зональные данные, используя только новый закры тый ключ:

Программе dnssec-signzone не нравится повторно подписывать зоны, уже подписанные другим ключом, поэтому мы начали опять с обыч ной версии зоны movie.edu. Вот фрагмент подписанного файла данных зоны, db.movie.edu.signed:

440 Глава 11. Безопасность Хотя зона включает две KEY-записи, а также SIG-запись edu, которая относится к обеим, прочие записи зоны были подписаны только новым.

закрытым ключом - с картой 47703.

Второй подписанный набор ключей нужен при удалении старой запи си KEY: SIG-запись, посланная нам из зоны edu, и относящаяся к обеим KEY-записям, становится бесполезной. Но если мы используем набор ключей, содержащий только новую запись KEY, все будет в порядке.

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

Расширения системы безопасности DNS К чему все это?

Мы понимаем, что DNSSEC выглядит немного, скажем так, устраша юще. (Нам стало плохо, когда мы впервые столкнулись с этим меха низмом.) Но в основе его разработки лежит очень и очень важная идея:

максимально затруднить подделку пакетов DNS. В наше время все большее распространение получает использование сети Интернет для ведения дел, а в этом случае очень важно быть уверенным, что попа дешь именно туда, куда собирался.

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

• Насколько хорош nslookup?

• Пакетный или диалоговый?

• Настройка • Как отключить список поиска • Основные задачи • Прочие задачи • Разрешение проблем с nslookup • Лучшие в сети Работа с dig nslookup и dig - Что это ты там бормочешь? - спросил Шалтай, впервые прямо взглянув на нее. - Скажи-ка мне лучше, как тебя зовут и зачем ты сюда явилась.

- Меня зовут Алиса, а...

- Какое глупое имя, - нетерпеливо прервал ее Шалтай-Болтай. - Что оно значит?

- Разве имя должно что-то значить? - проговорила Алиса с сомнением.

- Конечно, должно, - ответил Шалтай-Болтай и фыркнул.

Чтобы стать экспертом в решении проблем, связанных с DNS-сервера ми, необходим отладочный инструмент, который позволяет выпол нять DNS-запросы, причем инструмент достаточно гибкий. В этой гла ве мы изучим nslookup, поскольку эта программа распространяется в комплекте BIND и доступна на многих операционных системах. Разу меется, это не значит, что nslookup - самый лучший из существующих для отладки инструментов. У nslookup есть недостатки, и их так мно го, что использование этого инструмента в BIND 9 в настоящее время осуждается («deprecated», на человеческом языке - «официально не в почете»). Тем не менее, мы рассмотрим nslookup, поскольку это везде сущая программа. Затем мы перейдем к инструменту dig, который обеспечивает схожую функциональность и не страдает от недостатков, присущих nslookup.

Помните, что эта глава не всеобъемлюща, существуют аспекты nslook up и dig (по большей части слабо понятные и редко используемые), ко торые оставлены за кадром. Любознательные читатели всегда найдут эту информацию в соответствующих страницах руководства.

Насколько хорош nslookup? Насколько хорош nslookup?

По большей части nslookup будет использоваться для отправки запросов тем же способом, какой используется DNS-клиентом. Но иногда nslook up может применяться для отправки запросов DNS-серверам, как это делает не клиент, но собственно DNS-сервер. Способ применения этой программы зависит от проблемы, которую необходимо решить. Читате ли спросят: «Насколько точно nslookup эмулирует DNS-клиент или DNS-сервер? Использует ли функции библиотеки клиента BIND?» Нет, nslookup использует собственные функции для посылки запросов DNS серверам, но эти функции основаны на функциях клиента. Как следст вие поведение nslookup очень схоже с поведением клиента, но немного отличается. Мы будем обращать внимание читателей на эти различия.

Что касается эмуляции поведения DNS-сервера, nslookup позволяет посылать DNS-серверу запросы, которые абсолютно не отличаются от посылаемых DNS-серверами, но при этом используется другая схема передачи запросов. При этом, как и DNS-сервер, nslookup умеет произ водить передачу копии данных зоны. Итак, nslookup не эмулирует в точности ни клиент, ни DNS-сервер, но эмулирует их в достаточной степени, чтобы служить достойным инструментом для диагностики.

Теперь рассмотрим различия, о которых мы только что упоминали.

Множественные серверы nslookup умеет общаться только с одним DNS-серверов единовременно.

В этом заключается его самое большое отличие от DNS-клиента. Кли ент использует все инструкции nameserver из файла resolv.conf. Если в resolv.conf присутствуют две инструкции nameserver, клиент посылает запрос сначала первому серверу, затем второму, затем снова первому, и снова второму, и так, пока не будет получен ответ, либо не откажется от дальнейших попыток. Процесс повторяется для каждого запроса. С другой стороны, nslookup пытается получить ответ от первого из серве ров, перечисленных в resolv.conf, пока не потеряет всякую надежду, а затем переходит ко второму серверу. Получив ответ, программа фик сируется на одном из серверов и не посылает запросы второму. При этом желательно, чтобы диагностирующий инструмент работал толь ко с одним DNS-сервером, в целях сокращения числа переменных, участвующих в анализе проблемы. Если бы nslookup работал с не сколькими DNS-серверами, мы в значительно меньшей степени могли бы управлять сеансами диагностики. Таким образом, для диагности рующего инструмента фиксация на единственном сервере совершенно естественна.

Интервалы ожидания Интервалы ожидания nslookup соответствуют интервалам ожидания при работе клиента с единственным DNS-сервером. Интервалы ожида 444 Глава 12. nslookup и dig ния для DNS-сервера, при этом, основаны на том, насколько быстро DNS-сервер ответил на последний запрос, то есть являются динами чески изменяющимися величинами. Интервалы ожидания nslookup никогда не совпадают с интервалами ожидания DNS-серверов, но это также не является проблемой. При посылке запросов удаленным DNS серверам с помощью nslookup необходимо знать лишь результат, а не время, потраченное на поиск ответа.

Список поиска nslookup точно так же, как и клиент, реализует список поиска. Версии nslookup, поставляемые в составе BIND версий до 4.9, в основном ис пользуют «полный» список поиска: локальное доменное имя и имена всех предков, состоящие не менее чем из двух меток. Версии nslookup, поставляемые в составе BIND версии 4.9 и более поздних, используют сокращенный список поиска, который содержит только локальное до менное имя. Мы покажем, как определить эту характеристику nslook up в случае, если существует такая необходимость.

Список поиска не реализуется DNS-серверами, поэтому для работы в качестве DNS-сервера nslookup следует проинформировать о необходи мости отключить список поиска (подробности чуть позже).

Передача зоны nslookup производит передачу зоны в точности, как DNS-сервер. Но в от личие от DNS-сервера nslookup не проверяет порядковые номера в SOA записях перед получением данных зоны;

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

Использование NIS и файла /etc/hosts В этом последнем разделе мы не сравниваем nslookup с клиентом или DNS-сервером, но изучаем способы поиска по именам в целом. Как ин струмент, поставляемый концорциумом ISC, nslookup использует только DNS;

он не будет работать с NIS или файлом /etc/hosts. Боль шинство приложений способны использовать DNS, NIS или /etc/hosts, в зависимости от настройки системы. Не надейтесь, что nslookup помо жет обнаружить проблемы, если узел не настроен на использование DNS-серверов. Это возможно в случаях, когда поставщик усовершенствовал nslookup для работы с серверами NIS и файлом /etc/hosts;

именно так дела обстоят в сис теме HP-UX.

Пакетный или диалоговый? Пакетный или диалоговый?

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

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

Чтобы запустить программу в режиме диалога, следует просто набрать nslookup:

Для получения справки можно ввести ? или help.1 Для завершения ра боты следует набрать ^D (Ctrl-D), либо exit. Если попытаться завер шить работу с nslookup прерыванием по ^С (или по другому символу, определенному для прерываний), то желаемого результата не будет.

nslookup перехватывает сигнал прерывания, прекращает текущую операцию (например, передачу зоны) и выдает приглашение >.

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

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

Функция справки не реализована в nslookup пакета BIND 9 (в версии 9.1.0).

446 Глава 12. nslookup и dig i !

Небольшое вступление, прежде чем мы перейдем непосредственно к настройкам. DNS-сервер по умолчанию - bladerunner.fx.movie.edu. Это означает, что nslookup будет посылать запросы узлу bladerunner, если явным образом не указать другой DNS-сервер. Адрес 0.0.0.0 означает «этот узел». Когда nslookup в качестве адреса DNS-сервера использует 0.0.0.0 или 127.0.0.1, речь идет о DNS-сервере, работающем на ло кальной системе, в данном случае - на узле bladerunner.

Существуют настройки двух типов: переключатели и принимающие значения. Переключателям не присваиваются значения с помощью знака равенства. Множество значений переключателя ограничивается положениями «включено» и «выключено». Настройкам, принимаю щим значения, могут присваиваться... значения. Как определить, ка кие переключатели включены, а какие выключены? Настройка выклю чена, если ее имя предваряется словом «по». Так, nodebug означает, что отладка выключена. Как можно догадаться, переключатель search включен.

Способ изменения значений настроек зависит от того, используется nslookup в пакетном режиме или в диалоговом. В диалоговом сеансе настройку можно изменить с помощью команды set (set debug или set domain=classics.movie.edu). В командной строке следует опускать ключевое слово set и предварять имя параметра дефисом (nslookup -de bug или nslookup -domain=classics.movie.edu). Параметры могут сокра щаться до наиболее краткой, уникальной формы. Так, nodeb является допустимым сокращением nodebug. Помимо сокращения, имя на стройки querytype может записываться как type.

Рассмотрим каждую из настроек:

[no]debug Отладка по умолчанию выключена. При включенной отладке DNS сервер отображает интервалы ожидания и ответные сообщения.

См. также описание второго уровня отладки ([no]d2).

[no]defname По умолчанию nslookup добавляет локальное доменное имя к име нам, не содержащим точек. До того как появился список поиска, клиент BIND добавлял к именам, не содержащим точек, только ло кальное доменное имя;

описываемая настройка отражает этот факт, nslookup может вести клиент до появления списка поиска (se Настройка arch выключен, defname включен) или клиент со списком поиска (search включен).

[no]search Настройка search заменяет настройку для локального доменного имени (defname). To есть defname имеет силу только в том случае, если переключатель search выключен. По умолчанию nslookup до бавляет доменные имена из списка поиска (srchlist) к именам, кото рые не заканчиваются точкой.

[no]recurse По умолчанию nslookup создает рекурсивные запросы. В сообщени ях устанавливается бит рекурсии. Клиент BIND посылает рекур сивные запросы таким же образом. Но DNS-серверы посылают дру гим DNS-серверам нерекурсивные запросы.

[no]d Отладка второго уровня по умолчанию выключена. Если включить отладку, то в дополнение к стандартной диагностике будут отобра жаться посылаемые сообщения-запросы. Включение d2 также ав томатически включает debug. Выключение d2 выключает только d2;

debug остается включенным. Выключение debug выключает и debug, и d2.

[no]vc По умолчанию nslookup посылает запросы в UDP-дейтаграммах, а не через TCP-соединение. Большинство клиентов BIND посылают запросы по UDP, поэтому стандартное поведение nslookup совпада ет с поведением клиента. Клиенту можно предписать использова ние TCP, то же самое касается программы nslookup.

[no]ignoretc По умолчанию nslookup не игнорирует усеченные сообщения. Если бит «усечения» в полученном сообщении установлен - это значит, что DNS-сервер не смог уместить всю значимую информацию в UDP-дейтаграмму ответа - nslookup повторно посылает запрос, ис пользуя TCP-соединение. Это поведение также соответствует пове дению клиента BIND. Смысл повторения запроса с использованием TCP-соединения заключается в том, что размер TCP-ответа может многократно превышать размер UDP-ответа.

port= DNS-сервер принимает соединения через порт 53. Для целей отлад ки можно запустить DNS-сервер на другом порту, а затем предпи сать программе nslookup использовать этот порт для запросов.

querytype=A По умолчанию nslookup производит поиск А (адресных) RR-запи сей. Помимо этого, если указать IP-адрес (и тип запроса А или 448 Глава 12. nslookup и dig PTR), nslookup обращает адрес, добавляет in-addr.arpa и произво дит поиск PTR-записей.

class=IN Единственный класс, имеющий какой-то смысл, - Интернет (IN).

Ну, возможно еще класс Hesiod (HS), для людей из Массачусетско го технологического института или пользователей Ultrix.

timeout= Если DNS-сервер не ответил в пределах 5 секунд, nslookup посылает запрос повторно и удваивает интервал ожидания (до 10, 20, а затем до 40 секунд). Большинство клиентов BIND используют такие же значения при работе с одним DNS-сервером.

retry= Посылать запрос не более четырех раз. После каждой попытки зна чение интервала ожидания удваивается. Это соответствует поведе нию большинства версий клиента BIND.

root=a.root-servers.net.

Существует удобная команда root, которая позволяет изменить DNS-сервер на указанный. Выполнение команды root в командной строке современной версии nslookup равноценно выполнению ко манды server a.root-servers.net. В более старых версиях указывалось имя корневого DNS-сервера nic.ddn.mil (в умеренно старых) или да же sri-nic.arpa (в древних). «Корневой» сервер по умолчанию мож но изменить с помощью команды set root=server.

domain=fx.movie.edu Стандартное доменное имя, добавляемое при включенном defname.

srchlist=fx.movie.edu Если search включен, перечисленные здесь доменные имена добав ляются к именам, которые не заканчиваются точкой. Доменные имена перечисляются в порядке предпочтения, и разделяются сим волом слэша. (В nslookup из BIND версии 4.8.3 список поиска по умолчанию содержал бы значение fx.movie.edu/movie.edu. Начиная с версии 4.9 список поиска программы nslookup стандартно содер жит только доменное имя по умолчанию.1 Следует явно определить список поиска в файле /etc/resolv.conf, чтобы одновременно ис пользовать fx.movie.edu и movie.edu.) Это позволяет легко определить, какая версия nslookup используется: сле дует выполнить set all и проверить, содержит список поиска по умолчанию только локальное доменное имя (BIND версии 4.9 или более поздней) или также и доменные имена предков (BIND версии 4.8.3 или более ранней).

Как отключить список поиска файл.nslookuprc Собственные стандартные настройки программы nslookup можно опре делить в файле.nslookuprc. nslookup при запуске производит поиск файла.nslookuprc в домашнем каталоге пользователя, это справедливо как для пакетного, так и для диалогового режима. Файл.nslookuprc может содержать любые корректные команды set, по одной в строке.

Это полезно, к примеру, в случае, когда старая версия nslookup счита ет sri-nic.arpa корневым DNS-сервером. Корневой DNS-сервер, исполь зуемый по умолчанию, можно определить с помощью следующей стро ки в файле.nslookuprc:

set root=a. root-servers.net.

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

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

Может возникнуть необходимость запретить использование списка поиска (set nosearch) либо использовать при поиске абсолютные до менные имена, заканчивающиеся точкой. Как видно из примеров, мы предпочитаем второй вариант.

Основные задачи Существует несколько повседневных задач, которые приходится прак тически ежедневно решать с помощью nslookup: поиск IP-адреса или МХ-записей для определенного доменного имени или запрос данных у конкретного DNS-сервера. Сначала мы рассмотрим основные задачи, а потом перейдем к прочим, которые приходится решать гораздо реже.

Поиск записей различного типа По умолчанию nslookup производит поиск адреса для доменного имени, либо доменного имени для адреса. Запись любого типа можно найти, изменяя значение querytype, как показано в следующем примере:

450 Глава 12. nslookup и dig Разумеется, существует не так уж и много типов записей DNS. Более полный список приводится в приложении А «Формат сообщений DNS и RR-записей».

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

Основные задачи И ничего странного в этом нет. Дело в том, что когда локальный DNS сервер в первый раз производит поиск для имени slate.mines.colora do.edu, то связывается с DNS-сервером зоны mines.colorado.edu, и сер вер mines.colorado.edu авторитативно отвечает на вопрос. По сути дела, локальный DNS-сервер возвращает авторитативный ответ прямо про грамме nslookup. Помимо этого, ответ кэшируется. При повторном по иске для slate.mines.colorado.edu DNS-сервер извлекает кэширован ный ответ и возвращает его в качестве «неавторитативного». Обратите внимание, что мы завершаем доменные имена точкой при каждом поиске. Если бы мы этого не делали, то получали бы точно та кой же ответ. В некоторых случаях важно не забывать использовать абсолютные имена при отладке, а в некоторых это не имеет значения.

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

Переключение между DNS-серверами Иногда появляется необходимость послать прямой запрос другому DNS-серверу — к примеру, если возникло подозрение, что сервер ведет себя некорректно. Изменить используемый DNS-сервер в nslookup можно с помощью lserver. Разница между server и lserver в том, что lserver посылает запрос «локальному» DNS-серверу - тому, с которого все началось - в целях получения адреса сервера, на который происхо дит переключение;

server использует DNS-сервер по умолчанию вмес то локального. Это различие важно, поскольку сервер, на который произошло переключение может не отвечать:

При запуске первый DNS-сервер, relay.hp.com, становится сервером команды lserver. Это имеет значение для описываемого сеанса работы.

Интересно, что серверы имен BIND 9 представляют даже первый ответ как неавторитативный.

452 Глава 12. nslookup и dig В этот момент мы пытаемся переключиться обратно, на исходный DNS-сервер. Но на узле galt.cs.purdue.edu нет DNS-сервера, который позволил бы найти адрес relay.hp.com:

Чтобы не застрять, мы используем команду lserver, чтобы с помощью локального DNS-сервера найти адрес relay.hp.com:

Поскольку DNS-сервер на узле galt.cs.purdue.edu не ответил (ведь DNS сервер на этом узле вообще отсутствует), то не было возможности найти адрес узла relay.hp.com, чтобы переключиться на работу с DNS сервером на relay. И здесь на помощь приходит команда lserver: ло кальный DNS-сервер, relay, по-прежнему отвечал на запросы, и мы воспользовались этим обстоятельством. Мы могли бы также не приме нять lserver, а восстановить равновесие прямым указанием IP-адреса узла relay - server 15.255.152.2.

Существует также возможность изменять используемые DNS-серверы для отдельных запросов. Чтобы объяснить nslookup, что запрос по кон кретному доменному имени следует посылать определенному DNS серверу, следует указать DNS-сервер в качестве второго аргумента, после доменного имени, для которого ведется поиск:

И, разумеется, серверы можно переключать при запуске nslookup из командной строки. Сервер, которому посылается запрос, можно ука зать после доменного имени, для которого создается этот запрос:

Прочие задачи Такая команда является указанием nslookup посылать запрос DNS серверу terminator.movie.edu на предмет получения МХ-записей для имени fisherking.movie.edu.

Наконец, чтобы указать альтернативный DNS-сервер и перейти в ди алоговый режим, можно передать программе nslookup дефис вместо доменного имени:

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

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

Отображение сообщений-запросов и сообщений-ответов При необходимости можно предписать nslookup отображение посылае мых запросов и получаемых ответных сообщений. Для отображения ответов необходимо включить debug. Для отображения запросов и от ветов - d2. При необходимости отключить отладку полностью следует использовать set nodebug, поскольку set nod2 отключает только отлад ку второго уровня. Для приводимого фрагмента мы сделаем несколько комментариев. Особенно любопытные читатели могут стряхнуть пыль со своих копий документа RFC 1035, открыть страницу 25 и читать ее параллельно с нашими объяснениями.

454 Глава 12. nslookup и dig Прочие задачи Строки дефисов разделяют сообщения-запросы и сообщения-ответы.

Сейчас, как и было обещано, мы разберем содержимое сообщений. Па кеты DNS состоят из пяти разделов: заголовка (Header), вопроса (Ques tion), ответа (Answer), авторитативности (Authority) и вторичного (Ad ditional).

Раздел заголовка Раздел заголовка присутствует в каждом запросе или ответном со общении. Код операции, о котором сообщает nslookup, всегда имеет значение QUERY. Существуют другие коды операций: для асинхрон ных уведомлений об изменении зональных данных (NOTIFY) и дина мических обновлений (UPDATE), но nslookup их не встречает, по скольку посылает обычные запросы и получает стандартные ответы.

Поле ID в заголовке используется для связывания ответного сооб щения с запросом и обнаружения дублирующихся запросов или от ветов. Чтобы определить, какое сообщение является запросом, а ка кое ответом, следует изучить флаг заголовка. Строка want recursion означает, что запрос рекурсивный. В ответе значение этого флага копируется. Строка auth. answer идентифицирует авторитативный ответ. Другими словами, ответ получен из данных авторитативного DNS-сервера, а не из кэша. Код ответного сообщения, rcode, может иметь значения: по error (нет ошибок), server failure (ошибка серве ра), name error (ошибка в имени, известная также как nxdomain или nonexistent domain - несуществующий домен), not implemented (реализация отсутствует) или refused (отказ). Коды server failure, name error, not implemented и refused приводят к выдаче програм мой nslookup сообщений «Server failed», «Nonexistent domain», «Not implemented» и «Query refused», соответственно. Последние четыре записи в разделе заголовка представляют собой счетчики, определяющие, сколько RR-записей содержится в каждом из четы рех последующих разделов.

Раздел вопроса В сообщении DNS всегда присутствует один вопрос;

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

Раздел ответа Данные раздел содержит RR-записи, которые являются ответом на вопрос. В ответе может содержаться несколько RR-записей. К при 456 Глава 12. nslookup и dig меру, если узел входит в несколько сетей, может присутствовать не сколько адресных записей.

Раздел авторитативности В раздел авторитативности возвращаются записи DNS-серверов (NS-записи). Когда ответ является перенаправлением к другим DNS-серверам, координаты этих DNS-серверов перечислены в дан ном разделе.

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

Специально для педантичных читателей отметим, что существует ва риант, при котором число вопросов в сообщении DNS не равно одному:

в инверсных запросах это число равно нулю. Инверсный запрос содер жит один ответ, а раздел вопроса пуст. DNS-сервер заполняет раздел вопроса. Но как мы уже говорили, инверсные запросы занесены в красную книгу.

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

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

В приземленных терминах nslookup все это означает, что создание за просов в стиле клиента происходит при применении программы со стан дартными настройками. Чтобы предписать создание запросов в стиле DNS-сервера, следует использовать команды set norecurse и set nose arch. Для командной строки это будет выглядеть следующим образом:

nslookup -norecurse -nosearch.

Когда DNS-сервер BIND получает запрос, то ищет ответ в данных, ДЛЯ которых он авторитативен, а также в кэше. Если ответа на запрашива емые данные нет ни в кэше, ни в авторитативных данных, то DNS-сер вер отвечает, что имя не существует либо что отсутствуют записи за Прочие задачи прошенного типа. Если DNS-сервер не кэшировал ответ и не является авторитативным для зоны, о которой идет речь, то он начинает проче сывать пространство имен в поиске NS-записей. Всегда существуют NS-записи, расположенные выше в пространстве имен. В качестве по следнего средства DNS-сервер использует NS-записи высшего уровня корневой зоны.

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

Для следующего примера предположим, что мы пытаемся удовлетво рить рекурсивный запрос и не нашли никаких NS-записей вплоть до зоны gov. И это действительно может иметь место, если мы поинтере суемся у DNS-сервера relay.hp.com о данных по имени www.whitehou se.gov;

он не найдет подходящих NS-записей, пока не доберется до зо ны gov. Затем мы переключаем DNS-сервер на DNS-сервер зоны gov и задаем тот же вопрос. Получаем направление к DNS-серверам white house.gov. Переключаем DNS-сервер на DNS-сервер зоны whitehou se.gov и задаем тот же вопрос еще раз:

458 Глава 12. nslookup и dig Переключение на DNS-сервер gov (возможно, придется временно включить рекурсию, если ваш DNS-сервер не хранит в кэше адреса DNS-сервера gov):

Задаем тот же вопрос DNS-серверу gov. Он перенаправит нас к DNS серверам, расположенным ближе к искомому ответу:

Выбираем один из DNS-серверов whitehouse.gov - подойдет любой:

Прочие задачи Надеемся, этот пример дал читателям представление о том, как DNS серверы производят поиск по доменным именам. Если необходимо ос вежить картинку в памяти, обратитесь к рис. 2.12 и 2.13.

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

«Какой адрес у www.whitehouse.gov?» Как вы думаете, что произошло бы в случае, если бы DNS-сервер зоны gov сам уже кэшировал адрес www.whitehouse.gov? Этот DNS-сервер ответил бы на наш вопрос дан ными из кэша, вместо того чтобы направлять нас к DNS-серверам whi tehouse.gov. Почему это имеет значение? Предположим, мы что-то на путали с адресом одного из узлов нашей зоны. Нам указывают на ошибку, и мы ее исправляем. Наш DNS-сервер хранит корректные данные, но некоторые из удаленных DNS-серверов возвращают непра вильные данные, когда им задают вопрос об адресе этого узла. Один из DNS-серверов, обслуживающих зону более высокого уровня, напри мер корневой DNS-сервер, кэшировал неправильные данные;

получив запрос адреса узла, он отвечает неправильными данными, вместо того чтобы направить автора запроса к нашему DNS-серверу. Эту проблему довольно трудно выявить, поскольку только один из серверов «более высокого уровня» кэшировал неправильные данные, а значит, лишь некоторые запросы будут приводить к получению неправильных дан ных, а именно - запросы, адресованные этому DNS-серверу. Весело, правда? Конечно, в конце концов, неправильная запись в кэше DNS сервера «более высокого уровня» устареет и будет удалена. Если мы не хотим ждать, можно связаться с администраторами удаленного серве ра и попросить их перезапустить named с целью очистки кэша. Разуме ется, если удаленный DNS-сервер является важным и хорошо загру женным, администраторы, весьма вероятно, объяснят, куда мы мо жем отправляться с такими предложениями.

Передача зоны nsloohup может использоваться для передачи целой зоны с помощью команды ls. Эта возможность полезна в плане диагностики, если необ ходимо узнать доменное имя удаленного узла либо просто сосчитать, сколько узлов содержится во внешней зоне. Поскольку вывод может быть объемным, nslookup позволяет перенаправлять его в файл. Чтобы прервать процесс передачи зоны, можно использовать стандартный символ прерывания.

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

Взглянем на зону movie.edu. Как можно видеть из следующего фраг мента, доступны все данные зоны - SOA-запись даже дважды, что яв ляется артефактом, появление которого связано с обменом данными в 460 Глава 12. nslookup и dig процессе передачи зоны. Поскольку некоторые версии nslookup по умолчанию отображают только адрес и NS-записи, мы использовали ключ -d для получения всей зоны:

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

Разрешение проблем с nslookup Некоторые из версий nslookup даже реализуют встроенную команду vi ew, которая сортирует и отображает содержимое зоны в диалоговом ре жиме. Однако в последних изданиях BIND 8 команда view не работает, а в BIND 9 - на момент существования версии 9.1.0 - не поддерживается.

Разрешение проблем с nslookup Последнее, чего можно пожелать, так это проблем с инструментом, предназначенным для диагностирования проблем. К сожалению, не которые ошибки делают nslookup практически бесполезной програм мой. Прочие случаи ошибок nslookup (в лучшем случае) могут озада чить, поскольку при их возникновении пользователю не предоставля ется информация, на основе которой он мог бы продолжить работу.

Собственно nslookup является причиной проблем далеко не во всех случаях, в основном проблемы можно отнести на счет настройки и ра боты DNS-серверов. Проблемы такого рода мы и рассмотрим далее.

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

Тогда какого типа записи существуют? Чтобы узнать это, выполним команду set type=any:

462 Глава 12. nslookupn dig Сервер не отвечает Что случилось, если наш сервер имен не может найти собственное имя?

Сообщение об ошибке «no response from server» следует понимать бук вально: клиент не получил ответа. Совершенно не факт, что nslookup производит поиск чего-либо при запуске. Если вы видите, что адрес ва шего DNS-сервера - 0.0.0.0, это означает, что nslookup воспользовался именем узла системы (которое возвращается командой hostname) в ка честве значения поля Default Server (сервер по умолчанию), а затем выдал приглашение. И только при попытке найти какие-либо данные выясняется, что сервер не отвечает. В этом случае довольно очевидно, что DNS-сервер просто не запущен - потому что DNS-сервер должен смочь найти информацию по собственному имени. Однако если вы ищете информацию из внешнего мира, DNS-сервер мог не ответить, поскольку просто не успел найти данные до того, как nslookup потерял надежду получить ответ. Как определить разницу между DNS-серве ром, который просто не был запущен, и DNS-сервером, который рабо тает, но не ответил на запрос? Можно воспользоваться командой ls:

В данном случае DNS-сервер не запущен.1 Если до узла невозможно достучаться, сообщение об ошибке будет «timed out» (истек интервал Вообще-то такая ошибка может означать также и то, что где-то в сети фильтруются TCP-соединения на данный сервер - причем как в одном (по response) так и в другом (timeout) случае. - Примеч. науч. ред.

Разрешение проблем с nslookup ожидания). В случае, когда DNS-сервер запущен, будет получено сле дующее сообщение об ошибке:

Разумеется, если в вашем мире действительно не существует зоны высшего уровня foo.

Отсутствует PTR-запись для адреса DNS-сервера Вот одна из самых неприятных ошибок программы nslookup: что-то пошло не так, и nslookup завершил работу сразу после запуска:

Сообщение «nonexistent domain» (несуществующий домен) означает, что имя 3.249.249.192.in-addr.arpa не существует. Иначе говоря, про грамме nslookup не удалось отобразить 192.249.249.3, адрес своего DNS-сервера, в доменное имя. Но разве мы не сказали только что, что nslookup ничего не ищет при запуске? В приведенной ранее конфигу рации программа nslookup действительно ничего не искала при запус ке. Но это не правило. Если создать файл resolv.conf, содержащий одну или более инструкций nameserver, nslookup попытается произвести об ратное отображение адреса, чтобы получить доменное имя DNS-серве ра. В предыдущем примере присутствует DNS-сервер по адресу 192.249.249.3, но упоминается, что не существует PTR-записей для адреса 192.249.249.3. Очевидно, проблемы связаны с ошибками зоны обратного отображения, по крайней мере там, где дело касается домен ного имени 3.49.249.192.in-addr.arpa.

Сообщение «default servers are not available» (DNS-серверы по умолча нию недоступны) вводит пользователя в заблуждение. В конце кон цов, присутствует DNS-сервер, который может сообщить, что домен ное имя не существует. Чаще, если сервер не запущен, либо до него не возможно достучаться, встречается сообщение об ошибке «no response from server» (сервер не ответил). Только в этом случае сообщение «de fault servers are not available» приобретает смысл.

Запрос отвергнут Отказ в выполнении запросов может быть источником проблем при за пуске, а также причиной нерезультативного поиска в сеансе работы.

464 Глава 12. nslookup и dig Вот так выглядит завершение nslookup после запуска по причине по лучения отказа:

Существуют две возможные причины такого поведения. DNS-сервер не поддерживает инверсные запросы (более старые версии nslookup) либо существующий список доступа не позволяет произвести поиск.

Более старые версии nslookup (до версии 4.8.3) выполняли при запуске инверсные запросы. Инверсные запросы никогда не применялись ши роко - и программа nslookup являлась одним из тех приложений, в ко торых инверсные запросы использовались. Начиная с BIND версии 4. поддержка инверсных запросов прекратилась, что привело к появле нию проблем со старыми версиями nslookup. Чтобы справиться с эти ми проблемами были созданы новые параметры настройки.

В BIND 4 инструкция выглядит следующим образом:

Соответствующая инструкция для BIND 8:

(BIND 9 не поддерживает fake-iquery на момент существования версии 9.1.0.) Эта инструкция предписывает DNS-серверу отвечать на инверсные за просы «поддельным» ответом, который достаточно корректен, чтобы программа nslookup продолжала работу. Проблемы при запуске также можно отнести на счет списков доступа.

Когда nslookup пытается найти доменное имя своего DNS-сервера (по сылая не инверсный, а PTR-запрос), то может получить отказ. Если вы думаете, что проблема в списке доступа, убедитесь, что дали разреше ние узлу, на котором происходит работа, посылать запросы DNS-серве ру. Проверьте ТХТ-записи securezone и предписания allow-query, свя занные с IP-адресом локального узла, либо адресом loopback-интерфей са, если nslookup выполняется на той же машине, что и DNS-сервер.

Списки доступа могут не только предотвратить успешный запуск nslo okup. Они могут предотвращать успешное завершение поиска или пе редачи зоны в самый разгар сеанса работы, когда nslookup переключа ется на удаленный DNS-сервер. Это выглядит примерно так:

Поддельный ответ на инверсный запрос, скажем, доменного имени с адресом 192.249.249.3 - тот же самый адрес в квадратных скобках, [192.249.249.3].

Разрешение проблем с nslookup Первый из DNS-серверов resolv.conf не отвечает Еще одна вариация последней проблемы:

Первый сервер из списка, приводимого в файле resolv.conf, не ответил.

В resolv.conf присутствовала вторая инструкция nameserver, и второй DNS-сервер отозвался на запрос. С этого момента nslookup будет посы лать запросы только узлу wormhole.movie.edu;

но не будет посылать по следующие запросы серверу по адресу 192.249.249.3.

Как узнать, что происходит В последних примерах мы размахивали руками, утверждая, что nslo okup ищет адрес DNS-сервера, но никак не доказали этот факт. Вот на ше доказательство. На этот раз, при запуске nslookup мы включили от ладку d2 с помощью ключа командной строки. На втором уровне от ладки nslookup печатает посылаемые сообщения, а также сообщает об истечении интервалов ожидания и переключениях между серверами:

466 Глава 12. nslookup и dig Как можно видеть (строки timeout), программа nslookup потратила 75 се кунд на ожидание ответов, перед тем как окончательно сдаться. Без включения отладки экран был бы пуст в течение 75 секунд;

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

Неопределенная ошибка Существует возможность встретиться с довольно неприятной ошиб кой, которая называется «неопределенной». Ниже мы приводим при мер такой ошибки. Здесь присутствует лишь окончание фрагмента, поскольку нас на данный момент интересует лишь собственно ошибка (полностью сеанс работы с nslookup, приведший к получению этой ошибки, содержится в главе 14 «Разрешение проблем DNS и BIND»):

Дело в том, что объем ответной информации оказался слишком боль шим и не поместился в UDP-дейтаграмму. DNS-сервер перестал запол нять ответ, когда кончилось место. Бит усечения в ответном сообще нии не был установлен, потому что в этом случае программа nslookup повторила бы запрос через TCP-соединение;

скорее всего, DNS-сервер решил, что включил достаточное количество «важной» информации.

Ошибки такого рода встречаются не слишком часто. Это может проис ходить при создании слишком большого числа NS-записей для зоны, так что следует умерять свои аппетиты. (Подозреваем, советы вроде этого заставляют читателей спрашивать себя, зачем они купили эту книгу.) Сколько записей «слишком много» - зависит от того, насколь ко хорошо могут «упаковываться» доменные имена в пакете, а это, в свою очередь, зависит от того, сколько имен DNS-серверов, заканчива ются одинаковым доменным именем. Корневые DNS-серверы были пе Лучшие в сети реименованы и имеют окончание root-servers.net именно по этой при чине - в результате корневых серверов в сети Интернет может быть больше (13). Основное правило - старайтесь не создавать более десяти NS-записей. Чтобы узнать причину ошибки, показанной выше, при дется просто прочесть главу 14. Те из читателей, кто только что прочи тал главу 9 «Материнство», уже могут догадаться самостоятельно.

Лучшие в сети Труд системного администратора неблагодарный. Существуют опреде ленные вопросы, обычно довольно простые, которые задаются пользо вателями снова и снова. И иногда, пребывая в творческом настроении, администраторы изобретают эффективные способы помочь своим пользователям. Когда мы обнаруживаем, насколько их решения гени альны, то можем только восхищаться ими, жалея, что сами об этом не подумали. Вот один из таких случаев, системный администратор на шел способ решить досадную проблему с завершением сеанса nslookup:

Работа с dig Это один из способов справиться с так называемым недостатком nslo okup. Второй способ - просто выбросить nslookup и применять dig, Do main Information Groper - искатель доменной информации (название появилось раньше, чем расшифровка сокращения).

Ранее мы говорили, что dig не столь распространен, как nslookup, по этому начнем с рассказа о том, где его достать. Исходные тексты dig находятся в каталоге tools (BIND 4), в каталоге src/bin/dig (BIND 8) или в каталоге bin/dig (BIND 9) дистрибутива BIND. Если пакет соби рается из исходных текстов, будет собрана также и новая копию про граммы dig.

При использовании dig все аспекты поведения и создания запросов оп ределяются в командной строке, поскольку диалоговый режим работы 468 Глава 12 nslookup и dig в dig не реализован. Доменное имя, для которого производится поиск, указывается в качестве первого аргумента, тип запроса (например, а при поиске адресных записей, тх при поиске МХ-записей) - в ка честве второго аргумента;

по умолчанию происходит поиск адресных записей. DNS-сервер, которому следует посылать запросы, указывает ся после символа «@», причем можно использовать доменное имя или IP-адрес. По умолчанию запросы посылаются DNS-серверам из ге solv.conf.

dig очень хорошо разбирается в аргументах. Их можно указывать в любом порядке, a dig самостоятельно поймет, что тх - это, скорее все го, тип записей, а не доменное имя, для которого ведется поиск. Одно из серьезных различий между nslookup и dig заключается в том, что dig не использует список поиска, а значит - в качестве аргументов доменных имен всегда должны набираться абсолютные доменные име на. Так:

производит поиск адресных записей для plan9.fx.movie.edu;

запросы отправляются первому DNS-серверу из перечисленных в resolv.conf.

При этом команда:

производит поиск МХ-записей для acmebw.com через тот же DNS-сер вер, а команда:

посылает DNS-серверу wormhole.movie.edu запрос SOA-записи для то vie.edu.

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

выглядит следующим образом:

В действительности ранние версии пакета BIND 9 (до версии 9.1.0) содер жат ущербную в этом смысле реализацию dig, которая требует, чтобы аргу мент доменного имени предшествовал аргументу типа. При этом DNS-сер вер, с которым ведется работа, может быть указан в любой позиции.

Работа с dig Рассмотрим этот фрагмент по разделам.

Первая строка начинается с комментария <<>> DiG 8.3 <<>> и повто ряет аргументы командной строки, то есть отражает факт, что были запрошены NS-записи для корневой зоны у DNS-сервера a.root-ser vers.net.

Следующая строка, (1 server found), отражает тот факт, что dig, при поиске адресов, связанных с доменным именем, указанным после сим 470 Глава 12. nslookup и dig вола @, то есть a.root-servers.net, нашел ровно один адрес. (Если dig1 на ходит более трех адресов, то сообщает о трех найденных адресах, по скольку это максимальное число, с которым работает большинство клиентов и DNS-серверов.) Строка, которая начинается с ->> HEADER <<-, является первой частью заголовка ответного сообщения, полученного от удаленного DNS-сервера. Код операции в заголовке всегда QUERY, как и в случае с nslookup. Состояние представлено значением NOERROR;

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

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

Флаги (flags) содержат дополнительные сведения об ответе, qr отражает тот факт, что сообщение является ответом, а не запросом, dig декодиру ет ответы, но не запросы, поэтому qr присутствует всегда. Однако это не справедливо для флагов аа и rd.аа отражает авторитативность ответа, a rd - запрос рекурсии, бит, который был установлен в запросе (DNS сервер просто копирует этот бит в ответное сообщение). В большинстве случаев, когда бит rd установлен в запросе, ответ будет содержать флаг rа, который сообщает нам, что рекурсия на удаленном DNS-сервере была разрешена. Однако сервер a.root-servers.net является корневым DNS-сервером, рекурсия на нем запрещена, как мы показывали в главе 11 «Безопасность», поэтому рекурсивные запросы обрабатыва ются точно так же, как итеративные. Так что сервер игнорирует бит rd и показывает, что рекурсия недоступна, сбрасывая флаг rа.

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

Следующая за QUERY SECTION: строка содержит отправленный за прос: были запрошены NS-записи класса IN для корневой зоны. За строкой ANSWER SECTION: следуют 13 NS-записей для корневых DNS-серверов, а за строкой ADDITIONAL SECTION:

- 13 А-записей, которые соответствуют тем самым 13 корневым DNS-серверам. Если бы ответное сообщение содержало раздел авторитативности, мы бы увидели его содержимое после строки AUTHORITY SECTION:.

В самый конец dig добавляет сводную информацию о запросе и ответном сообщении. Первая строка содержит данные о том, через сколько вре мени после отправки запроса удаленный DNS-сервер вернул ответ. Вто рая строка показывает, с какого узла был отправлен запрос и какому DNS-серверу. Третья строка содержит временную отметку получения ответного сообщения. Четвертая - размеры запроса и ответа в байтах.

Работа с dig dig: передача зоны Как и nslookup, dig может использоваться для передачи зональных данных. Но в отличие от nslookup dig не имеет специальной команды, позволяющей запросить передачу зоны. Чтобы инициировать переда чу зоны следует указать axfr (тип запроса) и доменное имя зоны в ка честве аргументов командной строки. Следует помнить, что получить зону можно только от DNS-сервера, который является для зоны авто ритативным.

Для получения зоны movie.edu от DNS-сервера wormhole.movie.edu сле дует выполнить команду:

472 Глава 12. nslookup и dig Заметим, что, как и в случае с nslookup, SOA-запись присутствует в ре зультате дважды, в начале и в конце данных зоны. Как и все прочие данные, отображаемые в выводе dig, результат передачи зоны пред ставляется в формате мастер-файла, поэтому в случае необходимости этот результат можно использовать для создания файлов данных зоны. Ключи dig Ключей командной строки dig слишком много, чтобы описывать их здесь, поэтому мы ограничимся наиболее важными, а читателей отсы лаем к страницам руководства по dig.

-х адрес Программа nslookup достаточно сообразительна, чтобы опознавать IP-адрес и находить соответствующее доменное имя в in-addr.arpa.

dig ничем не хуже. Если использовать ключ -х, dig предполагает, что аргумент доменного имени в действительности является IP-ад ресом, обращает октеты и добавляет имя in-addr.arpa. Использова ние ключа -х также изменяет тип записей, поиск которых ведется по умолчанию, на ANY, так что произвести обратное отображение для IP-адреса можно командой dig -x 10.0.0.1.

-р порт Посылать запросы через указанный порт, а не через стандартный порт 53.

+norec[urse] Выключить рекурсию (по умолчанию включена).

+vc Посылать TCP-запросы (по умолчанию посылаются UDP-запросы).

Хотя перед этим придется удалить лишнюю SOA-запись.

• Уровни отладки • Включение отладки ^М А ^Ь • Чтение отладочной Н, ^^^ диагностики В ^ ^ ^ ^ • Алгоритм работы DNS-клиента J^m ^^^^r и отрицательное кэширование (BIND 8) • Алгоритм работы DNS-клиента и отрицательное кэширование (BIND 9) • Инструменты Чтение отладочного вывода BIND -Ах, Лилия, - сказала Алиса, глядя на Тигровую Лилию, легонько покачивающуюся на ветру.

- Как жалко, что вы не умеете говорить!

- Говорить-то мы умеем, - ответила Лилия.

- Было бы с кем!

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

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

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

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

Уровни отладки Объем информации, предоставляемой DNS-сервером, зависит от уров ня отладки. Чем ниже уровень отладки, тем меньше объем отладочной информации. Более высокие уровни отладки приводят к получению более подробной информации, но при этом быстрее съедают дисковое 474 Глава 13. Чтение отладочного вывода BIND пространство. Прочитав приличный объем отладочной информации, читатели получат представление о том, какой уровень отладки необхо дим для решения той или иной проблемы. Разумеется, если существу ет возможность воссоздать проблему, можно начать с уровня 1 и уве личивать уровень отладки, пока не будет получено достаточное коли чество информации. Для самой простой проблемы - невозможности получения информации по имени - первого уровня в большинстве слу чаев будет вполне достаточно, так что начинать следует с него.

Информация, доступная на различных уровнях Ниже приводится список уровней отладки для серверов BIND 8 и BIND 9. Отладочная информация обладает свойством кумулятивнос ти: уровень 2 содержит всю отладочную информацию уровня 1. Дан ные делятся на следующие основные классы: запуск, обновление базы данных, обработка запросов и работа с зонами. Мы не рассматриваем обновление внутренней базы данных сервера, поскольку проблемы обычно не связаны с этой областью. Тем не менее, как станет ясно в главе 14 «Разрешение проблем DNS и BIND», проблему может пред ставлять природа данных, которые DNS-сервер добавляет или удаляет из внутренней базы данных.

В BIND 8 и 9 существует 99 уровней отладки, но большая часть посту пающих в log-файл отладочных сообщений содержится в пределах не скольких уровней, которые мы сейчас и рассмотрим.

Уровни отладки BIND Уровень Информация на этом уровне отладки обязательно краткая. DNS серверы могут обрабатывать огромное число запросов, которые мо гут создавать огромный объем отладочной информации. Поскольку на данном уровне отладки сообщения минимизируются в объеме, существует возможность собрать данные за длительный период вре мени. Уровень 1 следует применять для получения основной ин формации по запуску сервера и наблюдения за транзакциями за просов. Некоторые из ошибок, в частности ошибки синтаксиса и ошибки формата пакетов DNS, записываются в log-файл на этом уровне. На этом же уровне отражаются ссылки (referrals).

Уровень Уровень 2 содержит много ценной информации: приводятся IP-ад реса внешних DNS-серверов, которые использовались при поиске, а также их RTT-метрики;

некорректные ответы;

для каждого ответа приводится тип исходного запроса - SYSTEM (sysquery) или USER.

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

Уровень Отладочная информация 3 уровня намного более многословна, по скольку содержит сообщения, связанные с обновлением базы дан ных DNS-сервера. При применении третьего и более высоких уров ней следует позаботиться о наличии достаточного объема свободного дискового пространства. На третьем уровне видны дублирующиеся запросы, генерируемые системные запросы (sysquery), имена уда ленных DNS-серверов, использованных при поиске, и число адре сов, найденных для каждого сервера.

Уровень Уровень 4 следует применять при необходимости отследить пакеты запросов и ответов, получаемые DNS-сервером. На этом уровне так же доступна информация о достоверности кэшированных данных.

Уровень На уровне 5 существует большое число различных сообщений, но они не являются особенно полезными для отладки в целом. Уро вень также содержит некоторые сообщения об ошибках, к примеру, об ошибочном завершении вызова malloc() или прекращении по пыток DNS-сервера обработать запрос.

Уровень Уровень 6 отображает ответы, посылаемые отправителям запросов.

Уровень Уровень 7 содержит несколько сообщений, связанных с настройкой либо с синтаксическим анализом.

Уровень На этом уровне нет значимой отладочной информации.

Уровень На этом уровне нет значимой отладочной информации.

Уровень Уровень 10 следует применять при необходимости отследить паке ты запросов и ответов, посылаемые DNS-сервером. Формат пакетов точно такой же, как и для уровня 4. Этот уровень отладки исполь зуется не слишком часто, поскольку ответы DNS-сервера можно увидеть с помощью программ nsloohup и dig.

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

476 Глава 13. Чтение отладочного вывода BIND Уровни отладки BIND Уровень Уровень 1 отражает основные операции DNS-сервера: загрузку зо ны, служебные операции (запросы SOA-записей, передачу зоны, очистку кэша), NOTIFY-сообщения, полученные запросы и порож денные высокоуровневые задачи (такие как поиск адресов DNS-сер вера).

Уровень Уровень 2 отражает мультакастовые запросы.

Уровень Уровень 3 отображает информацию о создании и выполнении задач и операций низкого уровня. К сожалению, большинство этих задач имеют не очень прозрачные имена (что вам говорит requestmgr_de tach?), а их аргументы и вовсе совершенно загадочны. Уровень также содержит сообщения, связанные с процессом ведения log файла зоны;

к примеру, сообщение поступает всякий раз, когда DNS-сервер вносит запись изменения зоны в log-файл зоны либо когда log-файл применяется к зоне при запуске. Работа валидатора DNSSEC и проверка TSIG-подписей также отражаются на третьем уровне.

Уровень Уровень 4 регистрирует переход DNS-сервера к использованию AXFR в случае, если журнал полученной зоны недоступен.

Уровень Уровень 5 содержит информацию о видах, использованных при от вете на запрос.

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

Уровень На этом уровне содержится лишь пара дополнительных сообщений (обновление и удаление записей из журнала зоны, счетчик числа байтов, полученных при передаче зоны).

Уровень Многие из сообщений, связанных с динамическим обновлением, от ражаются на уровне 8: проверка предварительных требований, за пись в журнал зоны и откаты. Помимо этого, уровень содержит не сколько сообщений низкого уровня, связанных с передачей зоны, в частности регистрацию RR-записей, которые были отправлены при передаче зоны.

Включение отладки Уровень Уровень 10 содержит несколько сообщений, связанных с активнос тью таймера зоны.

Уровень Уровень 20 отражает установку таймера обновления зоны.

Уровень На этом уровне представлены операции низкого уровня диспетчера задач BIND 9.

В BIND 8 и 9 существует возможность настроить DNS-сервер таким об разом, чтобы отладочные сообщения содержали информацию об уров не отладки. Достаточно установить параметр print-severity (см. раздел «Ведение log-файла в BIND 8 и 9» в главе 7 «Работа с BIND»).

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

Информацию можно изучать, чтобы понять, почему DNS-сервер рабо тает не так, как предполагалось, либо просто узнать, как работает DNS-сервер;

но не следует ожидать красиво оформленного и хорошо продуманного вывода.

Включение отладки Отладку в DNS-сервере можно включить при запуске из командной строки либо посылкой управляющих сообщений. Если для диагности рования проблемы необходимо иметь перед глазами информацию, вы даваемую при запуске сервера, нужно указать ключ командной стро ки. В случае необходимости включить или отключить отладку при уже работающем сервере надо воспользоваться управляющими сооб щениями. DNS-сервер записывает отладочный вывод в файл па med.run. DNS-серверы BIND 4 создают named.run в каталоге /usr/tmp (либо /var/tmp), a DNS-серверы BIND 8 и 9 - в рабочем каталоге DNS сервера.

Ключи командной строки При разрешении проблем иногда бывает необходимо видеть значение sortlist, знать, с каким интерфейсом связан файловый дескриптор, ли бо выяснить, в какой момент на стадии инициализации DNS-сервер завершил работу (в случае, если сообщение об ошибке, записанное де моном syslog, было недостаточно прозрачным). Чтобы получить отла дочную информацию такого рода, необходимо запустить сервер в ре жиме отладки со специальным ключом командной строки;

потому что ко времени посылки управляющего сообщения уже будет слишком поздно. Ключ командной строки, включающий отладку, выглядит 478 Глава 13. Чтение отладочного вывода BIND так:

-d уровень. DNS-сервер BIND 4 при использовании этого ключа командной строки не переходит в фоновый режим работы, как обыч но;

чтобы добиться этого, необходимо добавить символ & в конец ко мандной строки. Следующая командная строка запускает DNS-сервер BIND 4 с уровнем отладки 1:

DNS-серверы BIND 8 и 9 переходят в фоновый режим работы даже при использовании -d, и для них символ & можно не включать в команду.

Изменение уровня отладки с помощью управляющих сообщений Если нет необходимости изучать инициализацию DNS-сервера, следу ет запустить сервер без соответствующего ключа командной строки.

Позже отладку можно включить или выключить, используя ndc для отправления соответствующих управляющих сообщений процессу DNS-сервера. Следующие две команды устанавливают уровень отлад ки 3, а затем выключают отладку:

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

В программе rndc из пакета BIND 9.1.0 команды trace и notrace пока не реализованы (их нет и в демоне named версии 9.1.0), но будут при сутствовать в будущих версиях. Таким образом, при работе с BIND следует использовать ключ командной строки -d.

Чтение отладочной диагностики Мы рассмотрим пять примеров отладочной диагностики. В первом по казан запуск DNS-сервера. Следующие два примера связаны с успеш ным поиском адресов. Четвертый пример - для вторичного DNS-серве ра, синхронизирующего хранимую зону. Последний пример относится не к поведению DNS-сервера, но к поведению DNS-клиента, и речь пойдет об алгоритме поиска. В каждом случае (кроме последнего) DNS-сервер запускался заново, практически полностью очищая кэш.

Читатели, возможно, спросят, почему мы решили отразить во всех примерах нормальное поведение сервера - ведь глава посвящена от ладке. Дело в том, что необходимо знать, как выглядит нормальная работа, прежде чем начинать охоту за ошибками. Вторая причина мы стараемся более глубоко объяснить понятия, использованные в пре дыдущих главах (повторные запросы, время передачи сигнала и т. д.).

Чтение отладочной диагностики Запуск DNS-сервера (BIND 8, уровень отладки 1) Мы начнем изучение примеров отладочного вывода с фрагмента ини циализации DNS-сервера. Первым DNS-сервером будет BIND 8. Был использован ключ командной строки -d 1, и вот вывод, полученный в файле named.run:

480 Глава 13. Чтение отладочного вывода BIND Мы добавили к отладочному выводу номера строк, естественно, в обычной ситуации вы их не увидите. Строки со второй по шестую отра жают используемую версию BIND и имя файла настройки. Версия 8.2.3-Т 7В была выпущена консорциумом ISC (Internet Software Con sortium) в августе 2000 года. Для данного случая мы использовали файл настройки, расположенный в текущем каталоге./named.conf.

Строки с 7 по 23 отражают чтение файла настройки и файлов данных зоны сервером BIND. Данный DNS-сервер является только кэширую щим, соответственно, читаются файлы db.127.0.0 (строки с 9 по 16) и db.cache (строки 17-23). Строка 9 информирует нас об обновлении зо ны (0.0.127.IN-ADDRARPA), а строка 10 - о файлах, содержащих дан ные для зоны (db.127.0.0). Строка 11 говорит о том, что любые старые данные удаляются перед загрузкой новых. Строка 12 уведомляет о пе резагрузке зоны, которая производится, несмотря на то обстоятельство, что зона в действительности загружается впервые. Загрузка данных от ражена в строках с 13 по 15. В строках 16 и 23 z_time - это время про верки актуальности данных зоны, z_refresh - время обновления зоны.

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

Строки с 25 по 39 отражают процесс инициализации файловых де скрипторов. (В данном случае речь идет на самом деле о дескрипторах сокетов.) Файловые дескрипторы 20 и 21 (строки 27-29) связываются с адресом loopback-интерфейса, 127.0.0.1. Дескриптор 20 - сокет дейтаграмм, а дескриптор 21 - потоковый. Файловые дескрипторы и 23 (строки 32-34) связываются с интерфейсом 192.249.249.3. Адрес каждого интерфейса был исследован и использован;

адрес не исполь зуется, если он уже присутствует в списке либо если интерфейс не был инициализирован. Файловый дескриптор 5 (строки 36-39) связывает ся с адресом по маске, 0.0.0.0. Большинство сетевых демонов исполь зуют только один сокет - связанный с этим адресом, а не сокеты, свя занные с конкретными интерфейсами. Адрес по маске принимает па кеты, посылаемые любому из интерфейсов узла. Мы сделаем неболь шое отступление и объясним, по какой причине named использует одновременно сокет, связанный с адресом маски, и сокеты, связанные с конкретными интерфейсами.

Когда named получает запрос от приложения, либо от другого DNS сервера, запрос поступает через один из сокетов, связанных с конкрет ными интерфейсами. Если бы named не имел сокетов, связанных с конкретными интерфейсами, то получал бы запросы через сокет, свя занный с адресом маски. Когда named посылает ответ, то использует Чтение отладочной диагностики тот же дескриптор сокета, через который был получен запрос. Почему named поступает именно так? Когда ответы посылаются через сокет, связанный с адресом маски, ядро подставляет в качестве адреса отпра вителя адрес интерфейса, через который в действительности отправ ляется ответ. Этот адрес может совпадать или не совпадать с адресом, которому был направлен исходный запрос. Когда ответы посылаются через сокет, связанный с конкретным адресом, ядро подставляет в ка честве адреса отправителя этот самый конкретный адрес - тот же ад рес, которому был направлен исходный запрос. Если DNS-сервер полу чает ответ с IP-адреса, о котором ему ничего не известно, этот ответ по лучает статус «пришельца» и игнорируется, named старается избежать создания ответов-пришельцев, отправляя ответы через дескрипторы, связанные с конкретными интерфейсами, чтобы адрес отправителя совпадал с адресом получателя исходного запроса. Однако при посыл ке запросов named использует дескриптор маски, поскольку нет необ ходимости использовать конкретный IP-адрес.

Строки с 43 по 47 отражают посылку DNS-сервером системного запроса с целью выяснения, какие DNS-серверы в настоящий момент обслужи вают корневую зону. Это действие известно как «первичное заполне ние кэша». Первый же DNS-сервер возвращает ответ, содержащий ин формацию о 13 DNS-серверах.

Итак, DNS-сервер инициализирован и готов выполнять запросы.

Запуск DNS-сервера (BIND 9, уровень отладки 1) Отладочный вывод, полученный при запуске DNS-сервера BIND 9:

Читатели, вероятно, уже отметили основное различие между фрагмен тами отладочного вывода BIND версий 8 и 9. Диагностика BIND весьма лаконична. Дело в том, что BIND 8 существует уже около трех 482 Глава 13. Чтение отладочного вывода BIND лет, так что у авторов была масса времени, чтобы добавить к коду отла дочные сообщения. BIND 9 только что сошел с конвейера, так что его набор сообщений пока еще не очень велик.

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

Строки 1 и 2 содержат информацию об используемой версии BIND (9.1.0) и имя файла настройки. Как и в предыдущем примере, это файл named.conf, расположенный в текущем каталоге. В строке 3 со держится информация о том, что используется один процессор, чего и следовало ожидать на машине с одним процессором.

Строка четыре содержит простое предупреждение об изменении стан дартного значения предписания auth-nxdomain (которое рассматрива ется в главе 10 «Дополнительные возможности»). Строка 5 напомина ет, что на нашем узле отсутствуют сетевые интерфейсы IP версии 6;

в противном случае BIND 9 мог бы принимать запросы через эти интер фейсы.

Строки 6 и 7 отражают тот факт, что сервер ожидает поступления за просов через два сетевых интерфейса: 1о, loopback-интерфейс, и eth0, Ethernet-интерфейс. BIND 9 отображает адрес и порт в формате ад рес#порт, тогда как в BIND 8 используется формат [адрес].порт.

Строка 8 сообщает, что named принимает управляющие сообщения, поступающие через стандартный порт 953.

Строки 10-12 отражают загрузку сервером зоны 0.0.12 7.in-addr.arpa.

Смысл сообщений start (запуск) и loaded (загрузка завершена) очеви ден. Сообщение по journal отражает отсутствие журнала. (Журнал, описанный в главе 10, представляет собой запись динамических об новлений, полученных сервером для зоны.) Наконец, строки 13 и 14 отражают выполнение сервером служебных операций для зон 0.0.127.in-addr.arpa и version.bind. (version.bind — это встроенная CHAOSNET-зона, которая содержит единственную ТХТ запись, связанную с доменным именем version.bind.) Выполнение слу жебных операций для зоны - это процесс, который планирует выпол нение регулярных задач, таких как запросы SOA-записей для вторич ного сервера и зон-заглушек, или отправка NOTIFY-сообщений.

Успешный поиск (BIND 8, уровень отладки 1) Предположим, существует необходимость отследить процесс поиска сервером данных для доменного имени. Сервер был запущен без при менения соответствующего ключа командной строки. Вызовем ndc, чтобы включить отладку, выполним операцию для конкретного име ни, и затем выключим отладку, следующим образом:

Чтение отладочной диагностики Вот полученный в результате файл named.run:

484 Глава 13. Чтение отладочного вывода BIND Во-первых, обратите внимание, что в диагностике присутствуют IP-ад реса, а не доменные имена, что довольно странно для DNS-сервера. В действительности в этом нет ничего особенно странного. Если мы пы таемся решить проблему, связанную с поиском адреса по имени, то следует ограничить поиск по именам, потому что дополнительные опе рации делают диагностику менее удобной для чтения и затрудняют от ладку. Ни один из уровней отладки не предусматривает преобразова ние IP-адресов в доменные имена. Поэтому придется воспользоваться инструментом, который сделает это. Такой инструмент мы представим читателям позже.

Разберем отладочную диагностику построчно. Столь подробное рас смотрение необходимо, если мы хотим понять, что означает каждая из строк. Если включается отладка, то речь, как правило, идет о том, что бы выяснить, почему не происходит разрешение для некоторых имен;

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

Дейтаграмма поступила от узла с IP-адресом 192.249.249.3 (termina tor. movie.edu). Дейтаграмма может поступить с адреса 127.0.0.1 в слу чае, если отправитель пользуется тем же узлом, на котором работает DNS-сервер. Приложение, отправившее дейтаграмму, использовало порт 1162. DNS-сервер получил дейтаграмму через файловый дескрип тор (fd) 20. Диагностика запуска DNS-сервера, пример которой мы при водили ранее, позволяет определить, с каким интерфейсом связан фай ловый дескриптор 20. Длина (len) дейтаграммы составила 36 байтов.

Поскольку следующая строка начинается с подстроки req, становится ясно, что дейтаграмма являлась запросом. Имя, о котором шла речь в запросе, - galt.cs.purdue.edu. Идентификатор запроса - 29574. Подстро ка type=1 означает, что речь в запросе идет об адресной информации.

Подстрока class=1 - класс IN. Полный перечень типов запросов и клас сов содержится в заголовочном файле /usr/include/arpa/nameser.h.

DNS-сервер произвел поиск указанного имени и не нашел адреса. За тем была сделана безуспешная попытка найти внешний DNS-cepBep> которому имело бы смысл послать запрос;

и так вплоть до корневой зо ны (пустая строка в кавычках). Подстрока спате=0 означает, что DNS-сервер не нашел CNAME-записей. Если найдена CNAME-запись, производится поиск по каноническому имени вместо исходного, а спа те получает ненулевое значение.

Чтение отладочной диагностики Запрос был передан (через порт 53) DNS-серверу на узле 198.41.0. (j.root-servers.net). Для отправки запроса DNS-сервер воспользовался дескриптором 4 (который связан с адресом маски). DNS-сервер при своил запросу идентификационный номер 40070 (nsid=40070), чтобы впоследствии идентифицировать ответ на этот запрос. Приложение присвоило запросу идентификационный номер 29574 (id=29574), как можно видеть из строки nlookup. DNS-сервер ожидает ответа в течение четырех секунд перед отправкой запроса следующему DNS-серверу.

Ответил DNS-сервер узла j.root-servers.net. Поскольку ответ представ ляет собой делегирование, он полностью отображается в отладочной диагностике.

После того как информация, полученная в ответе, кэширована, поиск по имени повторяется. Как мы уже сказали, подстрока qtype=1 озна чает, что поступил запрос адресной информации.

Корневой сервер ответил перенаправлением к серверам зоны edu. Тот же запрос отправляется адресу 192.36.148.17 (Lroot-servers.net), кото рый соответствует одному из серверов edu. Lroot-servers.net возвраща ет информацию о серверах зоны purdue.edu.

На этот раз присутствует информация уровня имени cs.purdue.edu.

DNS-серверу по адресу 128.46.199.76 (harbor.ecn.purdue.edu) был от правлен запрос. Идентификатор запроса, присвоенный сервером, 40072.

DNS-сервер harbor.ecn.purdue.edu ответил. Чтобы идентифицировать содержимое ответа, следует посмотреть на последующие события.

Последний ответ, вероятнее всего, содержал запрошенный адрес, по скольку DNS-сервер ответил приложению (которое использовало при запросе порт 1162, что можно увидеть в строке диагностики исходного запроса). Ответ был отправлен в виде UDP-пакета (а не через ТСР-со единение) через файловый дескриптор 20.

486 Глава 13. Чтение отладочного вывода BIND DNS-сервер не был нагружен в момент создания вышеприведенного фрагмента;

он не обрабатывал параллельно другие запросы. При со здании log-файла диагностики на активном DNS-сервере дела обстоят не столь радужно. Придется прочесывать отладочный вывод в поисках частей, относящихся к поиску по имени, о котором идет речь. Но это не особенно трудно. Запустите свой любимый текстовый редактор, найдите строку nlookup, в которой идет речь об исходном имени. После этого останется лишь выбрать строки с таким же nsid-идентификато ром. В следующем фрагменте диагностики для BIND 8 мы покажем, как отследить nsid-идентификаторы.

Успешный поиск (BIND 9, уровень отладки 1) Ниже приводится отладочная диагностика для поиска по тому же до менному имени при использовании DNS-сервера BIND 9 на уровне от ладки 1, но она до смешного краткая. Тем не менее, как мы уже гово рили, очень важно знать, как выглядит диагностика при правильной работе. Итак:

Первая строка сообщает нам, что клиент с IP-адреса 192.249.249.3 (то есть локальный узел), работающий через порт 1090, отправил нам за прос адреса для имени galt.cs.purdue.edu. Авторство второй строки принадлежит той части DNS-сервера, которая занимается разрешени ем имен;

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

Успешный поиск с повторными запросами (BIND 8, уровень отладки 1) Не всякий поиск проходит так же «гладко», как последний - иногда для выполнения запроса требуются повторные запросы. В случае ус пешного окончания поиска для пользователя нет никакой разницы, хотя запросы, выполняемые с необходимостью выполнять повторные запросы, выполняются дольше. Ниже приводится фрагмент отладоч ного вывода, который содержит информацию о повторных запросах.

После получения этого фрагмента мы преобразовали IP-адреса в име на. Обратите внимание, насколько проще читать вывод с именами!

Чтение отладочной диагностики Этот фрагмент начинается точно так же, как предыдущий (строки с по 11): DNS-сервер получает запрос для имени ucunix.san.uc.edu, посы лает запрос DNS-серверу edu (i.root-servers.net), получает ответ, содер жащий перечень DNS-серверов для uc.edu, и посылает запрос одному из них (uceng.uc.edu).

Новыми в этом фрагменте являются строки resend (строки 12, 17 и 18).

Forw в строке 11 считается в качестве resend(addr=O n=0) - мы, ком пьютерные незнайки, всегда начинаем считать с нуля. Поскольку сервер uceng.uc.edu не ответил, DNS-сервер отправил запрос на ucbeh.san.uc.edu (строка 12), uccba.uc.edu (строка 17) и mail.cis.ohiostate.edu (строка 18).

Наконец, отозвался внешний DNS-сервер mail.cis.ohio state.edu (стро ка 20). Обратите внимание, что все повторные запросы можно найти поиском по подстроке nsid=3;

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

Также интересно обратить внимание на вторую дейтаграмму, получен ную от узла terminator.movie.edu (строка 14). Порт, дескриптор файла, длина, идентификатор и тип запроса полностью идентичны тем, что можно видеть в запросе в строке 3. Приложение не получило ответ во время, поэтому оно повторило исходный запрос. Поскольку DNS-сервер все еще обрабатывает первый из полученных запросов, второй запрос является дублирующим. DNS-сервер определил дублирующийся запрос и проигнорировал его, хотя это не отображено в выводе. Мы же знаем это наверняка, поскольку отсутствует строка forw: после строк req:, в отличие от того, что можно видеть на строках с четвертой по шестую.

Попробуйте угадать, как будет выглядеть этот фрагмент, если DNS сервер будет испытывать сложности с поиском адресов? Многочислен ные повторные запросы, свидетельствующие о попытках DNS-сервера найти адрес (эти строки можно найти поиском подстроки nsid=). При ложение отправит несколько дополнительных запросов, полагая, что предыдущие не были получены DNS-сервером. В конце концов DNS сервер прекратит поиск, и скорее всего, это произойдет уже после того, как собственно приложение потеряет надежду получить ответ.

488 Глава 13. Чтение отладочного вывода BIND Если речь идет о DNS-сервере BIND 9.1.0, повторно отправляемые за просы не отображаются на уровнях отладки ниже третьего, а на треть ем уровне их довольно нелегко различить в лавине прочих отладочных сообщений BIND 9. Ко всему, даже на уровне отладки 3 BIND 9.1.0 не упоминает о том, каким именно DNS-серверам отправляются повтор ные запросы.

Вторичный DNS-сервер производит проверку зоны (BIND 8, уровень отладки 1) Помимо проблем, связанных с поиском адресов, могут встречаться проблемы загрузки зоны вторичным DNS-сервером. Источник этой проблемы можно зачастую определить просто сравнением порядковых номеров в SOA-записи зоны на двух серверах, основном и дополни тельном, посредством использования nslookup или dig, что мы и проде монстрируем в главе 14. Если рассматриваемая проблема не поддается решению таким методом, можно прибегнуть к поиску причин в отла дочной информации. Мы покажем, как должна выглядеть отладочная информация при нормальной работе сервера.

Приводимый ниже фрагмент отладочного вывода был получен на «спокойном» DNS-сервере - не получающем никаких запросов - что бы было ясно видно, какие строки относятся к выполнению служеб ных операций для зоны. Вспомним, что дополнительные DNS-серверы BIND 4 и 8 используют порождаемые процессы для передачи зональ ных данных на локальный диск перед чтением этих данных. Вторич ный DNS-сервер записывает отладочную информацию в файл па med.run, а порожденный процесс записывает свою в файл xfer.ddt.PID.

Суффикс PID - по умолчанию идентификатор порожденного процесса, может быть изменен в целях обеспечения уникальности имени. Будьте бдительны - включение отладки на дополнительном DNS-сервере при ведет к появлению многочисленных файлов с именами xfer.ddt.PID, даже если речь идет всего лишь о том, чтобы отследить выполнение запроса адреса. Мы проводим эксперимент на уровень отладки 1, со включенным параметром log-файлирования print-time (BIND 8). Уро вень отладки 3 для случаев, когда передача зоны происходит, как пра вило, содержит больше информации, чем необходимо. Передача зоны размером в несколько сотен RR-записей может привести к созданию файла xfer.ddt.PID размером в несколько мегабайт.

Чтение отладочной диагностики В отличие от предыдущих фрагментов, этот содержит указатели вре мени в каждой строке. Датирование позволяет ясно увидеть группи ровку отладочных операторов.

Этот DNS-сервер является вторичным для единственной зоны, то vie.edu. Строка, датированная временем 00:13:18.026, показывает, что наступил момент синхронизации с основным сервером. Вторичный сервер запрашивает SOA-запись зоны и сравнивает порядковые номе ра перед принятием решения о загрузке зоны. Строки начиная с дати рованной 00:13:18.059 по 00:13:18.131 содержат порядковый номер зоны (26739), информацию о том, что хранимая зоны устарела, и ин формацию о запуске порожденного процесса (pid 390) для передачи зо ны. В момент 00:13:18.132 таймеру присваивается значение в 7200 се кунд. Это время, за которое должна завершиться передача зоны. В мо мент 00:14:02.089 мы видим код завершения порожденного процесса.

Код завершения 1 говорит о том, что данные зоны были успешно полу чены. Старые данные зоны удаляются (time 00:14:02.094), а новые за гружаются.

490 Глава 13. Чтение отладочного вывода BIND Следующая проверка (время 00:14:30.058) намечена через 1846 се кунд. Для данной зоны интервал обновления составляет 3600 секунд, так почему же сервер наметил проверку через 1846? DNS-сервер пыта ется избежать синхронизации таймера обновления. Вместо того чтобы использовать интервал, равный в точности 3600 секундам, он исполь зует случайно выбранное значение, большее половины интервала об новления (1800), но меньшее полного интервала (3600). В 00:45:16.046 происходит повторная проверка зоны, и на этот раз об новление не требуется.

Если взять фрагмент отладочного вывода за достаточно большой про межуток времени, можно увидеть много строк, похожих на строку 00:42:44.817, - по одной на каждый час. А происходит вот что: сервер перебирает кэшированную информацию, удаляя устаревшие данные, чтобы сократить объем занимаемой памяти.

Основной DNS-сервер данной зоны - сервер BIND версии 4. Если бы основной сервер принадлежал пакету BIND версии 8, вторичный сер вер получал бы уведомление при каждом изменении зоны, не дожида ясь окончания интервала обновления. Отладочный вывод вторичного сервера в этом случае выглядел бы практически так же, за исключени ем того, что сигналом к обновлению зоны было бы сообщение NOTIFY:

Вторичный DNS-сервер производит проверку зоны (BIND 9, уровень отладки 1) Эквивалентный отладочный вывод DNS-сервера BIND 9.1.0 на уровне 1, как всегда, более лаконичен. Выглядит он так:

Алгоритм работы DNS-клиента и отрицательное кэширование (BIND 8) Сообщение, датированное 15:05:00.059, показывает срабатывание тай мера обновления, что приводит к выполнению DNS-сервером служеб ных действий для зоны (в следующей строке). Во-первых, DNS-сервер ставит в очередь запрос SOA-записи для зоны класса IN - movie.edu (queue_soa_query для того же времени) и посылает его. В 15:05:00. сервер обнаруживает, что зона основного DNS-сервера имеет больший порядковый номер, чем хранимая (2000010923 и 2000010922), и вы полняет входящую передачу зоны {queue_xfrin). Через восемь миллисе кунд (15:05:00.070) передача зоны закончена, а в момент 15:05:01. DNS-сервер обнуляет таймер обновления (zone_timer).

Следующие три строки показывают выполнение сервером служебных операций для movie.edu. К примеру, если бы некоторые DNS-серверы movie.edu были расположены вне зоны movie.edu, DNS-сервер восполь зовался бы этим моментом для поиска их адресов (не только А-, но так же А6- и АААА-записей!), чтобы позже включать их в ответы. В по следних двух строках мы видим отправку DNS-сервером NOTIFY-co общений - двух, если-быть точными, - DNS-серверам, перечисленным в NS-записях movie.edu.

Алгоритм работы DNS-клиента и отрицательное кэширование (BIND 8) С помощью приводимых записей мы покажем, что такое алгоритм по иска и отрицательное кэширование клиента BIND версии 4.9 и более поздних с точки зрения DNS-сервера BIND 8. Мы могли бы выполнить поиск адреса для galt.cs.purdue.edu, как в предыдущем случае, но это не позволило бы нам оценить алгоритм поиска. Поэтому мы выполним запрос для несуществующего имени foo.bar. Причем дважды:

492 Глава 13. Чтение отладочного вывода BIND И еще раз поиск адреса foo.bar:

Давайте взглянем на клиент и его алгоритм поиска. Первое имя, для которого производится поиск адреса (строка 2), в точности совпадает с тем именем, которое мы набрали. Поскольку имя содержало по мень шей мере одну точку, поиск для него был выполнен без предваритель ных модификаций. Этот поиск вернул отрицательный результат, к имени был добавлен домен horror.movie.edu, и поиск повторился. (Кли енты BIND версий до 4.9 попытались бы добавить одновременно hor ror.movie.edu и movie.edu.) В седьмой строке отображено кэширование отрицательного ответа (ncache). Если то же имя используется в поиске в ближайшие несколь ко минут (строка 19), сервер может дать немедленный ответ, что имя не существует, поскольку этот отрицательный ответ все еще хранится в кэше. (Если слова не убеждают, сравните строки 3 и 19. Строка 3: ни чего не найдено по имени foo.bar, а в строке 19 это имя неожиданно на ходится.) Алгоритм работы DNS-клиента и отрицательное кэширование (BIND 9) Вот так выглядит отладочный вывод DNS-сервера BIND 9.1.0 при дважды повторенном поиске для foo.bar:

Эта диагностика намного более краткая, чем в BIND 8, но в ней содер жится необходимая информация. Первая строка, датированная 15:45:42.944, показывает первый запрос адреса foo.bar, поступивший от клиента cujo.horror.movie.edu (помните, что мы пропустили вывод через наш волшебный фильтр, преобразующий IP-адреса в имена, речь о котором пойдет ниже). Следующие две строки показывают, что Инструменты DNS-сервер выполнил две задачи (createfetch) для поиска адреса foo.bar: во-первых, собственно задачу поиска адреса для имени foo.bar, а во-вторых - вспомогательную задачу поиска NS-записи для корне вой зоны, которая необходима для завершения поиска по имени foo.bar. Получив текущую NS-запись для корневой зоны, DNS-сервер запрашивает у корневого DNS-сервера адрес для имени foo.bar и полу чает ответ, что домен высшего уровня с именем bar не существует. Но мы, к сожалению, этого не видим.

Строка, датированная 15:45:43.425, показывает использование спис ка поиска узлом cujo.horror.movie.edu и поиск имени foo.bar.horror.mo vie.edu. DNS-сервер порождает задачу (createfetch) поиска адреса этого доменного имени.

При повторном поиске foo.bar мы видим следующее:

Все заметили отсутствие строк createfetch? Наш DNS-сервер кэширует отрицательные ответы.

Инструменты Подведем итоги. Мы рассказывали о программе, преобразующей IP адреса в имена с целью облегчения чтения отладочного вывода. Вот эта программа на языке Perl:

Не рекомендуется передавать вывод named.run этому сценарию через конвейер при включенной отладке, поскольку сценарий выполняет собственные запросы к DNS-серверу.

• Виновата ли служба NIS?

• Инструменты и методы • Перечень возможных проблем • Проблемы перехода на новую версию • Проблемы сосуществования и версий • Ошибки TSIG • Симптомы проблем Разрешение проблем DNS и BIND - Конечно! Ведь без него будет очень скучно жить на свете! - сказал Деликатес.

- У тебя есть свой конек?

- Нет, у меня есть кошка, - сказала Алиса.

- Ее зовут...

- Прекрасно! - обрадовался Грифон.

-Давно пора тебе рассказать нам о себе и о своих приключениях!

В последних двух главах мы рассказали о применениях инструментов nslookup и dig, а также о том, как интерпретировать отладочную ин формацию, предоставляемую DNS-сервером. В этой главе мы пока жем, как применять эти программы совместно с традиционными сете выми инструментами Unix, в частности верным старым ping, для диаг ностирования и разрешения встречающихся на практике проблем DNS и BIND.

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

Виновата ли служба NIS? Виновата ли служба NIS?

Прежде чем начать обсуждение даигностики и разрешения конкрет ных проблем DNS и BIND, мы должны удостовериться, что читатели понимают, как отличить проблему, связанную с NIS, от проблемы, связанной с DNS. На узлах с работающей службой NIS может быть не просто понять, какая из служб является источником проблем. К при меру, классический BSD-nslookup не обращает внимания на NIS. Мож но работать с программой nslookup на системе Sun, бесконечно посы лая запросы DNS-серверам, а все прочие службы при этом будут ис пользовать NIS.

Как узнать, кто виноват? Некоторые поставщики изменяют nslookup на предмет использования NIS в качестве службы имен, если сущест вует настроенная NIS. Так, nslookup HP-UX сообщает, что намеревает ся посылать запросы серверу NIS - при запуске:

На узлах с обычной версией nslookup чаще всего можно использовать команду ypmatch, чтобы понять, что используется - DNS или NIS. ур match печатает пустую строку после информации об узле, полученной от DNS-сервера. В следующем примере ответ получен от NIS:

А в этом - от DNS-сервера:

Следует помнить, что это работает в SunOS 4.1.1, но может не работать в любой из более поздних версий SunOS. Насколько нам известно, это просто ошибка/особенность, которая может исчезнуть в следующей же версии.

Наиболее правильный способ понять, что ответ получен от NIS, - ис пользовать команду ypcat для просмотра содержимого базы данных hosts. К примеру, чтобы узнать, содержится ли узел andrew.cmu.edu в карте узлов NIS, можно воспользоваться командой:

Если ответ найден в NIS (и известно, что эта служба запрашивается первой), то найдена и причина проблемы.

496 Глава 14. Разрешение проблем DNS и BIND И наконец, в системах Unix, использующих файл nsswitch.conf, мож но узнать порядок опроса служб, найдя в этом файле запись для базы данных hosts. Следующая строка показывает, что в первую очередь за прашивается служба NIS:

а эта - что клиент прежде всего посылает запрос службе доменных имен:

Более подробная информация по синтаксису и семантике файла nss witch.conf содержится в главе 6 «Конфигурирование узлов».

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

Инструменты и методы В последних двух главах мы изучали nslookup, dig и отладочный вы вод DNS-сервера. Прежде чем продолжить, возьмем на вооружение не сколько новых инструментов, которые могут быть полезны при отлад ке: named-xfer, дампы базы данных и регистрация запросов.

Как применять named-xfer named-xfer - программа, вызываемая DNS-серверами BIND 4 и 8 для выполнения передачи зоны. (Как, вероятно, помнят читатели, DNS-cep веры BIND 9 - многопотоковые, им не нужна отдельная программа для получения зон: они просто выполняют эту операцию в паралелльном потоке.) named-xfer проверяет, является ли актуальной копия зональ ных данных, хранимая вторичным сервером, и при необходимости производит передачу зоны. (В версиях 4.9 и 8 named самостоятельно проверяет актуальность данных, чтобы избежать порождения ненуж ного процесса.) В главе 13 «Чтение отладочного вывода BIND» мы приводили отладоч ный вывод вторичного DNS-сервера BIND 8, созданный при проверке хранимой зоны. При получении зоны вторичный сервер создал порож денный процесс (named-xfer) для копирования данных в локальную файловую систему. Мы умолчали о том, что named-xfer можно запус кать и вручную, не дожидаясь, когда это сделает named, и что можно предписать этой программе создание собственной отладочной диагнос тики (без вовлечения named).

Это может быть полезно, если речь идет о проблеме, связанной с пере дачей зоны, но нет времени ждать, когда сервер named сам ее иниции i Инструменты и методы рует. Чтобы вручную изучить процесс передачи зоны, следует указать ряд ключей командной строки:

Это вывод named-xfer из пакета BIND 8.2.3. В более ранних версиях named-xfer набор ключей меньше.

named при вызове named-xfer использует ключ -г (для указания зоны, для которой следует производить проверку), ключ -f (для указания имени файла данных этой зоны, приводимого в named.boot или па med.conf), ключ -s (для указания порядкового номера зоны из храни мой вторичным сервером SOA-записи), а также перечисляет адреса серверов, с которыми предписано сверяться вторичному серверу (IP адреса предписания masters в операторе zone в файле named.conf либо инструкции secondary в named.boot). Если named работает в режиме отладки, используется также ключ -d для указания уровня отладки для named-xfer. Все остальные ключи предназначены для диагности ки проблем, они связаны с инкрементальной передачей зоны, TSIG подписями и другими подобными вещами.

При запуске named-xfer пользователем уровень отладки также может быть задан ключом командной строки -d. (Но следует помнить, что уровни отладки выше третьего приводят к получению огромного объ ема отладочной информации при успешной передаче зоны!) Альтерна тивное имя для файла отладочного вывода можно указать с помощью ключа -l. По умолчанию запись сообщений происходит в файл /var /tmp/xfer.ddt.XXXXXX, где ХХХХХХ - суффикс, добавляемый в це лях обеспечения уникальности имени файла, либо файл с тем же име нем в /usr/tmp. Можно также указать имя узла, к которому происхо дит обращение, вместо его IP-адреса.

К примеру, следующая командная строка позволяет понять, происхо дит ли передача зоны с узла terminator.movie.edu:

498 Глава 14. Разрешение проблем DNS и BIND В данной команде был использован нулевой порядковый номер (serial), чтобы гарантировать попытку передачи зоны named-xfer, даже если обновление не требуется. Нуль - это специальный порядковый номер, при указании которого named-xfer произведет передачу зоны, не обра щая внимания на реально существующий порядковый номер. Кроме того, мы предписали named-xfer помещать новые файлы данных зоны в каталог /tmp, не перезаписывая хранимые копии.

Успешно ли прошла передача? Это можно определить по коду, возвра щаемому программой named-xfer. В BIND версии 8.1.2 или более ран ней код завершения может принимать следующие значения:

0 Данные зоны соответствуют хранимым на основном сервере, пере дача не требуется.

1 Зона успешно получена.

2 Узел (или узлы), которым программа named-xfer отправила запро сы, недоступны, либо произошла ошибка, возможно, соответствую щее сообщение записано в log-файл syslog.

3 Произошла ошибка, соответствующее сообщение записано в log файл syslog.

В BIND 8.2 были добавлены новые значения для инкрементальной пе редачи зоны:

4 Успешная AXFR-передача (полная) зоны.

5 Успешная IXFR-передача (инкрементальная) зоны.

6 Основной DNS-сервер вернул AXFR named-xfer на запрос IXFR.

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

Обратите внимание, что в BIND версии 8.2 и более поздних named-xfer никогда не возвращает значение 1. Оно было заменено значениями с по 6.

Как обойтись без named-xfer?

Если было произведено обновление до BIND 9 и исполняемый файл na med-xfer отсутствует, можно по-прежнему использовать nsloohup или dig для получения зоны. Любой из инструментов, умеющих делать зап' росы, позволяет получить ту же информацию, что и named-xfer.

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

Инструменты и методы В nslookup можно изменить используемый DNS-сервер и выполнить команду ls -d в диалоговом режиме.

К сожалению, и dig, и nslookup не столь изящны в сообщениях об ошибках, как named-xfer. Если nslookup не может получить зону, то обычно рапортует о «неопределенной ошибке»:

Ошибка может быть вызвана списком доступа allow-transfer, тем фак том, что terminator.movie.edu в действительности не является автори тативным для movie.edu и целым рядом других проблем. Чтобы понять причину ошибки, можно выполнить дополнительные запросы либо свериться с сообщениями DNS-мастер-сервера, доступными в log-фай ле демона syslog.

Читаем дамп базы данных Пристальное изучения дампа внутренней базы данных DNS-сервера, включающей кэшированную информацию, также может быть полезно при поиске ошибок. Команды ndc dumpdb и rndc dumpdb приводят к созданию сервером named записи авторитативных данных, кэширован ных данных и данных корневых указателей в файл named_dump.db в рабочем каталоге BIND (либо в файл /usr/tmp/named_dump.db, или /var/tmp/named_dump.db, в случае использования BIND 4).' Ниже приводится пример файла named_dump.db. Авторитативные данные и каптированные записи отображены в начале файла без определенного порядка, за ними следуют данные корневых указателей:

BIND 9.1.0 является первой версией пакета BIND 9, в которой поддержива ется создание образа (дампа) базы данных.

500 Глава 14 Разрешение проблем DNS и BIND Инструменты и методы DNS-сервер, создавший этот файл, являлся авторитативным только для зоны 0.0.127.in-addr.arpa. Этим сервером был произведен поиск для двух имен: galt.cs.purdue.edu и cujo.movie.edu. В процессе поиска для galt.cs.purdue.edu сервер кэшировал не только адрес узла galt, но также список DNS-серверов для зоны purdue.edu и их адреса. Имя си jo.movie.edu в действительности не существует (как и зона movie.edu, используемая только в наших примерах), поэтому сервер кэшировал отрицательный ответ. В файле дампа отрицательный ответ закоммен тирован (строка начинается с символа точки с запятой), и вместо дан ных приводится причина получения отрицательного ответа (NXDO MAIN). Обратите внимание, что значение TTL довольно низкое (593).

В BIND 8.2 и более поздних версиях DNS-сервера отрицательные отве ты кэшируются на время, определяемое последним полем SOA-запи си, и это время обычно существенно меньше, чем стандартное значе ние TTL для всей зоны.

502 Глава 14. Разрешение проблем DNS и BIND В разделе указателей - в конце файла - содержатся данные из файла db.cache. TTL для данных указателей уменьшается и может обратить ся в нуль, но указатели никогда не удаляются.

После некоторых RR-записей присутствует точка с запятой и строка NT=. Это адресные записи DNS-серверов. Число определяет время пе редачи сигнала для конкретного DNS-сервера, оно хранится DNS-cep вером для ранжирования «собеседников» по скорости реагирования;

при следующем запросе будет использован сервер с наименьшим пока зателем RTT.

Кэшированные данные легко отличить от всех остальных - их записи дополняются отметкой достоверности (credibility, Cr=) и иногда - IP адресом сервера, от которого получены данные.1 Данные зоны и дан ные указателей дополняются отметкой Сl=, которая содержит номер уровня (count of level) в дереве доменов (корневой уровень имеет номер 0, foo будет иметь уровень 1, foo.foo - уровень 2 и т. д.). Сейчас мы сде лаем отступление и объясним понятие достоверности.

Разница между версиями 4.8.3 и 4.9 включает появление метрики до стоверности. Она позволяет DNS-серверу принимать более продуман ные решения относительно того, что следует делать с новыми данны ми, полученными от удаленного сервера.

У серверов версии 4.8.3 было только два уровня достоверности - ло кально-авторитативные данные и все остальные. Локально-авторита тивными назывались данные в файлах данных зоны - DNS-серверу прекрасно известно, когда стоит, а когда не стоит обновлять хранимую копию. Данные, получаемые от всех прочих DNS-серверов, имели оди наковую достоверность.

Вот реальная ситуация и действия сервера версии 4.8.3 в этой ситуа ции. Предположим, DNS-сервер производил поиск адреса для termina tor.movie.edu и получил авторитативный ответ от DNS-сервера зоны movie.edu. (Авторитативный ответ - наилучший из существующих.) Некоторое время спустя, при поиске для имени foo.oreilly.com, DNS сервер получает еще одну адресную запись для имени terminator.то vie.edu, но на этот раз - в качестве части информации о делегировании для oreilly.com (terminator.movie.edu является для этой зоны вторич DNS-сервер отображает IP-адрес удаленного сервера, если это возможно. В BIND 8.2 и более поздних версиях DNS-серверов IP-адрес доступен только в том случае, если использовано соответствующее предписание - host-statis tics, которое было описано в главе 8 «Развитие домена». В более ранних DNS-серверах BIND 4.9 и BIND 8 режим включен по умолчанию, host-sta tistics сохраняет впечатляющую статистику по каждому DNS-серверу и клиенту, с которым когда-либо контактировал данный DNS-сервер, что в некоторых случаях очень полезно (скажем, позволяет определить, от како го DNS-сервера получена определенная запись), но связано с потреблением повышенных объемов памяти.

Инструменты и методы ным DNS-сервером). DNS-сервер версии 4.8.3 обновил бы кэширован ную адресную запись для узла terminator.movie.edu, несмотря на то, что данные поступили от DNS-сервера сот, а не от авторитативного DNS-сервера movie.edu. Но ведь DNS-серверы сот и movie.edu возвра щают одинаковую информацию по terminator.movie.edu, и проблемы никакой нет? Да-да, а в южной Калифорнии никогда не идут дожди.

DNS-серверы версии 4.9 и более поздних проявляют некоторую раз борчивость. Как и серверы версии 4.8.3, они считают хранимые дан ные зоны неприкосновенными - в принципе. При этом проводится различие между различными типами данных, получаемых от удален ных DNS-серверов. Вот иерархия достоверности данных от удаленных серверов, в порядке понижения достоверности:

auth Записи извлечены из ответов авторитативных DNS-серверов (из раз дела ответа сообщений с установленным битом авторитативности).

answer Записи извлечены из неавторитативных либо каптированных отве тов (из раздела ответа сообщений со сброшенным битом авторита тивности).

addtnl Записи извлечены из оставшейся части сообщения - разделов авто ритативности и дополнительного. Раздел авторитативности сооб щения содержит NS-записи, делегирующие зону авторитативному DNS-серверу. Дополнительный раздел содержит адресные записи, которые, возможно, дополняют информацию из других разделов (скажем, это адресные записи, которые сопутствуют NS-записям из раздела авторитативности).

Существует одно исключение из этого правила: когда DNS-сервер про изводит начальное заполнение кэша корневых DNS-серверов, записи, имеющие достоверность addtnl получают достоверность answer, чтобы снизить вероятность их случайного изменения. Обратите внимание, в приведенном дампе адресные записи корневых DNS-серверов имеют достоверность answer, но при этом адресные записи для DNS-серверов purdue.edu имеют достоверность addtnl.

В описанной только что ситуации DNS-сервер версии 4.9 или более поздней не станет заменять авторитативные данные (достоверность au th) для terminator.movie.edu данными делегирования (достоверность ad dtnl), поскольку авторитативный ответ имеет большую достоверность.

Регистрация запросов В BIND версии 4.9 появилась регистрация запросов (query logging), которая может облегчить диагностирование некоторых проблем. Ког да регистрация запросов включена, работающий DNS-сервер записы 504 Глава 14. Разрешение проблем DNS и BIND вает каждый запрос в log-файл демона syslog. Такая возможность по лезна для поиска ошибок в настройках клиента, поскольку появляет ся способ проверить, что имя, для которого выполняется запрос, иден тично тому, о котором думал пользователь.

Прежде всего следует убедиться, что сообщения LOGINFO регистриру ются демоном syslog в потоке daemon. После этого необходимо включить регистрацию запросов одним из существующих способов: в BIND 4. применить настройку options query-log в загрузочном файле DNS-cep вера;

в BIND 4.9 или BIND 8 запустить DNS-сервер с ключом команд ной строки -q или послать команду ndc querylog работающему DNS серверу. В BIND версии 9.1.0 и более поздних версий (в более ранних версиях BIND 9 регистрация запросов не поддерживается) следует ис пользовать команду rndc querylog. В log-файле syslog начнут появ ляться сообщения примерно следующего характера:

Либо, в случае BIND 9, такие:

Сообщения включают IP-адрес узла, сделавшего запрос, а также собст венно запрос. Поскольку первый пример относится к DNS-серверу BIND 8.2.3, а запросы являются рекурсивными, сообщения в этом при мере начинаются с подстроки ХХ+. Итеративные запросы начинаются с подстроки XX. (DNS-серверы версий до 8.2.1 не различают в сообще ниях рекурсивные и нерекурсивные запросы.) Инверсные запросы включают дефис перед типом записи (для инверсного запроса адрес ной записи присутствует подстрока «-А» вместо «А»). После регистра ции достаточного количества запросов выключить регистрацию мож но с помощью повторного выполнения команды ndc querylog или rndc querylog.

Если приходится использовать более старую версию DNS-сервера BIND 9, получаемые запросы можно увидеть в отладочном выводе na med первого уровня 1.

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

Перечень возможных проблем Мы рассмотрим их в рабочем порядке, поскольку они встречаются до вольно часто и вызваны стандартными ошибками. Итак, участники конкурса в порядке общей очереди. Мы называем эти ошибки «Черто вой дюжиной».

1. Не был увеличен порядковый номер зоны Главным симптомом этой проблемы является нежелание DNS-серве ров получать изменения, которые были внесены в данные зоны на пер вичном мастер-сервере. Вторичные серверы считают, что зона не изме нилась, поскольку порядковый номер остался тем же.

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.