учебники, программирование, основы, введение в,

 

DNS

Все привыкли к тому, что имена компьютеров в Интернете выглядят как несколько слов, разделенных точками, например, lcc.gatech.edu или phys.cam.ac.uk. Дело в том, что в Сети принята иерархическая схема именования компьютеров, которая очень похожа на файловую систему UNIX.Самый верхний уровень пирамиды называется корневым доменом и обозначается символом точка (.). Вся эта схема именуется системой доменных имен (DNS , Domain Name System).
Что такое домен
Домен - это совокупность компьютеров в сети. Их объединяет только имя домена , т.е. для того, чтобы некий компьютер оказался элементом домена , достаточно в описании домена указать, что данный компьютер к нему относится и самому компьютеру об этом сказать. Компьютеры одного и того же домена могут быть удалены друг от друга географически, могут быть подключены к совершенно разным сетям и, возможно, даже не общаться между собой.
Домен может содержать отдельные компьютеры и поддомены. Поддомен - это домен , входящий в домен верхнего уровня. Любой домен , кроме корневого, является чьим-то поддоменом. Иерархия доменов легко прослеживается в их именах: домен lcc.gatech.edu, очевидно, является поддоменом домена gatech.edu.
Домены общего пользования (generic top level domains, gTLD) - это COM, NET, ORG, INFO, BIZ, MUSEUM, NAME, AERO и COOP. К ним относят домены ограниченного пользования, в которых могут зарегистрироваться только определенные организации, а именно: INT - международные организации, EDU - высшие учебные заведения США (это не мешает, впрочем, существованию домена spb.edu, который зарегистрирован на Санкт-Петербургский Государственный Университет (бывший Ленинградский Государственный Университет), GOV - правительственные организации США, MIL - военные организации США, ARPA - бывший домен проекта ARPANET, из которого выросла сеть Интернет, сейчас он используется для обратных зон, см. ниже раздел "Обратные зоны". Еще один домен - PRO - зарезервирован для сообществ профессионалов, но пока его администрирование никто не осуществляет.
Координацией всего, что связано с системой доменных имен , занимается общественная организация ICANN (The Internet Corporation for Assigned Names and Numbers), зарегистрированная в Калифорнии в 1998 году. У ICANN имеются региональные регистраторы - RIPE NCC, которая координирует действия в европейско-азиатском регионе и Северной Африке; ARIN, которая работает с Северной и Центральной Америкой; APNIC, которая отвечает за страны Тихоокеанского региона; и LACNIC, координирующая работу в странах Латинской Америки и Карибского бассейна. Информацию о выполняемой ими работе можно найти на сайтах регистраторов и на сайте ICANN (www.icann.org). В 2004-2005 году появился ряд новых доменов общего пользования, о которых мы не упоминаем.
В доменах верхнего (первого) уровня, таких, как RU, UK, FR и т.д., регистрируются домены второго уровня. В одних странах принято регистрировать домены общего пользования второго уровня (ac.uk для академического сообщества Великобритании и co.uk для коммерческих организаций там же), в других - нет. Обычно регистрацией доменов занимаются провайдеры Интернет, в том числе и в России.
Процедуры регистрации могут быть более или менее строгими в разных доменах , потому что эти процедуры определяет организация, ответственная за домен . Например, в домене FI (Финляндия) можно зарегистрировать домен только резиденту Финляндии или компании, имеющей государственную регистрацию в налоговой службе этой страны.
Организация, управляющая доменом , может делегировать право на управление частью этого домена другой организации или структурному подразделению. Например, если компания Ford Motor владеет доменом ford.com (а это так и есть!), то она могла бы делегировать право администрирования поддомена rus.ford.com своему российскому подразделению (а вот такого домена на самом деле нет - и не спрашивайте, почему...). Тогда картинка бы выглядела так:
Внешняя линия ограничивает пространство имен всего домена ford.com, а внутренняя - пространство имен rus.ford.com. То, что домен rus.ford.com "делегирован", означает, что право его администрирования, т.е. изменения записей о компьютерах, входящих в этот домен , передано другой организации (или подразделению). Так, администрирование домена france.ford.com, как видно из рисунка, осуществляется той же организацией, что и ford.com, а rus.ford.com администрируют другие люди. Делегирование дает возможность передать управление поддоменом не только организационно другой структуре, но и "переселить" информацию о поддомене на другой сервер имен, как будет показано ниже.

Что такое зона

"Зоной" в пространстве доменных имен называется совокупность компьютеров, управление доменными именами которых делегировано одной организации (подразделению). Так, в примере с доменом ford.com Зоной ford.com называется совокупность всех компьютеров в домене ford.com и его поддоменах, за исключением поддомена rus.ford.com, так как зона rus.ford.com была делегирована другой организации (или подразделению). Зона ford.com на рисунке - это все, что находится между внутренней и внешней кривыми.
Каждый домен обслуживается по крайней мере двумя постоянно доступными серверами имен. Сервер имен хранит список компьютеров домена и определяет соответствие имен компьютеров их IP-адресам. Информация о домене также содержит сведения о маршрутизации почтовых сообщений, адресованных в этот домен . Физически сервер имен представляет собой процесс (демон), работающий в системе.
Самый распространенный в Интернете сервер имен для UNIX-систем - это bind (Berkeley Internet Name Daemon). Вместе с Solaris 9 поставляется BIND 8. В пакет BIND, кроме программы named (это и есть собственно сервер имен), входят утилиты для получения информации от DNS и т.п.

Как работает DNS?

Представьте себе, что пользователь на компьютере с замысловатым именем 33-dialup.comstar.net решил посмотреть web-сайт www.example.ru. Что произойдет после того, как он наберет этот адрес в строке браузера?
Браузер нуждается в IP-адресе web-сервера, поэтому он запросит сервер имен о том, какой адрес у www.example.ru. Спрашивается, а какому серверу имен он задаст этот вопрос? Очевидно, тому, который указан в настройках компьютера 33-dialup.comstar.net. Там, скорее всего, указан адрес сервера имен провайдера, скажем, ns.comstar.net.
Получив этот запрос, сервер имен провайдера вначале поищет ответ в своем кэше, т.к. все DNS -запросы кэшируются. Если в кэше ответа нет, сервер имен проверит, нет ли ответа в его локальной базе. Его там не окажется, поскольку ns.comstar.net не отвечает за домен example.ru.
После этого сервер имен ns.comstar.net отправит запрос серверу имен корневого домена , как показано на рис. 17.2. Естественно, корневой сервер не имеет представления об адресе www.example.ru. Однако ему известен адрес сервера имен зоны ru. Этот адрес и будет сообщен вопрошающему серверу имен.
Сервер имен ns.comstar.net теперь отправит запрос серверу имен домена .ru, адрес которого он только что узнал. Тот сообщит ему адрес сервера имен example.ru, поскольку это самый близкий к www.example.ru из известных ему серверов имен.
Наконец, отправив запрос на сервер имен домена example.ru, сервер ns.comstar.net получит ответ на вопрос об IP-адресе компьютера www.example.ru, потому что этот компьютер находится в домене example.ru и его адрес известен серверу имен этого домена . Впрочем, если бы такого компьютера не существовало, то гарантированно достоверную информацию об этом все равно можно получить только от авторитетного сервера имен - то есть от сервера имен домена example.ru.
Теперь сервер ns.comstar.net отправляет долгожданную информацию на компьютер 33-dialup.comstar.net.
Почему сервер имен ns.comstar.net отправлял так много запросов, чтобы удовлетворить клиента, в то время как серверы имен других доменов ограничивались лишь ссылкой на известный им источник информации, пусть и самый близкий к авторитетному серверу имен из известных им? Может быть, потому, что сервер имен Comstar - самый вежливый в Сети? Оказывается, дело в том, что клиентская программа с 33-dialup.comstar.net прислала ему так называемый рекурсивный запрос, т.е. просьбу найти сам адрес, а не присылать ссылку на ближайший сервер имен. Так поступают все клиенты. Серверы имен обычно настроены так, чтобы самостоятельно выполнить поиск, поэтому ns.comstar.net отправлял другим серверам имен нерекурсивные запросы.
Возникает вопрос: а не слишком ли долго ждал ответа пользователь у компьютера 33-dialup.comstar.net? Как ни странно, недолго. И объясняется это тем, что DNS -запросы - это высокоприоритетный трафик, и маршрутизаторы в сети стараются передавать их побыстрее, вне очереди (конечно, всегда может организоваться "очередь тех, кто без очереди", но в ней все-таки стоять немного лучше). Кроме того, все вышеупомянутые серверы имен связаны достаточно быстрыми каналами связи. И наконец, высока вероятность, что на каком-то этапе ответ на запрос окажется в кэше промежуточного сервера имен, и часть запросов окажется ненужной. Например, если в кэше сервера имен ns.comstar.net есть адрес сервера имен домена ru (а это весьма вероятно), то запрос к серверу имен корневого домена не потребуется.
Из этого примера ясно, что любой сервер имен обязан знать адреса серверов имен корневого домена . Этих серверов несколько в разных странах, и они регулярно обмениваются информацией, несмотря на то, что список доменов верхнего уровня и ответственных за них серверов имен меняется нечасто. Список серверов имен корневого домена всегда входит в дистрибутив ПО сервера имен.

Полностью определенное доменное имя

Каждый компьютер в сети имеет имя. Например, компьютер, на котором я пишу эту книгу, называется sunny. Это его собственное имя, но по такому имени его можно отыскать только в моем локальном домене , но не в Интернете. Для получения доступа к компьютерам в других доменах следует указывать их полные имена. Это похоже на то, как мы обращаемся к файлам. Если я хочу посмотреть файл text в текущем каталоге, я дам команду

cat text

Если же этот файл лежит в другом каталоге, например, /usr/share/, то я дам команду

cat /usr/share/text

Аналогично для обращения через ssh к моему компьютеру из другого домена надо набрать что-то вроде

ssh sunny.eu.spb.ru

Некоторым (весьма редким) программам важно указать, что это полное имя компьютера. Для этого надо в конце имени поставить точку - она показывает, что слева от нее стоит имя домена верхнего уровня, т.к. сама точка обозначает корневой домен . Такое полное имя называют полностью определенным доменным именем (FQDN - fully qualified domain name).
Почему же точек в имени несколько, спросите вы, - ведь корневой домен всего один? На самом деле корневой домен имеет невидимое имя, и это имя - пустая строка! Это действительно так, за самой правой точкой в полностью определенном имени есть имя корневого домена - эта самая пустая строка. А символ точки - это всего лишь разделитель имен доменов и поддоменов. В тех случаях, когда на корневой домен все-таки надо как-то сослаться, используется его полное имя - символ точка (.). Не обозначать же его просто пустой строкой - тогда его никто не увидит!
Настройка клиента DNS
Настройка клиента DNS чрезвычайно проста - следует лишь указать верные значения в /etc/nsswitch.conf и /etc/resolv.conf. В последнем файле надо указывать IP-адрес, а не имя сервера имен, ибо нельзя обратиться к серверу имен по имени - ведь это он должен преобразовывать имена в IP-адреса.
Вот выдержка из файла /etc/nsswitch.conf:
#
# /etc/nsswitch.dns:
#
# An example file that could be copied over to
# /etc/nsswitch.conf; it uses
# DNS for hosts lookups, otherwise it does not use any
# other naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of
# "inet" transports.
passwd:                files
group:                 files
# You must also set up the /etc/resolv.conf file for
# DNS name server lookup. See resolv.conf(4).
hosts:                 files dns
ipnodes:               files
networks:              files
protocols:             files
Файл resolv.conf при этом выглядит так:
domain eu.spb.ru
nameserver 192.168.5.63
search eu.spb.ru
Настройка сервера DNS
Программа, которая является сервером имен и реализует службу DNS в Solaris, называется in.named (/usr/sbin/in.named). С системой Solaris 9 поставляется пакет BIND версии 8.2.4, в который входит эта программа.
Конфигурационный файл этой программы называется /etc/named.conf. Сервер имен всегда имеет рабочий каталог, где он хранит базу данных информации о доменах .
Этот каталог указывается в инструкции directory в файле конфигурации named.conf, и довольно часто администраторы выбирают в качестве такого каталога /var/named/.
В файле /etc/named.conf кроме имени рабочего каталога указываются все домены , за которые отвечает данный сервер имен, и названия файлов с описаниями этих доменов ; каждому домену соответствует свой файл описания. Один сервер имен может хранить информацию о нескольких доменах .
Правила регистрации доменов требуют, чтобы за каждый домен отвечали, как минимум, два сервера имен в разных IP-сетях; это правило ввели для страховки на случай непредвиденного отключения маршрутизации к одной из сетей.
Прежде чем начать подробное изучение файлов данных и файла конфигурации сервера имен, сделаем важное замечание: во всех этих файлах в Solaris 9 поставляемый с системой in.named ожидал в качестве разделителей полей знаки табуляции, а не пробелы! Если сервер имен при загрузке сообщает, что не смог найти информацию в файле конфигурации или файлах данных, следует:

  1. Уточнить, действительно ли вы строго следовали синтаксису файлов. Наиболее распространенными ошибками являются: отсутствие точки с запятой после инструкции в named.conf, отсутствие точки с запятой перед фигурной скобкой в named.conf, использование не тех скобок (круглых в named.conf или фигурных при описании домена в файле данных домена в записи SOA), непарные скобки (часто появляются в результате редактирования ранее созданного файла);
  2. Проверить, не являются ли символы-разделители полей в записях в файлах чем-либо, кроме табуляции (такое может возникнуть при переносе файлов откуда-либо методом cut-and-paste). Если не уверены в том, что там верные символы, лучше заменить их на табуляцию.

Рассмотрим файл /etc/named.conf в нашей системе. Положим, наш сервер имен обслуживает два домена : klava.net и macro.ru, причем для последнего домена наш сервер будет выполнять роль вторичного сервера имен.
options {
// это комментарий, раз строка начинается с //
directory "/var/named";
};
// дальше идет описание зон.
// эти - корневая и обратная локальная - обязательны
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0";
};
// дальше - описания зон, за которые мы отвечаем
zone "klava.net" {
type master;
file "klava.net";
};
// а это - те зоны, для которых наш сервер - вторичный
zone "macro.ru" {
type slave;
file "sec/macro.ru";
masters {
194.220.38.65;
};
};

Файл описания корневого домена named.root (фактически, список серверов имен корневого домена ) может быть уже установлен в системе. Если это не так, то его можно получить из самого надежного источника - по адресу ftp://ftp.rs.internic.net/domain/.
Каталог, в котором будут храниться файлы описаний доменов , для которых наш сервер имен является вторичным, должен быть доступен демону in.named для записи. Обычно это каталог /var/named/sec.
Файл описания домена состоит из записей, по одной на строку, называемых записями о ресурсах (RR - resource records). Каждый из ресурсов имеет класс и тип. В сети Интернет используется только класс IN, но DNS позволяет описывать ресурсы и других классов. Мы не будем рассматривать никакие классы, кроме IN. Типы ресурса бывают такими:

  • A - указание адреса компьютера с определенным именем (для поиска адреса по имени);
  • PTR - указание имени компьютера с определенным адресом (для поиска имени по адресу);
  • MX - указание почтового сервера для ресурса (домена или компьютера);
  • CNAME - псевдоним другого ресурса;
  • HINFO - текстовое описание ресурса;
  • SOA (starting of authority) - служебная информация о домене в целом.
  • NS - указание имени сервера имен для домена .

Каждая запись имеет определенный формат, а именно:
имя ресурса    класс          тип     информация
Изучим файлы описания доменов , на которые ссылались инструкции из файла /etc/named.conf:
klava.net:
$TTL    3600
@       IN      SOA     sunny.eu.spb.ru. hostmaster.sunny.eu.spb.ru. (
2004060101
3600
1200
3600000
3600 )
IN   NS             sunny.eu.spb.ru.
IN   MX      5       mail.eu.spb.ru.
IN   MX      10      sunny.eu.spb.ru.
mail    IN      A       194.221.15.1
127.0.0:
$TTL    3600
@       IN      SOA     sunny.eu.spb.ru.       hostmaster.sunny.eu.spb.ru. (
2004060100
3600
1200
3600000
3600 )
IN   NS      sunny.eu.spb.ru.
1       IN      PTR     localhost.
Тип SOA - это единственный тип, который предполагает многострочную запись. В записи SOA указывается имя домена (символ @ - это макроопределение, вместо которого подставляется имя домена из файла named.conf), полное имя авторитетного name-сервера домена , адрес персоны, ответственной за домен , времена и тайм-ауты обновления сведений о домене :

  • sunny.eu.spb.ru. - это имя авторитетного сервера имен. Авторитетным называется такой сервер имен, ответы которого не подвергаются сомнению. Дело в том, что на запрос о домене может ответить не только сервер имен, отвечающий за этот домен , но и любой другой сервер имен, если он получил эту информацию по запросу. Авторитетный ответ (autoritative answer) может быть получен только с сервера имен, непосредственно отвечающего за интересующий нас домен ;
  • hostmaster.sunny.eu.spb.ru. - это адрес e-mail персоны, ответственной за домен ; так как символ @ уже используется в описании домена в другом значении, то здесь он заменен на точку; когда вы будете писать письма ответственному лицу, делайте обратную замену и пишите по адресу hostmaster@sunny.eu.spb.ru.

Обратите внимание на то, что в конце адреса и в конце имени сервера стоит знак "точка" (.) - это для того, чтобы явно указать, что мы имеем дело с полностью определенным доменным именем . Если точку в конце имени не поставить, то после написанного в файле имени будет подставлено имя домена , например, если написать вместо "sunny.eu.spb.ru." то же самое, но без точки - "sunny.eu.spb.ru", фактически сервер имен поймет это как sunny.eu.spb.ru.klava.net. (если мы говорим об описании домена klava.net).
После открывающей круглой скобки следует указывать серийный номер версии файла данных домена . Этот номер необходимо изменять каждый раз, когда меняется хоть что-то в описании домена . Если забыть об этом, информация на вторичных серверах имен не обновится.
Серийный номер удобно указывать в формате YYYYMMDDVV, где YYYY - год, MM - месяц, DD - число месяца, VV - версия описания домена за этот день. Как видите, этот стандартный формат ограничивает нас в количестве изменений за день - не более ста. Постарайтесь унять торопливость и вносите изменения, только когда это действительно понадобится, а не раз в пять минут, пожалуйста!
Числа на следующих строках обозначают, соответственно, в секундах:

  • 3600 - период опроса главного сервера имен вторичными серверами;
  • 1200 - период повторных попыток опроса главного сервера имен вторичными серверами в случае неудачи при первой попытке опроса;
  • 3600000 - время устаревания информации на вторичном сервере (т.е. время, через которое вторичный сервер должен считать, что информация потеряла актуальность, и, если не удается получить обновление с главного сервера, перестать отвечать на запросы о домене );
  • 3600 - время жизни негативного ответа (т.е. ответа "нет такого компьютера у нас в домене !"). Это время, в течение которого сервер, запросивший информацию от нашего сервера, не будет посылать вторичный запрос, если на первый запрос пришел отрицательный ответ.

Инструкция $TTL в начале файла указывает, что серверы, получающие от нас ответы на свои вопросы, должны кэшировать эти ответы на время TTL (в секундах).
Записи типа NS содержат имена серверов имен домена , причем здесь не делается различия между главными и вторичными серверами имен, порядок следования записей в файле домена сам по себе ничего не означает.
Записи MX описывают правила маршрутизации почты. Каждая запись указывает на один из почтовых серверов, принимающих почту для данного домена (или компьютера):
IN   MX      5       mail.eu.spb.ru.
IN   MX      10      sunny.eu.spb.ru.
В приведенном выше примере почта для домена klava.net принимается одним из двух почтовых серверов - mail.eu.spb.ru или sunny.eu.spb.ru. Число, следующее за ключевым словом MX в записях о маршрутизации почты, называется показателем предпочтительности (preference). Это число показывает, насколько предпочтительно посылать почту на указанный почтовый сервер по сравнению с другими почтовыми серверами. Если для домена или компьютера указаны несколько записей MX с различными показателями предпочтительности, то почта направляется на первый доступный почтовый сервер с минимальным значением показателя предпочтительности.
Алгоритм отправки почты любым почтовым сервером таков:

  1. Почтовый сервер отправителя запрашивает свой сервер имен (тот, что указан в /etc/resolv.conf), куда надо отправить письмо для указанного в заголовке письма адресата.
  2. Сервер имен выдает ему список записей MX для адресата.
  3. Почтовый сервер выбирает запись с наименьшим значением показателя предпочтительности и пытается отправить почту указанному в этой записи почтовому серверу.
  4. Если это не удается, выбирается следующая запись с минимальным (из оставшихся) показателем предпочтительности и делается попытка отправить почту через указанный в ней почтовый сервер.

Попытки отправки почты повторяются до тех пор, пока почтовое сообщение не будет успешно отправлено либо время, прошедшее с начала первой попытки, не превысит установленный тайм-аут. В последнем случае отправитель получит уведомление о невозможности доставить письмо. По умолчанию большинство почтовых серверов пытаются доставить письмо в течение 5 суток.

Все временно неотправленные письма накапливаются в очереди сообщений, и почтовый сервер регулярно обрабатывает очередь, вновь и вновь пытаясь отправить письма согласно вышеописанному алгоритму.

Обратная зона

Обратной зоной в терминах системы доменных имен называется домен специального вида. Как мы помним, DNS - это индексированная база данных информации о компьютерах, где индексом служит доменное имя. В некоторых случаях требуется как раз определить это доменное имя - по известному адресу. В этом случае индексом к информации о компьютере (а конкретно - его имени) должен служить IP-адрес. Поэтому потребовалось создать еще один, параллельный доменному имени , индекс. Для этого был создан домен in-addr.arpa. Этот домен используется исключительно для поиска соответствия между известным IP-адресом и (искомым) доменным именем . Реальный IP-адрес преобразуется в доменное имя в домене in-addr.arpa посредством переиначивания: так, компьютер с адресом 192.177.16.43 представляется в домене in-addr.arpa как 43.16.177.192.in-addr.arpa. Таким образом, все компьютеры в Интернете могут иметь (и в большинстве своем имеют) доменные имена в домене in-addr.arpa. Это не мешает им иметь доменные имена в других доменах , например, компьютер с адресом 192.177.16.43 вполне может также относиться к домену example.ru и иметь там имя mailhost.example.ru.
Чтобы запись о компьютере появилась в домене in-addr.arpa, поддомен этого домена должен быть делегирован тому провайдеру или той организации, которая владеет соответствующим диапазоном IP-адресов, например, компания Russian Example, владеющая, среди прочих сетей, сетью класса С 192.177.16/24, может "оформить на себя", т.е. просить делегировать ей домен 16.177.192.in-addr.arpa. После этого системный администратор компании создаст файл с описанием соответствия адресов компьютеров в example.ru их доменным именам в этом домене . Обратная зона готова.
Как используют данные обратной зоны ? Наиболее востребованный способ состоит в проверке подлинности отправителя почтового сообщения. Сейчас практически все почтовые серверы в Интернете при обработке соединения с ними выполняют следующую операцию: вначале они требуют от соединяющегося с ними почтового сервера представиться. Тот, допустим, говорит, что его имя - mail.relays.org. Пакет с ответом, разумеется, содержит обратный IP-адрес отправителя, и почтовый сервер запрашивает обратную зону DNS, чтобы выяснить, какое имя в ней числится у компьютера с таким IP-адресом. Если пришедший ответ и то, что удаленый сервер сообщил о себе (mail.relays.org), не совпадает, то соединение считается нелегальным и письмо не принимается.
На любом компьютере, где запущен сервер имен named, обязательно должен присутствовать файл, описывающий обратную зону самого компьютера (т.е. соответствие имени localhost адресу 127.0.0.1). Этот файл часто носит имя localhost.rev или 127.0.0. Естественно, этот файл описания локальной обратной зоны обязан быть упомянут в конфигурации сервера имен named.conf:

cat 127.0.0
@       IN      SOA     ns.example.ru. hostmaster.example.ru.  (
               1.2     ;       Serial
               3600    ;       Refresh
               300             ;       Retry
               3600000         ;       Expire
               3600 )  ;       Minimum
   IN   NS      ns.example.ru.
1       IN      PTR     localhost.
 

Файл обратной зоны не обязательно является копией файла прямой зоны с "переставленными" столбцами, поскольку в одном домене могут присутствовать компьютеры из разных IP-сетей, а одна IP-сеть может объединять компьютеры из разных доменов .
В качестве базового примера можно рассмотреть ситуацию, когда все компьютеры домена входят в одну IP-сеть.
Еще раз отметим, что выделение IP-сети не обеспечивает автоматического делегирования соответствующей обратной зоны . Чтобы получить право администрирования обратной зоны сети, адреса из которой назначены вашим компьютерам, следует написать заявку о делегировании обратной зоны по стандартной форме. Имеет смысл проконсультироваться у своего провайдера, как это сделать, или просто заказать ему выполнение этой работы.
Имя обратной зоны всегда пишется как адрес IP-сети "наоборот", а за ним добавляется суффикс in-addr.arpa. Такая "запись наоборот" была введена с учетом иерархической структуры DNS : левая часть имени обозначает компьютер, правая - домен . В случае с IP-адресами все наоборот. В адресе номер сети идет слева, а номер компьютера в сети - справа. Для встраивания в DNS это не годилось, и адреса сетей "подогнали" под стандарт DNS .
Рассмотрим в качестве примера файл обратной зоны сети 192.177.16/24:

 
; $ORIGIN 16.177.192.IN-ADDR.ARPA.
; 16.177.192.IN-ADDR.ARPA. - это имя обратной зоны 
@       IN      SOA     qwe.example.ru. hostmaster.example.ru. 
(                                             2001021501      ; Serial
                  21600   ; Refresh 3 hours
                  7200    ; Retry 1 hour
                  7200000 ; Expire 2000 hours
                  86400 ) ; Negative TTL 24 hours
     IN    NS      qwe.example.ru.
     IN    NS      ns.ussr.eu.net.
     IN    NS      ns.spb.su.
;
;
31             IN             PTR            qwe.example.ru.
67             IN             PTR            qwe.example.ru.
134            IN             PTR            post.example.ru.
236            IN             PTR            margo.example.ru.
239            IN             PTR            annas.example.ru.

В этом файле есть запись SOA, описывающая обратную зону в целом, записи NS, указывающие на серверы имен этой зоны, и записи PTR, которые и описывают соответствие имен компьютеров из домена example.ru адресам IP-сети.
Файл example.ru описывает домен example.ru:

 
; example.ru
;
$ORIGIN ru.
example     IN      SOA     ns.example.ru. hostmaster.imc.example.ru.
(              2002072401     ; Serial
      21600    ; Refresh 3 hour
      7200     ; Retry 1 hour
      360000   ; Expire 100 hours
      86400)   ; Minimum 1 hours
   IN          NS      ns.example.ru.
; Secondary servers
   IN          NS      ns.olly.ru.
   IN          NS      ns.qq.ru.
; Domain mail address
   IN          MX      3   post.example.ru.
   IN          MX      10  relay.qq.ru.
$ORIGIN example.ru.
;
ns      IN              A      192.177.16.31
;
; Aliases
;
ftp     IN             CNAME   qwe.example.ru.
www     IN             CNAME   qwe.example.ru.
mail    IN             CNAME   post.example.ru.
; Computers
;
qwe     IN             A       192.177.16.31
qwe     IN             A       192.177.16.67
post    IN             A       192.177.16.134
margo   IN             A       192.177.16.236
annas   IN             A       192.177.16.239
annas   IN      HINFO   AT-486, WGR
; Don't forget increase Serial, please.

Обратите внимание на то, что часть записей - это записи CNAME. Они создают удобные псевдонимы. Если роль, скажем, почтового сервера mail.example.ru будет передана от post.example.ru другому компьютеру, будет достаточно всего лишь изменить имя в записи CNAME. Думать о том, какой у нового почтового сервера IP-адрес, не придется.
Один компьютер может иметь несколько IP-адресов (принадлежащих одному или - чаще - нескольким сетевым интерфейсам). Один IP-адрес может соответствовать нескольким именам компьютера, потому что компьютер может иметь несколько имен.
Помните, что если в файле описания домена встретятся имена доменов или компьютеров, не заканчивающиеся точкой, то они будут восприняты как неполностью определенные, и к ним будет дописан суффикс по умолчанию. Так, если в описании зоны вместо

 
qwe             IN      A       192.177.16.67

написать

 
qwe.example.ru  IN      A       192.177.16.67

то сервер имен воспримет эту запись как

qwe.example.ru.example.ru.   IN    A    192.177.16.67

Это не совсем то, что мы хотели, верно? Если мы хотим явно указать полное имя, следует написать так (обратите внимание на завершающую точку!):

qwe.example.ru.  IN      A       192.177.16.67

Программы для запросов к серверам имен
Чтобы получить информацию о чужом домене или проверить настройки собственного сервера имен, можно использовать несколько утилит, опрашивающих серверы DNS .
Прежде всего, это программа nslookup. Проверим наши настройки:

nslookup
Default Server: localhost
Address: 127.0.0.1
> set typ=soa
> klava.net.
Server: localhost
Address: 127.0.0.1
klava.net:
kir.spb.ru
origin = gate.co.spb.ru
mail addr = milu.co.spb.ru
serial = 2001012301
refresh = 21600 (6H)
retry  = 3600 (1H)
expire = 864000 (1w3d)
minimum ttl = 3600 (1H)
kir.spb.ru     nameserver = gate.co.spb.ru
kir.spb.ru     nameserver = imc.example.ru
gate.co.spb.ru         internet address = 192.168.5.19
imc.example.ru         internet address = 193.114.38.33
imc.example.ru         internet address = 193.114.38.65
imc.example.ru         internet address = 195.70.192.166
А вот так можно получить всю информацию о конкретной зоне или компьютере:
> set typ=any
> www.rbc.ru
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
www.rbc.ru     internet address = 62.118.249.16
www.rbc.ru     internet address = 62.118.249.66
www.rbc.ru     internet address = 194.186.36.138
www.rbc.ru     internet address = 194.186.36.175
www.rbc.ru     preference = 10, mail exchanger = mail.rbc.ru
www.rbc.ru     preference = 20, mail exchanger = relay.rbc.ru
www.rbc.ru     preference = 30, mail exchanger = relay2.rbc.ru
Authoritative answers can be found from:
rbc.ru nameserver = ns2.rbc.ru
rbc.ru nameserver = ns3.rbc.ru
mail.rbc.ru    internet address = 80.68.240.91
relay.rbc.ru   internet address = 80.68.240.103
relay2.rbc.ru  internet address = 194.186.36.142
ns2.rbc.ru     internet address = 62.118.249.100
ns3.rbc.ru     internet address = 194.186.36.186
Выход из программы nslookup - "Ctrl-D".
С программой host работать еще проще, но она не входит в стандартную поставку Solaris, поэтому привыкшим к ней администраторам Linux и FreeBSD следует использовать dig:
dig @localhost klava.net
; <<>> DiG 8.3 <<>> @localhost klava.net
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0
;; QUERY SECTION:
;;   klava.net, type = A, class = IN
;; AUTHORITY SECTION:
klava.net.       1H IN SOA    sunny.eu.spb.ru.
hostmaster.sunny.eu.spb.ru. (
2004060101 ; serial
1H   ; refresh
20M ; retry
5w6d16h     ; expiry
1H )        ; minimum
;; Total query time: 1 msec
;; FROM: sunny to SERVER: localhost 127.0.0.1
;; WHEN: Tue Jun 1 12:58:55 2004
;; MSG SIZE sent: 27 rcvd: 89

dig yandex.ru
; <<>> DiG 8.3 <<>> yandex.ru
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4,
ADDITIONAL: 4
;; QUERY SECTION:
;;   yandex.ru, type = A, class = IN
;; ANSWER SECTION:
yandex.ru.     1h58m12s IN A  213.180.216.200
;; AUTHORITY SECTION:
yandex.ru.     23h3m57s IN NS ns2.yandex.ru.
yandex.ru.     23h3m57s IN NS ns3.yandex.ru.
yandex.ru.     23h3m57s IN NS ns.ispm.ru.
yandex.ru.     23h3m57s IN NS ns1.yandex.ru.
;; ADDITIONAL SECTION:
ns2.yandex.ru. 23h30m16s IN A 213.180.199.34
ns3.yandex.ru. 23h30m16s IN A 213.180.193.2
ns.ispm.ru.    15h4m39s  IN A  80.244.228.2
ns1.yandex.ru. 23h30m16s IN A 213.180.193.1
;; Total query time: 8 msec
;; FROM: sunny to SERVER: default -- 192.168.5.18
;; WHEN: Tue Jun 1 17:34:51 2004
;; MSG SIZE sent: 27 rcvd: 185
Для получения информации о домене , ответственной за него организации и его регистрационных данных служит программа whois:
whois -h whois.ripn.net rambler.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:        RAMBLER.RU
type:   CORPORATE
nserver:       ns.park.rambler.ru. 81.19.67.2
nserver:       ns.rambler.ru. 81.19.66.49
state: REGISTERED, DELEGATED
org:    Rambler Internet Holdings, LLC
phone: +7 095 7453619
fax-no:        +7 095 7453619
e-mail:        dns@rambler-co.ru
e-mail:        denis@rambler-co.ru
registrar:     RUCENTER-REG-RIPN
created:       1996.09.26
paid-till:     2004.08.01
source:        RIPN
Last updated on 2004.06.01 17:46:29 MSK/MSD
whois -h whois.ripe.net PT30-RIPE
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html
person:        Philip I Torchinsky
address:       Institute of Macromolecular Compounds
address:       Bolshoi pr., 31
address:       St.Petersburg 199004
address:       Russia
phone: +7 812 218 56 01
fax-no:        +7 812 218 68 69
e-mail:        filip@macro.lgu.spb.su
e-mail:        root@filip.stud.pu.ru
nic-hdl:       PT30-RIPE
changed:       filip@macro.lgu.spb.su 19960125
source:        RIP
Как видим, программа whois может помочь узнать не только информацию о зарегистрировавшей домен организации, но и о персоне, отвечающей за тот или иной домен .
Если программы whois нет под рукой или соединения с портом 43 запрещены фильтром пакетов, можно воспользоваться "чужой" программой whois через доступный всем web-интерфейс (например, www.internic.net/whois.html или www.ripn.net/nic/whois/index.html).

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика