Differences between revisions 10 and 11
Revision 10 as of 2008-07-11 13:31:11
Size: 29366
Comment:
Revision 11 as of 2008-07-11 15:52:37
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

PavelSutyrin, DmitryChistikov


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