Программа тестирования системы доменных имен

2004 г

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

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

Программа тестирования системы доменных имен - 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<<- opcode: QUERY, status: NOERROR, id: 39541
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3


;; QUESTION SECTION:
;quest.polyn.kiae.su.           IN      A


;; ANSWER SECTION:
quest.polyn.kiae.su.    3600    IN      A       144.206.192.2


;; AUTHORITY SECTION:
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.


;; ADDITIONAL SECTION:
ns.spb.su.              160259  IN      A       193.124.83.69
ns.ussr.eu.net.         166860  IN      A       193.124.22.65
polyn.net.kiae.su.      71012   IN      A       144.206.160.32


;; Query time: 3 msec
;; SERVER: 144.206.192.10#53(144.206.192.10)
;; WHEN: Tue Nov  5 20:17:23 2002
;; MSG SIZE  rcvd: 187


>

На самом деле, это довольно пространный ответ, если сравнивать его с отчетом host, например. Он больше похож на отладочные сообщения системы тестирования нового сервера доменных имен. Видимо, так оно и есть.

Еще одной особенностью dig является отключенный по умолчания список поиска (подстановка имен доменов по умолчанию):

/usr/local/bin/dig quest
; <<>> DiG 9.2.1 <<>> quest
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50813
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:
;quest.                         IN      A


;; AUTHORITY SECTION:
.              185     IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISI
GN-GRS.COM. 2002110500 1800 900 604800 86400


;; Query time: 2 msec
;; SERVER: 144.206.192.10#53(144.206.192.10)
;; WHEN: Tue Nov  5 20:21:11 2002
;; MSG SIZE  rcvd: 98


>

Как видно из этого примера имя 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<<- opcode: QUERY, status: NXDOMAIN, id: 54475
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:
;144.206.192.1.                 IN      A


;; AUTHORITY SECTION:
               574     IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISI
GN-GRS.COM. 2002110500 1800 900 604800 86400


;; Query time: 2 msec
;; SERVER: 144.206.192.10#53(144.206.192.10)
;; WHEN: Tue Nov  5 20:29:20 2002
;; MSG SIZE  rcvd: 106


>

В данном случае адрес воспринят просто как доменное имя и вместо записи 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<<- opcode: QUERY, status: NOERROR, id: 30502
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3


;; QUESTION SECTION:
;2.192.206.144.in-addr.arpa.    IN      PTR


;; ANSWER SECTION:
2.192.206.144.in-addr.arpa. 3014 IN     PTR     quest.polyn.kiae.su.


;; AUTHORITY SECTION:
192.206.144.in-addr.arpa. 3138  IN      NS      polyn.net.kiae.su.
192.206.144.in-addr.arpa. 3138  IN      NS      ns.ussr.eu.net.
192.206.144.in-addr.arpa. 3138  IN      NS      ns.spb.su.


;; ADDITIONAL SECTION:
polyn.net.kiae.su.      68707   IN      A       144.206.160.32
ns.ussr.eu.net.         164555  IN      A       193.124.22.65
ns.spb.su.              157954  IN      A       193.124.83.69


;; Query time: 3 msec
;; SERVER: 144.206.192.10#53(144.206.192.10)
;; WHEN: Tue Nov  5 20:55:48 2002
;; MSG SIZE  rcvd: 222


>

Вот теперь все правильно, и имя преобразовано в имя домена зоны 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<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      2.192.206.144.in-addr.arpa, type = PTR, class = IN


;; ANSWER SECTION:
2.192.206.144.in-addr.arpa.  1H IN PTR  quest.polyn.kiae.su.


;; AUTHORITY SECTION:
192.206.144.in-addr.arpa.  1H IN NS  polyn.net.kiae.su.
192.206.144.in-addr.arpa.  1H IN NS  ns.spb.su.
192.206.144.in-addr.arpa.  1H IN NS  ns.ussr.eu.net.


;; ADDITIONAL SECTION:
polyn.net.kiae.su.      1D IN A         144.206.160.32
ns.spb.su.              1D IN A         193.124.83.69
ns.ussr.eu.net.         1D IN A         193.124.22.65


;; Total query time: 15 msec
;; FROM: generate.polyn.kiae.su to SERVER: ns.spb.su.  193.124.83.69
;; WHEN: Tue Nov  5 20:50:14 2002
;; MSG SIZE  sent: 44  rcvd: 198


>

На самом деле, для интереса можно вручную проделать весь этот путь, для того, чтобы оценить полезность опции "-х" 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<<- opcode: QUERY, status: NOERROR, id: 17703
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:
;2.192.206.144.in-addr.arpa.    IN      PTR


;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3


;; QUESTION SECTION:
;2.192.206.144.in-addr.arpa.    IN      PTR


;; ANSWER SECTION:
2.192.206.144.in-addr.arpa. 1385 IN     PTR     quest.polyn.kiae.su.


;; AUTHORITY SECTION:
192.206.144.in-addr.arpa. 1509  IN      NS      polyn.net.kiae.su.
192.206.144.in-addr.arpa. 1509  IN      NS      ns.ussr.eu.net.
192.206.144.in-addr.arpa. 1509  IN      NS      ns.spb.su.


;; ADDITIONAL SECTION:
polyn.net.kiae.su.      67078   IN      A       144.206.160.32
ns.ussr.eu.net.         162926  IN      A       193.124.22.65
ns.spb.su.              156325  IN      A       193.124.83.69


;; Query time: 2 msec
;; SERVER: 144.206.192.10#53(144.206.192.10)
;; WHEN: Tue Nov  5 21:22:57 2002
;; MSG SIZE  rcvd: 222


>

Теперь вернемся к вопросу применения списка поиска, который по умолчанию отключен в 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.conf
настроить систему ведения журналов 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<<- opcode: UPDATE, status: NOERROR, id:  65532
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0


>

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

Смотрим в журнал динамических обновлений зоны сервера доменных имен:

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<<- opcode: QUERY, status: NOERROR, id: 14834
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:
;VERSION.BIND.                  CH      TXT


;; ANSWER SECTION:
VERSION.BIND.           0       CH      TXT     "9.2.1"


;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Wed Nov  6 14:19:12 2002
;; MSG SIZE  rcvd: 48


generate#

На самом деле, настраивая 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.

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

P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)

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

http://ciisa.isa.utl.pt/cgi-bin/man2html?dig+1 - справочное руководство по dig в стиле Unix manual. Следует иметь в виду, что версия с которой вы работаете можно довольно сильно отличаться от этого описания. По этой причине лучше использовать тот manual, который поставляется с дистрибутивом named и dig

Назад Оглавление Вперед