Differences between revisions 13 and 15 (spanning 2 versions)
Revision 13 as of 2008-07-11 20:40:09
Size: 28977
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 50: Line 50:
Прежде чем разбираться, как именно работает DNS-запрос, сделаем еще одно замечание. Наряду с задачей преобразования доменного имени в IP-адрес существует и задача преобразования IP-адреса в доменное имя. Она возникает, к примеру, в случае той или иной нежелательной сетевой активности с некоторого IP-адреса. Разумно в такой ситуации разобраться, кто этим адресом пользуется. Используется эта информация и в случае пересылке почты. Допустим, мы хотим пересылать почту только для таких-то доменов, вплоть до своего собственного. Понятно, что у машин, имеющих адреса из нашего домена, могут быть довольно разнообразные IP-адреса. Каждый раз, когда происходит подключение к нашему серверу, будем выяснять не только IP-адрес, но и (по нему) доменное имя клиента. На основании этого доменного имени и выясняется, следует ли разрешить данному клиенту пересылать почту через наш сервер. Прежде чем разбираться, как именно работает DNS-запрос, сделаем еще одно замечание. Наряду с задачей преобразования доменного имени в IP-адрес существует и задача обратного преобразования - IP-адреса в доменное имя. Она возникает, к примеру, в случае нежелательной сетевой активности с некоторого IP-адреса. Разумно в такой ситуации разобраться, кто этим адресом пользуется. Другой пример - пересылка почты. Допустим, мы хотим пересылать почту только для таких-то доменов (вплоть до своего собственного). Понятно, что у машин, имеющих адреса из нашего домена, могут быть довольно разнообразные IP-адреса, поэтому каждый раз, когда происходит подключение к нашему серверу, мы будем выяснять не только IP-адрес, но и (по нему) доменное имя клиента. На основании этого доменного имени и выясняется, следует ли разрешить данному клиенту пересылать почту через наш сервер.
Line 63: Line 63:
Здесь доменное имя 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}}}. Здесь доменное имя 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}}}.
Line 74: Line 74:
Она выводит простейшую информацию о запрошенном доменном имени. Попадают в ее вывод также алиасы и tcname'ы: если в сети у одной и той же машины есть несколько имен, то соответствие всех этих имен данному IP-адресу также можно выяснить. Она выводит простейшую информацию о запрошенном доменном имени. Попадают в ее вывод также алиасы и tcname'ы: если в сети у одной и той же машины есть несколько имен, то соответствие всех этих имен данному IP-адресу также можно выяснить с помощью DNS.
Line 162: Line 162:
Результаты не поменялись, однако на запрос ответил сам сервер {{{ns5.yandex.ru}}}. Это как раз та самая ситуация, когда мы обратились к запросов к серверу, непосредственно отвечающему за нужную зону. Попробуем обратиться к этому же серверу с другим запросом: Результаты не поменялись, однако на запрос ответил сам сервер {{{ns5.yandex.ru}}}. Это как раз та самая ситуация, когда мы обратились к серверу, непосредственно отвечающему за нужную нам зону. Попробуем обратиться к этому же серверу с другим запросом:
Line 246: Line 246:
Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS - адреса nameserver'ов. У домена cdrom.com есть машина, которая пересылает почту (запись типа MX, mail exchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF (?)). Есть запись типа SOA (которую мы уже видели), в которой хранится служебная информация ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе есть дополнительная информация, о которой сейчас говорить не будем. Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS - адреса nameserver'ов. У домена cdrom.com есть машина, которая пересылает почту (запись типа MX, mail exchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF (?)). Есть запись типа SOA (которую мы уже видели), содержащая служебную информацию ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе {{{dig}}} есть дополнительная информация, о которой сейчас говорить не будем.
Line 280: Line 280:
Как видно, соответствия 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). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе:
Как видно, соответствия 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 374: Line 374:
|| 41 || 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)