Сеть TCP/IP в Linux

Служба доменных имен

В предыдущих примерах Мефодий использовал ключ "-n" многих сетевых утилит, чтобы избежать путаницы между IP-адресами и доменными именами компьютеров. С другой стороны, доменные имена – несколько слов (часто осмысленных) —запоминать гораздо удобнее, чем адреса (четыре числа).

Когда-то имена всех компьютеров в сети, соответствующие IP-адресам, хранились в файле /etc/hosts. Пока абоненты Internet были наперечет, поддерживать правильность его содержимого не составляло труда. Как только сеть начала расширяться, неувязок стало больше. Трудность была не только в том, что содержимое hosts быстро менялось, но и в том, что за соответствие имен адресам в различных сетях отвечали разные люди и разные организации. Появилась необходимость структурировать глобальную сеть не только топологически (с помощью IP и сетевых масок ), но и административно, с указанием, за какие группы адресов кто отвечает.

Проще всего было структурировать сами имена компьютеров. Вся сеть была поделена на домены – зоны ответственности отдельных государств ("us", "uk", "ru", "it" и т. п.) или независимые зоны ответственности ("com", "org", "net", "edu" и т. п.). Для каждого из таких доменов первого уровня должно присутствовать подразделение, выдающее всем абонентам имена, заканчивающиеся на ". домен " Подразделение обязано организовать и поддерживать службу, заменяющую файл hosts: любой желающий имеет право узнать, какой IP-адрес соответствует имени компьютера в этом домене или какому доменному имени соответствует определенный IP-адрес.

Такая служба называется DNS ( D omain N ame S ervice, служба доменных имен ). Она имеет иерархическую структуру. Если за какую-то группу абонентов домена отвечают не хозяева домена, а кто-то другой, ему выделяется поддомен (или домен второго уровня ), и он сам распоряжается именами вида "имя_компьютера.поддомен.домен". Например, за компьютеры в домене " .ru ", принадлежащие корпорации "Dry Bugs", отвечают сотрудники соответствующего подразделения этой корпорации. Корпорация владеет поддоменом dbugs.ru. В домене ru не обязаны знать, какие именно адреса есть в поддомене, но обязаны предоставить информацию о том, как обратиться к серверу имен поддомена dbugs.ru.Сами сотрудники "Dry Bugs" тоже отвечают только за несколько собственных компьютеров, а всю ответственность за компьютеры в подразделениях перекладывают на сетевых администраторов этих подразделений, выделив им поддомены третьего уровня – pr.dbugs.ru, cook.dbugs.ru и warehouse.dbugs.ru. Таким образом, получается нечто вроде распределенной сетевой базы данных, хранящей короткие записи о соответствии доменных имен IP-адресам.

Доменное имя. Имя абонента Internet, имеющее текстовый формат и используемое вместо IP-адреса. Состоит из собственного имени абонента в домене и имени домена, определяющего административную принадлежность абонента. В отличие от IP-адреса, доменное имя не задается самим абонентом сети, а устанавливается службой доменных имен .

Все программы, работающие с доменными именами, оказываются клиентами какого-нибудь сервера доменных имен (DNS-сервера). Для этого они обращаются к функциям из библиотеки libresolv (или им подобным), а те уже определяют, как превратить доменное имя в адрес. Функции используют файл /etc/host.conf, описывающий, какими способами они должны выполнять преобразование доменных имен в адреса и обратно, а также формат выдачи данных в различных случаях. Обычно сначала проверяется файл /etc/hosts, а если там соответствий не найдено – /etc/resolv.conf. В resolv.conf указан домен по умолчанию (он приписывается в конец имени, если другим способом имя никак не удается преобразовать в адрес ) и один-два адреса DNS-серверов, к которым и обращаются функции. В роли таких клиентов выступили утилиты ping и traceroute в предыдущих примерах, преобразуя имя www.ru в адрес 194.87.0.50. Если утилите traceroute не указывать ключ "-n", она подаст несколько DNS-запросов, по одному на каждый маршрутизатор, на обратное преобразование – из IP-адреса в доменное имя:

order hosts,bind
multi on
[root@localhost root]# cat /etc/resolv.conf
domain nipponman.ru
nameserver 192.168.102.1
[root@localhost root]# traceroute -q1 www.ru
traceroute to www.ru (194.87.0.50), 30 hops max, 38 byte packets
1 fuji.nipponman.ru (192.168.102.1) 1.378 ms
2 ppp83-237-29-1.pppoe.mtu-net.ru (83.237.29.1) 41.155 ms
3 195.34.53.53 (195.34.53.53) 48.503 ms
4 195.34.53.53 (195.34.53.53) 24.033 ms
5 M9-cr01-A197-cr01.core.mtu.ru (195.34.53.10) 33.414 ms
6 M9-gw2-M9-cr01.core.mtu.ru (195.34.53.81) 26.259 ms
7 s-b3-pos0-0.telia.net (213.248.67.93) 59.791 ms
8 s-bb1-pos5-0-0.telia.net (213.248.66.1) 67.011 ms
9 mow-b1-pos1-0.telia.net (213.248.101.10) 76.138 ms
10 demos-101566-mow-okt-i1.c.telia.net (213.248.78.170) 78.591 ms
11 m9-3-GE4-0-0-vl10.Demos.net (194.87.0.66) 69.813 ms
12 www.ru (194.87.0.50) 70.583 ms

Как видно из примера, обратное преобразование в современной сети работает не всегда. Отсутствие обратной зоны не поощряется сообществом, но и не считается преступлением. Мефодий заметил, что компьютер, не имеющий обратного преобразования адреса, вообще какой-то странный: один раз он передал пакет сам себе (здесь Мефодий не совсем прав: на самом деле этот маршрутизатор отчего-то уменьшает TTL пакета на 2, поэтому-то и на третьем, и на четвертом шаге именно он возвращает ICMP-сообщение). Кстати сказать, именно по причине того, что DNS- запрос невелик, зато даже один абонент сети может выдать их множество, основным транспортным протоколом для DNS выбран UDP, а не TCP (это не касается протоколов обмена целыми зонами между DNS-серверами – там, конечно, господствует TCP).

Если вся задача пользователя – это послать DNS-запрос, то лучше воспользоваться утилитой host, специально для этого предназначенной:

methody@localhost:~ $ host www.ru
www.ru has address 194.87.0.50
methody@localhost:~ $ host 194.87.0.51
51.0.87.194.in-addr.arpa domain name pointer www.demos-internet.ru.
methody@localhost:~ $ host -t ns www.ru
www.ru name server ns.demos.su.
www.ru name server ns1.demos.net.
methody@localhost:~ $ host -t mx www.ru
www.ru mail is handled by 5 hq.demos.ru.

Довольно необычен формат, в котором хранятся таблицы обратного преобразования адресов. Оказывается, IP-адрес представлен в такой таблице как имя в домене in-addr.arpa, причем это имя совпадает с адресом, записанным задом наперед. Такой формат идет от иерархической структуры DNS. Если некоторая организация получает во владение сеть, допустим, 194.0.0.0/8, она должна обслуживать DNS-запросы к домену 194.in-addr.arpa. Если при этом сеть 194.87.0.0/16 передана другой организации, ей же передается обязанность обслуживать DNS-запросы к поддомену этого домена – 87.194.in-addr.arpa, и так вплоть до собственно IP-адресов. Вместо host можно использовать утилиту dig, которая выводит больше информации о том, как проходил сам запрос.

Помимо записей типа "адрес" ( A, прямое преобразование) и "указатель на имя" ( PTR, обратное преобразование), в системе DNS может храниться и другая информация. Таблица (зона) некоторого домена должна содержать адреса доменных серверов всех его поддоменов (записи типа NS ). Кроме того, в домене должно быть определено имя почтового пересыльщика (запись типа MX ). Если почтовый пересыльщик домена не указан, электронная почта направляется почтовому пересыльщику родительского домена.

В зоне DNS есть даже запись типа "просто текст", TXT: при желании можно самому определить интерпретацию полей этой записи и организовать поверх DNS предназначенную для каких угодно целей базу данных по IP-адресам или доменным именам ^{8Так поступают, например, при создании "черных списков" абонентов сети, от которых почтовый сервер не принимает писем.}. В отличие от dig, которой для запроса к обратной зоне требуется ключ "-x", утилита host различает запросы к прямой и обратной зонам по тому, задан ли в качестве параметра адрес или доменное имя. Для указания конкретного типа искомой записи обеим утилитам требуется этот тип передать явно. Тип any означает поиск всех записей с указанным именем:

methody@localhost:~ $ dig www.us any
; <<>> DiG 9.2.4rc5 <<>> www.us any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6451
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;www.us. IN ANY
;; ANSWER SECTION:
www.us. 1766 IN A 209.173.57.26
www.us. 1766 IN A 209.173.53.26
www.us. 1767 IN NS pine.neustar.com.
www.us. 1767 IN NS willow.neustar.com.
www.us. 1767 IN NS cypress.neustar.com.
www.us. 1767 IN NS oak.neustar.com.
www.us. 1771 IN MX 20 pine.neustar.com.
www.us. 1771 IN MX 5 oak.neustar.com.
www.us. 1771 IN MX 5 willow.neustar.com.
www.us. 1771 IN MX 10 cypress.neustar.com.
;; ADDITIONAL SECTION:
pine.neustar.com. 135024 IN A 209.173.57.70
willow.neustar.com. 135024 IN A 209.173.53.84
cypress.neustar.com. 135024 IN A 209.173.57.84
oak.neustar.com. 135024 IN A 209.173.53.70
;; Query time: 932 msec
;; SERVER: 192.168.102.1#53(192.168.102.1)
;; WHEN: Wed Dec 22 22:01:24 2004
;; MSG SIZE rcvd: 281