|
Size: 29366
Comment:
|
Size: 28823
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| Как видно, в нем всего четыре строки (первая - комментарий). В строках вида {{{nameserver ip-адрес}}} указаны адреса DNS-серверов. {{{search имя_домена}}} означает, что преобразование доменного имени в IP-адрес будет происходить следующим образом: если указано не полное домена, а только имя компьютера, то {{{имя_домена}}} будет приписано к этому имени через точку. Разберемся, почему эта информация записана в файл. Можно запускать множество разных программ: браузер, ping, telnet, - неужели все они при своей работе читают этот файл? На самом деле эту работу за них проделывает специальная библиотека - libresolv, или попросту resolver. Отметим, что одно из достоинств операционной системы Linux как раз и состоит в том, что большинство (в случае ПСПО) используемых программ - свободные, а потому, написав один раз алгоритм преобразование доменного имени в IP-адрес и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над подобными действиями. С использованием libresolv связана следующая тонкость. В операционной системе эта библиотека работает на довольно низком уровне, причем часть кода должна выполняться чуть ли не от имени суперпользователя. Понятно, что это может представлять серьезную опасность в случае некорректной работы resolver'а (в случае обнаружения ошибки). Поэтому в ПСПО ALT Linux для resolver'а создано специальное изолированное окружение. Для обновления необходимых для работы resolver'а данных (обновления конфигурационных файлов) есть специальная команда: |
Как видно, в нем всего четыре строки, первая из которых - комментарий). В строках вида {{{nameserver ip-адрес}}} указаны адреса DNS-серверов. {{{search имя_домена}}} означает, что преобразование доменного имени в IP-адрес будет происходить следующим образом: если указано не полное имя домена, а только имя компьютера, то {{{имя_домена}}} будет приписано к этому имени через точку. Разберемся, почему эта информация записана в файл. Можно запускать множество разных программ: браузер, ping, telnet, - неужели все они при своей работе читают этот файл? На самом деле эту работу за них проделывает специальная библиотека - libresolv, или попросту resolver. Отметим, что одно из достоинств операционной системы Linux как раз и состоит в том, что большинство (в случае ПСПО) используемых программ - свободные, а потому, написав один раз алгоритм преобразование доменного имени в IP-адрес и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над подобными действиями. С использованием libresolv связана следующая тонкость. В операционной системе эта библиотека работает на довольно низком уровне, причем часть кода должна выполняться чуть ли не от имени суперпользователя. Понятно, что это может представлять серьезную опасность в случае некорректной работы resolver'а (в случае обнаружения ошибки). Поэтому в ПСПО ALT Linux для resolver'а создано специальное изолированное окружение. Для обновления необходимых для работы resolver'а данных (обновления конфигурационных файлов) есть специальная команда: |
| Line 45: | Line 23: |
| Эта команда записывает множество различных конфигурационных файлов из /etc в различные нуждающиеся в них изолированные окружения. В ПСПО используется сразу несколько изолированных окружений для различных сервисов, которые могут быть потенциально опасными. На самом деле это означает, что занимающиеся вопросами безопасности в ALT Linux люди не уверены, что в коде соответствующих программ нет ошибок, а потому считают нужным эти программы "изолировать". Запущенная в изолированном окружении программа может пользоваться только той частью файловой системы, в которой она запущена - это некоторый специально выделенный каталог и все его подкаталоги. Именно туда и следует копировать конфигурационные файлы. В нашем случае изолированное окружение для resolver'а находится в /var/resolv: |
Эта команда записывает множество различных конфигурационных файлов из /etc в различные нуждающиеся в них изолированные окружения. В ПСПО используется сразу несколько изолированных окружений для различных сервисов, которые могут быть потенциально опасными. На самом деле это означает, что занимающиеся вопросами безопасности в ALT Linux люди не уверены, что в коде соответствующих программ нет ошибок, а потому считают нужным эти программы "изолировать". Запущенная в изолированном окружении программа может пользоваться только той частью файловой системы, в которой она запущена - это некоторый специально выделенный каталог и все его подкаталоги. Именно туда и следует копировать конфигурационные файлы. В нашем случае изолированное окружение для resolver'а находится в /var/resolv: |
| Line 63: | Line 30: |
| Конфигурационные файлы в изолированном окружении (как и во всей файловой системе) лежат в каталоге etc: |
Конфигурационные файлы в изолированном окружении (как и во всей файловой системе) лежат в каталоге etc: |
| Line 71: | Line 37: |
| Среди них, как и ожидалось, есть и hosts, и resolv.conf. Присутствует здесь и файл services. Библиотеки же лежат в lib: |
Среди них, как и ожидалось, есть и hosts, и resolv.conf. Присутствует здесь и файл services. Библиотеки же лежат в lib: |
| Line 81: | Line 46: |
| Как видим, здесь есть libnss и libnsl, нужные для работы resolver'a, а также сам libresolv. Еще раз отметим, что при изменении хотя бы одного из конфигурационных файлов в /etc необходимо выполнять команды {{{update_chrooted all}}} и {{{update_chrooted conf}}}. Прежде чем разбираться, как именно работает DNS-запрос, сделаем еще одно замечание. Наряду с задачей преобразования доменного имени в IP-адрес существует и задача преобразования IP-адреса в доменное имя. Она возникает, к примеру, в случае той или иной нежелательной сетевой активности с некоторого IP-адреса. Разумно в такой ситуации разобраться, кто этим адресом пользуется. Используется эта информация и в случае пересылке почты. Допустим, мы хотим пересылать почту только для таких-то доменов, вплоть до своего собственного. Понятно, что у машин, имеющих адреса из нашего домена, могут быть довольно разнообразные IP-адреса. Каждый раз, когда происходит подключение к нашему серверу, будем выяснять не только IP-адрес, но и (по нему) доменное имя клиента. На основании этого доменного имени и выясняется, следует ли разрешить данному клиенту пересылать почту через наш сервер. |
Как видим, здесь есть libnss и libnsl, нужные для работы resolver'a, а также сам libresolv. Еще раз отметим, что при изменении хотя бы одного из конфигурационных файлов в /etc необходимо выполнять команды {{{update_chrooted all}}} и {{{update_chrooted conf}}}. Прежде чем разбираться, как именно работает DNS-запрос, сделаем еще одно замечание. Наряду с задачей преобразования доменного имени в IP-адрес существует и задача преобразования IP-адреса в доменное имя. Она возникает, к примеру, в случае той или иной нежелательной сетевой активности с некоторого IP-адреса. Разумно в такой ситуации разобраться, кто этим адресом пользуется. Используется эта информация и в случае пересылке почты. Допустим, мы хотим пересылать почту только для таких-то доменов, вплоть до своего собственного. Понятно, что у машин, имеющих адреса из нашего домена, могут быть довольно разнообразные IP-адреса. Каждый раз, когда происходит подключение к нашему серверу, будем выяснять не только IP-адрес, но и (по нему) доменное имя клиента. На основании этого доменного имени и выясняется, следует ли разрешить данному клиенту пересылать почту через наш сервер. |
| Line 111: | Line 61: |
| Здесь доменное имя www.ru было преобразовано в IP-адрес 194.87.0.50, на которые и отправлялись ICMP-запросы. Как видно, пакеты "не успевали" доставляться по заданному адресу (сообщение "Time to live exceeded"), о чем и сообщал маршрутизатор с адресом 194.85.40.34. Его адрес преобразовывался для нас программой {{{ping}}} в доменное имя {{{m10-1-gw.msk.runnet.ru}}}. Заметим, что явного указания выполнять это преобразование мы не давали. Чтобы утилита {{{ping}}} таких преобразований не выполняла, следует вызывать ее с ключом {{{-n}}}. Для явного преобразования IP-адресов в доменные имена и обратно можно использовать несколько специальных утилит. Не все из них одинаково удобны для пользователя (одна - {{{nslookup}}} - вообще считается устаревшей). Посмотрим на простейшую из них - {{{hostinfo}}}: |
Здесь доменное имя www.ru было преобразовано в IP-адрес 194.87.0.50, на которые и отправлялись ICMP-запросы. Как видно, пакеты "не успевали" доставляться по заданному адресу (сообщение "Time to live exceeded"), о чем и сообщал маршрутизатор с адресом 194.85.40.34. Его адрес преобразовывался для нас программой {{{ping}}} в доменное имя {{{m10-1-gw.msk.runnet.ru}}}. Заметим, что явного указания выполнять это преобразование мы не давали. Чтобы утилита {{{ping}}} таких преобразований не выполняла, следует вызывать ее с ключом {{{-n}}}. Для явного преобразования IP-адресов в доменные имена и обратно можно использовать несколько специальных утилит. Не все из них одинаково удобны для пользователя (одна - {{{nslookup}}} - вообще считается устаревшей). Посмотрим на простейшую из них - {{{hostinfo}}}: |
| Line 132: | Line 72: |
| Она выводит простейшую информацию о запрошенном доменном имени. Попадают в ее вывод также алиасы и tcname'ы: если в сети у одной и той же машины есть несколько имен, то соответствие всех этих имен данному IP-адресу также можно выяснить. Более сложная программа называется {{{host}}} (она может не входить в стандартный состав дистрибутива): |
Она выводит простейшую информацию о запрошенном доменном имени. Попадают в ее вывод также алиасы и tcname'ы: если в сети у одной и той же машины есть несколько имен, то соответствие всех этих имен данному IP-адресу также можно выяснить. Более сложная программа называется {{{host}}} (она может не входить в стандартный состав дистрибутива): |
| Line 165: | Line 101: |
| Примерно так же работает и программа {{{dig}}} из пакета bind-utils: |
Примерно так же работает и программа {{{dig}}} из пакета bind-utils: |
| Line 198: | Line 133: |
| Строки, начинающиеся с точки с запятой, - это комментарии. Формат выдачи соответствует формату хранения данных в распределенной базе данных DNS. Видно, что имени ya.ru соответствует IP-адрес 213.180.204.8, а за зону ya.ru отвечают два доменных сервера: {{{ns1.yandex.ru}}} и {{{ns5.yandex.ru}}}. На всякий случай {{{dig}}} вывела также IP-адреса этих серверов (заметим, что это действительно {{{ns1.yandex.ru}}} и {{{ns5.yandex.ru}}}. На всякий случай {{{dig}}} вывела также IP-адреса этих серверов (заметим, что это действительно адреса из двух различных сетей класса B), а также различную статистику в комментариях: сколько времени заняло ожидание ответа, кто на самом деле ответил на запрос и пр. Заметим, что наш запрос был обслужен локальным сервером, указанным в /etc/resolv.conf. Добавим теперь в командную строку новый параметр: |
Строки, начинающиеся с точки с запятой, - это комментарии. Формат выдачи соответствует формату хранения данных в распределенной базе данных DNS. Видно, что имени ya.ru соответствует IP-адрес 213.180.204.8, а за зону ya.ru отвечают два доменных сервера: {{{ns1.yandex.ru}}} и {{{ns5.yandex.ru}}}. На всякий случай {{{dig}}} вывела также IP-адреса этих серверов (заметим, что это действительно адреса из двух различных сетей класса B), а также различную статистику в комментариях: сколько времени заняло ожидание ответа, кто на самом деле ответил на запрос и пр. Заметим, что наш запрос был обслужен локальным сервером, указанным в /etc/resolv.conf. Добавим теперь в командную строку новый параметр: |
| Line 237: | Line 160: |
| Результаты не поменялись, однако на запрос ответил сам сервер {{{ns5.yandex.ru}}}. Это как раз та самая ситуация, когда мы обратились к запросов к серверу, непосредственно отвечающему за нужную зону. Попробуем обратиться к этому же серверу с другим запросом: |
Результаты не поменялись, однако на запрос ответил сам сервер {{{ns5.yandex.ru}}}. Это как раз та самая ситуация, когда мы обратились к запросов к серверу, непосредственно отвечающему за нужную зону. Попробуем обратиться к этому же серверу с другим запросом: |
| Line 262: | Line 181: |
| Обратим внимание, что сервер отказался обслуживать рекурсивный (по умолчанию) запрос. По сути дела, он ответил: "Не знаю". Понятно, что у держателей ya.ru нет никакого резона отвечать на рекурсивные DNS-запросы от посторонних (для них) узлов. |
Обратим внимание, что сервер отказался обслуживать рекурсивный (по умолчанию) запрос. По сути дела, он ответил: "Не знаю". Понятно, что у держателей ya.ru нет никакого резона отвечать на рекурсивные DNS-запросы от посторонних (для них) узлов. |
| Line 291: | Line 207: |
| Итак, домен cdrom.com существует (об этом говорит запись типа SOA - state of authority), а IP-адреса у него нет, - весьма полезная информация. Запросим теперь записи произвольных типов ({{{-t any}}}): |
Итак, домен cdrom.com существует (об этом говорит запись типа SOA - state of authority), а IP-адреса у него нет, - весьма полезная информация. Запросим теперь записи произвольных типов ({{{-t any}}}): |
| Line 330: | Line 244: |
| Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS - адреса nameserver'ов. У домена cdrom.com есть машина, которая пересылает почту (запись типа MX, mail exchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF (?)). Есть запись типа SOA (которую мы уже видели), в которой хранится служебная информация ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе есть дополнительная информация, о которой сейчас говорить не будем. Выполним теперь с помощью {{{dig}}} обратное преобразование ({{{-x}}}) для IP-адреса 213.180.204.8, который мы получили при запросе о {{{ya.ru}}}: |
Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS - адреса nameserver'ов. У домена cdrom.com есть машина, которая пересылает почту (запись типа MX, mail exchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF (?)). Есть запись типа SOA (которую мы уже видели), в которой хранится служебная информация ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе есть дополнительная информация, о которой сейчас говорить не будем. Выполним теперь с помощью {{{dig}}} обратное преобразование ({{{-x}}}) для IP-адреса 213.180.204.8, который мы получили при запросе о {{{ya.ru}}}: |
| Line 378: | Line 278: |
| Как видно, соответствия IP-адресов именам лежат совсем в другой базе. Тип соответствующих записей называется PTR (pointer). Интересно отметить, в какой форме представляются в этой базе IP-адреса. Запрашивается по сути дела домен следующего вида: IP-адрес, записанный "наоборот", к которому через точку приписана строка "in-addr.arpa}}}. Почему так? Дело тут в алгоритме, по которому раздаются диапазоны адресов. Пусть мы получили, к примеру, адреса 213.180.0.0/16. Это означает, что ответственный за этот домен nameserver должен отвечать на обратные запросы для всех соответствующих компьютеров. Как это сделать, ведь база DNS устроена по другому принципу (за nc.cs.msu.su и imap.cs.msu.su отвечает один и тот же сервер)? При создании сервера, ответственного, например, за поддиапазон 213.180.204.0/24, разумно записывать числа из IP-адресов в обратном порядке. Соответствующая зона будет выглядеть как 204.180.213.in-addr.arpa, логика же работы DNS не изменится. Действительно, принципиальной разницы между доменами cs.msu.su и 204.180.213.in-addr.arpa с этой точки зрения нет. Вернемся к поставленной ранее задаче. Как узнать, какой организации принадлежит тот или иной IP-адрес или диапазон? Для этого есть служба whois. Действительно, система DNS не предназначена для выяснения административных отношений. Ее удобно использовать для построения распознаваемой топологии сети, связанной с этими отношениями. Система whois же привязана к регистрации доменных имен. Эта процедуру проводит либо системный администратор, который может выделить для тех или иных целей поддомен, либо специальная организация, торгующая доменными именами, скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе: |
Как видно, соответствия IP-адресов именам лежат совсем в другой базе. Тип соответствующих записей называется PTR (pointer). Интересно отметить, в какой форме представляются в этой базе IP-адреса. Запрашивается по сути дела домен следующего вида: IP-адрес, записанный "наоборот", к которому через точку приписана строка "in-addr.arpa}}}. Почему так? Дело тут в алгоритме, по которому раздаются диапазоны адресов. Пусть мы получили, к примеру, адреса 213.180.0.0/16. Это означает, что ответственный за этот домен nameserver должен отвечать на обратные запросы для всех соответствующих компьютеров. Как это сделать, ведь база DNS устроена по другому принципу (за nc.cs.msu.su и imap.cs.msu.su отвечает один и тот же сервер)? При создании сервера, ответственного, например, за поддиапазон 213.180.204.0/24, разумно записывать числа из IP-адресов в обратном порядке. Соответствующая зона будет выглядеть как 204.180.213.in-addr.arpa, логика же работы DNS не изменится. Действительно, принципиальной разницы между доменами cs.msu.su и 204.180.213.in-addr.arpa с этой точки зрения нет. Вернемся к поставленной ранее задаче. Как узнать, какой организации принадлежит тот или иной IP-адрес или диапазон? Для этого есть служба whois. Действительно, система DNS не предназначена для выяснения административных отношений. Ее удобно использовать для построения распознаваемой топологии сети, связанной с этими отношениями. Система whois же привязана к регистрации доменных имен. Эта процедуру проводит либо системный администратор, который может выделить для тех или иных целей поддомен, либо специальная организация, торгующая доменными именами, скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе: |
| Line 436: | Line 308: |
| Итак, домен ya.ru зарегистрирован, права на управление им переданы администратору. Указана организация, телефон, факс, почтовый адрес. "Registrar" - это регистратор (указана дата регистрации и дата, до которой использование этого доменного имени считается оплаченным). Обратим внимание на службу регистрации - их несколько, поэтому совершенно необязательно whois будет работать именно так. Вообще, алгоритм выяснения whois'а довольно хитр. К примеру, запрашивая информацию по доменам вида *.us, можно иногда получить специальный идентификационный номер с предложением позвонить по особому номеру телефона ("заплатите нам столько-то и мы вам все расскажем"). whois-серверов на свете довольно много, а процедура их регистрации весьма причудлива. Как следствие, результаты whois-запросов могут быть весьма непредсказуемы. К примеру, ответ на запрос {{{whois google.com}}} может содержать более двухсот строк, причем полезными, по-видимому, можно считать менее половины из них. |
Итак, домен ya.ru зарегистрирован, права на управление им переданы администратору. Указана организация, телефон, факс, почтовый адрес. "Registrar" - это регистратор (указана дата регистрации и дата, до которой использование этого доменного имени считается оплаченным). Обратим внимание на службу регистрации - их несколько, поэтому совершенно необязательно whois будет работать именно так. Вообще, алгоритм выяснения whois'а довольно хитр. К примеру, запрашивая информацию по доменам вида *.us, можно иногда получить специальный идентификационный номер с предложением позвонить по особому номеру телефона ("заплатите нам столько-то и мы вам все расскажем"). whois-серверов на свете довольно много, а процедура их регистрации весьма причудлива. Как следствие, результаты whois-запросов могут быть весьма непредсказуемы. К примеру, ответ на запрос {{{whois google.com}}} может содержать более двухсот строк, причем полезными, по-видимому, можно считать менее половины из них. |
| Line 506: | Line 364: |
| Как видно, информация взята из RIPE - это регистратор, который раздает адреса в России. В основном ответе указано, что диапазон 62.117.85.0/24 выдан ЗАО НПО Прогтех, есть соответствующий адрес сайта, а также адрес: Московская область, город Жуковский и т. д. Какой же автономной системе принадлежит этот диапазон? Это comcor, чей диапазон 62.117.64.0/18. Они этот диапазон "нарезали" и отдали поддиапазон 62.117.85.0/24 "вниз". Вообще, это вполне разумная информация, из которой ясно, кто реальный владелец данного IP-адреса и кто ему этот IP-адрес выдал. |
Как видно, информация взята из RIPE - это регистратор, который раздает адреса в России. В основном ответе указано, что диапазон 62.117.85.0/24 выдан ЗАО НПО Прогтех, есть соответствующий адрес сайта, а также адрес: Московская область, город Жуковский и т. д. Какой же автономной системе принадлежит этот диапазон? Это comcor, чей диапазон 62.117.64.0/18. Они этот диапазон "нарезали" и отдали поддиапазон 62.117.85.0/24 "вниз". Вообще, это вполне разумная информация, из которой ясно, кто реальный владелец данного IP-адреса и кто ему этот IP-адрес выдал. |
Преобразование имён и IP-адресов: практика
Обратимся теперь собственно к ПСПО. Посмотрим на файл /etc/resolv.conf:
[root@vaio ~]# 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-адрес будет происходить следующим образом: если указано не полное имя домена, а только имя компьютера, то имя_домена будет приписано к этому имени через точку.
Разберемся, почему эта информация записана в файл. Можно запускать множество разных программ: браузер, ping, telnet, - неужели все они при своей работе читают этот файл? На самом деле эту работу за них проделывает специальная библиотека - libresolv, или попросту resolver. Отметим, что одно из достоинств операционной системы Linux как раз и состоит в том, что большинство (в случае ПСПО) используемых программ - свободные, а потому, написав один раз алгоритм преобразование доменного имени в IP-адрес и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над подобными действиями.
С использованием libresolv связана следующая тонкость. В операционной системе эта библиотека работает на довольно низком уровне, причем часть кода должна выполняться чуть ли не от имени суперпользователя. Понятно, что это может представлять серьезную опасность в случае некорректной работы resolver'а (в случае обнаружения ошибки). Поэтому в ПСПО ALT Linux для resolver'а создано специальное изолированное окружение. Для обновления необходимых для работы resolver'а данных (обновления конфигурационных файлов) есть специальная команда:
[root@vaio ~]# update_chrooted all
Эта команда записывает множество различных конфигурационных файлов из /etc в различные нуждающиеся в них изолированные окружения. В ПСПО используется сразу несколько изолированных окружений для различных сервисов, которые могут быть потенциально опасными. На самом деле это означает, что занимающиеся вопросами безопасности в ALT Linux люди не уверены, что в коде соответствующих программ нет ошибок, а потому считают нужным эти программы "изолировать". Запущенная в изолированном окружении программа может пользоваться только той частью файловой системы, в которой она запущена - это некоторый специально выделенный каталог и все его подкаталоги. Именно туда и следует копировать конфигурационные файлы. В нашем случае изолированное окружение для resolver'а находится в /var/resolv:
[root@vaio ~]# ls /var/resolv/ etc lib var
Конфигурационные файлы в изолированном окружении (как и во всей файловой системе) лежат в каталоге etc:
[root@vaio ~]# ls /var/resolv/etc/ host.conf hosts localtime nsswitch.conf resolv.conf services
Среди них, как и ожидалось, есть и hosts, и resolv.conf. Присутствует здесь и файл services. Библиотеки же лежат в lib:
[root@vaio ~]# 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 необходимо выполнять команды update_chrooted all и update_chrooted conf.
Прежде чем разбираться, как именно работает DNS-запрос, сделаем еще одно замечание. Наряду с задачей преобразования доменного имени в IP-адрес существует и задача преобразования IP-адреса в доменное имя. Она возникает, к примеру, в случае той или иной нежелательной сетевой активности с некоторого IP-адреса. Разумно в такой ситуации разобраться, кто этим адресом пользуется. Используется эта информация и в случае пересылке почты. Допустим, мы хотим пересылать почту только для таких-то доменов, вплоть до своего собственного. Понятно, что у машин, имеющих адреса из нашего домена, могут быть довольно разнообразные IP-адреса. Каждый раз, когда происходит подключение к нашему серверу, будем выяснять не только IP-адрес, но и (по нему) доменное имя клиента. На основании этого доменного имени и выясняется, следует ли разрешить данному клиенту пересылать почту через наш сервер.
Заметим, что обратное преобразование производит и утилита ping:
[demo@vaio demo]$ ping www.ru PING www.ru (194.87.0.50) 56(84) bytes of data. From m10-1-gw.msk.runnet.ru (194.85.40.34) icmp_seq=1 Time to live exceeded From m10-1-gw.msk.runnet.ru (194.85.40.34) icmp_seq=2 Time to live exceeded From m10-1-gw.msk.runnet.ru (194.85.40.34) icmp_seq=3 Time to live exceeded From m10-1-gw.msk.runnet.ru (194.85.40.34) icmp_seq=4 Time to live exceeded
Здесь доменное имя www.ru было преобразовано в IP-адрес 194.87.0.50, на которые и отправлялись ICMP-запросы. Как видно, пакеты "не успевали" доставляться по заданному адресу (сообщение "Time to live exceeded"), о чем и сообщал маршрутизатор с адресом 194.85.40.34. Его адрес преобразовывался для нас программой ping в доменное имя m10-1-gw.msk.runnet.ru. Заметим, что явного указания выполнять это преобразование мы не давали. Чтобы утилита ping таких преобразований не выполняла, следует вызывать ее с ключом -n.
Для явного преобразования IP-адресов в доменные имена и обратно можно использовать несколько специальных утилит. Не все из них одинаково удобны для пользователя (одна - nslookup - вообще считается устаревшей). Посмотрим на простейшую из них - hostinfo:
[demo@vaio demo]$ hostinfo ya.ru address: 213.180.204.8 hostname: ya.ru aliases:
Она выводит простейшую информацию о запрошенном доменном имени. Попадают в ее вывод также алиасы и tcname'ы: если в сети у одной и той же машины есть несколько имен, то соответствие всех этих имен данному IP-адресу также можно выяснить.
Более сложная программа называется host (она может не входить в стандартный состав дистрибутива):
[demo@vaio demo]$ 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:
[demo@vaio demo]$ 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. Добавим теперь в командную строку новый параметр:
[demo@vaio demo]$ 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. Это как раз та самая ситуация, когда мы обратились к запросов к серверу, непосредственно отвечающему за нужную зону. Попробуем обратиться к этому же серверу с другим запросом:
[demo@vaio demo]$ 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-запросы от посторонних (для них) узлов.
Что же будет, если мы обратимся к местному серверу?
[demo@vaio demo]$ 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):
[demo@vaio demo]$ 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 - адреса nameserver'ов. У домена cdrom.com есть машина, которая пересылает почту (запись типа MX, mail exchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF (?)). Есть запись типа SOA (которую мы уже видели), в которой хранится служебная информация ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе есть дополнительная информация, о которой сейчас говорить не будем.
Выполним теперь с помощью dig обратное преобразование (-x) для IP-адреса 213.180.204.8, который мы получили при запросе о ya.ru:
[demo@vaio demo]$ 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. Это означает, что ответственный за этот домен nameserver должен отвечать на обратные запросы для всех соответствующих компьютеров. Как это сделать, ведь база DNS устроена по другому принципу (за nc.cs.msu.su и imap.cs.msu.su отвечает один и тот же сервер)? При создании сервера, ответственного, например, за поддиапазон 213.180.204.0/24, разумно записывать числа из IP-адресов в обратном порядке. Соответствующая зона будет выглядеть как 204.180.213.in-addr.arpa, логика же работы DNS не изменится. Действительно, принципиальной разницы между доменами cs.msu.su и 204.180.213.in-addr.arpa с этой точки зрения нет.
Вернемся к поставленной ранее задаче. Как узнать, какой организации принадлежит тот или иной IP-адрес или диапазон? Для этого есть служба whois. Действительно, система DNS не предназначена для выяснения административных отношений. Ее удобно использовать для построения распознаваемой топологии сети, связанной с этими отношениями. Система whois же привязана к регистрации доменных имен. Эта процедуру проводит либо системный администратор, который может выделить для тех или иных целей поддомен, либо специальная организация, торгующая доменными именами, скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе:
george@alt:~> 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-адресам:
george@alt:~> 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 |
40 |
1 |
1 |
1 |
|
1 |
|
|