Программа тестирования системы доменных имен - dig
В данном материале рассматривается применение различных опций программы dig - одного из основных средств тестирования работы системы доменных имен, поставляемого вместе с BIND сервером системы доменных имен.
Программа dig входит в комплект поставки BIND. Ее основное назначение - проверка правильности работы сервера доменных имен. При исполнении программы она сообщает свою версию, которая, как правило, совпадает с версией BIND.
Для того, чтобы просто получить IP-адрес по имени хоста достаточно выполнить:
> /usr/local/bin/dig quest.polyn.kiae.su.
; > DiG 9.2.1 > quest.polyn.kiae.su. ;; global options: printcmd ;; Got answer: ;; ->>HEADER
На самом деле, это довольно пространный ответ, если сравнивать его с отчетом host, например. Он больше похож на отладочные сообщения системы тестирования нового сервера доменных имен. Видимо, так оно и есть.
Еще одной особенностью dig является отключенный по умолчания список поиска (подстановка имен доменов по умолчанию):
/usr/local/bin/dig quest ; > DiG 9.2.1 > quest ;; global options: printcmd ;; Got answer: ;; ->>HEADER
Как видно из этого примера имя quest не расширяется именем домена. В конце имени хоста просто ставится символ ".", и запрос через локальный сервер доменных имен, который выполняет рекурсивные запросы, переправляется на корневой сервер A.
Оба предыдущих примера хорошо демонстрируют тот факт, что dig просто распечатывает секции DNS сообщения и его заголовок, т.е. формат отчета dig предполагает определенную "подкованность" пользователя в форматах и спецификациях системы доменных имен.
В отличие от других средств отладки DNS dig при получении доменного имени по IP-адресу требует указания соответствующей опции для поиска в обратных зонах, сам адрес по умолчанию не "выворачивает": >/p>
> /usr/local/bin/dig 144.206.192.1
; > DiG 9.2.1 > 144.206.192.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER
В данном случае адрес воспринят просто как доменное имя и вместо записи PTR dig ищет адресную запись.
Для того чтобы адрес инвертировался нужно указать опцию "-x":
> /usr/local/bin/dig -x 144.206.192.2
; > DiG 9.2.1 > -x 144.206.192.2 ;; global options: printcmd ;; Got answer: ;; ->>HEADER
Вот теперь все правильно, и имя преобразовано в имя домена зоны in-addr.arpa, и запрашивается запись типа PTR.
На самом деле можно и самому попробовать поискать "в лоб", задавая имя хоста в зоне in-addr.arpa и тип записи PTR, но это будет многоступенчатый процесс. Сначала dig отправит вас на корневые сервера, потом, на сервера зоны 144.in-addr.arpa и т.д., до тех пор, пока не откликнется авторитативный сервер зоны 192.206.144.in-addr.arpa:
> dig @ns.spb.su. 2.192.206.144.in-addr.arpa. -t ptr -c IN
; > DiG 8.3 > @ns.spb.su. 2.192.206.144.in-addr.arpa. -t -c ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER
На самом деле, для интереса можно вручную проделать весь этот путь, для того, чтобы оценить полезность опции "-х" J.
Если объем информации по умолчанию вас раздражает, и Вы хотите получить более краткие отчеты, то можно применить опцию запроса "+short":
> /usr/local/bin/dig -x 144.206.192.2 +short quest.polyn.kiae.su. >
т.е. ничего лишнего. Получили только имя хоста. Естественно, что эту опцию можно применять к любому запросу dig, если она (опция) не противоречит логике запроса.
Например, мы хотим получить в отчете сам запрос (опция +qr). При этом ясно, что получение краткого отчета противоречит нашему желанию. Если мы зададим опцию краткого отчета, то запроса в отчете не будет:
> /usr/local/bin/dig -x 144.206.192.2 +qr +short quest.polyn.kiae.su. >
Если убрать "+sort", запрос в отчете dig появится (от ";;Sending:" до ";;Got answer:"):
> /usr/local/bin/dig -x 144.206.192.2 +qr
; > DiG 9.2.1 > -x 144.206.192.2 +qr ;; global options: printcmd ;; Sending: ;; ->>HEADER>HEADER
Теперь вернемся к вопросу применения списка поиска, который по умолчанию отключен в dig.
Для включения необходимо указать опцию запроса "+search":
> /usr/local/bin/dig quest +search +short 144.206.192.2 >
На самом деле, мы получили то, что запрашивали. Вот только полного имени хоста нам так и не сообщили. К какому домену принадлежит имя quest. На первый взгляд мы и так знаем, в каком домене находимся, но ведь список поиска может состоять из нескольких доменных имен. Если /etc/resolv.conf будет иметь следующее содержание:
domain polyn.kiae.su nameserver 144.206.192.10 nameserver 144.206.160.32
то при поиске IP-адреса для хоста polyn мы ничего не получим, т.к. хоста polyn.polyn.kiae.su в описании зоны нет:
generate# /usr/local/bin/dig polyn +search +nocomments
; > DiG 9.2.1 > polyn +search +nocomments ;; global options: printcmd ;polyn. IN A . 251 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISI GN-GRS.COM. 2002110501 1800 900 604800 86400 ;; Query time: 2 msec ;; SERVER: 144.206.192.10#53(144.206.192.10) ;; WHEN: Wed Nov 6 13:11:53 2002 ;; MSG SIZE rcvd: 98
generate#
В данном отчете мы отключили печать комментариев (+nocomments), поэтому он получился более компактным, чем стандартный отчет.
Теперь изменим resolv.conf:
nameserver 144.206.192.10 nameserver 144.206.160.32 search polyn.kiae.su kiae.su .
Результат будет совсем иным:
generate# /usr/local/bin/dig polyn +search +nocomments
; > DiG 9.2.1 > polyn +search +nocomments ;; global options: printcmd ;polyn.kiae.su. IN A polyn.kiae.su. 3600 IN A 144.206.160.32 polyn.kiae.su. 3600 IN NS ns.spb.su. polyn.kiae.su. 3600 IN NS ns.ussr.eu.net. polyn.kiae.su. 3600 IN NS polyn.net.kiae.su. ns.spb.su. 98951 IN A 193.124.83.69 ns.ussr.eu.net. 105552 IN A 193.124.22.65 polyn.net.kiae.su. 9704 IN A 144.206.160.32 ;; Query time: 3 msec ;; SERVER: 144.206.192.10#53(144.206.192.10) ;; WHEN: Wed Nov 6 13:19:07 2002 ;; MSG SIZE rcvd: 175
generate#
Dig начала перебор доменных имен из resolv.conf. При этом, если бы мы попросили короткий отчет, то не имели бы представления о полном имени хоста:
generate# /usr/local/bin/dig polyn +search +nocomments +short 144.206.160.32 generate#
Для демонстрации трассы поиска информации в системе доменных имен, в dig предусмотрена опция "+trace":
generate# /usr/local/bin/dig www.ru +trace
; > DiG 9.2.1 > www.ru +trace ;; global options: printcmd . 352895 IN NS F.ROOT-SERVERS.NET. . 352895 IN NS B.ROOT-SERVERS.NET. . 352895 IN NS J.ROOT-SERVERS.NET. . 352895 IN NS K.ROOT-SERVERS.NET. . 352895 IN NS L.ROOT-SERVERS.NET. . 352895 IN NS M.ROOT-SERVERS.NET. . 352895 IN NS I.ROOT-SERVERS.NET. . 352895 IN NS E.ROOT-SERVERS.NET. . 352895 IN NS D.ROOT-SERVERS.NET. . 352895 IN NS A.ROOT-SERVERS.NET. . 352895 IN NS H.ROOT-SERVERS.NET. . 352895 IN NS C.ROOT-SERVERS.NET. . 352895 IN NS G.ROOT-SERVERS.NET. ;; Received 436 bytes from 144.206.192.10#53(144.206.192.10) in 3 ms
ru. 172800 IN NS NS2.NIC.FR. ru. 172800 IN NS NS.RIPN.NET. ru. 172800 IN NS NS2.RIPN.NET. ru. 172800 IN NS SUNIC.SUNET.SE. ru. 172800 IN NS NS.UU.NET. ru. 172800 IN NS NS1.RELCOM.ru. ;; Received 260 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 242 ms
www.ru. 86400 IN NS ns.demos.su. www.ru. 86400 IN NS ns1.demos.net. ;; Received 76 bytes from 192.93.0.4#53(NS2.NIC.FR) in 170 ms
www.ru. 86400 IN A 194.87.0.50 www.ru. 86400 IN NS ns.demos.su. www.ru. 86400 IN NS ns1.demos.net. ;; Received 140 bytes from 194.87.0.9#53(ns.demos.su) in 7 ms
generate#
В данном случае dig в отчете показывает отклики от серверов, которые она опрашивает. Для начала dig сообщила нам, что локальный сервер 144.206.192.10 за зону ru не отвечает и, что он отправил нас к корневым серверам. Те, в свою очередь, отправили нас на серверы зоны ru. Серверы зоны ru отправили нас на серверы зоны www.ru. Первый из этих серверов (ns.demos.ru) сообщил нам искомый адрес. Еще раз обратите внимание на то, что поиск адреса осуществляла сама dig, а не локальный сервер доменных имен. По этой причине проверять этой опцией работу локального сервера по обработке рекурсивных запросов не стоит.
Dig обладает еще одной интересной особенностью - выполнением нескольких команд за один раз. При чем, это не выборка нескольких опций из файла, а исполнение нескольких запросов, указанных в командной строке:
generate# /usr/local/bin/dig news.ru +short -x 144.206.160.32 www.ru ns 194.87.0.23 polyn.net.kiae.su. ns.demos.su. ns1.demos.net. generate#
В данном случае мы хотим получить IP адрес news.ru, имя для хоста 144.206.160.32 и все NS записи для зоны www.ru . Dig прекрасно справляется с поставленной задачей, мешаю, правда, все ответы в одну кучу.
На самом деле у dig есть еще один режим, который позволяет выполнять несколько запросов за раз. Это пакетная обработка файлов запросов. Пусть у нас будет иметься в наличии файл comd.txt следующего содержания:
quest.polyn.kiae.su. +short -x 144.206.192.2 +short www.rambler.su. +trace +noshort
Первая строка - это запрос на короткий отчет, который должен нам сообщить IP-адрес хоста auest.polyn.kiae.su, вторая срока запрашивает короткий отчет при поиске имени хоста с IP-адресом 144.206.192.2, в третьей строке мы запрашиваем трассу опроса серверов для имени www.rambler.ru и отменяем короткий отчет. Таким образом, каждый запрос dig - это отдельная строка файла. При запуске dig мы получим следующий отчет:
generate# /usr/local/bin/dig -f comd.txt 144.206.192.2 quest.polyn.kiae.su. . 332654 IN NS A.ROOT-SERVERS.NET. . 332654 IN NS H.ROOT-SERVERS.NET. . 332654 IN NS C.ROOT-SERVERS.NET. . 332654 IN NS G.ROOT-SERVERS.NET. . 332654 IN NS F.ROOT-SERVERS.NET. . 332654 IN NS B.ROOT-SERVERS.NET. . 332654 IN NS J.ROOT-SERVERS.NET. . 332654 IN NS K.ROOT-SERVERS.NET. . 332654 IN NS L.ROOT-SERVERS.NET. . 332654 IN NS M.ROOT-SERVERS.NET. . 332654 IN NS I.ROOT-SERVERS.NET. . 332654 IN NS E.ROOT-SERVERS.NET. . 332654 IN NS D.ROOT-SERVERS.NET. ;; Received 436 bytes from 144.206.192.10#53(144.206.192.10) in 4 ms
ru. 172800 IN NS NS2.NIC.FR. ru. 172800 IN NS NS.RIPN.NET. ru. 172800 IN NS NS2.RIPN.NET. ru. 172800 IN NS SUNIC.SUNET.SE. ru. 172800 IN NS NS.UU.NET.
ru. 172800 IN NS NS1.RELCOM.ru. ;; Received 268 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 139 ms
rambler.ru. 86400 IN NS ns.park.rambler.ru. rambler.ru. 86400 IN NS ns.rambler.ru. ;; Received 103 bytes from 192.93.0.4#53(NS2.NIC.FR) in 170 ms
www.rambler.ru. 3600 IN A 81.19.66.131 www.rambler.ru. 3600 IN A 81.19.66.50 rambler.ru. 3600 IN NS ns.rambler.ru. rambler.ru. 3600 IN NS ns.park.rambler.ru. ;; Received 135 bytes from 217.73.193.23#53(ns.park.rambler.ru) in 4 ms
generate#
Теперь от запросов к серверу, как рекурсивных, так и нерекурсивных, перейдем к копированию зоны. Для этого в качестве типа запроса нужно задать тип AXFR. При этом мы будем иммитировать работу slave сервера системы доменных имен, который пытается скопировать зону:
generate# /usr/local/bin/dig @localhost webstatistics.ru. axfr +multiline
; > DiG 9.2.1 > @localhost webstatistics.ru. axfr +multiline ;; global options: printcmd webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. ( 2 ; serial 3600 ; refresh (1 hour) 600 ; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) ) webstatistics.ru. 3600 IN NS ns.webstatistics.ru. webstatistics.ru. 3600 IN NS ns4.nic.ru. webstatistics.ru. 3600 IN A 144.206.192.60 host.webstatistics.ru. 3 IN A 144.206.192.63 ns.webstatistics.ru. 3600 IN CNAME webstatistics.ru. user.webstatistics.ru. 3 IN CNAME host.webstatistics.ru. user1.webstatistics.ru. 3 IN CNAME user.webstatistics.ru. www.webstatistics.ru. 3 IN A 144.206.160.32 www.webstatistics.ru. 3 IN A 144.206.192.60 www.webstatistics.ru. 3 IN A 144.206.192.61 www.webstatistics.ru. 3 IN A 144.206.192.62 www1.webstatistics.ru. 3 IN CNAME www.webstatistics.ru. zone.webstatistics.ru. 3 IN NS ns.webstatistics.ru. webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. ( 2 ; serial 3600 ; refresh (1 hour) 600 ; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) ) ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Wed Nov 6 19:13:48 2002 ;; XFR size: 16 records
generate#
В этом примере мы применили сразу два атрибута командной строки, которые не применяли раньше. Во-первых, мы явным образом указали сервер (@loacalhost), с которого мы хотим списать зону, во-вторых, указали явным образом тип запроса (axfr). Последний параметр (+multilane) позволил нам в удобочитаемом виде расположить опции SOA записи. Как и положено (RFC-1034) при копировании зоны SOA запись появляется дважды - в начале и конце передачи данных.
Вообще говоря, dig позволяет проиммитировать и инкрементальный обмен данными - тип запроса ixfr:
generate# /usr/local/bin/dig @193.0.0.236 example.com ixfr=2002010300
; > DiG 9.2.1 > @193.0.0.236 example.com ixfr=2002010300 ;; global options: printcmd example.com. 172800 IN SOA dns1.icann.org. hostmaster.icann .org. 2002020400 7200 3600 1209600 21600 example.com. 21600 IN NS a.iana-servers.net. example.com. 21600 IN NS b.iana-servers.net. example.com. 172800 IN A 192.0.34.72 www.example.com. 172800 IN A 192.0.34.72 example.com. 172800 IN SOA dns1.icann.org. hostmaster.icann .org. 2002020400 7200 3600 1209600 21600 ;; Query time: 62 msec ;; SERVER: 193.0.0.236#53(193.0.0.236) ;; WHEN: Wed Nov 6 19:30:16 2002 ;; XFR size: 7 records
generate#
Номер, который задается в качестве параметра ixfr - это серийный номер описания зоны. На самом деле, из данного отчета мало что понятно, т.к. мы не знаем, когда проводились реальные обновления зоны, и в чем они состояли.
Для того, чтобы проверить при помощи dig работу динамического обновления зоны, необходимо это свойство named настроить. Для этого следует выполнить две вещи:
Разрешение динамического обновление настраивается следующим образом: в файл конфигурации named в правила, относящиеся к конкретной зоне добавляют опцию allow-update:
zone "webstatistics.ru" { type master; file "webstatistics.ru"; allow-update { { 144.206.192.55; 144.206.160.32; 127.0.0.1; }; }; };
Специалисты по безопасности в этом месте заклеймят нас позором, т.к. мы только перечислили IP-адреса, с которых можно проводить обновление, но не установили дополнительных условий типа подписей транзакций (TSIG - transaction signature). Но на наш взгляд в данном случае упоминание дополнительных "наворотов" не способствует прозрачности изложения материала, а потому вопросы безопасности мы пока отодвинем на второй план. Мы просто хотим убедиться в работе dig с ixfr.
Теперь нам нужно быть уверенными в том, что сервер действительно принимает запросы динамического обновления и реагирует на них. Для этого нужно настроить соответствующим образом журнал обращений к серверу доменных имен. За эту часть работы отвечает опция logging в файле конфигурации named:
logging { channel "update_log"{ file "update.log"; severity debug 3; }; category "default" { "default_syslog"; "default_debug"; }; category "update" { "update_log"; }; };
Мы создали новый канал для ведения журнала - update_log. Связали с этим каналом файл update.log, который будет размещаться в рабочем каталоге сервера. Серьезность сообщений, которые туда будут писаться, определили как отладку третьего уровня. Сам канал отнесли к категории Update (список категорий, по которым ведутся журналы в named, ограничен и приведен в руководстве системного администратора сервера).
Теперь перезапустим сервер и попробуем внести изменение в зону "на лету", воспользовавшись программой nsupdate:
generate# /usr/local/bin/nsupdate -d > server 127.0.0.1 > zone webstatistics.ru > update add newhost 3600 in cname host >
Reply from update query: ;; ->>HEADER
Прямо скажем, что для обычного пользователя не очень информативно. Само обновление сразу в файл описания зоны не попадет, и поэтому не просто установить факт свершившегося обновления.
Смотрим в журнал динамических обновлений зоны сервера доменных имен:
generate# more namedb/update.log client 144.206.192.55#3187: updating zone 'webstatistics.ru/IN': adding an RR generate#
Наш уровень сообщений позволил нам узнать, что что-то обновилось, но вот что? Сначала запустим dig для того, чтобы узнать серийный номер зоны. Это нам даст первую информацию о том, было или не было обновление, если мы, конечно, помним предыдущий серийный номер:
generate# /usr/local/bin/dig @localhost webstatistics.ru soa +short ns.webstatistics.ru. paul.webstatistics.ru. 7 3600 600 86400 3600 generate#
Вот теперь запускаем dig для тестирования состояний динамических обновлений:
generate# /usr/local/bin/dig @localhost webstatistics.ru ixfr=6 +nocomments
; > DiG 9.2.1 > @localhost webstatistics.ru ixfr=6 +nocomments ;; global options: printcmd webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 7 3600 600 86400 3600 webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 6 3600 600 86400 3600 webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 7 3600 600 86400 3600 newhost.webstatistics.ru. 3600 IN CNAME host.webstatistics.ru. webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 7 3600 600 86400 3600 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Thu Nov 7 10:55:35 2002 ;; XFR size: 5 records
generate#
Вполне прогнозируемый результат. Dig сообщил нам, что не только была добавлена запись CNAME, но и изменилась запись SOA. Таким образом, мы можем с удовлетворением отметить, что все прекрасно работает.
Если снова посмотреть на описание зоны, которое до этого момента мы правили руками, то оно изменится гораздо существеннее, чем можно было бы ожидать. Сервер при динамическом обновлении его переписывает, подгоняя под внешний вид и стиль описания, которого придерживаются сами разработчики сервера.
Вообще говоря, у нас в запасе есть еще один способ убедиться в том, что все работает прекрасно - это файл журнала обновлений, но не наш, а системный для зоны webstatistics.ru - webstatistics.ru.jnl. В этом файле должны сохраняться все динамические обновления зоны.
Следует, правда, иметь в виду, что информация пишется туда не для чтения ее человеком, но бездушной машиной. Разобрать, конечно, кое-что можно, но dig удобнее.
В конце концов, если не очень торопиться, то изменения должны появиться и в описании зоны, но при этом нужно будет подождать некоторое время (примерно час). Понятно, что в этих условиях Dig позволит получить информацию быстрее.
Dig позволяет получать информацию не только об интернет зонах. Например, в BIND есть такая особенность: named дает возможность удаленному пользователю узнать версию пакета. На самом деле это не очень хорошо. Если данная версия обладает "дыркой" в системе безопасности, то сервер доменных имен только помогает определить инструмент для своего взлома.
generate# /usr/local/bin/dig -t txt -c chaos VERSION.BIND @localhost
; > DiG 9.2.1 > -t txt -c chaos VERSION.BIND @localhost ;; global options: printcmd ;; Got answer: ;; ->>HEADER
На самом деле, настраивая BIND, можно "прикинуться" другой версией пакета. Для этого в файл конфигурации named нужно указать:
zone "bind" chaos { type master ; file "bind"; allow-query { localhost ; } ; allow-transfer { none; } ; };
И создать описание зоны (файл bind):
$ORIGIN bind. @ 1D CHAOS SOA localhost. root.localhost. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum CHAOS NS localhost.
Собственно, пример с запросом на версию BIND призван был показать тот факт, что dig, как и любая другая система тестирования DNS, может запрашивать записи не только из Internet (класс IN), но и из других поддерживаемых в DNS классах.
В новых версиях BIND можно поступить еще проще, вставив в options (в файле named.conf) следующий фрагмент:
options { version "Ne znaju"; };
В этом случае текст у директивы version будет отображаться в качестве txt RR-записи в зоне version.bind класса chaos.
