Все привыкли к тому, что имена компьютеров в Интернете выглядят как несколько слов, разделенных точками, например,
Домен – это совокупность компьютеров в сети. Их объединяет только имя домена, т.е. для того, чтобы некий компьютер оказался элементом домена, достаточно в описании домена указать, что он к нему относится и самому компьютеру об этом сказать. Компьютеры одного и того же домена могут быть удалены друг от друга географически, могут быть подключены к совершенно разным сетям и, возможно, даже не общаться между собой.
Домен может содержать отдельные компьютеры и поддомены. Поддомен – это домен, входящий в домен верхнего уровня. Любой домен, кроме корневого, является чьим-то поддоменом. Иерархия доменов легко прослеживается в их именах: домен
Вся совокупность имен доменов называется "пространством имен доменов", и это название, должно быть, оценят математики. Чтобы структурировать пространство имен и облегчить именование новых компьютеров в сети, давно договорились, что все домены верхнего ("первого") уровня, т.е. те, что являются поддоменами корневого домена, делятся на две большие группы: национальные и общего пользования. Национальные домены (
Домены общего пользования (generic top level domains,
Координацией всего, что связано с системой доменных имен, занимается общественная организация
В доменах верхнего (первого) уровня, таких, как RU, UK, FR и т.д., регистрируются домены второго уровня. В одних странах принято регистрировать домены общего пользования второго уровня (ac.uk для академического сообщества Великобритании и co.uk для коммерческих организаций там же), в других – нет. Обычно регистрацией доменов занимаются провайдеры Интернет, в том числе и в России.
Процедуры регистрации могут быть более или менее строгими в разных доменах, потому что эти процедуры определяет организация, ответственная за домен. Например, в домене FI (Финляндия) можно зарегистрировать домен только резиденту Финляндии или компании, имеющей государственную регистрацию в налоговой службе этой страны.
Организация, управляющая доменом, может делегировать право на управление частью этого домена другой организации или структурному подразделению. Например, если компания Ford Motor владеет доменом ford.com (а это так и есть!), то она могла бы делегировать право администрирования поддомена rus.ford.com своему российскому подразделению (а вот такого домена на самом деле нет – и не спрашивайте, почему...).
Тогда картинка бы выглядела так:
(рис 5.1) Делегирование поддомена 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-адресам. Информация о домене также содержит сведения о маршрутизации почтовых сообщений, адресованных в этот домен. Физически сервер имен представляет собой процесс (демона), работающего в системе. Этот демон называется сервером имен (NS, name server).
Самый распространенный в Интернет сервер имен для UNIX-систем – это bind (Berkeley Internet Name Daemon). Вместе с Solaris 9 поставляется BIND 8. В пакет BIND, кроме программы named (это и есть собственно сервер имен), входят утилиты для получения информации от DNS и т.п.
Лучшей книгой про DNS уже много лет подряд остается книга "DNS и BIND" издательства O'Reilly Assosiates. Русский перевод издан в издательстве "Символ-плюс" (www.books.ru).
Представьте себе, что пользователь на компьютере с замысловатым именем 33-
Веб-обозреватель нуждается в IP-адресе веб-сервера, поэтому он запросит сервер имен о том, какой адрес у www.example.ru. Спрашивается, а какому серверу имен он задаст этот вопрос? Очевидно, тому, который указан в настройках компьютера 33-
Получив этот запрос, сервер имен провайдера вначале поищет ответ в своем кэше, т.к. все DNS-запросы кэшируются. Если в кэше ответа нет, сервер имен посмотрит, нет ли ответа в его локальной базе. Его там не окажется, так как ns.comstar.net не отвечает за домен example.ru.
После этого сервер имен ns.comstar.net отправит запрос серверу имен корневого домена, как показано на рис. 5.2. Естественно, корневой сервер не имеет представления об адресе www.example.ru. Однако, ему известен адрес сервера имен зоны ru. Этот адрес и будет сообщен вопрошающему серверу имен.
(рис 5.2) Поиск адреса по имени сервером именСервер имен 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-
Почему сервер имен ns.comstar.net отправлял так много запросов, чтобы удовлетворить клиента, а серверы имен других доменов ограничивались лишь ссылкой на известный им источник информации, пусть и самый близкий к авторитетному серверу имен из известных им? Может быть, потому, что сервер имен Comstar – самый вежливый в Сети? Оказывается, дело в том, что клиентская программа с 33-
Возникает вопрос: а не слишком ли долго ждал ответа пользователь у компьютера 33-
Из этого примера ясно, что любой сервер имен обязан знать адреса серверов имен корневого домена. Этих серверов несколько в разных странах, и они регулярно обмениваются информацией, несмотря на то, что список доменов верхнего уровня и ответственных за них серверов имен меняется нечасто. Список серверов имен корневого домена всегда входит в дистрибутив ПО сервера имен.
Каждый компьютер в сети имеет имя. Например, мой компьютер, на котором я пишу книгу, называется sunny. Это его собственное имя, но по такому имени его можно отыскать только в моем локальном домене, но не в Интернете. Для получения доступа к компьютерам в других доменах следует указывать их полные имена. Это похоже на то, как мы обращаемся к файлам. Если я хочу посмотреть файл text в текущем каталоге, я дам команду
cat text
Если же этот файл лежит в другом каталоге, например, /usr/share/, то я дам команду
cat /usr/share/ text
Аналогично, для обращения через ssh к моему компьютеру из другого домена надо сказать что-то вроде
ssh sunny.eu.spb.ru
Некоторым (весьма редким) программам важно указать, что это полное имя компьютера. Для этого надо в конце имени поставить точку – она показывает, что слева от нее стоит имя домена верхнего уровня, т.к. сама точка обозначает корневой домен. Такое полное имя называют полностью определенным доменным именем (FQDN – fully qualified domain name).
Почему же точек в имени несколько, спросите вы, – ведь корневой домен всего один? На самом деле корневой домен имеет невидимое имя, потому что это имя – пустая строка. Нет-нет, я не разыгрываю никого, это правда! И за самой правой точкой в полностью определенном имени действительно есть имя корневого домена – эта самая пустая строка. Не ожидали? Тем не менее, это так. А символ точки – это всего лишь разделитель имен доменов и поддоменов. В тех случаях, когда на корневой домен все-таки надо как-то сослаться, используется его обозначение – символ точка (.). Ну не обозначать же его просто пустой строкой – тогда его никто не увидит!
Настройка клиента 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 в Solaris, называется in.named ( /usr/sbin/in.named ). С системой Solaris 10 поставляется пакет BIND версии 9 (например, в SXDE 1/08 установлен bind 9.3.4-P1), в который входит эта программа.
Конфигурационный файл этой программы называется /etc/named.conf. Сервер имен всегда имеет рабочий каталог, где он хранит базу данных информации о доменах. Этот каталог указывается в инструкции directory в файле конфигурации named.conf, и довольно часто администраторы выбирают в качестве такого каталога /var/named/.
В файле /etc/named.conf кроме имени рабочего каталога указываются все домены, за которые отвечает данный сервер имен, и названия файлов с описаниями этих доменов; каждому домену соответствует свой файл описания. Один сервер имен может хранить информацию о нескольких доменах.
Правила регистрации доменов требуют, чтобы за каждый домен отвечали, как минимум, два сервера имен в разных IP-сетях; это правило ввели ради страховки на случай непредвиденного отключения маршрутизации к одной из сетей.
Прежде чем начать подробное изучение файлов данных и файла конфигурации сервера имен, сделаем важное замечание: во всех этих файлах в Solaris 10 поставляемый с системой in.named ожидал в качестве разделителей полей знаки табуляции, а не пробелы! Если при загрузке сервера имен он сообщает, что не смог найти информацию в файле конфигурации или файлах данных, следует:
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) – служебная информация о домене в целом.Каждая запись имеет определенный формат, а именно:
имя ресурса класс тип информация
Изучим файлы описания доменов, на которые ссылались инструкции из файла /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-сервера домена, адрес персоны, ответственной за домен, времена и тайм-ауты обновления сведений о домене:
@ уже используется в описании домена в другом значении, то здесь он заменен на точку; когда вы будете писать письма ответственному лицу, делайте обратную замену и пишите по адресу 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 – версия описания домена за этот день. Как видите, этот стандартный формат ограничивает нас в количестве изменений за день – не более ста. Постарайтесь унять торопливость и вносите изменения, только когда это действительно понадобится, а не раз в пять минут, пожалуйста!
Числа на следующих строках обозначают, соответственно, в секундах:
Инструкция $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 с различными показателями предпочтительности, то почта направляется на первый доступный почтовый сервер с минимальным значением показателя предпочтительности.
Алгоритм отправки почты любым почтовым сервером таков:
/etc/resolv.conf ), куда надо отправить письмо для указанного в заголовке письма адресата;Попытки отправки почты повторяются, пока почтовое сообщение не будет успешно отправлено либо пока время, прошедшее с начала первой попытки, не превысит установленный тайм-аут. В последнем случае отправитель получит уведомление о невозможности доставить письмо. По умолчанию большинство почтовых серверов пытаются доставить письмо в течение 5 суток.
Все временно не отправленные письма накапливаются в очереди сообщений, и почтовый сервер регулярно обрабатывает очередь, вновь и вновь пытаясь отправить письма согласно вышеописанному алгоритму.
Чтобы запись о компьютере появилась в домене in-addr.arpa, поддомен этого домена должен быть делегирован тому провайдеру или той организации, которая владеет соответствующим диапазоном IP-адресов, – например, компания Russian Example, владеющая, среди прочих сетей, сетью класса С 192.177.16/24, может "оформить на себя", т.е. просить делегировать ей, домен 16.177.192.in-addr.arpa. После этого системный администратор компании создаст файл с описанием соответствия адресов компьютеров в example.ru их доменным именам в этом домене.
Как используют данные
На любом компьютере, где запущен сервер имен named, обязательно должен присутствовать файл, описывающий обратную зону самого компьютера (т.е. соответствие имени localhost адресу 127.0.0.1). Этот файл часто носит имя localhost.rev или 127.0.0. Естественно, этот файл описания локальной
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-сети не обеспечивает автоматического делегирования соответствующей
Имя
Рассмотрим в качестве примера файл
; $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 remember 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
В некоторых случаях требуется устанавливать соответствие между IP-адресом и именем компьютера в ситуации, когда имя компьютера заранее не известно. Именно так бывает, когда надо создать описание $GENERATE (доступен в bind версии 8 и выше). Вот пример файла
@ IN SOA ns.provider.ru. hostmaster.provider.ru. ( 2006042002 ; Serial 21600 ; Refresh 3 hours 7200 ; Retry 1 hour 3600000 ; Expire 1000 hours 86400 ) ; Minimum 24 hours IN NS ns.provider.ru. ; address -> full name with end point ; 82 IN PTR pluto.provider.ru. 84 IN PTR orion.provider.ru. $GENERATE 130-254 $ PTR pool-10-$.provider.ru.
Макрос в последней строке данного примера эквивалентен множеству строк, начинающемуся строкой
130 IN PTR pool-10-130.provider.ru.
и заканчивающемуся строкой
254 IN PTR pool-10-254.provider.ru.
Чтобы получить информацию о чужом домене или проверить настройки собственного сервера имен, можно использовать несколько утилит, опрашивающих серверы DNS.
Во-первых, это программа nslookup. Проверим наши настройки:
nslookup Default Server: localhost Address: 127.0.0.1 > set type=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 type=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).
Все привыкли к тому, что имена компьютеров в Интернете выглядят как несколько слов, разделенных точками, например,
Домен – это совокупность компьютеров в сети. Их объединяет только имя домена, т.е. для того, чтобы некий компьютер оказался элементом домена, достаточно в описании домена указать, что он к нему относится и самому компьютеру об этом сказать. Компьютеры одного и того же домена могут быть удалены друг от друга географически, могут быть подключены к совершенно разным сетям и, возможно, даже не общаться между собой.
Домен может содержать отдельные компьютеры и поддомены. Поддомен – это домен, входящий в домен верхнего уровня. Любой домен, кроме корневого, является чьим-то поддоменом. Иерархия доменов легко прослеживается в их именах: домен
Вся совокупность имен доменов называется "пространством имен доменов", и это название, должно быть, оценят математики. Чтобы структурировать пространство имен и облегчить именование новых компьютеров в сети, давно договорились, что все домены верхнего ("первого") уровня, т.е. те, что являются поддоменами корневого домена, делятся на две большие группы: национальные и общего пользования. Национальные домены (
Домены общего пользования (generic top level domains,
Координацией всего, что связано с системой доменных имен, занимается общественная организация
В доменах верхнего (первого) уровня, таких, как RU, UK, FR и т.д., регистрируются домены второго уровня. В одних странах принято регистрировать домены общего пользования второго уровня (ac.uk для академического сообщества Великобритании и co.uk для коммерческих организаций там же), в других – нет. Обычно регистрацией доменов занимаются провайдеры Интернет, в том числе и в России.
Процедуры регистрации могут быть более или менее строгими в разных доменах, потому что эти процедуры определяет организация, ответственная за домен. Например, в домене FI (Финляндия) можно зарегистрировать домен только резиденту Финляндии или компании, имеющей государственную регистрацию в налоговой службе этой страны.
Организация, управляющая доменом, может делегировать право на управление частью этого домена другой организации или структурному подразделению. Например, если компания Ford Motor владеет доменом ford.com (а это так и есть!), то она могла бы делегировать право администрирования поддомена rus.ford.com своему российскому подразделению (а вот такого домена на самом деле нет – и не спрашивайте, почему...).
Тогда картинка бы выглядела так:
(рис 5.1) Делегирование поддомена 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-адресам. Информация о домене также содержит сведения о маршрутизации почтовых сообщений, адресованных в этот домен. Физически сервер имен представляет собой процесс (демона), работающего в системе. Этот демон называется сервером имен (NS, name server).
Самый распространенный в Интернет сервер имен для UNIX-систем – это bind (Berkeley Internet Name Daemon). Вместе с Solaris 9 поставляется BIND 8. В пакет BIND, кроме программы named (это и есть собственно сервер имен), входят утилиты для получения информации от DNS и т.п.
Лучшей книгой про DNS уже много лет подряд остается книга "DNS и BIND" издательства O'Reilly Assosiates. Русский перевод издан в издательстве "Символ-плюс" (www.books.ru).
Представьте себе, что пользователь на компьютере с замысловатым именем 33-
Веб-обозреватель нуждается в IP-адресе веб-сервера, поэтому он запросит сервер имен о том, какой адрес у www.example.ru. Спрашивается, а какому серверу имен он задаст этот вопрос? Очевидно, тому, который указан в настройках компьютера 33-
Получив этот запрос, сервер имен провайдера вначале поищет ответ в своем кэше, т.к. все DNS-запросы кэшируются. Если в кэше ответа нет, сервер имен посмотрит, нет ли ответа в его локальной базе. Его там не окажется, так как ns.comstar.net не отвечает за домен example.ru.
После этого сервер имен ns.comstar.net отправит запрос серверу имен корневого домена, как показано на рис. 5.2. Естественно, корневой сервер не имеет представления об адресе www.example.ru. Однако, ему известен адрес сервера имен зоны ru. Этот адрес и будет сообщен вопрошающему серверу имен.
(рис 5.2) Поиск адреса по имени сервером именСервер имен 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-
Почему сервер имен ns.comstar.net отправлял так много запросов, чтобы удовлетворить клиента, а серверы имен других доменов ограничивались лишь ссылкой на известный им источник информации, пусть и самый близкий к авторитетному серверу имен из известных им? Может быть, потому, что сервер имен Comstar – самый вежливый в Сети? Оказывается, дело в том, что клиентская программа с 33-
Возникает вопрос: а не слишком ли долго ждал ответа пользователь у компьютера 33-
Из этого примера ясно, что любой сервер имен обязан знать адреса серверов имен корневого домена. Этих серверов несколько в разных странах, и они регулярно обмениваются информацией, несмотря на то, что список доменов верхнего уровня и ответственных за них серверов имен меняется нечасто. Список серверов имен корневого домена всегда входит в дистрибутив ПО сервера имен.
Каждый компьютер в сети имеет имя. Например, мой компьютер, на котором я пишу книгу, называется sunny. Это его собственное имя, но по такому имени его можно отыскать только в моем локальном домене, но не в Интернете. Для получения доступа к компьютерам в других доменах следует указывать их полные имена. Это похоже на то, как мы обращаемся к файлам. Если я хочу посмотреть файл text в текущем каталоге, я дам команду
cat text
Если же этот файл лежит в другом каталоге, например, /usr/share/, то я дам команду
cat /usr/share/ text
Аналогично, для обращения через ssh к моему компьютеру из другого домена надо сказать что-то вроде
ssh sunny.eu.spb.ru
Некоторым (весьма редким) программам важно указать, что это полное имя компьютера. Для этого надо в конце имени поставить точку – она показывает, что слева от нее стоит имя домена верхнего уровня, т.к. сама точка обозначает корневой домен. Такое полное имя называют полностью определенным доменным именем (FQDN – fully qualified domain name).
Почему же точек в имени несколько, спросите вы, – ведь корневой домен всего один? На самом деле корневой домен имеет невидимое имя, потому что это имя – пустая строка. Нет-нет, я не разыгрываю никого, это правда! И за самой правой точкой в полностью определенном имени действительно есть имя корневого домена – эта самая пустая строка. Не ожидали? Тем не менее, это так. А символ точки – это всего лишь разделитель имен доменов и поддоменов. В тех случаях, когда на корневой домен все-таки надо как-то сослаться, используется его обозначение – символ точка (.). Ну не обозначать же его просто пустой строкой – тогда его никто не увидит!
Настройка клиента 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 в Solaris, называется in.named ( /usr/sbin/in.named ). С системой Solaris 10 поставляется пакет BIND версии 9 (например, в SXDE 1/08 установлен bind 9.3.4-P1), в который входит эта программа.
Конфигурационный файл этой программы называется /etc/named.conf. Сервер имен всегда имеет рабочий каталог, где он хранит базу данных информации о доменах. Этот каталог указывается в инструкции directory в файле конфигурации named.conf, и довольно часто администраторы выбирают в качестве такого каталога /var/named/.
В файле /etc/named.conf кроме имени рабочего каталога указываются все домены, за которые отвечает данный сервер имен, и названия файлов с описаниями этих доменов; каждому домену соответствует свой файл описания. Один сервер имен может хранить информацию о нескольких доменах.
Правила регистрации доменов требуют, чтобы за каждый домен отвечали, как минимум, два сервера имен в разных IP-сетях; это правило ввели ради страховки на случай непредвиденного отключения маршрутизации к одной из сетей.
Прежде чем начать подробное изучение файлов данных и файла конфигурации сервера имен, сделаем важное замечание: во всех этих файлах в Solaris 10 поставляемый с системой in.named ожидал в качестве разделителей полей знаки табуляции, а не пробелы! Если при загрузке сервера имен он сообщает, что не смог найти информацию в файле конфигурации или файлах данных, следует:
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) – служебная информация о домене в целом.Каждая запись имеет определенный формат, а именно:
имя ресурса класс тип информация
Изучим файлы описания доменов, на которые ссылались инструкции из файла /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-сервера домена, адрес персоны, ответственной за домен, времена и тайм-ауты обновления сведений о домене:
@ уже используется в описании домена в другом значении, то здесь он заменен на точку; когда вы будете писать письма ответственному лицу, делайте обратную замену и пишите по адресу 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 – версия описания домена за этот день. Как видите, этот стандартный формат ограничивает нас в количестве изменений за день – не более ста. Постарайтесь унять торопливость и вносите изменения, только когда это действительно понадобится, а не раз в пять минут, пожалуйста!
Числа на следующих строках обозначают, соответственно, в секундах:
Инструкция $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 с различными показателями предпочтительности, то почта направляется на первый доступный почтовый сервер с минимальным значением показателя предпочтительности.
Алгоритм отправки почты любым почтовым сервером таков:
/etc/resolv.conf ), куда надо отправить письмо для указанного в заголовке письма адресата;Попытки отправки почты повторяются, пока почтовое сообщение не будет успешно отправлено либо пока время, прошедшее с начала первой попытки, не превысит установленный тайм-аут. В последнем случае отправитель получит уведомление о невозможности доставить письмо. По умолчанию большинство почтовых серверов пытаются доставить письмо в течение 5 суток.
Все временно не отправленные письма накапливаются в очереди сообщений, и почтовый сервер регулярно обрабатывает очередь, вновь и вновь пытаясь отправить письма согласно вышеописанному алгоритму.
Чтобы запись о компьютере появилась в домене in-addr.arpa, поддомен этого домена должен быть делегирован тому провайдеру или той организации, которая владеет соответствующим диапазоном IP-адресов, – например, компания Russian Example, владеющая, среди прочих сетей, сетью класса С 192.177.16/24, может "оформить на себя", т.е. просить делегировать ей, домен 16.177.192.in-addr.arpa. После этого системный администратор компании создаст файл с описанием соответствия адресов компьютеров в example.ru их доменным именам в этом домене.
Как используют данные
На любом компьютере, где запущен сервер имен named, обязательно должен присутствовать файл, описывающий обратную зону самого компьютера (т.е. соответствие имени localhost адресу 127.0.0.1). Этот файл часто носит имя localhost.rev или 127.0.0. Естественно, этот файл описания локальной
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-сети не обеспечивает автоматического делегирования соответствующей
Имя
Рассмотрим в качестве примера файл
; $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 remember 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
В некоторых случаях требуется устанавливать соответствие между IP-адресом и именем компьютера в ситуации, когда имя компьютера заранее не известно. Именно так бывает, когда надо создать описание $GENERATE (доступен в bind версии 8 и выше). Вот пример файла
@ IN SOA ns.provider.ru. hostmaster.provider.ru. ( 2006042002 ; Serial 21600 ; Refresh 3 hours 7200 ; Retry 1 hour 3600000 ; Expire 1000 hours 86400 ) ; Minimum 24 hours IN NS ns.provider.ru. ; address -> full name with end point ; 82 IN PTR pluto.provider.ru. 84 IN PTR orion.provider.ru. $GENERATE 130-254 $ PTR pool-10-$.provider.ru.
Макрос в последней строке данного примера эквивалентен множеству строк, начинающемуся строкой
130 IN PTR pool-10-130.provider.ru.
и заканчивающемуся строкой
254 IN PTR pool-10-254.provider.ru.
Чтобы получить информацию о чужом домене или проверить настройки собственного сервера имен, можно использовать несколько утилит, опрашивающих серверы DNS.
Во-первых, это программа nslookup. Проверим наши настройки:
nslookup Default Server: localhost Address: 127.0.0.1 > set type=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 type=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).
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.