| 6.5. Запрос к серверу DNS |  | |
|---|---|---|
 | Глава 6. Сетевое администрирование |  |
| 6.5. Запрос к серверу DNS | | |
|---|---|---|
| | Глава 6. Сетевое администрирование | |
Описание. Кандидат BSDA должен понимать основы теории DNS, включая типы DNS записей обратное преобразование имён и перенос зон. Кандидат должен уметь посылать запросы серверу DNS о записях нужного типа, понимать какой сервер авторитетен за зону и понимать готов ли сервер к пересылке зоны.
Практика. dig(1), host(1), nslookup(1), ping(8), telnet(1)
Литература по настройке серверов DNS чрезвычайно обильна. Я пройдусь по теме насколько это возможно кратко.
Итак, протоколы IP и IPv6 устроены таким образом, что адресация
происходит при помощи числовых адресов. Нельзя сказать, что
человека это должно как-то напрягать, ведь никто не протестует
против применения семизначных, десятизначных и даже более
длинных телефонных номеров. Однако иметь более мнемоничные
адреса несомненно удобнее. Почти сразу, как только появился
интернет, появились таблицы соответствия IP адресов и символьных
имён машин. Эти таблицы и по сей день хранятся в файле
/etc/hosts. Однако задача синхронизации
данного файла между машинами очень скоро стала непомерно
сложной. В настоящий момент можно с уверенностью сказать, что
она вообще нереальна. Для решения этой проблемы возникла система
DNS — распределённая база данных.
Распределённая, значит ни один сервер не содержит в себе сведений обо всём пространстве имён Интернета. Каждый сервер ответственен за свой участок этого пространства. Говорят, что данный сервер авторитетен для данной зоны.
Таким образом, пространство имён Интернета поделено на зоны. Каждый сервер может отвечать за ноль и более зон. Рассмотрим, что происходит когда некоторой машине надо узнать IP адрес машины www.dragonflybsd.org.
![[*]](images/button-yellow.png)
6.5.1. Теория вопроса![[+]](images/button-green.png)
6.5.1.1.1. /etc/hosts, затем, в случае неудачи,
будет изучен файл /etc/resolv.conf.
Дополнительную информацию об этих этапах можно узнать из Раздел 6.1.4, «/etc/resolv.conf(5)» и Раздел 6.7, «Изменение порядка разрешения имён».
Сейчас нам важно, что в итоге мы сделали запрос к некоторому
серверу DNS.
Сервер DNS должен самостоятельно узнать адрес машины
www.dragonflybsd.org. и сообщить его клиенту даже если он не
является авторитетным для зоны в которой находится данная
машина (т.е. зоны dragonflybsd.org.). Сервер, который в
состоянии выполнить всю работу по розыску адреса, задав все
вопросы другим серверам DNS самостоятельно называется
рекурсивным. В /etc/resolv.conf можно
указывать только рекурсивные сервера DNS.
Первым делом наш сервер посылает запрос одному из корневых серверов DNS. Разумеется ни один из корневых серверов не знает ответа на этот вопрос. Больше того, ни один из них и не будет разбираться в вопросе, т.е. ни один из них не является рекурсивным. Зато они знают, какие сервера ответственны за зону org. И этой информацией делятся.
Вся информация полученная нашим сервером DNS надолго помещается в его кеш. Время хранения в кеше, зависит от настроек зоны, т.е. определяется не нашим DNS сервером, а теми серверами, которые ответственны за зону (в самом деле, только они могут знать насколько надёжны предоставленные ими данные). Некоторые серверы DNS могут существовать исключительно ради своего кеша и не иметь ни одной зоны, за которую они бы отвечали (так называемы кеширующие серверы).
Заметьте, что есть чёткая иерархия зон, но нет иерархии серверов DNS. Сервер DNS первым делом осуществляет запрос к корневому серверу, а вовсе не к «своему начальнику». Понятие старшинства среди серверов отсутствует, оно есть только для зон. Конечно сервер должен задать кому-то самый первый вопрос. Этот вопрос он задаёт корневому серверу. Адреса корневых серверов он берёт из специальной зоны подсказок, которая распространяется с исходным кодом сервера. Ниже я покажу как получить эту информацию.
![[Замечание]](images/note.png) | Замечание |
|---|---|
Иерархию серверов DNS можно создать искуственно при помощи опции
forwarders и зон типа forward.
Это может быть полезно, если на предприятии поднимаеться свой
локальный «национальный» домен типа
local. и в нём поддомены типа
finans.local., kb.local., где
будут хосты типа glavbuh.finans.local.,
ingeneer.finans.local., причём на зоны втророго
уровня ответственны свои DNS сервера, отличные от центрального
сервера, ответственного за зону local..
|
В каждой зоне могут быть записи следующих типов:
Таблица 6.1. Типы записей в файле зоны DNS
| Запись | Описание |
|---|---|
| SOA | Определение параметров зоны DNS (таймауты, адрес ответственного лица) |
| NS | Определение DNS-серверов ответственных (авторитетных) за зоны, делегирование полномочий поддоменам. |
| Записи типа SOA и NS обязательны, остальных записей может не быть вовсе. | |
| A | Преобразование имени в IP адрес |
| AAAA или A6 | Преобразование имени в IPv6 адрес |
| PTR | Преобразование IP адреса в имя |
| MX | Указание почтового сервера ответственного за зону |
| KEY | Открытый ключ шифрования для имени DNS |
| CNAME | Псевдоним, алиас, синоним. |
| SRV | Распределение нагрузки на сервис |
| TXT | Текстовая запись используется с самой разной целью |
| HINFO | Информация о машине, например архитектура и операционная система. |
В каждой зоне обязательно должны присутствовать записи типа SOA и NS. Если для домена example.org. почту принимает машина mx.example.org., то для неё должна существовать специальная MX запись. Почтовых машин отвечающих за домен может быть несколько. В записи типа MX упоминается их приоритет. Почту принимает машина с наименьшим значением приоритета, а если она недоступна, то следующая. Если запись MX для домена example.org. отсутствует, то эту почту принимает машина example.org.
Полное описание работы с сервером BIND выходит за рамки данного раздела. Мы лишь опишем настройку файла зоны, с тем, чтобы администратор мог сознательно применять утилиты host(1), dig(1) и nslookup(1).
Сначала зона должна быть объявлена в конфигурационном файле
сервиса named(8) —
named.conf(5). Этот конфигурационный
файл может находиться в файле
/etc/namedb/named.conf, а может в
/var/named/etc/namedb/named.conf.
Сервис named(8) часто запускается в
окружении chroot(8) в каталоге
/var/named/, однако для удобства
администрирования всё равно оставляют мягкую ссылку
/etc/namedb/named.conf.
Зона, оъявленная в BIND, может иметь один из следующих типов: master, slave, hint или forward. Зона hint содержит в себе адреса корневых серверов DNS, с которых начинает опрос рекурсивный сервер DNS. Эта зона практически не подвержена никаким изменениям и обычно не должна редактироваться администратором.
Зона типа master должна быть описана в файле. Файл описания зоны мы рассмотрим ниже, а сейчас взглянем на объявление зоны типа master:
...skip...
options {
directory "/etc/namedb";
...skip...
}
...skip...
zone "example.org." {
type master;
file "master/example.zone";
};
...skip...
Здесь сказано, что зона example.org. описана в файле
master/example.zone. Этот адрес дан
относительно каталога /etc/namedb (см.
опцию directory).
Зону типа master редактирует администратор, но за эту зону может отвечать несколько серверов DNS. Для того, чтобы все они обладали одинаковой согласованной информацией, на всех прочих серверах DNS поднимается зона типа slave, которая синхронизируется с зоной типа master. Зона типа slave объявляется следующим образом:
zone "example.org." {
type slave;
file "slave/example.zone";
masters {
192.168.1.1;
};
};
Здесь сказано, что зона имеет тип slave, а сервер, с
которого надо брать информацию о ней (master) имеет адрес
192.168.1.1. Информация о зоне (файл зоны) будет
сохраняться в файле slave/example.zone.
Последняя опция необязательна, если файл не указан,
информация будет храниться в памяти и при перезагрузке
сервера DNS пропадёт.
Зона типа forward применяется в редких случаях, когда надо заставить наш сервер DNS делать запрос о зоне для которой он не авторитетен не к одному из корневых серверов, перечисленных в зоне hint, а к некоторому конкретному серверу. Например, пусть DNS A, расположенный на некотором предприятии, описывает локальную зону local. и делегирует зону finans.local. серверу DNS B. Поскольку сервер A не авторитетен для зоны finans.local., при попытке разрешить имя major-buhg.finans.local., он обратится к корневому серверу DNS (несмотря на то, что он сам делегировал зону finans.local. серверу B) и потерпит неудачу, так как зоны local. с точки зрения корневых серверов не существует. Поэтому на сервере A мы должны описать зону finans.local. типа forward для того, чтобы он переадресовывал запросы к этой зоне на авторитетный для неё сервер B:
zone "local." {
type master;
file "master/local.zone";
};
zone "finans.local." {
type forward;
masters {
192.168.1.2; // server B
};
};
В свою очередь, на сервере B нам, вероятно, надо указать
опцию forwarders, в которой указать сервер
A, тогда опрос сервер B будет производить не с корневых
серверов, а с сервера A и разрешение имён находящихся в зоне
local. будет работать корректно. Кроме того, такое действие
полезно, если на предприятии поднято несколько серверов DNS,
а выход в Интернет на брандмауэре разрешён только серверу A.
...skip...
options {
directory "/etc/namedb";
forwarders {
192.168.1.1; // server A
};
...skip...
}
Файл зоны состоит из перечня записей различного типа. Типы записей в файле зоны были перечислены в Таблица 6.1, «Типы записей в файле зоны DNS». Как уже говорилось, обязательных записей в этом файле всего две: запись типа SOA и запись типа NS в которой указан сервер DNS ответственный за данную зону.
В каждой записи имеется необязательное поле, в котором
указывается время жизни данной записи в кешах серверов DNS.
Чтобы не указывать эту величину в каждой строке (как правило
нет никакого смысла делать различные времена жизни для
разных записей) её можно указать в самом начале файла, задав
переменную $TTL.
Все адреса в файле зоны должны заканчиваться на точку (т.н.
формат FQDN: fully qualified domain
name — полностью описанное имя домена). Если имя
не кончается на точку, к нему дописывается содержимое
переменной $ORIGIN. Если данная
переменная не задана явно, то в ней содержится имя зоны,
т.е. то, что объявлено в файле
named.conf(5).
Другая интересная переменная — $INCLUDE позволяет включить внутрь
одного файла зоны другой файл.
Комментарии в файле зоны начинаются с символа ;.
Первая запись в файле зоны — запись типа SOA. помимо необязательного поля TTL в записи SOA имеется десять обязательных полей, поэтому записать её в одну строку весьма затруднительно. Для того, чтобы запись типа SOA можно было написать в несколько строк, применяются круглые скобки. запись не кончится, пока не закроется круглая скобка.
Вот пример файла зоны с описанием:
$TTL 36000
@ IN SOA ns.example.ru. root.example.ru. (
2006011700 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS ns.example.ru.
IN NS ns1.example.ru.
IN NS ns2.otherplace.ru.
IN MX 5 smtp.example.ru.
IN MX 15 smtp.otherplace.ru.
ns IN A 192.168.0.1
ns1 IN A 192.168.0.2
smtp IN A 192.168.0.1
www IN A 192.168.0.3
site1 IN CNAME www
site2 IN CNAME www
В приведённом примере сперва задана переменная $TTL, затем сделано двенадцать
записей: первая запись типа SOA, три типа NS, две типа MX,
четыре типа A и две типа CNAME.
@ будет
заменён на содержимое переменной $ORIGIN, но мы могли бы написать
явно example.ru..
@
применяться в файле зоны не может (как уже было сказано,
он заменяется на переменную $ORIGIN), вместо него
используется точка. данная запись выглядит как доменное
имя. Можно написать просто root, в этом случае имя будет
достроено до FQDN из переменной $ORIGIN, и первая точка будет
заменена на знак @. Таким
образом, запись root в данном поле превратится в адрес
root@example.ru.
В записи типа NS, в данном примере, отсутствует первое поле. Это значит, что оно будет взято из предыдущей записи. Таким образом, все три записи NS относятся к зоне example.ru. и описывают три сервера авторитетных для данной зоны. Два из них будут slave, а один, упомянутый в записи SOA — master.
Поле с классом записи (IN) так же как и TTL необязательное, и тоже, как и TTL могло бы отсутствовать.
В остальном синтаксис достаточно прост, назначение данной записи — перечислить ответственные за зону сервера DNS, поэтому обязательных полей здесь два: тип записи и имя сервера.
Разумеется сервер DNS не обязан находиться в описываемой зоне. В данном случае упомянут один сервер DNS из другой зоны otherplace.ru. Если сервер находится в нашей зоне, мы должны ниже, в записи типа A указать его адрес, если он в другой зоне, то его адрес должны указать там. Тем не менее нет никаких причин не включить этот сервер ещё и в нашу зону. Это удобнее, так как мы, в этом случае можем сами указать соответствующий IP.
| Замечание |
|---|---|
| Не следует в данной записи указывать IP или имена заданные в записях типа CNAME. Указанные здесь имена должны быть описаны ниже в записи типа A или AAAA. |
![[Важно]](images/important.png) | Важно |
|---|---|
| Хотя согласно правилам построения системы DNS для зоны достаточно иметь один сервер DNS (поэтому запись типа NS обязательна, но может быть единственной), если вы описываете домен второго уровня внутри зоны ru., то по правилам RIPE вы обязаны иметь не менее двух серверов DNS в различных сетях класса C. Т.е. у этих двух серверов обязан отличаться как минимум третий байт в адресе IPv4. |
Здесь описано какие хосты ответственны за приём почты направляющейся в домен example.ru. Если такой записи нет вообще, то почту будет принимать машина с именем example.ru. Если таких записей много, то сперва будет предпринята попытка доставить почту на машину с самым низким значением поля с приоритетом, затем, в случае неуспеха, на машину со следующим приоритетом и так далее.
Итак, данная запись отличается только тем, что в ней добавлено поле с приоритетом записи, сразу после типа записи MX.
| Важно |
|---|---|
| Не следует в данной записи указывать IP или имена заданные в записях типа CNAME. Указанные здесь имена должны быть описаны ниже в записи типа A или AAAA. |
Данная запись указывает соответствие между именем и адресом IP. В случае, если в файле зоны имеется несколько записей с одинаковым именем, но разными адресами, например:
www IN A 192.168.0.1
www IN A 192.168.0.2
www IN A 192.168.0.3
...адреса будут выдаваться сервером DNS циклически: в ответ на первый запрос о имени www.example.ru сервер DNS даст адрес 192.168.0.1, следующему клиенту дадут адрес 192.168.0.2 и дальше по кругу. Это один из способов распределения нагрузки между различными серверами. К сожалению, это не самый удачный способ распределения нагрузки: при аварии на одном из серверов, даже если принять оперативные меры по редактированию файла зоны, в многочисленных кешах ещё долго будет сидеть информация о неработающем сервере и треть клиентов продолжит получать неправильную информацию. Снижение TTL на данные записи приведёт к увеличению нагрузки на систему DNS и в конечном итоге приведёт к замедлению обслуживания клиентов.
Запись этого типа нужна для того, чтобы клиентское програмное обеспечение могло самостоятельно разыскивать машину, на которой поднят нужный сервис и осуществлять распределение нагрузки. К сожалению, немногие браузеры могут похвастать поддержкой этого типа записи в файле зоны. И всё же:
;; _служба._протокол.имя [ttl] IN SRV приоритет вес порт сервер
_http._tcp.www IN SRV 0 1 80 www.server.ru.
IN SRV 0 3 8080 old.server.ru.
В приведённом примере браузер должен осуществить запрос с целью определить на каком сервере и на каком порту обслуживают злужбу http по протоколу tcp. Как результат он получает информацию о том, что эти запросы обслуживают две машины: www.server.ru и old.server.ru. Причём первая обслуживает 25% запросов и работает на порту 80, а вторая обслуживает 75% запросов и работает на порту 8080. Распределение нагрузки осуществляется на основе поля «вес» на добровольной основе, т.е. дано на откуп клиенту.
Поле «приоритет» имеет то же значение, что и для записи MX. Клиент должен обращаться к записи с наименьшим числом в поле «приоритет», и переходить к записи с большим приоритетом, только если сервера из записей с меньшим недоступны.
Имя службы и протокола должно начинаться с подчерка, чтобы не перепутать их с обычными именами. Имена служб и протоколов описаны в [RFC-1700].
Текстовая запись. В ней может находиться самая разнообразная информация. Например стихи:
poem IN TXT ( "The Road goes ever on and on"
"Down from the door where it began."
"Now far ahead the Road has gone,"
"And I must follow, if I can,"
"Purshuing it with eager feet,"
"Until it joins some larger way"
"Where many paths and errands meet."
"And whither then? I cannot say." )
Ёмкость этой записи — пара килобайт. Мы
вполне можем использовать её для хранения коротких
стихотворений, создав доменные имена для разных
поэтов... Однако у этой записи есть множество других,
более полезных применений. В некоторых случаях в ней
хранят публичные ключи. Старые версии BIND хранили в
записях TXT информацию о том, кому можно отвечать на
запросы к зоне (в новых версиях это делается при
помощи директивы allow-query).
Итак, администратор должен уметь не только определять IP адрес машины, но и запрашивать записи о зоне определённого типа. Для осуществления этих запросов существует три команды: host(1), dig(1), nslookup(1).
| Замечание |
|---|---|
Имейте ввиду, все три утилиты работают с системой DNS и ни одна
из них не проверяет файл /etc/hosts. Таким
образом, информация полученная при помощи данных утилит не
обязательно даёт ответ на вопрос «почему мой веб-браузер
идёт на адрес XYZ, когда я ввожу URL http://xyz.org/?».
|
Программа host(1) существует во многих вариантах. В FreeBSD она умеет сообщать практически ту же информацию, что и dig(1), но в других системах это может быть не так. Здесь мы приведём примеры на базе FreeBSD, как наиболее полные.
Запрос IP по адресу:
$ host mail.ru
mail.ru has address 194.67.57.26
mail.ru mail is handled (pri=10) by mxs.mail.ru
Как видно, нам сообщили не только IP машины mail.ru, но и некоторую дополнительную информацию (имя почтовой машины и её приоритет). Эта информация приходит от сервера DNS в том же UDP пакете и её получение не требует со стороны программы host(1) никаких специальных действий. И всё же, некоторые варианты этой программы могут не сообщать всей информации.
Программе можно явно указать сервер DNS, в этом случае запрос будет сделан к нему:
$ host mail.ru 194.67.23.130
Using domain server 194.67.23.130:
mail.ru has address 194.67.57.26
mail.ru mail is handled (pri=10) by mxs.mail.ru
И наконец, можно запросить конкретный тип записи:
$host -t NS mail.ru mail.ru name server ns2.mail.ru mail.ru name server ns3.mail.ru mail.ru name server ns4.mail.ru mail.ru name server ns5.mail.ru mail.ru name server ns.mail.ru mail.ru name server ns1.mail.ru$host -t SOA mail.ru mail.ru start of authority ns.mail.ru hostmaster.mail.ru ( 3209013119 ;serial (version) 300 ;refresh period 900 ;retry refresh this often 172800 ;expiration period 300 ;minimum TTL )
Опция -v включает режим verbose.
$host -t NS -v mail.ru Trying null domain rcode = 0 (Success), ancount=6 The following answer is not authoritative: The following answer is not verified as authentic by the server: mail.ru 16141 IN NS ns4.mail.ru mail.ru 16141 IN NS ns5.mail.ru mail.ru 16141 IN NS ns.mail.ru mail.ru 16141 IN NS ns1.mail.ru mail.ru 16141 IN NS ns2.mail.ru mail.ru 16141 IN NS ns3.mail.ru Additional information: ns.mail.ru 153899 IN A 194.67.23.130 ns1.mail.ru 299802 IN A 194.67.57.103 ns2.mail.ru 167593 IN A 194.67.57.104 ns3.mail.ru 278118 IN A 194.67.23.17 ns4.mail.ru 278118 IN A 194.67.57.4 ns5.mail.ru 278118 IN A 194.67.23.232$host -t SOA -v mail.ru Trying null domain rcode = 0 (Success), ancount=1 The following answer is not authoritative: The following answer is not verified as authentic by the server: mail.ru 21455 IN SOA ns.mail.ru hostmaster.mail.ru ( 3209013119 ;serial (version) 300 ;refresh period 900 ;retry refresh this often 172800 ;expiration period 300 ;minimum TTL ) For authoritative answers, see: mail.ru 15127 IN NS ns.mail.ru mail.ru 15127 IN NS ns1.mail.ru mail.ru 15127 IN NS ns2.mail.ru mail.ru 15127 IN NS ns3.mail.ru mail.ru 15127 IN NS ns4.mail.ru mail.ru 15127 IN NS ns5.mail.ru Additional information: ns.mail.ru 152885 IN A 194.67.23.130 ns1.mail.ru 298788 IN A 194.67.57.103 ns2.mail.ru 166579 IN A 194.67.57.104 ns3.mail.ru 277104 IN A 194.67.23.17 ns4.mail.ru 277104 IN A 194.67.57.4 ns5.mail.ru 277104 IN A 194.67.23.232
В последнем случае нам даже явно рекомендуют обращаться за
информацией на авторитетные серверы и указывают их адреса. С
опцией -v отчёт программы
host(1) становится похож на отчёт
dig(1) (см. ниже) и начинает повтрять
синтаксис файла зоны.
Утилита dig(1) более «разговорчива». Одна из особенностей её отчётов состоит в том, что они даются сразу в формате файла зоны:
$ dig mail.ru
; <<>> DiG 8.3 <<>> mail.ru
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9099
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
;; QUERY SECTION:
;; mail.ru, type = A, class = IN
;; ANSWER SECTION:
mail.ru. 1h56m42s IN A 194.67.57.26
;; AUTHORITY SECTION:
mail.ru. 4h21m12s IN NS ns2.mail.ru.
mail.ru. 4h21m12s IN NS ns3.mail.ru.
mail.ru. 4h21m12s IN NS ns4.mail.ru.
mail.ru. 4h21m12s IN NS ns5.mail.ru.
mail.ru. 4h21m12s IN NS ns.mail.ru.
mail.ru. 4h21m12s IN NS ns1.mail.ru.
;; ADDITIONAL SECTION:
ns.mail.ru. 1d18h37m10s IN A 194.67.23.130
ns1.mail.ru. 3d11h8m53s IN A 194.67.57.103
ns2.mail.ru. 1d22h25m24s IN A 194.67.57.104
ns3.mail.ru. 3d5h7m29s IN A 194.67.23.17
ns4.mail.ru. 3d5h7m29s IN A 194.67.57.4
ns5.mail.ru. 3d5h7m29s IN A 194.67.23.232
;; Total query time: 9 msec
;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2
;; WHEN: Wed Apr 5 14:37:57 2006
;; MSG SIZE sent: 25 rcvd: 244
Символ ; в файле зоны является
комментарием. Заметим, что мы не требовали от программы
dig(1) информацию о серверах NS, и всё же
он запросил её у сервера DNS. Разумеется, это не вся информация
о зоне.
Попробуем запросить информацию о записях SOA и MX.
$dig MX mail.ru ; <<>> DiG 8.3 <<>> MX mail.ru ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28695 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 7 ;; QUERY SECTION: ;; mail.ru, type = MX, class = IN ;; ANSWER SECTION: mail.ru. 4h6m37s IN MX 10 mxs.mail.ru. ;; AUTHORITY SECTION: mail.ru. 4h6m37s IN NS ns2.mail.ru. mail.ru. 4h6m37s IN NS ns3.mail.ru. mail.ru. 4h6m37s IN NS ns4.mail.ru. mail.ru. 4h6m37s IN NS ns5.mail.ru. mail.ru. 4h6m37s IN NS ns.mail.ru. mail.ru. 4h6m37s IN NS ns1.mail.ru. ;; ADDITIONAL SECTION: mxs.mail.ru. 2h4m39s IN A 194.67.23.20 ns.mail.ru. 1d18h22m35s IN A 194.67.23.130 ns1.mail.ru. 3d10h54m18s IN A 194.67.57.103 ns2.mail.ru. 1d22h10m49s IN A 194.67.57.104 ns3.mail.ru. 3d4h52m54s IN A 194.67.23.17 ns4.mail.ru. 3d4h52m54s IN A 194.67.57.4 ns5.mail.ru. 3d4h52m54s IN A 194.67.23.232 ;; Total query time: 2 msec ;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2 ;; WHEN: Wed Apr 5 14:52:31 2006 ;; MSG SIZE sent: 25 rcvd: 264$dig SOA mail.ru ; <<>> DiG 8.3 <<>> SOA mail.ru ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59976 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6 ;; QUERY SECTION: ;; mail.ru, type = SOA, class = IN ;; ANSWER SECTION: mail.ru. 5h51m47s IN SOA ns.mail.ru. hostmaster.mail.ru. ( 3209013119 ; serial 5M ; refresh 15M ; retry 2D ; expiry 5M ) ; minimum ;; AUTHORITY SECTION: mail.ru. 4h6m19s IN NS ns5.mail.ru. mail.ru. 4h6m19s IN NS ns.mail.ru. mail.ru. 4h6m19s IN NS ns1.mail.ru. mail.ru. 4h6m19s IN NS ns2.mail.ru. mail.ru. 4h6m19s IN NS ns3.mail.ru. mail.ru. 4h6m19s IN NS ns4.mail.ru. ;; ADDITIONAL SECTION: ns.mail.ru. 1d18h22m17s IN A 194.67.23.130 ns1.mail.ru. 3d10h54m IN A 194.67.57.103 ns2.mail.ru. 1d22h10m31s IN A 194.67.57.104 ns3.mail.ru. 3d4h52m36s IN A 194.67.23.17 ns4.mail.ru. 3d4h52m36s IN A 194.67.57.4 ns5.mail.ru. 3d4h52m36s IN A 194.67.23.232 ;; Total query time: 6 msec ;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2 ;; WHEN: Wed Apr 5 14:52:50 2006 ;; MSG SIZE sent: 25 rcvd: 275
Для запроса к конкретному серверу DNS его адрес необходимо предварять символом at:
$ dig mail.ru @194.67.23.130
; <<>> DiG 8.3 <<>> mail.ru @194.67.23.130
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62910
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
;; QUERY SECTION:
;; mail.ru, type = A, class = IN
;; ANSWER SECTION:
mail.ru. 6H IN A 194.67.57.26
;; AUTHORITY SECTION:
mail.ru. 6H IN NS ns.mail.ru.
mail.ru. 6H IN NS ns1.mail.ru.
mail.ru. 6H IN NS ns2.mail.ru.
mail.ru. 6H IN NS ns4.mail.ru.
mail.ru. 6H IN NS ns5.mail.ru.
mail.ru. 6H IN NS ns3.mail.ru.
;; ADDITIONAL SECTION:
ns.mail.ru. 6H IN A 194.67.23.130
ns1.mail.ru. 6H IN A 194.67.57.103
ns2.mail.ru. 6H IN A 194.67.57.104
ns4.mail.ru. 6H IN A 194.67.57.4
ns5.mail.ru. 6H IN A 194.67.23.232
ns3.mail.ru. 6H IN A 194.67.23.17
;; Total query time: 91 msec
;; FROM: aluminum.mccme.ru to SERVER: 194.67.23.130
;; WHEN: Wed Apr 5 15:05:16 2006
;; MSG SIZE sent: 25 rcvd: 244
Заметьте, что в этом запросе размеры таймаутов стали более «круглыми» — ровно по 6 часов. Причина в том, что мы задали вопрос авторитетному за эту зону серверу. Ответы, которые мы получали до сих пор мы брали из кешей неавторитетных серверов, поэтому в качестве TTL мы получали время указывающее на то, сколько осталось жить в кеше той или иной записи.
Давайте попробуем узнать с помощью команды dig(1) адреса серверов отвечающих за корневую зону (.) и время жизни записей о корневых серверах.
$ dig NS .
; <<>> DiG 8.3 <<>> NS .
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5359
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 5d1h8m12s IN NS F.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS G.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS H.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS I.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS J.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS K.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS L.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS M.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS A.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS B.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS C.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS D.ROOT-SERVERS.NET.
. 5d1h8m12s IN NS E.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
J.ROOT-SERVERS.NET. 6d1h8m12s IN A 192.58.128.30
;; Total query time: 2 msec
;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2
;; WHEN: Thu Apr 6 11:37:56 2006
;; MSG SIZE sent: 17 rcvd: 244
Очень хорошо, теперь мы знаем что думает о корневых серверах, в настоящий момент обслуживающий нас сервер DNS. Мы видим, что время жизни информации о корневых серверах истечёт через пять дней, один час, восемь минут, двенадцать секунд. Кстати нам, кроме имён корневых серверов, в разделе ADDITIONAL SECTION сказали ещё и адрес одного из серверов. Давайте зададим этот вопрос снова, но теперь не нашему серверу DNS, а сервру j.root-servers.net. с адресом IP 192.58.128.30. Он авторитетен за корневую зону и полученная от него информация будет истиной в последней инстанции.
$ dig NS . @192.58.128.30
; <<>> DiG 8.3 <<>> NS . @192.58.128.30
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50893
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
B.ROOT-SERVERS.NET. 5w6d16h IN A 192.228.79.201
J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
;; Total query time: 299 msec
;; FROM: aluminum.mccme.ru to SERVER: 192.58.128.30
;; WHEN: Thu Apr 6 11:44:56 2006
;; MSG SIZE sent: 17 rcvd: 436
Как видим, истинное время жизни составляет без малого шесть недель (1000 часов). При помощи такого большого TTL сервера пытаются снизить нагрузку на себя.
Поскольку команда dig(1) выдаёт информацию в формате файла зоны, если мы вдруг почему-то потеряли файл с настройками зоны hint, мы можем сохранить вывод данной команды в файл и использовать его.
Наконец, мы можем сделать запрос записи типа TXT, содержащей короткое стихотворение. Это стихотворение мы записали в файл зоны раньше.
$ dig TXT poem.house.hcn-strela.ru
; <<>> DiG 9.3.2 <<>> TXT poem.house.hcn-strela.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8468
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; QUESTION SECTION:
;poem.house.hcn-strela.ru. IN TXT
;; ANSWER SECTION:
poem.house.hcn-strela.ru. 36000 IN TXT "The Road goes ever on
and on" "Down from the door where it began." "Now far ahead the
Road has gone," "And I must follow, if I can," "Purshuing it
with eager feet," "Until it joins some larger way" "Where many
paths and errands meet." "And whither then? I cannot say."
;; AUTHORITY SECTION:
house.hcn-strela.ru. 36000 IN NS ns.hcn-strela.ru.
house.hcn-strela.ru. 36000 IN NS ns1.hcn-strela.ru.
house.hcn-strela.ru. 36000 IN NS ns.house.hcn-strela.ru.
;; ADDITIONAL SECTION:
ns.house.hcn-strela.ru. 36000 IN A 83.102.236.196
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 17 12:05:09 2007
;; MSG SIZE rcvd: 376
nslookup(1) самая древняя программа из этих трёх. Кроме всего прочего она интересна ещё и тем, что входит в стандартную поставку большинства операционных систем компании MicroSoft.
Её синтаксис несколько напоминает синтаксис команды host(1):
$nslookup mail.ru Server: ns.mccme.ru Address: 62.117.108.2 Non-authoritative answer: Name: mail.ru Address: 194.67.57.26$nslookup mail.ru 194.67.23.130 Server: ns.mail.ru Address: 194.67.23.130 Name: mail.ru Address: 194.67.57.26
Но главная изюминка nslookup(1) состоит в том, что она умеет работать интерактивно:
$nslookup Default Server: ns.mccme.ru Address: 62.117.108.2>server 194.67.23.130 Default Server: ns.mail.ru Address: 194.67.23.130>set type=MX>mail.ru Server: ns.mail.ru Address: 194.67.23.130 mail.ru preference = 10, mail exchanger = mxs.mail.ru mail.ru nameserver = ns.mail.ru mail.ru nameserver = ns1.mail.ru mail.ru nameserver = ns2.mail.ru mail.ru nameserver = ns4.mail.ru mail.ru nameserver = ns5.mail.ru mail.ru nameserver = ns3.mail.ru mxs.mail.ru internet address = 194.67.23.20 ns.mail.ru internet address = 194.67.23.130 ns1.mail.ru internet address = 194.67.57.103 ns2.mail.ru internet address = 194.67.57.104 ns4.mail.ru internet address = 194.67.57.4 ns5.mail.ru internet address = 194.67.23.232 ns3.mail.ru internet address = 194.67.23.17>set type=SOA>mail.ru Server: ns.mail.ru Address: 194.67.23.130 mail.ru origin = ns.mail.ru mail addr = hostmaster.mail.ru serial = 3209013119 refresh = 300 (5M) retry = 900 (15M) expire = 172800 (2D) minimum ttl = 300 (5M) mail.ru nameserver = ns.mail.ru mail.ru nameserver = ns1.mail.ru mail.ru nameserver = ns2.mail.ru mail.ru nameserver = ns4.mail.ru mail.ru nameserver = ns5.mail.ru mail.ru nameserver = ns3.mail.ru ns.mail.ru internet address = 194.67.23.130 ns1.mail.ru internet address = 194.67.57.103 ns2.mail.ru internet address = 194.67.57.104 ns4.mail.ru internet address = 194.67.57.4 ns5.mail.ru internet address = 194.67.23.232 ns3.mail.ru internet address = 194.67.23.17>exit
| |  | |
| 6.4. Проверка доступности TCP/IP сервиса |  | 6.6. Определение кто ответственный за зону DNS |