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

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

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

Алгоритм выяснения хуиза довольно сложный. Точно также и гораздо полезнее произвдить whois по айпишникам, чтобы узнавать информацию об ip-адресах и о реальных его владельцах.
Обратимся теперь собственно к ПСПО. Посмотрим на файл /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 как раз и состоит в том, что большинство (в случае ПСПО) используемых программ - свободные, а потому, реализовав однажды применяемый алгоритм и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над механизмом выполнения подобных операций.

С использованием 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}}}.

 ''Что конкретно выполняют эти '''две''' команды?'' -- DmitryChistikov <<DateTime(2008-07-12T00:35:19+0400)>>

Прежде чем разбираться, как именно работает 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-адресу также можно выяснить с помощью DNS.

Более сложная программа называется {{{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}}} есть дополнительная информация, о которой сейчас говорить не будем.

Выполним теперь с помощью {{{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-адрес выдал.
Line 13: Line 370:
## ВНИМАНИЕ! Поля значащие, просьба редактироать только числа и списки модулей ## ВНИМАНИЕ! Поля значащие, просьба редактировать только числа и списки модулей
Line 15: Line 372:
## Ментейнеры прописываются в сответствии с PspoTasks ## Ментейнеры прописываются в соответствии с PspoTasks
Line 17: Line 374:
|| 0 || 1 || 1 || 1 || || 1 || PavelSutyrin, DmitryChistikov || || || || 42 || 1 || 1 || 1 || || 1 || PavelSutyrin, DmitryChistikov || || ||

Преобразование имён и 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 как раз и состоит в том, что большинство (в случае ПСПО) используемых программ - свободные, а потому, реализовав однажды применяемый алгоритм и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над механизмом выполнения подобных операций.

С использованием 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.

  • Что конкретно выполняют эти две команды? -- DmitryChistikov 2008-07-11 20:35:19

Прежде чем разбираться, как именно работает 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-адресу также можно выяснить с помощью DNS.

Более сложная программа называется 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 есть дополнительная информация, о которой сейчас говорить не будем.

Выполним теперь с помощью 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

42

1

1

1

1

PavelSutyrin, DmitryChistikov


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