Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2008-07-03 19:03:21
Size: 5771
Editor: eSyr
Comment:
Revision 5 as of 2008-07-04 03:31:03
Size: 27749
Editor: PavelSutyrin
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Теперь обратимся к тому, как это работает в альте. Есть файл /etc/resolv.conf. В нём кк правило неск. строчек, как правило, двух видов. Одни search домен, другие nameserver ip-адрес. Это значит, что преобр. будет присх. таким образом: если вы указли неполное имя, то будет добавлено имя домена, указанное в search. Да, почему это файл: Мы вот запускали кучу утилит, неужели они ходят файл? На самом деле, это делает одна библиотека, с которой они скомпилированы. Есть тонкость с libresolv, он работает на достаточно низком уровне, и часть его чуть ли не под рутом выполняется, поэтому в альте оно в изолированном окружении, и для обновления конфигов есть alt-specific команда update_chrooted all. Для того, чтобы увидеть, что он использует, можно посмотреть /var/resolv/.

Теперь псмотрим, как работает dns-запрос. У нас, как мы гворили, есть libresolv и подсистема резолверов, которой пользуются разные программы. Есть задача не только преобр. доменного имени в ip-адрес, но и задача преобр. ip-адреса в доменное имя. Например, когда происх. нежелательная активность с какого-то ip, и хочется понять, какой домен за этим стоит. Например, пересылка почты. В частности, обр. преобр. производит тот же ping, когда получает ответ от серверов. Существует две утилиты (на самом деле, их больше), которые делают это явн. Есть программа hstinfo, которая выводит прост. инф., она выводит ip, алиасы. Более сложная программа наз. host, она не всегда входит в состав дистрибутивов. Лично лектор привык пользоваться программой dig. Входит dig в пакет bind-utils. Формат выдачи соотв. формату хранения в распр. БД DNS. Выводится различная информация, в том числе, кто ответил на запрос. параметроь @... можно указать, у какго сервера запрашивать информацию. Ключом -t any можно запросить записи любого вида. Например, если сказать dig cdrom.com -t any, то можно узнать, что есть почтовый сервер, какой-то текст. Это показывает, что в dns-записи может лежать разное. Если же сказать dig -x на ip, то можно получить информацию из обратной бзы. Обратите внимание, в каком формате хранятся адреса. Они хранятся задом наперёд, потому что днс отрывает с конца. Записи этог вида имеют тип ptr.

И всё-таки, как узнать, какой организации принадлжеит ip? Для этого есть служба whois. DNS не предн. для выясн. адм. отношений, он предн. для постр. топологии сети. Выглядит оно след. образом: когда рег. доменное имя, то вы идёте либо к адм., и просите у него поддобмен, или идёте к орг. какой-то и рег. доменное имя второго уровня. В этом случае вы указываете свою контактную информацию.

Алгоритм выяснения хуиза довольно сложный. Точно также и гораздо полезнее произвдить whois по айпишникам, чтобы узнавать информацию об ip-адресах и о реальных его владельцах.
{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, он работает на довольно низком
уровне, и часть кода чуть не от {{{root}}} выполняется, поэтому в
альтлинуксе такая специфика: resolver вынесен в изолированное
окружение, и для обновления конфигов есть alt-specific (характерная
для Альтлинукса) команда {{{update_chrooted all}}}. Эта команда записывает
целую кучу разных конфигурационных файлов из /etc в целую
кучу изолированных окружений, где их хотят. В альтлинуксе
используется сразу несколько изолированных окружений для
разных служб, которые потенциально могут быть опасны, и ребята,
которые занимаются security попросту не уверены, что они до конца
прочитали и выучили наизусть весь исходный код, чтобы понять, что
там нет никаких ошибок, поэтому на всякий случай они их.. ребята,
да, Дима Левин, поэтому он на всякий случай запихнул системную
службу в изолированное окружение, и, поскольку запущенная
в изолированном окружении программа ничего не видит, кроме
каталога, в котором она запущена и подкаталогов его, то туда-то
как раз и надо копировать. Для того, чтобы увидеть, что он
использует, можно посмотреть {{{ls /var/resolv/}}}. Что у нас есть? {{{etc/}}},
посмотрим что там -- как раз те самые вещи, которые относятся к
процедуре преобразования адресов, hosts, localtime понятно почему, namespace
switch (?), ничего не буду про него говорить, простая штука, но мимо
темы, файл resolv.conf, который, если бы мы его меняли, пришлось бы его
туда скопировать, и файл их /etc/serviced (?), еще там есть библиотеки ({{{lib/}}}),
нужные для библиотеки 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. А, ну умерло. А нет, оно.... вау.. слушайте, как тут много всего,
ну, спасибо гуглу. ... dns about.com... godaddy.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}
Line 13: Line 268:
## ВНИМАНИЕ! Поля значащие, просьба редактироать только числа и списки модулей ## ВНИМАНИЕ! Поля значащие, просьба редактировать только числа и списки модулей
Line 15: Line 270:
## Ментейнеры прописываются в сответствии с PspoTasks ## Ментейнеры прописываются в соответствии с PspoTasks
Line 17: Line 272:
|| 0 || 1 || 1 || 1 || || 1 || PavelSutyrin, DmitryChistikov || || || || 20 || 1 || 1 || 1 || || 1 || PavelSutyrin (расшифровка завершена), DmitryChistikov || || ||

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

{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, он работает на довольно низком уровне, и часть кода чуть не от root выполняется, поэтому в альтлинуксе такая специфика: resolver вынесен в изолированное окружение, и для обновления конфигов есть alt-specific (характерная для Альтлинукса) команда update_chrooted all. Эта команда записывает целую кучу разных конфигурационных файлов из /etc в целую кучу изолированных окружений, где их хотят. В альтлинуксе используется сразу несколько изолированных окружений для разных служб, которые потенциально могут быть опасны, и ребята, которые занимаются security попросту не уверены, что они до конца прочитали и выучили наизусть весь исходный код, чтобы понять, что там нет никаких ошибок, поэтому на всякий случай они их.. ребята, да, Дима Левин, поэтому он на всякий случай запихнул системную службу в изолированное окружение, и, поскольку запущенная в изолированном окружении программа ничего не видит, кроме каталога, в котором она запущена и подкаталогов его, то туда-то как раз и надо копировать. Для того, чтобы увидеть, что он использует, можно посмотреть ls /var/resolv/. Что у нас есть? etc/, посмотрим что там -- как раз те самые вещи, которые относятся к процедуре преобразования адресов, hosts, localtime понятно почему, namespace switch (?), ничего не буду про него говорить, простая штука, но мимо темы, файл resolv.conf, который, если бы мы его меняли, пришлось бы его туда скопировать, и файл их /etc/serviced (?), еще там есть библиотеки (lib/), нужные для библиотеки 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. А, ну умерло. А нет, оно.... вау.. слушайте, как тут много всего, ну, спасибо гуглу. ... dns about.com... godaddy.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}


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

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

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

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

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

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

Level

Maintainer

Start date

End date

20

1

1

1

1

PavelSutyrin (расшифровка завершена), DmitryChistikov


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