Различия между версиями 4 и 6 (по 2 версиям)
Версия 4 от 2008-07-04 06:20:31
Размер: 27571
Редактор: PavelSutyrin
Комментарий: гыгы
Версия 6 от 2008-07-04 19:46:20
Размер: 27730
Редактор: PavelSutyrin
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 6: Строка 6:
файл /etc/resolv.conf, давайте на него посмотрим. В буквально файл /etc/resolv.conf, давайте на него посмотрим. В нём буквально
Строка 34: Строка 34:
уровне, и часть кода чуть не от рута выполняется, поэтому в уровне, и часть кода чуть не от {{{root}}} выполняется, поэтому в
Строка 55: Строка 55:
туда скопировать, и файл их /etc/serviced (?), еще там есть библиотеки,
нужные для библиотеки resolver'а, libresolv, libnss, libnsl, я не знаю что это
туда скопировать, и файл их /etc/serviced (?), еще там есть библиотеки ({{{lib/}}}),
нужные для библиотеки resolver'а, сам libresolv, libnss, и libnsl, (по поводу последнего) я не знаю что это
Строка 90: Строка 90:
превратила 194.85.40.34 в m10.gv1.msk.ranet.ru. Это вот такой пример неявного превратила 194.85.40.34 (?) в m10.gv1.msk.ranet.ru (?). Это вот такой пример неявного
Строка 94: Строка 94:
существует три, но их еще не существует. Если вы найдете книжку, существует три, но третьей уже не существует. Если вы найдете книжку,
Строка 99: Строка 99:
устаревшую...", да, да, он deprecated, вы думайте, что делать.
устаревшую...", да, да, "он deprecated, вы думайте, что делать".
Строка 106: Строка 105:
что эти имена есть у одного ip-шника. Более сложная программа что эти имена есть у этого одного ip-шника. Более сложная программа
Строка 116: Строка 115:
там не круглая малиновка. Да? round robin переводится как "круглая там не круглая малиновка. round robin переводится как "круглая
Строка 132: Строка 131:
хотят отвечать на рекурсивные dns-запросы, исходящие из npg (?),
не относящиеся к яндексу.
хотят отвечать на рекурсивные dns-запросы, исходящие из npg (?), то есть от узлов, не относящихся к яндексу.
Строка 147: Строка 145:
у команды dig, а расскажите нам все про домен cdrom.com, сказали,
типа записи любой (-t any), попросили все записи, которые про
у команды dig, "а расскажите нам все про домен cdrom.com", сказали,
"типа записи любой" ({{{-t any}}}), попросили все записи, которые про
Строка 151: Строка 149:
сервера 10 (их может быть несколько), и он называется pipe.cdrom.com, сервера 10 (их может быть несколько), и он называется pipe.cdrom.com (?),
Строка 212: Строка 210:
домен второго уровня, там, за .ru, значит вот. В этом случае, когда домен второго уровня, там, за .ru. В этом случае, когда
Строка 220: Строка 218:
все закиберсквоттим ya.ru, а, у них еще будет месяц, у него будет все закиберсквоттим ya.ru, а нет, у них еще будет месяц, у него будет
Строка 223: Строка 221:
адрес придет письмо?) Нет, гораздо интереснее, начнут туда адрес придет письмо?) Нет, гораздо интереснее, на этот адрес начнут
Строка 228: Строка 226:
google.com. А, ну умерло. А нет, оно.... wow.. слушайте, как тут много всего,
ну, спасибо гуглу. ... dns about.com... daddy.com.. какой-то шведский, что
google.com. А, ну умерло. А нет, оно.... вау.. слушайте, как тут много всего,
ну, спасибо гуглу. ... dns about.com... godaddy.com.. какой-то шведский, что
Строка 239: Строка 237:
сами придумали?.. Дальше, там будет настоящий. markmonitor, это он
и есть. Алгоритм выяснения этого whois'а достаточно непонятный,
сами придумали?.. Дальше, дальше, там будет настоящий. Вот он. markmonitor, это он
и есть.

Алгоритм выяснения этого whois'а достаточно непонятный,
Строка 272: Строка 272:
|| 20 || 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 (последним исправлял пользователь eSyr 2009-03-22 23:09:00)