Differences between revisions 3 and 27 (spanning 24 versions)
Revision 3 as of 2008-07-03 23:37:47
Size: 27575
Editor: PavelSutyrin
Comment:
Revision 27 as of 2009-03-22 23:09:00
Size: 29529
Editor: eSyr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
{01:17:35}

Теперь обратимся к тому, как это работает в альте. Есть
файл /etc/resolv.conf, давайте на него посмотрим. В буквально
несколько строчек, как правило, следующего вида: либо Одни
{{{search имя_домена}}}, либо {{{nameserver ip-адрес}}}. Это значит, что
преобразование доменного имени в ip-адрес будет происходить
следующим образом: : если вы указали не полное доменное имя,
а какое-то имя домена, имя, то к нему будет приделана строчка,
в данном случае, prov.ru, (Максим, скажите что-нибудь типа {{{ping www}}},
а мы посмотрим (..) Ну, попробуйте {{{host www}}}, а нет, {{{host}}} туда не
ходит, он сразу к nameserver'у ходит. Опять у информики отвалилась
крыша. Скажите {{{ip r}}}. Откройте traceroute, посмотрим... {{{-l}}}, ух,
нифига себе, это что за номер. А, dns отвалился тем временем. У
них пинг-понг уже происходит где-то.... вот здесь, очень близко
(третий, что ли, хоп).

Да, почему это вообще файл: Мы вот запускали кучу программ:
броузер, ping, telnet, мы запускали кучу разных утилит, неужели они
все ходят в один и тот же файл, чтобы произвести эту самую
подстановку?.. На самом деле, это делает некая библиотека,
с которой все эти утилиты как она скомпилированы. Т.е.,
преобразование адресов в обе стороны --- это дело, на самом деле,
некой библиотеки, которая называется libresolv или попросту resolver,
и небольшое достоинство Линукс как раз в том и состоит, что
поскольку все программы свободные, то мы можем один раз написать
вот этот вот алгоритм превращения, и потом все программы будут
этим пользоваться, просто при компиляции мы собираем... (...) А
это одно и то же, да.. ну да, линкуется он динамически.

Есть некая тонкость с libresolv, он работает на довольно низком
уровне, и часть кода чуть не от рута выполняется, поэтому в
альтлинуксе такая специфика: resolver вынесен в изолированное
окружение, и для обновления конфигов есть alt-specific (характерная
для Альтлинукса) команда {{{update_chrooted all}}}. Эта команда записывает
целую кучу разных конфигурационных файлов из /etc в целую
кучу изолированных окружений, где их хотят. В альтлинуксе
используется сразу несколько изолированных окружений для
разных служб, которые потенциально могут быть опасны, и ребята,
которые занимаются security попросту не уверены, что они до конца
прочитали и выучили наизусть весь исходный код, чтобы понять, что
там нет никаких ошибок, поэтому на всякий случай они их.. ребята,
да, Дима Левин, поэтому он на всякий случай запихнул системную
службу в изолированное окружение, и, поскольку запущенная
в изолированном окружении программа ничего не видит, кроме
каталога, в котором она запущена и подкаталогов его, то туда-то
как раз и надо копировать. Для того, чтобы увидеть, что он
использует, можно посмотреть {{{ls /var/resolv/}}}. Что у нас есть? {{{etc/}}},
посмотрим что там -- как раз те самые вещи, которые относятся к
процедуре преобразования адресов, hosts, localtime понятно почему, namespace
switch (?), ничего не буду про него говорить, простая штука, но мимо
темы, файл resolv.conf, который, если бы мы его меняли, пришлось бы его
туда скопировать, и файл их /etc/serviced (?), еще там есть библиотеки,
нужные для библиотеки resolver'а, libresolv, libnss, libnsl, я не знаю что это
такое. поскольку многие службы у нас работают в изолированном
окружении, так и resolver, и наша задача регулярно, когда мы меняем
один из этих конфигурационных файлов, выполнять командочку
{{{update_chrooted all}}} и {{{update_chrooted conf}}}, потому что там еще библиотеки
копируются, чтобы они туда копировались. ЭТо специфика альта.

{01:27:20}

Теперь посмотрим, как работает dns-запрос. Стоп, сейчас мы
все сделаем. У нас, как мы говорили, есть libresolv и подсистема
резолверов, которой пользуются разные программы, типа ping'а или
того же самого firefox'а для преобразования адресов. Кстати сказать,
есть задача не только преобразования доменного имени в ip-адрес,
но и задача обратного преобразования ip-адреса в доменное имя.
Это бывает нужно, например, в случае, когда происходит какая-то
нежелательная сетевая активность с какого-то ip, и хочется
понять, что за сайт стоит за этим айпишником. Например, пересылка
почты. Например, мы хотим пересылать почту только для таких-то
доменов, вплоть до своего собственного, при этом именно для
доменов, для тех машин, которые мы сами зарегистрировали, ну у
этих доменов могут быть довольно разнообразные ip-адреса. Вот
происходит подключение с какого-то ip-адреса, вот разрешать
этому почтовому клиенту пересылать почту, или нет? Ответ очень
простой, давайте выясним его доменное имя, и в зависимости от
этого доменного имени выясним, разрешить ему это делать, или нет.

(dns прочухался, или закэшировался, попробуйте ya.ru
сказать... интернет прочухался не весь, ну ладно)

Обратите внимание, обратное преобразование и здесь
(?) происходило, мы запустили программу {{{ping}}}, эта программа
получила некоторый icmp ответ от 194.85.40.34, и специально
для нас она произвела обратное преобразование адресов и
превратила 194.85.40.34 в m10.gv1.msk.ranet.ru. Это вот такой пример неявного
обратного преобразования адресов, который делают за нас,
не по нашей просьбе. Существует две утилиты (на самом деле,
их больше), используются (явно) для преобразования адресов. Их
существует три, но их еще не существует. Если вы найдете книжку,
в которой вам порекомендуют для явного преобразования адресов
воспользоваться утилитой nslookup, знайте, что это устаревшая
штука, nslookup'а уже нет. Некоторое время он в альте был, но он
запускался с предупреждением, что "а вы знаете, что вы запускаете
устаревшую...", да, да, он deprecated, вы думайте, что делать.


Есть простейшая программа hostinfo, давайте скажем {{{hostinfo ya.ru}}},
которая выводит простейшую. информацию о ya.ru, она выводит
на него также и алиасы и tcname'ы, то есть, если в сети несколько
имен у одной машины, то она может узнать, а может и не узнать,
что эти имена есть у одного ip-шника. Более сложная программа
называется host, возможно, она не входит в стандартный состав
дистрибутивов. Лично лектор привык пользоваться программой
dig, которая занимается тем же самым. Входит dig в пакет bind-utils.
Давайте попробуем {{{dig ya.ru}}}. То что начинается с {{{;}}} --- это
комментарий. Формат выдачи соответствует формату хранения
этих данных в этой вот распределенной базе данных DNS. Мы видим,
что у адреса ya.ru есть ip-шник, вот он, мы видим, что за зону ya.ru
отвечают два доменных сервера, (первый и пятый) Ну, на самом деле
их больше, но здесь два. Да, может быть там круглая малиновка, нет
там не круглая малиновка. Да? round robin переводится как "круглая
малиновка", шарообразная малиновка, сферическая... На всякий
случай dig рассказала вам, какие ip-адреса у этих ns-серверов,
кстати, идея относительно зон класса B подтверждается, явно
две разных сети класса B, и еще всякую статистику вывела в
комментариях, сколько времени это происходило, кто на самом
деле ответил на этот запрос, обратите внимание, ответил на
этот вопрос наш сервер локальный, который мы сами прописали в
resolv.conf. Мы можем вызвать команду {{{dig ya.ru @ns5.yandex.ru}}}, как видите,
разницы никакой, за исключением того, что вам ответил на запрос
сам сервер ns5.yandex.ru. Этот как раз та самая ситуация, когда мы
с запросом обратились непосредственно к dns-серверу. Давайте
попробуем обратиться к нему с рекурсивным запросом, стрелка
вверх, напишите здесь что-нибудь вроде {{{cdrom.com}}}. Смотрите что он
сделал, он отказался обслуживать рекурсивный запрос, он говорит,
"не знаю". Почему? Потому что ребята из яндекса совершенно не
хотят отвечать на рекурсивные dns-запросы, исходящие из npg (?),
не относящиеся к яндексу.

{01:35:42}

А если мы уберем эту блямбу и обратимся к местному серверу,
то он подумал, аж три секунды, нет, три десятых секунды думал,
нашел что домен такой есть, а ip-адреса у него нет. Кстати, это
тоже полезная информация. Смотрите, ip-адреса, соответствующего
этому доменному имени, не существует, зато существует сам
домен. О чем это нам говорит надпись SOA state of authority (?). А это надо
{{{-t any}}} сказать, давайте скажем. В записи dns могут лежать записи
любого вида. Запись типа A (адрес) --- это одна из многих возможных
записей. Какие еще записи лежат? Во-первых, это мы уже видели
много раз, записи типа NS, адреса nameserver'ов, когда мы спросили
у команды dig, а расскажите нам все про домен cdrom.com, сказали,
типа записи любой (-t any), попросили все записи, которые про
него существуют. Ну, например, оказывается у cdrom.com есть машина,
которая пересылает почту, MX, mail exchanger. Приоритет у этого почтового
сервера 10 (их может быть несколько), и он называется pipe.cdrom.com,
дальше выбирайте сами. Кстати, dig нам для этого его подумал (?),
вот. Во-вторых, у домена cdrom.com есть запись типа TXT, в которой
хранится вот такая штука. ЭТо SPF, гадость. Ну, лежит, какой-то
текст, этому делу ассоциированный. В третьих, у домена cdrom.com есть
запись типа SOA, state of authority, которая определяет вот эти числа,
те самые время жизни, время обновления, и т.п., расшифровывать
не будут, это серийный номер 2007100313, похоже, на дату похоже, да,
это удобно, когда зону меняешь, текущую дату вписываешь и тем
самым этот серийный номер все время увеличивается, а дальше
там время жизни, время последнего обновления, время жизни всего
домена, и т.п. А дальше дополнительная информация. Оказывается,
относительно домена cdrom.com у нас лежит аж три типа записей -- MX,
TXT, SOA, Давайте мы с помощью dig сделаем обратно преобразование,
скажем dig -x на (вот этот вот адрес), а, ну как обычно оно опять
умерло. Да ладно, почтовик, давайте попробуем кого-нибудь
попинать, работает... Давайте dig -x вот этому (?) скажем, ага. Ну,
плохо живется в жизни, ну вот, очень хорошо. Как видите, это
совсем другая база, в которой лежат обратные соответствия,
т.е. ip-адресов именам, тип этот называется ptr, от слова pointer, самое
забавное, в какой форме представляются ip-адреса, особенно те, кто
не знает, посмотрите внимательно, найдите четыре сходства между
тем ip-адресом, который мы в команде dig использовали, и вот этой
штукой. Вот кто не в курсе, тем будет интересно. Все заметили,
что это такое? Это этот ip-адрес, записанный задом наперед. Почему
так?.. Дело в том, какому алгоритму раздаются диапазоны адресов,
Нам скорее всего, раздадутся адреса, допустим, 213.180/16. Это значит,
что ответственный за этот домен, которому выдали 213.180/16, он будет
обязан отвечать на запросы типа dig -x, то есть типа ptr, для всех этих
65 тысяч компьютеров. Как это вместить в базу данных dns, которая
устроена задом наперед, она должна seek'ать в обе стороны, nc.cs.msu.su,
imap.cs.msu.su. Да очень просто, записать задом наперед 8.204.180.213, потом
взять оторвать от него половину, ну здесь была не половина,
а последний байт, это означает что у нас есть некий сервер,
который отвечает за диапазон адресов 213.180.204.0/24, и вот именно
он нам ответил, ns1.yandex.net нам ответил. Авторитарный, вот он. То
есть, вот такая зона, которая хранит эти самые адреса, всегда
кончается на inaddr_arpa (?), вот, и дальше у нее задом наперед идет
прописанный адрес соответствующего... идея состоит в том, что
вот у нас домен, вот это вот домен, какая разница? бывает cs.msu.su,
а бывает 204.180.213.inaddr.arpa. Итак, про утилиты dig, host, hostinfo я рассказал.

Я бы вернулся вот к этому. И все-таки, как узнать, какой
организации принадлежит такой-то ip-адрес, или даже
такой-то... ? Для этого есть служба whois. whois, допустим, ya.ru. Ну, нету
whois'а... А это пароль, типа сказать?...

(как там... 102.68.200.10 предлагаю сделать перерыв, или перерыв после
этого сделаем) ... это надо скопировать куда-нибудь, с этого
места скрипта никакого нет (ssh), так что скопируйте. Смотрите,
о чем я сейчас говорю.

Все-таки, DNS не предназначен для выяснения административных
отношений, он предназначен для построения распознаваемой
топологии сети, связанной с этим самым административным
положением. Для выяснения административных отношений
на сегодняшний день используется служба whois. Выглядит это
следующим образом: когда вы регистрируете доменное имя, вы это
делаете так: либо идет к системному администратору и говорите:
выдай мне поддомен какой-нибудь поменьше, либо идете к некоей
организации, которая раздает доменные имена, и платите ей за
домен второго уровня, там, за .ru, значит вот. В этом случае, когда
вы регистрируете домен второго уровня, вы заноситесь в базу
данных, доступную вот этому whois'у, в "информация о вас". Вот домен
ya.ru, состояние: он зарегистрированный и права на его управление
переданы администратору, организация: Яндекс, телефон, факс,
почта, регистрационный номер того, кто регистрировал, regisrar
это регистратор, в 99 году они это дело придумали, до 2008 года
они это оплатили, через месяц у них это закончится. Давайте
все закиберсквоттим ya.ru, а, у них еще будет месяц, у него будет
состояние pending. Эх, не получится, я думаю, яндекс первый просечет,
что у них просрочился домен. (Наверное вот на этот почтовый
адрес придет письмо?) Нет, гораздо интереснее, начнут туда
ломиться ногами пользователи, которые перестанут ходить на
ya.ru. Обратите внимание на комментарии вот на эти, такие службы
регистрации -- их несколько, поэтому совершенно необязательно
будет написано, что это вот так вот будет работать. Попробуйте
google.com. А, ну умерло. А нет, оно.... wow.. слушайте, как тут много всего,
ну, спасибо гуглу. ... dns about.com... daddy.com.. какой-то шведский, что
ли.. давайте дальше смотреть, мне интересно стало, vm vietnam,.. кароче,
люди нашли.. ua -- это Украина? О, Китай, нет, Тайвань. sprosiuyandeksa.ru?... Я
вот что хотел рассказать. На самом деле этих whois-серверов на
свете довольно много, и процедура их регистрации в качестве
сервера, отвечающего на whois-запросы, она довольно причудливая и
то что мы сейчас видим как раз, это результат того, что какие-то
люди, видимо, решившие заработать на том, что бы слить это потом
гуглу за деньги, или организовать нормальный фишинг, если это там
происхоидит проверка, и так далее... прикольно. может это гуглоиды
сами придумали?.. Дальше, там будет настоящий. markmonitor, это он
и есть. Алгоритм выяснения этого whois'а достаточно непонятный,
например домены в зоне us штатские, вы можете получить вместо
информации некий идентификационный номер, соответствующий
штатам, а дальше позвоните по такому-то телефону, заплатите
столько-то баксов, вам все расскажут.

Точно также и даже гораздо полезнее производить поиск whois по
ip-адресу, там будет видно, какие сети, какой организации какие
диапазоны выданы, давайте попробуем.

(62.117.86.102), не, ждем. во-первых, информация взята из RIPE, это русский
диапазон, которые раздаёт адреса в России, вот диапазон верхнего
уровня, кстати сказать, всего 256 адресов, не так интересно. А, там
даже меньше, тут больше, тут /18. Вот это, видимо, основной ответ,
диапазон адресов /24 выдан ЗАО НПО ПРАКТЕХ, какой-то практех.ру,
Московская область, г. Жуковский, ну и так далее. Теперь вопрос в
том, какой автономной системе это принадлежит, комкор, им выдан
диапазон /18, и они из своего /18 выдают ниже, вот они нарезали,
выдали ниже. Достаточно разумная информация, из которой видно,
кто реальный владелец этого ip-адреса, и кто ему этот ip-адрес
выдал. Такая вот штука.

Перерыв 10 минут.

{01:56:17}
=== Файл /etc/resolfv.conf ===

Обратимся теперь собственно к ПСПО. Посмотрим на файл /etc/resolv.conf:

{{{
# cat /etc/resolv.conf
# Generated by dhcpcd for interface eth0
search prov.ru
nameserver 194.190.241.162
nameserver 194.226.215.65
}}}

Как видно, в нашем случае в нем всего четыре строки, первая из которых - комментарий. В строках вида {{{nameserver ip-адрес}}} указаны адреса DNS-серверов. Строка {{{search имя_домена}}} означает, что преобразование доменного имени в IP-адрес будет происходить следующим образом: если указано не полное имя домена, а только имя компьютера, то {{{имя_домена}}} будет приписано к имени компьютера через точку, и только затем имя будет преобразовываться в IP-адрес.


=== Библиотека libresolv ===


Преобразование имени в адрес и обратно используется в большом количестве различных программ. Программы-браузеры, утилиты типа ping и telnet -- неужели все они при своей работе читают этот файл? На самом деле эту работу за них проделывает специальная библиотека --- libresolv, или попросту resolver на общепринятом сленге. Отметим, что одно из достоинств операционной системы GNU/Linux как раз и состоит в том, что большинство используемых программ --- свободные, а потому, реализовав однажды применяемый алгоритм и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над механизмом выполнения подобных операций.

С использованием libresolv связан следующая тонкий момент. В операционной системе эта библиотека работает на довольно низком уровне, причем часть кода должна выполняться практически с правами суперпользователя. Понятно, что это может представлять серьезную угрозу в случае некорректной работы этой библиотеки, в случае обнаружения в ней ошибки. Поэтому в ПСПО ALT Linux для библиотеки преобразования имён создано специальное изолированное окружение. Для обновления необходимых для работы библиотеки данных (конфигурационных файлов) есть специальная команда:

{{{
# update_chrooted conf
}}}

Эта команда записывает множество различных конфигурационных файлов из /etc в различные нуждающиеся в них изолированные окружения. В ПСПО используется сразу несколько изолированных окружений для различных сервисов, которые могут быть потенциально опасными. На самом деле это означает, что занимающиеся вопросами безопасности в ALT Linux люди не уверены, что в коде соответствующих программ нет ошибок, а потому считают нужным эти программы изолировать. Запущенная в изолированном окружении программа может пользоваться только той частью файловой системы, в которой она запущена - это некоторый специально выделенный каталог и все дерево его подкаталогов. Именно туда и следует копировать конфигурационные файлы. В нашем случае изолированное окружение для библиотеки преобразования имён находится в /var/resolv:

{{{
# ls /var/resolv/
etc lib var
}}}

Конфигурационные файлы в изолированном окружении (как и в основной файловой системе) лежат в каталоге etc:

{{{
# ls /var/resolv/etc/
host.conf hosts localtime nsswitch.conf resolv.conf services
}}}

Среди них, как и ожидалось, есть и {{{hosts}}}, и {{{resolv.conf}}}. Присутствует здесь и файл services. Сама библиотека и используемые ее библиотеки лежат в {{{/var/resolv/lib}}}.

{{{
# ls /var/resolv/lib/
libnsl.so.1 libnss_hesiod.so.2 libnss_nis.so.2
libnss_dns.so.2 libnss_mdns4.so.2 libnss_nisplus.so.2
libnss_files.so.2 libnss_mdns4_minimal.so.2 libresolv.so.2
}}}

Как видим, здесь есть libnss и libnsl, нужные для работы resolver'a, а также сам libresolv. Еще раз отметим, что при изменении хотя бы одного из конфигурационных файлов в {{{/etc}}} (кроме файлов в каталоге {{{/etc/net}}}, о которых будет рассказано далее) необходимо выполнить команду {{{update_chrooted conf}}} для обновления конфигурации ограниченных окружений.

=== Прямое и обратное преобразование ===

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

Заметим, что обратное преобразование производят и вспомогательные утилиты, например утилита {{{traceroute}}} для обнаружения последовательности маршрутизаторов до некоторого адреса:
{{{
$ traceroute www.ru
...
7 msk-bgw1-ae0-350.rt-comm.ru (217.106.2.157) 51.970 ms 53.449 ms 53.882 ms
8 msk-dsr8-ge8-19.rt-comm.ru (217.106.1.134) 43.304 ms 44.741 ms *
9 iki-c1-vl10.demos.net (194.87.0.111) 49.192 ms * *
10 www.ru (194.87.0.50) 14.069 ms 14.148 ms 14.271 ms
}}}

Здесь доменное имя www.ru было преобразовано в IP-адрес 194.87.0.50, на который и отправлялись пакеты. IP-адреса обнаруженных маршрутизаторов преобразовывались в их DNS-имена. Заметим, что явного указания выполнять это преобразование мы не давали. Чтобы утилита {{{traceroute}}} таких преобразований не выполняла, следует вызывать ее с ключом {{{-n}}}.

Для явного преобразования IP-адресов в доменные имена и обратно можно использовать несколько специальных утилит. Не все из них одинаково удобны для пользователя (одна --- {{{nslookup}}} --- вообще считается устаревшей). Посмотрим на простейшую из них - {{{hostinfo}}}:

{{{
$ hostinfo ya.ru
address: 213.180.204.8
hostname: ya.ru
aliases:
}}}

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

Более сложная программа для преобразования имен в адреса и обратно называется {{{host}}}:

{{{
$ host -a ya.ru
Trying "ya.ru"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60336
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ya.ru. IN ANY

;; ANSWER SECTION:
ya.ru. 7030 IN NS ns5.yandex.ru.
ya.ru. 7030 IN NS ns1.yandex.ru.
ya.ru. 7030 IN A 213.180.204.8

;; AUTHORITY SECTION:
ya.ru. 7030 IN NS ns5.yandex.ru.
ya.ru. 7030 IN NS ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns5.yandex.ru. 345430 IN A 213.180.204.1
ns1.yandex.ru. 345430 IN A 213.180.193.1

Received 142 bytes from 194.190.241.162#53 in 66 ms
}}}

Примерно так же работает и программа {{{dig}}} из пакета bind-utils:

{{{
$ dig ya.ru

; <<>> DiG 9.3.5 <<>> ya.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ya.ru. IN A

;; ANSWER SECTION:
ya.ru. 7012 IN A 213.180.204.8

;; AUTHORITY SECTION:
ya.ru. 7012 IN NS ns5.yandex.ru.
ya.ru. 7012 IN NS ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns5.yandex.ru. 345412 IN A 213.180.204.1
ns1.yandex.ru. 345412 IN A 213.180.193.1

;; Query time: 6 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul 3 17:54:40 2008
;; MSG SIZE rcvd: 114

}}}

Начинающиеся с точки с запятой строки --- это комментарии. Формат выдачи соответствует формату хранения данных в распределенной базе данных DNS. Видно, что имени ya.ru соответствует IP-адрес 213.180.204.8, а за зону ya.ru отвечают два доменных сервера: {{{ns1.yandex.ru}}} и {{{ns5.yandex.ru}}}. На всякий случай {{{dig}}} вывела также IP-адреса этих серверов (заметим, что это действительно адреса из двух различных сетей класса B), а также различную статистику в комментариях: сколько времени заняло ожидание ответа, кто на самом деле ответил на запрос и пр. Заметим, что наш запрос был обслужен локальным сервером, указанным в /etc/resolv.conf. Добавим теперь в командную строку новый параметр:

{{{
$ dig ya.ru @ns5.yandex.ru

; <<>> DiG 9.3.5 <<>> ya.ru @ns5.yandex.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54389
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru. IN A

;; ANSWER SECTION:
ya.ru. 7200 IN A 213.180.204.8

;; AUTHORITY SECTION:
ya.ru. 7200 IN NS ns1.yandex.ru.
ya.ru. 7200 IN NS ns5.yandex.ru.

;; Query time: 6 msec
;; SERVER: 213.180.204.1#53(213.180.204.1)
;; WHEN: Thu Jul 3 17:56:50 2008
;; MSG SIZE rcvd: 82
}}}

Результаты не поменялись, однако на запрос ответил сам сервер {{{ns5.yandex.ru}}}. Это как раз та самая ситуация, когда мы обратились к серверу, непосредственно отвечающему за нужную нам зону. Попробуем обратиться к этому же серверу с другим запросом:

{{{
$ dig cdrom.com @ns5.yandex.ru

; <<>> DiG 9.3.5 <<>> cdrom.com @ns5.yandex.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42056
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cdrom.com. IN A

;; Query time: 6 msec
;; SERVER: 213.180.204.1#53(213.180.204.1)
;; WHEN: Thu Jul 3 17:57:19 2008
;; MSG SIZE rcvd: 27
}}}

Обратим внимание, что сервер отказался обслуживать рекурсивный (по умолчанию) запрос. По сути дела, он ответил: "Не знаю". Понятно, что у держателей ya.ru нет никаких причин отвечать на рекурсивные DNS-запросы от посторонних (для них) узлов.

Что же будет, если мы обратимся к местному серверу?

{{{
$ dig cdrom.com

; <<>> DiG 9.3.5 <<>> cdrom.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58456
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;cdrom.com. IN A

;; AUTHORITY SECTION:
cdrom.com. 300 IN SOA cdrom.com. root.digitalriver.com. 2007100313 600 300 604800 300

;; Query time: 300 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul 3 17:57:55 2008
;; MSG SIZE rcvd: 90
}}}

Итак, домен cdrom.com существует (об этом говорит запись типа SOA - state of authority), а IP-адреса у него нет, - весьма полезная информация. Запросим теперь записи произвольных типов ({{{-t any}}}):

{{{
$ dig cdrom.com -t any

; <<>> DiG 9.3.5 <<>> cdrom.com -t any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;cdrom.com. IN ANY

;; ANSWER SECTION:
cdrom.com. 3600 IN MX 10 pike.cdrom.com.
cdrom.com. 300 IN TXT "v=spf1 include:spf-dc1.digitalriver.com include:spf-dc2.digitalriver.com include:spf-dc7.digitalriver.com include:spf-dc5.digitalriver.com include:spf-dc6.digitalriver.com ~all"
cdrom.com. 0 IN SOA cdrom.com. root.digitalriver.com. 2007100313 600 300 604800 300

;; AUTHORITY SECTION:
cdrom.com. 172757 IN NS 3dns1.digitalriver.com.
cdrom.com. 172757 IN NS 3dns3.digitalriver.com.
cdrom.com. 172757 IN NS dc7dns01.digitalriver.com.

;; ADDITIONAL SECTION:
pike.cdrom.com. 3600 IN A 204.216.28.222
3dns1.digitalriver.com. 172757 IN A 208.217.74.35
3dns3.digitalriver.com. 172757 IN A 66.192.77.35
dc7dns01.digitalriver.com. 172757 IN A 81.21.144.40

;; Query time: 202 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul 3 17:58:37 2008
;; MSG SIZE rcvd: 427
}}}

Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS --- адреса серверов имен (''!NameServers''). У домена cdrom.com есть машина, которая пересылает почту (запись типа MX --- ''Mail eXchanger''). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF --- специальная информация, часто используемая для борьбы со спамом). Есть запись типа SOA (которую мы уже видели), содержащая служебную информацию ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе {{{dig}}} есть дополнительная информация, о которой сейчас говорить не будем.

Выполним теперь с помощью {{{dig}}} обратное преобразование ({{{-x}}}) для IP-адреса 213.180.204.8, который мы получили при запросе о {{{ya.ru}}}:

{{{
$ dig -x 213.180.204.8

; <<>> DiG 9.3.5 <<>> -x 213.180.204.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2747
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

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

;; ANSWER SECTION:
8.204.180.213.in-addr.arpa. 13746 IN PTR ya.ru.

;; AUTHORITY SECTION:
204.180.213.in-addr.arpa. 8820 IN NS ns1.yandex.net.
204.180.213.in-addr.arpa. 8820 IN NS ns2.yandex.net.

;; ADDITIONAL SECTION:
ns1.yandex.net. 64148 IN A 213.180.193.1
ns2.yandex.net. 64148 IN A 213.180.199.34

;; Query time: 6 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul 3 18:02:26 2008
;; MSG SIZE rcvd: 141
}}}

Как видно, соответствия IP-адресов именам лежат в отдельной базе. Тип соответствующих записей называется PTR (''pointer'' --- указатель). Интересно отметить, в какой форме представляются в этой базе IP-адреса. Запрашивается по сути дела домен следующего вида: IP-адрес, записанный "наоборот", к которому через точку приписана строка ''in-addr.arpa''. Почему так? Дело тут в алгоритме, по которому раздаются диапазоны адресов. Пусть мы получили, к примеру, адреса 213.180.0.0/16. Это означает, что ответственный за этот домен сервер имен должен отвечать на обратные запросы для всех соответствующих компьютеров. Но как это сделать, ведь база DNS устроена по другому принципу и, например, за имена cs.msu.ru и cmc.msu.ru отвечает один и тот же сервер? При создании сервера, ответственного, например, за поддиапазон 213.180.204.0/24, разумно записывать числа из IP-адресов в обратном порядке. Соответствующая зона будет выглядеть как 204.180.213.in-addr.arpa, логика же работы DNS не изменится! Действительно, принципиальной разницы между доменами msu.ru и 204.180.213.in-addr.arpa с этой точки зрения нет.


=== Служба whois ===

Вернемся к поставленной ранее задаче. Как узнать, какой организации принадлежит тот или иной IP-адрес или диапазон? Для этого есть служба whois. Действительно, система DNS не предназначена для выяснения административных отношений. Ее удобно использовать для построения распознаваемой топологии сети, связанной с этими отношениями. Система whois же привязана к регистрации доменных имен. Данная процедура проводится либо системным администратором, который может выделить для тех или иных целей поддомен, либо специальной организацией, торгующей доменными именами, скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе:

{{{
$ whois ya.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain: YA.RU
type: CORPORATE
nserver: ns5.yandex.ru.
nserver: ns1.yandex.ru.
state: REGISTERED, DELEGATED
org: YANDEX, LLC.
phone: +7 495 7397000
fax-no: +7 495 7397070
e-mail: noc@yandex.net
registrar: RUCENTER-REG-RIPN
created: 1999.07.12
paid-till: 2008.08.01
source: TC-RIPN
Last updated on 2008.07.03 18:04:47 MSK/MSD
}}}

Итак, домен ya.ru зарегистрирован, права на управление им переданы администратору. Указана организация, телефон, факс, почтовый адрес. Поле "Registrar" - это регистратор (указана дата регистрации и дата, до которой использование этого доменного имени считается оплаченным). Обратим внимание на службу регистрации - их несколько, поэтому совершенно необязательно whois будет работать именно так. Вообще, алгоритм выяснения whois'а довольно хитр. К примеру, запрашивая информацию по доменам вида *.us, можно иногда получить специальный идентификационный номер с предложением позвонить по особому номеру телефона ("заплатите нам столько-то и мы вам все расскажем").

Серверов службы whois на свете довольно много, а процедура их регистрации весьма причудлива. Как следствие, результаты whois-запросов могут быть весьма непредсказуемы. К примеру, ответ на запрос {{{whois google.com}}} может содержать более двухсот строк, причем полезными, по-видимому, можно считать менее половины из них.

Можно производить поиск информации whois и по IP-адресам:
{{{
$ whois 62.117.85.102
% This is the RIPE Whois query server #3.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '62.117.85.0 - 62.117.85.255'

inetnum: 62.117.85.0 - 62.117.85.255
netname: COMCOR-PROGTEH
descr: Network for ZAO NPO "Progteh"
country: RU
admin-c: CNA3-RIPE
tech-c: CNA3-RIPE
status: ASSIGNED PA
mnt-by: AS8732-MNT
source: RIPE # Filtered

person: Chicherov Nikolay Andreevich
e-mail: sysadmin@progtech.ru
address: Russia, Mosk. obl., g.Zhukovskiy, Amet-Han Sultana
phone: +7 495 824831031
mnt-by: AS8732-MNT
nic-hdl: CNA3-RIPE
source: RIPE # Filtered

% Information related to '62.117.64.0/18AS8732'

route: 62.117.64.0/18
descr: comcor.ru
origin: AS8732
mnt-by: AS8732-MNT
source: RIPE # Filtered

% Information related to '62.117.85.0/24AS35475'

route: 62.117.85.0/24
descr: Progtech ISP
origin: AS35475
mnt-by: AS8732-MNT
source: RIPE # Filtered
}}}

Как видно, информация взята из RIPE --- это регистратор, который раздает адреса в России. В основном ответе указано, что диапазон 62.117.85.0/24 выдан ЗАО "НПО Прогтех", есть соответствующий адрес сайта, а также адрес: Московская область, город Жуковский и т. д. К какой же автономной системе принадлежит этот диапазон? Это comcor, чей диапазон 62.117.64.0/18. Они этот диапазон "нарезали" и отдали поддиапазон 62.117.85.0/24 "вниз". Вообще, это вполне разумная информация, из которой ясно, кто реальный владелец данного IP-адреса и кто ему этот IP-адрес выдал.
Line 272: Line 372:
|| 20 || 1 || 1 || 1 || || 1 || PavelSutyrin (расшифровка завершена), DmitryChistikov    || || || || 90 || 1 || 1 || 1 || || 1 || PavelSutyrin, DmitryChistikov, VsevolodKrishchenko || || ||

Преобразование имён и IP-адресов: практика

Файл /etc/resolfv.conf

Обратимся теперь собственно к ПСПО. Посмотрим на файл /etc/resolv.conf:

# cat /etc/resolv.conf
# Generated by dhcpcd for interface eth0
search prov.ru
nameserver 194.190.241.162
nameserver 194.226.215.65

Как видно, в нашем случае в нем всего четыре строки, первая из которых - комментарий. В строках вида nameserver ip-адрес указаны адреса DNS-серверов. Строка search имя_домена означает, что преобразование доменного имени в IP-адрес будет происходить следующим образом: если указано не полное имя домена, а только имя компьютера, то имя_домена будет приписано к имени компьютера через точку, и только затем имя будет преобразовываться в IP-адрес.

Библиотека libresolv

Преобразование имени в адрес и обратно используется в большом количестве различных программ. Программы-браузеры, утилиты типа ping и telnet -- неужели все они при своей работе читают этот файл? На самом деле эту работу за них проделывает специальная библиотека --- libresolv, или попросту resolver на общепринятом сленге. Отметим, что одно из достоинств операционной системы GNU/Linux как раз и состоит в том, что большинство используемых программ --- свободные, а потому, реализовав однажды применяемый алгоритм и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над механизмом выполнения подобных операций.

С использованием libresolv связан следующая тонкий момент. В операционной системе эта библиотека работает на довольно низком уровне, причем часть кода должна выполняться практически с правами суперпользователя. Понятно, что это может представлять серьезную угрозу в случае некорректной работы этой библиотеки, в случае обнаружения в ней ошибки. Поэтому в ПСПО ALT Linux для библиотеки преобразования имён создано специальное изолированное окружение. Для обновления необходимых для работы библиотеки данных (конфигурационных файлов) есть специальная команда:

# update_chrooted conf

Эта команда записывает множество различных конфигурационных файлов из /etc в различные нуждающиеся в них изолированные окружения. В ПСПО используется сразу несколько изолированных окружений для различных сервисов, которые могут быть потенциально опасными. На самом деле это означает, что занимающиеся вопросами безопасности в ALT Linux люди не уверены, что в коде соответствующих программ нет ошибок, а потому считают нужным эти программы изолировать. Запущенная в изолированном окружении программа может пользоваться только той частью файловой системы, в которой она запущена - это некоторый специально выделенный каталог и все дерево его подкаталогов. Именно туда и следует копировать конфигурационные файлы. В нашем случае изолированное окружение для библиотеки преобразования имён находится в /var/resolv:

# ls /var/resolv/
etc  lib  var

Конфигурационные файлы в изолированном окружении (как и в основной файловой системе) лежат в каталоге etc:

# ls /var/resolv/etc/
host.conf  hosts  localtime  nsswitch.conf  resolv.conf  services

Среди них, как и ожидалось, есть и hosts, и resolv.conf. Присутствует здесь и файл services. Сама библиотека и используемые ее библиотеки лежат в /var/resolv/lib.

# ls /var/resolv/lib/
libnsl.so.1        libnss_hesiod.so.2         libnss_nis.so.2
libnss_dns.so.2    libnss_mdns4.so.2          libnss_nisplus.so.2
libnss_files.so.2  libnss_mdns4_minimal.so.2  libresolv.so.2

Как видим, здесь есть libnss и libnsl, нужные для работы resolver'a, а также сам libresolv. Еще раз отметим, что при изменении хотя бы одного из конфигурационных файлов в /etc (кроме файлов в каталоге /etc/net, о которых будет рассказано далее) необходимо выполнить команду update_chrooted conf для обновления конфигурации ограниченных окружений.

Прямое и обратное преобразование

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

Заметим, что обратное преобразование производят и вспомогательные утилиты, например утилита traceroute для обнаружения последовательности маршрутизаторов до некоторого адреса:

$ traceroute www.ru 
...
7  msk-bgw1-ae0-350.rt-comm.ru (217.106.2.157)  51.970 ms  53.449 ms  53.882 ms
8  msk-dsr8-ge8-19.rt-comm.ru (217.106.1.134)  43.304 ms  44.741 ms *
9  iki-c1-vl10.demos.net (194.87.0.111)  49.192 ms * *
10  www.ru (194.87.0.50)  14.069 ms  14.148 ms  14.271 ms

Здесь доменное имя www.ru было преобразовано в IP-адрес 194.87.0.50, на который и отправлялись пакеты. IP-адреса обнаруженных маршрутизаторов преобразовывались в их DNS-имена. Заметим, что явного указания выполнять это преобразование мы не давали. Чтобы утилита traceroute таких преобразований не выполняла, следует вызывать ее с ключом -n.

Для явного преобразования IP-адресов в доменные имена и обратно можно использовать несколько специальных утилит. Не все из них одинаково удобны для пользователя (одна --- nslookup --- вообще считается устаревшей). Посмотрим на простейшую из них - hostinfo:

$ hostinfo ya.ru
address: 213.180.204.8
hostname: ya.ru
aliases:

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

Более сложная программа для преобразования имен в адреса и обратно называется host:

$ host -a ya.ru
Trying "ya.ru"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60336
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ya.ru.                         IN      ANY

;; ANSWER SECTION:
ya.ru.                  7030    IN      NS      ns5.yandex.ru.
ya.ru.                  7030    IN      NS      ns1.yandex.ru.
ya.ru.                  7030    IN      A       213.180.204.8

;; AUTHORITY SECTION:
ya.ru.                  7030    IN      NS      ns5.yandex.ru.
ya.ru.                  7030    IN      NS      ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns5.yandex.ru.          345430  IN      A       213.180.204.1
ns1.yandex.ru.          345430  IN      A       213.180.193.1

Received 142 bytes from 194.190.241.162#53 in 66 ms

Примерно так же работает и программа dig из пакета bind-utils:

$ dig ya.ru

; <<>> DiG 9.3.5 <<>> ya.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  7012    IN      A       213.180.204.8

;; AUTHORITY SECTION:
ya.ru.                  7012    IN      NS      ns5.yandex.ru.
ya.ru.                  7012    IN      NS      ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns5.yandex.ru.          345412  IN      A       213.180.204.1
ns1.yandex.ru.          345412  IN      A       213.180.193.1

;; Query time: 6 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 17:54:40 2008
;; MSG SIZE  rcvd: 114

Начинающиеся с точки с запятой строки --- это комментарии. Формат выдачи соответствует формату хранения данных в распределенной базе данных DNS. Видно, что имени ya.ru соответствует IP-адрес 213.180.204.8, а за зону ya.ru отвечают два доменных сервера: ns1.yandex.ru и ns5.yandex.ru. На всякий случай dig вывела также IP-адреса этих серверов (заметим, что это действительно адреса из двух различных сетей класса B), а также различную статистику в комментариях: сколько времени заняло ожидание ответа, кто на самом деле ответил на запрос и пр. Заметим, что наш запрос был обслужен локальным сервером, указанным в /etc/resolv.conf. Добавим теперь в командную строку новый параметр:

$ dig ya.ru @ns5.yandex.ru

; <<>> DiG 9.3.5 <<>> ya.ru @ns5.yandex.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54389
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  7200    IN      A       213.180.204.8

;; AUTHORITY SECTION:
ya.ru.                  7200    IN      NS      ns1.yandex.ru.
ya.ru.                  7200    IN      NS      ns5.yandex.ru.

;; Query time: 6 msec
;; SERVER: 213.180.204.1#53(213.180.204.1)
;; WHEN: Thu Jul  3 17:56:50 2008
;; MSG SIZE  rcvd: 82

Результаты не поменялись, однако на запрос ответил сам сервер ns5.yandex.ru. Это как раз та самая ситуация, когда мы обратились к серверу, непосредственно отвечающему за нужную нам зону. Попробуем обратиться к этому же серверу с другим запросом:

$ dig cdrom.com @ns5.yandex.ru

; <<>> DiG 9.3.5 <<>> cdrom.com @ns5.yandex.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42056
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cdrom.com.                     IN      A

;; Query time: 6 msec
;; SERVER: 213.180.204.1#53(213.180.204.1)
;; WHEN: Thu Jul  3 17:57:19 2008
;; MSG SIZE  rcvd: 27

Обратим внимание, что сервер отказался обслуживать рекурсивный (по умолчанию) запрос. По сути дела, он ответил: "Не знаю". Понятно, что у держателей ya.ru нет никаких причин отвечать на рекурсивные DNS-запросы от посторонних (для них) узлов.

Что же будет, если мы обратимся к местному серверу?

$ dig cdrom.com

; <<>> DiG 9.3.5 <<>> cdrom.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58456
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;cdrom.com.                     IN      A

;; AUTHORITY SECTION:
cdrom.com.              300     IN      SOA     cdrom.com. root.digitalriver.com. 2007100313 600 300 604800 300

;; Query time: 300 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 17:57:55 2008
;; MSG SIZE  rcvd: 90

Итак, домен cdrom.com существует (об этом говорит запись типа SOA - state of authority), а IP-адреса у него нет, - весьма полезная информация. Запросим теперь записи произвольных типов (-t any):

$ dig cdrom.com -t any

; <<>> DiG 9.3.5 <<>> cdrom.com -t any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;cdrom.com.                     IN      ANY

;; ANSWER SECTION:
cdrom.com.              3600    IN      MX      10 pike.cdrom.com.
cdrom.com.              300     IN      TXT     "v=spf1 include:spf-dc1.digitalriver.com include:spf-dc2.digitalriver.com include:spf-dc7.digitalriver.com include:spf-dc5.digitalriver.com include:spf-dc6.digitalriver.com ~all"
cdrom.com.              0       IN      SOA     cdrom.com. root.digitalriver.com. 2007100313 600 300 604800 300

;; AUTHORITY SECTION:
cdrom.com.              172757  IN      NS      3dns1.digitalriver.com.
cdrom.com.              172757  IN      NS      3dns3.digitalriver.com.
cdrom.com.              172757  IN      NS      dc7dns01.digitalriver.com.

;; ADDITIONAL SECTION:
pike.cdrom.com.         3600    IN      A       204.216.28.222
3dns1.digitalriver.com. 172757  IN      A       208.217.74.35
3dns3.digitalriver.com. 172757  IN      A       66.192.77.35
dc7dns01.digitalriver.com. 172757 IN    A       81.21.144.40

;; Query time: 202 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 17:58:37 2008
;; MSG SIZE  rcvd: 427

Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS --- адреса серверов имен (NameServers). У домена cdrom.com есть машина, которая пересылает почту (запись типа MX --- Mail eXchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF --- специальная информация, часто используемая для борьбы со спамом). Есть запись типа SOA (которую мы уже видели), содержащая служебную информацию ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе dig есть дополнительная информация, о которой сейчас говорить не будем.

Выполним теперь с помощью dig обратное преобразование (-x) для IP-адреса 213.180.204.8, который мы получили при запросе о ya.ru:

$ dig -x 213.180.204.8

; <<>> DiG 9.3.5 <<>> -x 213.180.204.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2747
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

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

;; ANSWER SECTION:
8.204.180.213.in-addr.arpa. 13746 IN    PTR     ya.ru.

;; AUTHORITY SECTION:
204.180.213.in-addr.arpa. 8820  IN      NS      ns1.yandex.net.
204.180.213.in-addr.arpa. 8820  IN      NS      ns2.yandex.net.

;; ADDITIONAL SECTION:
ns1.yandex.net.         64148   IN      A       213.180.193.1
ns2.yandex.net.         64148   IN      A       213.180.199.34

;; Query time: 6 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 18:02:26 2008
;; MSG SIZE  rcvd: 141

Как видно, соответствия IP-адресов именам лежат в отдельной базе. Тип соответствующих записей называется PTR (pointer --- указатель). Интересно отметить, в какой форме представляются в этой базе IP-адреса. Запрашивается по сути дела домен следующего вида: IP-адрес, записанный "наоборот", к которому через точку приписана строка in-addr.arpa. Почему так? Дело тут в алгоритме, по которому раздаются диапазоны адресов. Пусть мы получили, к примеру, адреса 213.180.0.0/16. Это означает, что ответственный за этот домен сервер имен должен отвечать на обратные запросы для всех соответствующих компьютеров. Но как это сделать, ведь база DNS устроена по другому принципу и, например, за имена cs.msu.ru и cmc.msu.ru отвечает один и тот же сервер? При создании сервера, ответственного, например, за поддиапазон 213.180.204.0/24, разумно записывать числа из IP-адресов в обратном порядке. Соответствующая зона будет выглядеть как 204.180.213.in-addr.arpa, логика же работы DNS не изменится! Действительно, принципиальной разницы между доменами msu.ru и 204.180.213.in-addr.arpa с этой точки зрения нет.

Служба whois

Вернемся к поставленной ранее задаче. Как узнать, какой организации принадлежит тот или иной IP-адрес или диапазон? Для этого есть служба whois. Действительно, система DNS не предназначена для выяснения административных отношений. Ее удобно использовать для построения распознаваемой топологии сети, связанной с этими отношениями. Система whois же привязана к регистрации доменных имен. Данная процедура проводится либо системным администратором, который может выделить для тех или иных целей поддомен, либо специальной организацией, торгующей доменными именами, скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе:

$ whois ya.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:     YA.RU
type:       CORPORATE
nserver:    ns5.yandex.ru.
nserver:    ns1.yandex.ru.
state:      REGISTERED, DELEGATED
org:        YANDEX, LLC.
phone:      +7 495 7397000
fax-no:     +7 495 7397070
e-mail:     noc@yandex.net
registrar:  RUCENTER-REG-RIPN
created:    1999.07.12
paid-till:  2008.08.01
source:     TC-RIPN
Last updated on 2008.07.03 18:04:47 MSK/MSD

Итак, домен ya.ru зарегистрирован, права на управление им переданы администратору. Указана организация, телефон, факс, почтовый адрес. Поле "Registrar" - это регистратор (указана дата регистрации и дата, до которой использование этого доменного имени считается оплаченным). Обратим внимание на службу регистрации - их несколько, поэтому совершенно необязательно whois будет работать именно так. Вообще, алгоритм выяснения whois'а довольно хитр. К примеру, запрашивая информацию по доменам вида *.us, можно иногда получить специальный идентификационный номер с предложением позвонить по особому номеру телефона ("заплатите нам столько-то и мы вам все расскажем").

Серверов службы whois на свете довольно много, а процедура их регистрации весьма причудлива. Как следствие, результаты whois-запросов могут быть весьма непредсказуемы. К примеру, ответ на запрос whois google.com может содержать более двухсот строк, причем полезными, по-видимому, можно считать менее половины из них.

Можно производить поиск информации whois и по IP-адресам:

$ whois 62.117.85.102
% This is the RIPE Whois query server #3.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '62.117.85.0 - 62.117.85.255'

inetnum:      62.117.85.0 - 62.117.85.255
netname:      COMCOR-PROGTEH
descr:        Network for ZAO NPO "Progteh"
country:      RU
admin-c:      CNA3-RIPE
tech-c:       CNA3-RIPE
status:       ASSIGNED PA
mnt-by:       AS8732-MNT
source:       RIPE # Filtered

person:         Chicherov Nikolay Andreevich
e-mail:         sysadmin@progtech.ru
address:        Russia, Mosk. obl., g.Zhukovskiy, Amet-Han Sultana
phone:          +7 495 824831031
mnt-by:         AS8732-MNT
nic-hdl:        CNA3-RIPE
source:         RIPE # Filtered

% Information related to '62.117.64.0/18AS8732'

route:        62.117.64.0/18
descr:        comcor.ru
origin:       AS8732
mnt-by:       AS8732-MNT
source:       RIPE # Filtered

% Information related to '62.117.85.0/24AS35475'

route:          62.117.85.0/24
descr:          Progtech ISP
origin:         AS35475
mnt-by:         AS8732-MNT
source:         RIPE # Filtered

Как видно, информация взята из RIPE --- это регистратор, который раздает адреса в России. В основном ответе указано, что диапазон 62.117.85.0/24 выдан ЗАО "НПО Прогтех", есть соответствующий адрес сайта, а также адрес: Московская область, город Жуковский и т. д. К какой же автономной системе принадлежит этот диапазон? Это comcor, чей диапазон 62.117.64.0/18. Они этот диапазон "нарезали" и отдали поддиапазон 62.117.85.0/24 "вниз". Вообще, это вполне разумная информация, из которой ясно, кто реальный владелец данного IP-адреса и кто ему этот IP-адрес выдал.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

90

1

1

1

1

PavelSutyrin, DmitryChistikov, VsevolodKrishchenko


PspoClasses/080703/02DNSPractice (last edited 2009-03-22 23:09:00 by eSyr)