Cредства и методы тестирования работы системы доменных имен, отличные от nslookup, host и dig

2004 г

Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

Cредства и методы тестирования работы системы доменных имен, отличные от nslookup, host и dig

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

Было бы странно, если при обсуждении проблем системы доменных имен мы не упомянули об авторе qmail профессоре Бернштейне (D J Bernstein aka DJB). Почтовый транспортный агент (в современной терминологии, после выхода в свет RFC - 2821, почтовый сервер) qmail имел и имеет до сих довольно много приверженцев и стойко удерживает второе место по числу установок в Сети.

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

В отличии от BIND djbdns состоит из нескольких независимых компонентов, которые запускаются в системе как независимые процессы. Более того, каждый процесс (демон) должен быть запущен с правами уникального пользователя.

DNScache - это кэширующий сервер, который выполняет рекурсивные запросы локальных клиентов. Tynidns - это сервер, который отвечает только на udp запросы к своей зоне. Axfrdns и axfr-get используются при обмене данными зоны по TCP.

При работе с djbdns не нужно самому руками править зону. Для этого есть несколько специальных утилит. Кроме самого djbdns на ваш Unix-клон придется поставить еще парочку продуктов: daemonstools, ucspi-tcp. Эти продукты необходимы для работы djbdns и обеспечивают пакету приемлемую безопасность и быстродействие.

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

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

И так, для получения информации из системы DNS в djbdns используются: dnsip, dnsipq, dnsname, dnsmx, dnstxt.

Dnsip позволяет получать IP-адрес хоста, если задано полное (FQDN) доменное имя этого хоста. Если имя задано частично, то получаем пустую строку. Перебор имен доменов в данном случае не осуществляется.

generate# ./dnsip quest.polyn.kiae.su.
144.206.192.2
generate#

Мы попросили у dnsip IP-адрес хоста quest.polyn.kiae.su. Задавать символ точки на конце имени не обязательно. Имена можно перечислять в качестве аргументов командной строки. В последнем случае каждый ответ будет напечатан на отдельной строке:

generate# ./dnsip quest.polyn.kiae.su www.ru
144.206.192.2
194.87.0.50
generate#

Для того, чтобы получать адреса для имен, заданных частично, следует воспользоваться программой dnsipq:

generate# dnsipq quest cpuv1
quest.polyn.kiae.su 144.206.192.2
cpuv1.kiae.su 193.124.22.22
generate#

В первом случае произведена подстановка всего доменного имени, а во втором фрагмента доменного имени, состоящего из двух частей, что соответствует алгоритму подстановки resolver. Если теперь попросить более мелкий фрагмент доменного имени, то мы ничего не получим:

generate# dnsipq relarn
relarn.
generate#

Хоста relarn в доменах polyn.kiae.su и kiae.su нет, а просто ru не применяется в переборе resolver-а. Попутно заметим, что djbdns не использует resolver BIND или тот, который установлен по умолчанию.

Еще один интересный момент:

generate# dnsipq www www.polyn
www.polyn.kiae.su 144.206.160.32
www.polyn
generate#

Адрес для хоста www.polyn.kiae.su в принципе существует, но заданное частично начало имени не позволяет его найти.

Теперь от поиска IP-адресов по именам перейдем к поиску имен по IP-адресам. Для этого в djbdns служит программа dnsname:

generate# ./dnsname 144.206.192.55
generate.polyn.kiae.su
generate#

Все так же лаконично, как и в случае поиска адресов - задаем адрес и получаем имя. Поиск, естественно, осуществляется по "обратным" зонам, но преобразовывать IP-адрес в формат зоны in-addr.arpa не нужно.

Точно так же, как и в случае dnsip, в dnsname можно задавать запрос на поиск нескольких имен:

generate# ./dnsname 144.206.192.55 144.206.160.32
generate.polyn.kiae.su
polyn.net.kiae.su
generate#

Каждый ответ будет печататься в этом случае на отдельной строке.

Вообще говоря, в djbdns есть программа-фильтр, которая прямо так и называется dnsfilter. Ее главное назначение принимать из потока стандартного ввода IP-адреса, и выдавать в поток стандартного вывода доменные имена:

generate# ./dnsfilter
144.206.192.1
144.206.192.1
144.206.192.2
144.206.192.2=quest.polyn.kiae.su
144.206.192.55
144.206.192.55=generate.polyn.kiae.su
144.206.160.32
144.206.160.32=polyn.net.kiae.su
generate#

Как видно из примера, если соответствие существует, то выдается строка типа "IP-адрес=доменное_имя", если не существует, то просто на стандартный вывод копируется IP-адрес. В примере dnsfilter использовался как простая интерактивная команда, хотя основное ее назначение работать в связке с другими командами в качестве фильтра.

На самом деле есть еще один интересный момент:

generate# ./dnsname 127.0.0.1.


generate#

Мы пытаемся найти имя для адреса 127.0.0.1. Система его, естественно, не находит, потому, что не знает к кому обращаться за ним. Для этой сети в in-adrr.arpa зона не поддерживается.

А вот dig нам ответ дает совершенно запросто:

generate# ./dig @localhost -x 127.0.0.1 +short
localhost.polyn.kiae.su.
generate#

Мы запрашиваем локальный сервер, а на нем обратная зона 0.0.127.in-addr.arpa определена.

Мы сейчас оставим за скобками правомерность такого запроса вообще. Пример нужен был нам для того, чтобы обратить внимание на аргумент, который в dnsname, dnsip и dnsipq мы не использовали - имя сервера, к которому мы обращаемся запросом. В конце концов, если не указывать имя сервера, то и dig ничего не вернет:

generate# ./dig -x 127.0.0.1 +short
generate#

Следующая программа - это dnsmx. Она позволяет получить MX записи для заданного доменного имени:

generate# ./dnsmx polyn.kiae.su
10 polyn.kiae.su
20 relay1.relcom.ru
generate#

Если для заданного имени нет MX записей, то возвращается искусственная несуществующая запись:

generate# ./dnsmx kuku.polyn.kiae.su
0 kuku.polyn.kiae.su
generate#

Тем самым dnsmx моделирует работу MTA.

Такое внимание к MX записям объясняется наличием ошибок при описании зоны в части прописывания пересылки почты внутри зоны. Например, наличие петель пересылки.

Другая команда, dnstxt, написана, видимо, по причине использования TXT записей для совершенно разных функций. Например, для ограничения доступа к зоне (secure_zone TXT запись). Привести толковый пример использования TXT записи сложно. Перебирая провайдеров, мы наткнулись только на demos.ru:

generate# ./dnstxt demos.ru
$Id: demos.ru,v 1.3 2002/05/13 08:14:45 rvp Exp $
generate#

В качестве отклика отображается та часть записи, которая относится к полю DATA (см. "Описание зоны. Формат записи описания ресурсов RR."):

demos.ru. 86361 IN TXT "$Id: demos.ru,v 1.3 2002/05/13 08:14:45 rvp Exp $"

Теперь рассмотрим программы для тестирования работы собственно серверов: dnsqr, dnsq, dnstrace. Программу tinydns-get мы опустим, т.к. это компонента сервера и требует установки дополнительного программного обеспечения в отличие от других команд.

Программа dnsqr посылает рекурсивные запросы на получение записей определенного типа для доменного имени, которое задается последним аргументом командной строки:

generate# ./dnsqr any polyn.kiae.su
255 polyn.kiae.su:
338 bytes, 1+7+3+5 records, response, authoritative, noerror
query: 255 polyn.kiae.su
answer: polyn.kiae.su 3600 NS polyn.net.kiae.su
answer: polyn.kiae.su 3600 NS ns.spb.su
answer: polyn.kiae.su 3600 NS ns.ussr.eu.net
answer: polyn.kiae.su 3600 SOA polyn.net.kiae.su paul.kiae.su 233 3600 300 99999
99 3600
answer: polyn.kiae.su 3600 MX 10 polyn.kiae.su
answer: polyn.kiae.su 3600 MX 20 relay1.relcom.ru
answer: polyn.kiae.su 3600 A 144.206.160.32
authority: polyn.kiae.su 3600 NS polyn.net.kiae.su
authority: polyn.kiae.su 3600 NS ns.spb.su
authority: polyn.kiae.su 3600 NS ns.ussr.eu.net
additional: polyn.net.kiae.su 70984 A 144.206.160.32
additional: ns.spb.su 135020 A 193.124.83.69
additional: ns.ussr.eu.net 136323 A 193.124.22.65
additional: polyn.kiae.su 3600 A 144.206.160.32
additional: relay1.relcom.ru 60516 A 193.125.152.57
generate#

В данном случае мы попросили все записи для имени Polyn.kiae.su.

Сразу следует оговориться, что получить зону целиком при помощи команд отладки пакета djbdns нельзя. Для этого следует пользоваться компонентой сервера этого пакета - tinydns-get. Возможность ввести в качестве аргумента тип axfr не должна вводить в заблуждение:

generate# ./dnsqr axfr polyn.kiae.su
252 polyn.kiae.su:
temporary failure
generate#

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

generate# ./dnsq mx quest.polyn.kiae.su 144.206.160.32
15 quest.polyn.kiae.su:
251 bytes, 1+2+3+5 records, response, authoritative, weird ra, noerror
query: 15 quest.polyn.kiae.su
answer: quest.polyn.kiae.su 3600 MX 10 quest.polyn.kiae.su
answer: quest.polyn.kiae.su 3600 MX 20 relay1.relcom.ru
authority: polyn.kiae.su 3600 NS polyn.net.kiae.su
authority: polyn.kiae.su 3600 NS ns.spb.su
authority: polyn.kiae.su 3600 NS ns.ussr.eu.net
additional: quest.polyn.kiae.su 3600 A 144.206.192.2
additional: relay1.relcom.ru 78029 A 193.125.152.57
additional: polyn.net.kiae.su 66089 A 144.206.160.32
additional: ns.spb.su 66066 A 193.124.83.69
additional: ns.ussr.eu.net 131676 A 193.124.22.65
generate#

В данном примере мы запрашиваем авторитативный сервер зоны polyn.kiae.su на предмет наличия MX записей для хоста quest.polyn.kiae.su. В качестве ответа получаем эти записи плюс информацию о серверах ответственных за зону polyn.kiae.su. Стоит отметить, что тип запроса (тип записи) был преобразован в цифровой код, который соответствует этому типу RR (число "15" перед именем хоста в первой строке отчета).

Теперь посмотрим, как работает программа трассировки поиска информации в системе DNS. Вообще говоря, это монстр, который может порождать тысячи запросов. Он позволяет проверить все пути в дереве DNS, которые приводят к получению ответа. При этом можно выявить медленные серверы, некорректное делегирование, неработающие серверы и другие проблемы. Например, в отчете для зоны ru. есть такие строчки:

1 ns.ussr.eu.net 194.85.119.1
        ALERT: lame server; refers to .

Саму программу запускают следующим образом:

generate# ./dnstrace soa ru ns.ripn.net
                    . cache NS .
                    . cache A 194.85.119.1
6 ru 194.85.119.1
                    ru cache NS ns.ripn.net
                    ru cache NS ns1.relcom.ru
                    ru cache NS ns.uu.net
                    ru cache NS sunic.sunet.se
                    ru cache NS ns2.nic.fr
                    ru cache NS ns2.ripn.net
                    ns.ripn.net cache A 194.85.119.1
                    ns1.relcom.ru cache A 193.125.152.3
                    ns2.ripn.net cache A 194.226.96.30
                    ru 86400 SOA ns.ripn.net hostmaster.ripn.net
400 5371 7200 900 2592000 345600
…

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

Собственно, на этом примере можно завершить рассмотрение творения DJB. Следует заметить, что довольно часто djbdns рассматривают в качестве альтернативы BIND. Вызвано это, скорее всего, не тем, что сервер Бернштейна действительно хорош по своим потребительским и прочим качествам, а тем, что реальной альтернативы BIND пока действительно не видно.

Рассмотрим еще несколько программ тестирования зон системы DNS. Первой из них будет dnswalk. Программа написана на Perl (первоначально она представляла фильтр программы dig) с использованием модуля Net::DNS. Основное назначение программы поиск ошибок в описании зон и поиск некорректного делегирования.

Если вызвать программу без дополнительных ключей командной строки, то получим: generate# dnswalk bard.kiae.ru. Checking bard.kiae.ru. Getting zone transfer of bard.kiae.ru. from iris.polyn.kiae.su...done. SOA=ns.polyn.kiae.ru contact=paul.polyn.kiae.su BAD: bard.kiae.ru NS polyn.kiae.ru: unknown host WARN: bard.kiae.ru MX iris.polyn.kiae.ru: unknown host WARN: bard.kiae.ru A 144.206.192.32: no PTR record WARN: mail.bard.kiae.ru A 144.206.192.32: no PTR record WARN: www.bard.kiae.ru A 144.206.192.32: no PTR record 0 failures, 4 warnings, 1 errors. generate#

Из отчета видно, что сначала найден авторитативный сервер зоны (iris.polyn.kiae.su), далее выявлено некорректное делегирование (unknown host для NS записи) и список нефатальных ошибок, который сводится к отсутствию записей в "обратной зоне".

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

generate# dnswalk -l webstatistics.ru.

В данном случае мы ищем некорректное делегирование. Если есть подозрение на то, что оно существует, то dnswalk выдаст строку типа:

FAIL: Cannot get SOA record for webstatistics.ru from ns4.nic.ru (lame?):
no name servers

Можно попросить dnswalk рекурсивно просмотреть и все поддомены:

generate# dnswalk -r webstatistics.ru.
Checking webstatistics.ru.
Getting zone transfer of webstatistics.ru. from ns.webstatistics.ru...done.
SOA=ns.webstatistics.ru contact=paul.webstatistics.ru
BAD: webstatistics.ru NS ns.webstatistics.ru: CNAME (to webstatistics.ru)
BAD: webstatistics.ru NS ns4.nic.ru: unknown host
WARN: user1.webstatistics.ru CNAME user.webstatistics.ru: CNAME
(to host.webstatistics.ru)
BAD: zone.webstatistics.ru NS ns.webstatistics.ru: CNAME (to webstatistics.ru)
Checking zone.webstatistics.ru
BAD: SOA record not found for zone.webstatistics.ru
BAD: zone.webstatistics.ru has NO authoritative nameservers!
BAD: All zone transfer attempts of zone.webstatistics.ru failed!
0 failures, 6 warnings, 6 errors.
generate#

В данном случае в зоне делегируется поддомен zone.webstatistics.ru, для которого не удается найти авторитативных серверов.

Кроме того, в отчете сообщается и о других ошибках описания зоны, например, о синонимах в NS записях.

К сожалению, в dnswalk нельзя указать сервер, который мы собираемся тестировать. Сервер берется из resolv.conf. В конце концов, нужный нам сервер можно указать первым в resolv.conf и тогда dnswalk будет работать с ним.

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

generate# nslint
nslint: "cname" referenced by other "cname" or "mx": ns.webstatistics.ru.
nslint: name referenced without other records: generate.polyn.kiae.su.
nslint: missing "ptr": paul.webstatistics.ru. -> 144.206.192.50
nslint: "cname" referenced by other "cname" or "mx": user.webstatistics.ru.
nslint: missing "ptr": host.webstatistics.ru. -> 144.206.192.63
nslint: missing "a": localhost.polyn.kiae.su. -> 127.0.0.1
nslint: missing "ptr": webstatistics.ru. -> 144.206.192.60
nslint: name referenced without other records: ns4.nic.ru.
nslint: missing "ptr": www.webstatistics.ru. -> 144.206.160.32
nslint: missing "ptr": www.webstatistics.ru. -> 144.206.192.60
nslint: missing "ptr": www.webstatistics.ru. -> 144.206.192.61
nslint: missing "ptr": www.webstatistics.ru. -> 144.206.192.62
nslint: 144.206.192.60 in use by www.webstatistics.ru. and webstatistics.ru.
generate#

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

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

Существует еще одна возможность тестирования работы сервера доменных имен - анализ его log-файла. Для выполнения этих действий написан скрипт, который назывался lamers.sh. В последнее время его переписали и он работает с DOC, т.е. кроме анализа log-файла еще и тестирует сервер путем вызова программ из DOC.

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

#--------------------------------------------------------------------------
#  See if there are any lamers
#--------------------------------------------------------------------------
grep "Lame" $LOGFILE | tr A-Z a-z | grep -v "*" | awk '{
    if (length($9) == 2)
	next
    print substr($9, 2, length($9) - 2), substr($11, 2, length($11) - 2) }' |
    sort -u | awk '{
		printf("%s %s\n", $1, $2)
}' > $LAMERS

В BIND версии 9 можно настроить сервер таким образом, чтобы он сам собирал сообщения о некорректном делегировании:

channel "lammers_log" {
                file "lammers.log";
                severity info;
        };
        category "lame-servers" { "lammers_log"; };

Этот фрагмент нужно вставить в опцию logging в файле настройки named.conf.

Тогда при обнаружении некорректного делегирования в этом файле будут появляться строчки типа:

lame server resolving 'www.ietf.net' (in 'ietf.NET'?): 218.145.29.146#53

Мы уже упоминали DOC (domain obscenity control) в контексте lamers. На самом деле этот продукт можно использовать совершенно самостоятельно. К написанию первоначальной версии DOC приложил руку Paul Moskapetris (отец DNS). Одно время DOC входило в состав дистрибутива BIND. Сейчас программу можно найти среди дополнительного программного обеспечения (ports) для большинства Unix-клонов.

Краткий отчет программы DOC будет выглядеть следующим образом:

generate# /usr/local/bin/doc alpha.ru.
Doc-2.1.4: doc alpha.ru.
Doc-2.1.4: Starting test of alpha.ru.   parent is ru.
Doc-2.1.4: Test date - Thu Nov 14 16:40:13 MSK 2002
;; res_nsend to server ns2.nic.fr.  192.93.0.4: Operation timed out
DIGERR (UNKNOWN): dig @ns2.nic.fr. for SOA of parent (ru.) failed
Summary:
   ERRORS found for alpha.ru. (count: 2)
Done testing alpha.ru.  Thu Nov 14 16:40:24 MSK 2002


generate#

На самом деле интересно, что же за ошибки существуют в описании зоны. Для этого следует обратиться к файлу log.alpha.ru., который генерирует программа. Информацию об ошибках можно получить и на стандартный вывод:

generate# /usr/local/bin/doc -e alpha.ru.
Doc-2.1.4: doc -e alpha.ru.
Doc-2.1.4: Starting test of alpha.ru.   parent is ru.
Doc-2.1.4: Test date - Thu Nov 14 16:45:33 MSK 2002
ERROR: NS list from alpha.ru. authoritative servers does not
  === match NS list from parent (ru.) servers
ERROR: ns.alpha.ru. claims to be authoritative, but does not appear in
NS list from authoritative servers
Summary:
   ERRORS found for alpha.ru. (count: 2)
Done testing alpha.ru.  Thu Nov 14 16:45:35 MSK 2002


generate#

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

DOC использует dig Для получения содержания зоны, поэтому просто так без dig он работать не будет.

Есть еще одна любопытная программа - nsping. Ее не следует путать с "тезкой", которая применяется для Lotus Notes и Domino. Nsping тестирует серверы методом "случайного тыка". Основная идея заключается в том, чтобы обойти кэширование записей описания ресурсов и таким образом получить правдоподобную информацию о работоспособности сервера.

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

generate# /usr/local/sbin/nsping -z kiae.ru localhost
NSPING localhost (127.0.0.1): Domain = "kiae.ru", Type = "IN A"
+ [   0 ]   159 bytes from 127.0.0.1:    0.471 ms [    0.000 san-avg ]
+ [   1 ]   158 bytes from 127.0.0.1:    0.433 ms [    0.452 san-avg ]
+ [   2 ]   159 bytes from 127.0.0.1:    0.492 ms [    0.465 san-avg ]
+ [   3 ]   159 bytes from 127.0.0.1:    0.474 ms [    0.467 san-avg ]
+ [   4 ]   159 bytes from 127.0.0.1:    0.443 ms [    0.463 san-avg ]
+ [   5 ]   158 bytes from 127.0.0.1:    0.426 ms [    0.456 san-avg ]
^C
Total Sent: [   6 ] Total Received: [   6 ] Missed: [   0 ] Lagged [   0 ]
Ave/Max/Min:    0.456 /    0.492 /    0.426
generate#

В качестве первого параметра мы заказали зону, из которой хотели бы получать адреса, а в качестве второго параметра сервер (в данном случае localhost), который обрабатывал бы наши рекурсивные запросы.

Можно попросить оценить время получения и другого типа записей, например MX-записей:

generate# /usr/local/sbin/nsping -z rambler -T mx localhost
NSPING localhost (127.0.0.1): Domain = "rambler", Type = "IN MX"
+ [   0 ]   455 bytes from 127.0.0.1:    0.712 ms [    0.000 san-avg ]
+ [   1 ]   454 bytes from 127.0.0.1:    0.625 ms [    0.668 san-avg ]
+ [   2 ]   455 bytes from 127.0.0.1:    0.770 ms [    0.702 san-avg ]
+ [   3 ]   455 bytes from 127.0.0.1:    0.841 ms [    0.737 san-avg ]
+ [   4 ]   455 bytes from 127.0.0.1:    0.761 ms [    0.742 san-avg ]
+ [   5 ]   454 bytes from 127.0.0.1:    0.626 ms [    0.723 san-avg ]
^C
Total Sent: [   6 ] Total Received: [   6 ] Missed: [   0 ] Lagged [   0 ]
Ave/Max/Min:    0.723 /    0.841 /    0.625
generate#

Любопытно сравнить время получения информации с различных серверов. Например, с локального и с авторитативного сервера домена Microsoft:

generate# /usr/local/sbin/nsping -c 1 -z microsoft.com. -T ns dns1.dc.msft.net.
NSPING dns1.dc.msft.net. (207.68.128.151): Domain = "microsoft.com.", Type = "IN
 NS"
- [   0 ]   113 bytes from 207.68.128.151:  126.201 ms [    0.000 san-avg ]


Total Sent: [   2 ] Total Received: [   1 ] Missed: [   1 ] Lagged [   0 ]
Ave/Max/Min:  126.201 /  126.201 /  126.201
generate# /usr/local/sbin/nsping -c 1 -z microsoft.com. -T ns localhost
NSPING localhost (127.0.0.1): Domain = "microsoft.com.", Type = "IN NS"
+ [   0 ]   266 bytes from 127.0.0.1:    0.610 ms [    0.000 san-avg ]


Total Sent: [   2 ] Total Received: [   1 ] Missed: [   1 ] Lagged [   0 ]
Ave/Max/Min:    0.610 /    0.610 /    0.610
generate#

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

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

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

Рекомендованная литература:

P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)

Полезные ссылки:

http://cr.yp.to/djbdns.html -странички djbdns, написанные профессором Бернштейном. Это первоисточник.
http://djbdns.org/ - странички группы любителей djbdns. Довольно много информации по патеку, но гораздо больше его особенностей можно получить подписавшись на конференцию BIND. J
http://www.canb.auug.org.au/~millerp/dnsutl/dnsutl.html - сайт dnsutl - пакета генерации описания зон. Лучше все же писать зоны самому, а прибегать к автоматизации только в совершенно прозрачных случаях.
http://www.visi.com/~barr/dnswalk/ - страница dnswalk. Последня версия программы датируется 2000 годом. Новее найти не удалось.
http://www.ripe.net/ripe/mail-archives/dns-wg/1994/msg00013.html - это прототип RFC 1731. Здесь перечислены средства отладки описания зон и основные проблемы, которые могут быть решены при помощи этих средств.

Назад Оглавление