2004 г
Система доменных имен
Материалы книги П.Б. Храмцова
iнфоцентр
Программа тестирования системы доменных имен - host
В данном материале рассматривается применение различных опций программы host - одного из основных средств тестирования работы системы доменных имен.
Программа host среди трех наиболее используемых средств тестирования DNS (nslookup, dig, host) самая "свежая". В ней учтены нарекания пользователей, которые вызывают ее аналоги - nslookup и dig, а также реализованы возможности диагностирования ошибок и подсчета статистики.
Host не является средством отладки серверов доменных имен, каковым по сути является dig. Host не имеет интерактивного режима работы, который присутствует в nslookup. Зато host проста в использовании, не перегружена опциями и атрибутами, имеет ясный и лаконичный синтаксис и отчетность. Кроме того, ее любят применять в качестве компонента скриптов, которые кроме всего прочего призваны проверять наличие или отсутствие описания хостов в системе DNS.
Самый простой пример использования Host - это поиск IP-адреса по доменному имени:
> host quest
quest.polyn.kiae.su has address 144.206.192.2
quest.polyn.kiae.su mail is handled (pri=10) by quest.polyn.kiae.su
quest.polyn.kiae.su mail is handled (pri=20) by relay1.relcom.ru
>
В данном случае мы задали короткое имя хоста. Оно было расширено именем домена, в котором находится хост, с которого осуществляется запрос к системе доменных имен (polyn.kiae.su). В качестве отклика мы получили не только IP-адрес, но и информацию о том, как на хост polyn.kiae.su доставляется почта, т.е. какие хосты являются почтовыми шлюзами.
При решении обратной задачи, поиска имени по IP-адресу можно также воспользоваться программой host:
> host 144.206.192.2
2.192.206.144.IN-ADDR.ARPA domain name pointer quest.polyn.kiae.su
>
Как мы видим из этого примера, отчет host гораздо лаконичнее, чем отчет nslookup, например, - это просто сообщение о наличии записи в обратной зоне. Если бы с данным адресом, а точнее с именем 2.192.206.144.in-addr.arpa, в обратной зоне было бы связано более одной записи, то host сообщила бы о наличии всех этих записей:
> host 144.206.192.11
11.192.206.144.IN-ADDR.ARPA domain name pointer www.kiae.ru
11.192.206.144.IN-ADDR.ARPA domain name pointer kiae.polyn.kiae.su
>
Host принимает в качестве аргументов не только короткие имена, но и более длинные последовательности, которые могут быть как полными именами (FQDN), так и неполными именами:
> host quest.polyn
quest.polyn.kiae.su mail is handled (pri=20) by relay1.relcom.ru
quest.polyn.kiae.su mail is handled (pri=10) by quest.polyn.kiae.su
>
В контексте этого примера интересно рассмотреть, как host перебирает доменные имена и, вообще, что реально происходит. Для этого воспользуемся опцией отладки "-d":
> host -d quest.polyn
;; res_nmkquery(QUERY, quest.polyn, IN, A)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56773
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; quest.polyn, type = A, class = IN
;; Querying server (# 1) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56773
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; quest.polyn, type = A, class = IN
. 9m48s IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. (
2002110200 ; serial
30M ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
rcode = 3 (Non-existent domain), ancount=0
;; res_nmkquery(QUERY, quest.polyn, IN, MX)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56774
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; quest.polyn, type = MX, class = IN
;; Querying server (# 1) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56774
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; quest.polyn, type = MX, class = IN
. 9m48s IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. (
2002110200 ; serial
30M ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
rcode = 3 (Non-existent domain), ancount=0
;; res_nmkquery(QUERY, quest.polyn.polyn.kiae.su, IN, MX)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56775
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; quest.polyn.polyn.kiae.su, type = MX, class = IN
;; Querying server (# 1) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56775
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; quest.polyn.polyn.kiae.su, type = MX, class = IN
polyn.kiae.su. 1H IN SOA polyn.net.kiae.su. paul.kiae.su. (
233 ; serial
1H ; refresh
5M ; retry
16w3d17h46m39s ; expiry
1H ) ; minimum
rcode = 3 (Non-existent domain), ancount=0
;; res_nmkquery(QUERY, quest.polyn.kiae.su, IN, MX)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56776
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; quest.polyn.kiae.su, type = MX, class = IN
;; Querying server (# 1) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56776
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; quest.polyn.kiae.su, type = MX, class = IN
quest.polyn.kiae.su. 1H IN MX 10 quest.polyn.kiae.su.
quest.polyn.kiae.su. 1H IN MX 20 relay1.relcom.ru.
polyn.kiae.su. 1H IN NS polyn.net.kiae.su.
polyn.kiae.su. 1H IN NS ns.spb.su.
polyn.kiae.su. 1H IN NS ns.ussr.eu.net.
quest.polyn.kiae.su. 1H IN A 144.206.192.2
relay1.relcom.ru. 21h21m56s IN A 193.125.152.57
polyn.net.kiae.su. 18h51m35s IN A 144.206.160.32
ns.spb.su. 20h28m28s IN A 193.124.83.69
ns.ussr.eu.net. 20h20m50s IN A 193.124.22.65
rcode = 0 (Success), ancount=2
quest.polyn.kiae.su mail is handled (pri=10) by quest.polyn.kiae.su
quest.polyn.kiae.su mail is handled (pri=20) by relay1.relcom.ru
>
Как видно из этого примера, сначала host просто запрашивает IP-адрес для имени quest.polyn у сервера 144.206.192.10. Получает ответ, что такого домена (polyn) нет. Запрос host посылала рекурсивный, поэтому опрос корневого сервера, ответ которого приведен в примере, был получен сервером 144.206.192.10.
Затем host формирует запрос на поиск MX записи по тому же неполному имени. Естественным образом получаем также отрицательный ответ от корневого сервера об отсутствии домена polyn.
Теперь host расширяет наше неполное имя именем домена по умолчанию. Берет его из resolv.conf. Домена polyn.polyn.kiae.su также не существует.
Теперь host хост расширяет неполное имя только частью имени домена kiae.su. Тип записи при этом не модифицируется и остается равным MX, хотя по умолчанию сначала использовался тип A.
Хост quest в зоне polyn.kiae.su существует и для него есть MX записи, о чем нас с радастью и информируют. Кроме того, мы получаем информацию о том, какие серверы доменных имен являются авторитативными для зоны polyn.kiae.su.
Мягко говоря мы получили не совсем то, что хотели. Для того чтобы получить IP-адрес в данном случае, нужно явно задать тип записи A - "-t a":
> host -t a quest.polyn
quest.polyn.kiae.su has address 144.206.192.2
>
Если попросить host выдать более подробную информацию, то можно получить следующее:
> host -v -t a quest.polyn
Trying null domain
rcode = 3 (Non-existent domain), ancount=0
Trying domain "polyn.kiae.su"
rcode = 3 (Non-existent domain), ancount=0
Trying domain "kiae.su"
rcode = 0 (Success), ancount=1
The following answer is not verified as authentic by the server:
quest.polyn.kiae.su 3600 IN A 144.206.192.2
For authoritative answers, see:
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 information:
ns.spb.su 59905 IN A 193.124.83.69
ns.ussr.eu.net 59447 IN A 193.124.22.65
polyn.net.kiae.su 54092 IN A 144.206.160.32
>
Таким образом, мы видим ту же самую последовательность проверки зон, но только теперь host не запрашивает MX записи, а пытается получить только адресные записи (A).
Внимательный читатель уже заметил, что вместо флага "-d" мы в последнем примере использовали флаг "-v". Флаг "-d" - это флаг отладочного отчета. В нем (отладочном отчете) расшифрованы значения флагов заголовка сообщений протокола DNS и содержание самих запросов. При флаге "-v" мы просто получаем подробный отчет вместо обычного укороченного отчета.
Теперь посмотрим еще один пример:
> host kuku.polyn.kiae.su
kuku.polyn.kiae.su.kiae.su mail is handled (pri=80) by relay1.kiae.su
kuku.polyn.kiae.su.kiae.su mail is handled (pri=90) by relay2.kiae.su
> host -v kuku.polyn.kiae.su.
rcode = 3 (Non-existent domain), ancount=0
Host not found.
> host -v kuku.polyn.kiae.su
Trying null domain
rcode = 3 (Non-existent domain), ancount=0
Trying domain "polyn.kiae.su"
rcode = 3 (Non-existent domain), ancount=0
Trying domain "kiae.su"
rcode = 0 (Success), ancount=0
For authoritative answers, see:
kiae.su 86400 IN SOA ns.kiae.ru noc-dns.relarn.ru(
650127450 ;serial (version)
28800 ;refresh period
3600 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)
>
Сначала мы запросили адреса несуществующего имени. В домене polyn.kiae.su нет хоста с именем kuku. Во всяком случае, в описании зоны его нет точно. Host, тем не менее, в коротком отчете выдает MX записи для этого имени.
Мы задаем на конце имени символ ".", чтобы избежать перебора доменных имен. В этом случае мы получаем ответ, который и должны были получить. Теперь нам интересно, а почему в первом случае появились MX записи. Повторяем расширенный отчет, но без символа "." на конце имени хоста. Мы получаем положительный отклик, который говорит нам, что домен kiae.su существует. Но откуда адресные записи? Смотрим отладку, точнее только последнюю ее часть, которая касается домена kiae.su:
;; res_nmkquery(QUERY, kuku.polyn.kiae.su.kiae.su, IN, MX)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28015
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; kuku.polyn.kiae.su.kiae.su, type = MX, class = IN
;; Querying server (# 1) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28015
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 6
;; kuku.polyn.kiae.su.kiae.su, type = MX, class = IN
kuku.polyn.kiae.su.kiae.su. 23h52m13s IN MX 90 relay2.kiae.su.
kuku.polyn.kiae.su.kiae.su. 23h52m13s IN MX 80 relay1.kiae.su.
kiae.su. 23h52m13s IN NS ns.kiae.ru.
kiae.su. 23h52m13s IN NS ns2.ripn.net.
kiae.su. 23h52m13s IN NS ns.spb.su.
kiae.su. 23h52m13s IN NS ns.ussr.eu.net.
relay2.kiae.su. 23h52m13s IN A 193.125.152.57
relay1.kiae.su. 23h52m13s IN A 193.125.152.57
ns.kiae.ru. 19h41m6s IN A 194.226.65.4
ns2.ripn.net. 1d14h31m54s IN A 194.226.96.30
ns.spb.su. 16h21m18s IN A 193.124.83.69
ns.ussr.eu.net. 16h13m40s IN A 193.124.22.65
rcode = 0 (Success), ancount=2
kuku.polyn.kiae.su.kiae.su mail is handled (pri=90) by relay2.kiae.su
kuku.polyn.kiae.su.kiae.su mail is handled (pri=80) by relay1.kiae.su
>
Теперь понятно, что наш запрос в процессе обработки превратился в запрос MX записи, а для домена kiae.su установлены два почтовых шлюза. Мораль проста - нужно заказывать точный тип записи, и задавать полное доменное имя хоста с магической "." на конце.
До этого момента мы использовали host в качестве имитатора клиента DNS. Теперь попробуем изобразить сервер доменных имен, а точнее slave, который копирует зону:
> host -d -l vega.ru.
;; res_nmkquery(QUERY, vega.ru, IN, NS)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64141
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; vega.ru, type = NS, class = IN
;; Querying server (# 1) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64141
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; vega.ru, type = NS, class = IN
vega.ru. 19h45m17s IN NS ns2.macomnet.ru.
vega.ru. 19h45m17s IN NS ns.macomnet.ru.
vega.ru. 19h45m17s IN NS ns1.psychol.ras.ru.
ns2.macomnet.ru. 19h45m17s IN A 212.5.66.14
ns.macomnet.ru. 19h45m17s IN A 195.128.64.3
ns1.psychol.ras.ru. 19h14m24s IN A 62.117.88.14
rcode = 0 (Success), ancount=3
Found 1 addresses for ns2.macomnet.ru
Found 1 addresses for ns.macomnet.ru
Found 1 addresses for ns1.psychol.ras.ru
;; res_nmkquery(QUERY, vega.ru, IN, AXFR)
Trying 212.5.66.14
Server failed, trying next server: Query refused
;; res_nmkquery(QUERY, vega.ru, IN, AXFR)
Trying 195.128.64.3
Server failed, trying next server: Query refused
;; res_nmkquery(QUERY, vega.ru, IN, AXFR)
Trying 62.117.88.14
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
vega.ru name server ns1.psychol.ras.ru
rcode = 0 (Success), ancount=1
vega.ru name server ns.macomnet.ru
rcode = 0 (Success), ancount=1
vega.ru name server ns2.macomnet.ru
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
vega.ru has address 194.67.107.8
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
vega-gw.vega.ru has address 194.67.107.8
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
localhost.vega.ru has address 127.0.0.1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
belti.vega.ru has address 213.59.3.161
rcode = 0 (Success), ancount=1
www.belti.vega.ru has address 213.59.3.161
rcode = 0 (Success), ancount=1
ns1.vega.ru has address 194.67.107.1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
rcode = 0 (Success), ancount=1
ns2.vega.ru has address 194.67.107.1
rcode = 0 (Success), ancount=1
>
Из отладочного отчета мы видим, что сначала определяются авторитативные сервера, а потом с них запрашивается передача зоны (AXFR). Но серверы macomnet.ru не дают нам списать зону. Наш запрос ими "отражен". Однако сервер ns1.psychol.ras.ru нам разрешает списать зону.
Любопытно, что именно он и является master домена vega.ru:
> host -t soa vega.ru
vega.ru start of authority ns1.psychol.ras.ru serge.psychol.ras.ru(
2001121202 ;serial (version)
7200 ;refresh period
1800 ;retry refresh this often
3600000 ;expiration period
107800 ;minimum TTL
)
>
Если бы мы не включали режим отладочного отчета, то получили бы только:
> host -l vega.ru
vega.ru name server ns1.psychol.ras.ru
vega.ru name server ns.macomnet.ru
vega.ru name server ns2.macomnet.ru
vega.ru has address 194.67.107.8
vega-gw.vega.ru has address 194.67.107.8
localhost.vega.ru has address 127.0.0.1
belti.vega.ru has address 213.59.3.161
www.belti.vega.ru has address 213.59.3.161
ns1.vega.ru has address 194.67.107.1
ns2.vega.ru has address 194.67.107.1
>
На самом деле мы всю зону не скопировали, а точнее host нам не показал всей информации, которая есть в файле описания зоны. Для того чтобы получить эту информацию, нужно задать больше параметров:
> host -l -t any vega.ru.
vega.ru start of authority ns1.psychol.ras.ru serge.psychol.ras.ru(
2001121202 ;serial (version)
7200 ;refresh period
1800 ;retry refresh this often
3600000 ;expiration period
107800 ;minimum TTL
)
vega.ru name server ns1.psychol.ras.ru
vega.ru name server ns.macomnet.ru
vega.ru name server ns2.macomnet.ru
vega.ru mail is handled (pri=0) by vega-gw.vega.ru
vega.ru mail is handled (pri=10) by new.psychol.ras.ru
vega.ru has address 194.67.107.8
smtp.vega.ru is a nickname for vega.ru
nntp.vega.ru is a nickname for vega.ru
news.vega.ru is a nickname for vega.ru
gopher.vega.ru is a nickname for vega.ru
vega-gw.vega.ru mail is handled (pri=0) by vega-gw.vega.ru
vega-gw.vega.ru mail is handled (pri=10) by new.psychol.ras.ru
vega-gw.vega.ru mail is handled (pri=30) by polyn.net.kiae.su
vega-gw.vega.ru has address 194.67.107.8
mail.vega.ru is a nickname for vega.ru
localhost.vega.ru has address 127.0.0.1
www.vega.ru is a nickname for vega.ru
belti.vega.ru mail is handled (pri=10) by pms.belti.ru
belti.vega.ru mail is handled (pri=20) by mail.belti.ru
belti.vega.ru has address 213.59.3.161
www.belti.vega.ru has address 213.59.3.161
ns1.vega.ru has address 194.67.107.1
ftp.vega.ru is a nickname for vega.ru
ns.vega.ru is a nickname for vega.ru
ns2.vega.ru has address 194.67.107.1
vega.ru start of authority ns1.psychol.ras.ru serge.psychol.ras.ru(
2001121202 ;serial (version)
7200 ;refresh period
1800 ;retry refresh this often
3600000 ;expiration period
107800 ;minimum TTL
)
>
Как это не выглядит странным, но расширенный отчет, в котором для сокращения его объема мы удалили несколько записей, выглядит гораздо более привычно, чем стандартный отчет host. Во всяком случае, в нем читаются обычные записи описания ресурсов для зоны vega.ru:
> host -l -v -t any vega.ru
rcode = 0 (Success), ancount=3
Found 1 addresses for ns.macomnet.ru
Found 1 addresses for ns1.psychol.ras.ru
Found 1 addresses for ns2.macomnet.ru
Trying 195.128.64.3
Server failed, trying next server: Query refused
Trying 62.117.88.14
vega.ru 107800 IN SOA ns1.psychol.ras.ru serge.psychol.ras.ru(
2001121202 ;serial (version)
7200 ;refresh period
1800 ;retry refresh this often
3600000 ;expiration period
107800 ;minimum TTL
)
vega.ru 107800 IN NS ns1.psychol.ras.ru
vega.ru 107800 IN NS ns.macomnet.ru
vega.ru 107800 IN NS ns2.macomnet.ru
vega.ru 107800 IN MX 0 vega-gw.vega.ru
vega.ru 107800 IN MX 10 new.psychol.ras.ru
vega.ru 107800 IN A 194.67.107.8
smtp.vega.ru 107800 IN CNAME vega.ru
nntp.vega.ru 107800 IN CNAME vega.ru
news.vega.ru 107800 IN CNAME vega.ru
gopher.vega.ru 107800 IN CNAME vega.ru
vega-gw.vega.ru 107800 IN A 194.67.107.8
mail.vega.ru 107800 IN CNAME vega.ru
www.vega.ru 107800 IN CNAME vega.ru
ftp.vega.ru 107800 IN CNAME vega.ru
ns.vega.ru 107800 IN CNAME vega.ru
ns2.vega.ru 107800 IN A 194.67.107.1
vega.ru 107800 IN SOA ns1.psychol.ras.ru serge.psychol.ras.ru(
2001121202 ;serial (version)
7200 ;refresh period
1800 ;retry refresh this often
3600000 ;expiration period
107800 ;minimum TTL
)
>
Любопытно, что SOA запись повторяется дважды, но это не какая-то особенность host. Сами разработчики host пишут о том, что это происходит по таинственной причине ("arcane reasons"). На самом деле в RFC-1034 черным по белому написано, что при передаче зоны по AXFR запросу, а именно им и пользуются при копировании зоны, в качестве первого и последнего сообщений в потоке обмена данными передается узел начала описания зоны (top authoritative node of the zone), а это, собственно, и есть SOA запись. На самом деле так себя ведут все программы, если они правильно соблюдают рекомендации RFC.
Пока в своих запросах мы использовали только серверы умолчания, которые указаны в resolv.conf. Host позволяет использовать в качестве сервера доменных имен для клиента, который хочет получить обслуживание свих рекурсивных запросов, любой сервер сети. Точнее, мы можем попытаться использовать "чужой" сервер таким образом:
> host -t a polyn.kiae.su ns.spb.su
Using domain server:
Name: ns.spb.su
Address: 193.124.83.69
Aliases:
polyn.kiae.su has address 144.206.160.32
>
Вообще говоря, не любой сервер будет выполнять рекурсивный запрос. Например, корневые серверы его не выполняют:
> host -t a polyn.kiae.su A.ROOT-SERVERS.NET.
Using domain server:
Name: A.ROOT-SERVERS.NET
Address: 198.41.0.4
Aliases:
>
Любой администратор может ограничить использование своего сервера хостами сети для обслуживания рекурсивных запросов.
Теперь несколько замечаний по поводу работы с серверами. Во-первых, в качестве корневого сервера host всегда использует A сервер, а, во-вторых, при работе с серверами доменных имен умолчания, хост не выбирает лучший из них, а просто пользуется первым, если он работает, а если не работает, то берет второй из списка:
generate# host -d demin
;; res_nmkquery(QUERY, demin.polyn.kiae.su, IN, A)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56137
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; demin.polyn.kiae.su, type = A, class = IN
;; Querying server (# 1) address = 144.206.192.1
;; new DG socket
res_send: recvfrom: Connection refused
;; Querying server (# 2) address = 144.206.192.10
;; new DG socket
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56137
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; demin.polyn.kiae.su, type = A, class = IN
demin.polyn.kiae.su. 1H IN A 144.206.192.4
Это не весь отладочный отчет, а только его фрагмент, который позволяет зафиксировать перебор серверов. Если мы снова обратимся к услугам host, то перебор серверов будет выполнен вновь.
На самом деле, вовсе не факт, что в вашей системе стоит программа host, а если даже она установлена, то, скорее всего, в ней нет множества полезных функций, из-за которых ее предпочитают другим системам тестирования DNS. Просто версия старая. По этой причине лучше всего ее (программу Host) скопировать с ftp сервера ftp://ftp.nikhef.nl/pub/network/host.tar.Z. На момент написания этого материала наиболее свежей версией была версия от 2000 года.
Что полезного можно найти в свежих версиях программы. Например, проверку записи SOA:
> ./host -C webstatistics.ru. 144.206.192.55
webstatistics.ru (generate.polyn.kiae.su)
ns.webstatistics.ru paul.webstatistics.ru (1 3600 600 86400 3600)
!!! webstatistics.ru SOA expire is less than 1 week (1 day)
>
Host в данном случае указала на слишком короткий срок отключения slave сервера при отказе основного сервера доменных имен.
А вот пример проверки записей NS и теста серверов доменных имен:
generate# host -t ns webstatistics.ru. 144.206.192.55
webstatistics.ru NS ns.webstatistics.ru
!!! webstatistics.ru NS host ns.webstatistics.ru is not canonical
webstatistics.ru NS ns4.nic.ru
generate# /stats/archive/host/host -C webstatistics.ru. ns4.nic.ru
webstatistics.ru (ns4.nic.ru)
webstatistics.ru SOA record currently not present at ns4.nic.ru
generate#
Две последовательно примененные команды host позволяют выявить отсутствие описания зоны на сервере ns4.nic.ru.
Вот еще один пример применения host:
generate# ./host -L 1 webstatistics.ru. 144.206.192.55
webstatistics.ru. NS ns.webstatistics.ru.
!!! webstatistics.ru NS host ns.webstatistics.ru is not canonical
В данном случае host сообщает нам, что имя сервера ns.webstatistics.ru - это синоним, а не каноническое имя. Параметр "-L 1" позволяет управлять рекурсий перебора синонимов, т.е. несколько раз обращаться системе DNS для поиска канонического имени при наличии цепочки синонимов.
Host позволяет реализовать множество полезных отчетов. Именно по этой причине его применяют для получения статистики в RIPE. Вот в заключении фрагмент отчета по зоне ru:
generate# ./host -H ru.
ru AXFR record query refused by NS2.RIPN.NET
!!! WINUP.ru NS host hw.prometeus.nsc.ru is not canonical
!!! AK.ru NS host ns4.piter.net does not exist
AK.ru has lame delegation to ns4.piter.net
!!! DC.ru NS host dc.netway.ru does not exist
DC.ru has lame delegation to dc.netway.ru
…
Речь идет о некорректном делегировании. Для указанных в NS записях имен серверов нет IP-адресов.
Рекомендованная литература:
- 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 с.
Полезные ссылки:
- Peter Koch. Ripe-203. Recommendations for DNS SOA Values. 1999. (http://www.ripe.net/docs/ripe-203.html)
- http://ciisa.isa.utl.pt/cgi-bin/man2html?host+1 - страница man host для операционной системы Linux. Это не полный список ключей, но кое что есть.
Назад Оглавление Вперед