Отображение доменных имен на IP-адреса. (Лекция 5-6) презентация

на IP-адреса, поэтому для доступа к сетевому ресурсу в параметрах программы вполне достаточно указать IP-адрес, чтобы программа правильно поняла, к какому хосту ей нужно обратиться.
Например, команда ftp://192.168.180.1 будет устанавливать сеанс связи с нужным ftp-сервером, а команда http://192.168.180.1 откроет начальную страницу на Web-сервере ФАВТ.
Однако пользователи обычно предпочитают работать с символьными именами компьютеров, и операционные системы локальных сетей приучили их к этому удобному способу. Следовательно, в сетях TCP/IP должны существовать символьные имена хостов и механизм для установления соответствия между символьными именами и IP-адресами.

таких как Novell NetWare, Microsoft Windows или IBM OS/2, пользователи всегда работали с символьными именами компьютеров.
Так как локальные сети состояли из небольшого числа компьютеров, то использовались так называемые плоские имена, состоящие из последовательности символов, не разделенных на части. Примерами таких имен являются: G442-1, MOPEVM, SRV.
Для установления соответствия между символьными именами и MAC-адресами в этих операционных системах применялся механизм широковещательных запросов, подобный механизму запросов протокола ARP.
Так, широковещательный способ разрешения имен реализован в протоколе NetBIOS, на котором были построены многие локальные ОС. Несмотря на то что Windows 2003+ пропагандирует и во всю ивановскую внедряет поддержку DNS, полностью отказаться от использования NetBIOS пока не удается

территориально распределенных сетях, подобный подход оказывается неэффективным по нескольким причинам:
1. Уникальность имен в пределах большой сети.
В небольших сетях уникальность имен компьютеров обеспечивает администратор сети, записывая несколько десятков имен в журнале или файле.
При росте сети задачу решают уже несколько администраторов, согласовывая имена между собой неформальным способом.
Однако если сеть расположена в разных городах или странах, то администраторам каждой части сети нужно придумать способ именования, который позволил бы им давать имена новым компьютерам независимо от других администраторов, обеспечивая в то же время уникальность имен для всей сети.
Самый надежный способ решения этой задачи — отказ от плоских имен в принципе.

хорошо работает только в небольшой локальной сети, не разделенной на подсети. В крупных сетях, где общая широковещательность не поддерживается, нужен другой способ разрешения символьных имен.
Обычно хорошей альтернативой широковещательности является применение централизованной службы, поддерживающей соответствие между различными типами адресов всех компьютеров сети:
Компания Microsoft для своей корпоративной операционной системы Windows NT разработала централизованную службу WINS, которая поддерживает базу данных NetBIOS-имен и соответствующих им IP-адресов.
Или файлы hosts, причем на каждом компьютере

Для эффективной организации именования компьютеров в больших сетях естественным является применение иерархических составных имен (так же как и иерархического способа адресации между прочим).

одном текстовом файле, который велся централизованно и рассылался на все машины сети ARPANET. Никакой иерархии в именах машин не было, и процедура присваивания имени компьютеру предполагала проверку уникальности желательного имени в масштабах страны. Объем изменений был огромен и поглощал большую часть пропускной способности ARPANET. Поэтому в содержимом этого файла часто не отображалось реальное состояние сети.
Вскоре стало ясно, что статическая таблица машин, которой хватало для небольшой сети, явно неадекватна потребностям большой и растущей сети ARPANET. Система доменных имен решает проблемы, с которыми не справилась такая таблица, используя две концепции: иерархию имен машин и распределение ответственности.
Систему доменных имен формально описал Пол Мокапетрис (Paul Mocka petris) в RFC882 и 883 (1983 г. ) В 1987 г. ее откорректировали (RFC1034 и 1035) а в 1990 г. расширили (RFC 1101 и 1183). Пол кроме того написал первую не UNIX версию.
Работа по переносу DNS в UNIX была начата в 1984 г. четырьмя старшекурсниками университета в Беркли Дугласом Терри (Douglas Terry), Марком Пеинтером (Mark Painter), Дэвидом Ригглом (David Riggle) и Сонг Ньян Чжоу (Songman Zhou). Эстафету подхватил Ральф Кэмпбелл (Ralph Campbell) из Computer Systems Research Group, который начал "склеивать" доменную систему имен в BSD UNIX. В 1985 г. Кевин Данлэп (Kevin Dunlap), инженер DEC временно работавший в Беркли, принял этот проект в свои руки и создал систему BIND (Berkeley Internet Name Domain — систему доменных Internet-имен реализации Беркли). Майк Кареле (Mike Karels) и Пот Викси (Paul Vixie) сопровождали эту систему в течение ряда лет. Пол продолжает вести ее и сейчас, пользуясь помощью участников телеконференции isc.org и членов списка рассылки bind-workers.
Система BIND входит в состав большинства поставляемых UNIX систем. Кроме того, ее можно получить с машины ftp.uu.net. Доменная система имен реализована и для других, не UNIX-овских операционных систем, но здесь будет рассмотрена только BIND, т.к. на ее примере функционирование DNS можно описать углубившись во многие тонкости, в других реализациях просто скрытые.

реализованную в виде распределенной базы данных;
библиотечные подпрограммы запросов этой базы данных (это тоже часть BIND!)
усовершенствованные средства маршрутизации электронной почты;
протокол обмена информацией об именах.

по мере приближения к корню дерева. Каждый домен — это отдельный ломоть пространства имен, которым управляет один административный объект. Корень дерева имеет имя, под ним находятся домены верхнего (или корневого) уровня. Домены верхнего уровня относительно постоянны.

В США домены верхнего уровня отражают организационно-политическую структуру и, как правило, имеют трехбуквенные имена Для доменов вне США используются двухбуквенные коды стран ISO.

символьная часть имени, вторая по старшинству символьная часть имени и т. д.

Младшая часть имени соответствует конечному узлу сети.

В отличие от имен файлов, при записи которых сначала указывается самая старшая составляющая, затем составляющая более низкого уровня и т. д., запись доменного имени начинается с самой младшей составляющей, а заканчивается самой старшей. Составные части доменного имени отделяется друг от друга точкой. Например, в имени pop3.favt.tsure.ru составляющая pop3 является именем одного из компьютеров в домене favt.tsure.ru.

разделить административную ответственность за назначение уникальных имен между различными людьми или организациями в пределах своего уровня иерархии. Так, для примера, приведенного выше, один человек может нести ответственность за то, чтобы все имена, которые имеют окончание «ru», имели уникальную следующую вниз по иерархии часть.
Если этот человек справляется со своими обязанностями, то все имена типа www.ru, tsure.ru или yandex.ru будут отличаться второй по старшинству частью.
Разделение административной ответственности позволяет решить проблему образования уникальных имен без взаимных консультаций между организациями, отвечающими за имена одного уровня иерархии. Очевидно, что должна существовать одна организация, отвечающая за назначение имен верхнего уровня иерархии.
Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен (domain).
Например, имена
favt.tsure.ru
smtp.favt.tsure.ru
pop3.favt.tsure.ru
ftp.favt.tsure.ru
входят в домен favt.tsure.ru, так как все эти имена имеют одну общую старшую часть — имя favt.tsure.ru.

Термин "домен" очень многозначен, поэтому его нужно трактовать в рамках определенного контекста.
Кроме доменов имен стека TCP/IP в компьютерной литературе также часто упоминаются домены Windows NT, домены коллизий и некоторые другие.
Общим у всех этих терминов является то, что они описывают некоторое множество компьютеров, обладающее каким-либо определенным свойством.

другой домен как его составная часть, то такой домен могут называть поддоменом (subdomain), хотя название домен за ним также остается. Обычно поддомен называют по имени той его старшей составляющей, которая отличает его от других поддоменов. Например, поддомен favt.tsure.ru обычно называют поддоменом (или доменом) favt. Имя поддомену назначает администратор вышестоящего домена. Хорошей аналогией домена является каталог файловой системы.
Если в каждом домене и поддомене обеспечивается уникальность имен следующего уровня иерархии, то и вся система имен будет состоять из уникальных имен.
По аналогии с файловой системой, в доменной системе имен различают краткие имена, относительные имена и полные доменные имена.
Краткое имя — это имя конечного узла сети: хоста или порта маршрутизатора. Краткое имя — это лист дерева имен.
Относительное имя — это составное имя, начинающееся с некоторого уровня иерархии, но не самого верхнего. Например, www.favt — это относительное имя.
Полное доменное имя (fully qualified domain name, FQDN) включает составляющие всех уровней иерархии, начиная от краткого имени и кончая корневой точкой: www.favt.tsure.ru.

соответствии со своими составными именами, при этом они могут иметь совершенно различные IP-адреса, принадлежащие к различным сетям и подсетям. Например, в домен favt.tsure.ru могут входить хосты с адресами 80.250.181.67 и 192.168.180.1
Доменная система имен реализована в сети Internet, но она может работать и как автономная система имен в крупной корпоративной сети, использующей стек TCP/IP, но не связанной с Internet.
В Internet корневой домен управляется центром InterNIC. Домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Имена этих доменов должны следовать международному стандарту ISO 3166. Для обозначения стран используются трехбуквенные и двухбуквенные аббревиатуры, а для различных типов организаций — следующие обозначения:
com — коммерческие организации (например, microsoft. com);
edu — образовательные (например, mit.edu);
gov — правительственные организации (например, nsf.gov);
org — некоммерческие организации (например, fidonet.org);
net — организации, поддерживающие сети (например, nsf.net).
Каждый домен администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Чтобы получить доменное имя, необходимо зарегистрироваться в какой-либо организации, которой InterNIC делегировал свои полномочия по распределению имен доменов. В России такой организацией является РосНИИРОС, которая отвечает за делегирование имен поддоменов в домене ru.

запросы машин, используя DNS;
командные интерфейсы пользователь<->DNS: nslookup, dig, host.

Согласно терминологии, принятой в DNS, демон типа named (или машина, на которой он работает) называется сервером имен, а программа-клиент, которая обращается к нему — определителем.

IP-адресах.
Если named не знает ответа на какой-либо запрос, он опрашивает другие серверы и помещает их ответы в кэш. Этот демон, кроме того, отвечает за выполнение зонных пересылок, обеспечивающих копирование данных между серверами одного домена.

режимов:
Основном
Вспомогательном
Кэширующем
Режимы отличаются друг от друга двумя характеристиками:
откуда поступают данные
авторитетен ли сервер для данного домена

Зона — это домен за вычетом своих поддоменов.
Серверы имен работают именно с зонами, но часто говорится "домен", хотя подразумевается "зона"

Основной сервер имен хранит на диске оригинал данных домена.
Вспомогательный сервер копирует данные своего домена с основного сервера посредством операции зонной пересылки. В домене может быть несколько вспомогательных серверов имен; обязательный минимум — один.
Кэширующий сервер имен загружает адреса нескольких важных машин (серверов корневого домена) из файла запуска и получает все остальные данные, кэшируя ответы на разрешаемые им запросы.
Большинство основных и вспомогательных серверов также имеют свои собственные кэши.

устаревшим. Тем не менее, очень высокая доля неавторитетных ответов совершенно оправданна.
Основные и вспомогательные серверы авторитетны для своих доменов, но не для кэшированной информации о других доменах. Кэширующие серверы имен никогда не бывают авторитетными.

Авторитетные ответы могут быть противоречивыми, если системный администратор изменил данные основного сервера имен и забыл сообщить об этом вспомогательным серверам (или если на вспомогательные серверы изменения еще не распространены

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

сократить объем DNS-трафика в сети.
Хорошо, если одна машина одновременно является и основным сервером для своих доменов, и вспомогательным сервером для других доменов.

именами машин и их адресами в файле /etc/hosts выполняли библиотечные подпрограммы gethostbyname и gethostbyaddr
Для того чтобы такую информацию выдавала DNS, эти подпрограммы необходимо изменить. Новые версии, как правило, интегрируются в С-библиотеку системы (libc.а) или же помещаются в свою собственную библиотеку, libresolv.a.
Если операционная система не поддерживает разделяемые библиотеки, то, при изменении библиотечной подпрограммы, прикладные программы необходимо перекомпоновать.
Если это gethostbyname и ее производные, то страдают только те программы, которые относятся к сетевому программному обеспечению.
Если система BIND инсталлируется с нуля, то в указаниях по инсталляции должен быть список программ, которые необходимо перестроить

системы, либо одновременно и клиентом, и сервером.
Для преобразования имен машин в IP–адреса программы вызывают подпрограмму gethostbyname.
Если конфигурация машины предполагает использование DNS, gethostbyname с помощью определителя DNS запрашивает адрес у сервера имен.
Серверы имен бывают рекурсивными и нерекурсивными.

Если у него есть адрес, кэшированный из предыдущего запроса или если он авторитетен для домена, к которому относится имя, то он даст соответствующий ответ. В противном случае вместо правильного ответа он выдает отсылку к авторитетным серверам другого домена, которые должны знать ответ.
Клиент нерекурсивного сервера должен быть готов принимать отсылки и обрабатывать их.
Рекурсивный сервер возвращает только реальные ответы и сообщения об ошибках Он сам отслеживает отсылки, освобождая от этой обязанности клиента. Базовая процедура разрешения запроса, по сути дела та же, единственное отличие состоит в том, что этот сервер имен заботится об обработке отсылок, не передавая их обратно клиенту.
Есть один побочный эффект принуждения сервера имен к отслеживанию отсылок: в его кэш поступает информация о промежуточных доменах.

часто бывает так, что это как раз то, что нужно, поскольку последующие операции поиска, инициируемые любой машиной этой сети, пользуются результатами предыдущих усилий сервера.
С другой стороны, серверу домена высокого уровня (такого, как com или ru) не рекомендуется хранить информацию, запрашиваемую машиной, которая находится на несколько уровней ниже. Его кэш быстро распухнет и, из–за дополнительных затрат времени на обработку рекурсивных запросов, пропускная способность упадет.

По этим причинам серверы имен нижних уровней обычно являются рекурсивными, а серверы высших уровней (верхнего и частично второго) — нерекурсивными.
Библиотеки определителей, поставляемые с большинством версии UNIX, не понимают отсылок; они рассчитывают, что локальный сервер имен будет рекурсивным.

Рекурсия может привести к заполнению кэша второстепенной информацией. Корневые серверы и безопасные основные серверы не должны этого делать

сервер, например, не сможет дать адрес машины www.favt.tsure.ru, он последовательно обратится к серверам домена favt.tsure.ru, tsure.ru, ru и корневого домена.
Отсылка должна включать адреса серверов домена, на который она указывает, поэтому выбор — не произвольный, сервер должен ссылаться на тот домен, серверы которого ему уже известны. Как правило, выдается наиболее полный из известных доменов. В нашем примере был бы выдан домен favt.tsure.ru (если это возможно).
Кэши серверов имен обычно предварительно загружаются серверами корневого домена ("."), поэтому всегда можно сделать некую ссыпку, даже если это будут просто слова "спроси у корневого сервера"

машины vvxnb.favt.tsure.ru. Предполагается, что перед запросом никакие из требуемых данных не кэшировались, за исключением серверов домена edu

свои локальный сервер имен ‑ ns.favt.tsure.ru.

Локальный сервер имен ответа на запрос не знает. Более того, он не знает ничего ни о narod.yandex.ru, ни о yandex.ru. Он знает некоторые серверы домена ru и, будучи рекурсивным, спрашивает ru о машине cis-01.narod.yandex.ru

Локальный сервер посылает запрос о машине cis-01 серверу домена yandex.ru.

Сервер yandex.ru не знает ответа, но, будучи рекурсивным, направляет этот запрос серверу домена narod.yandex.ru

Доменом ru управляют нерекурсивные серверы имен, поэтому вместо сообщения запрошенного адреса локальному серверу говорят: “Пойди-ка спроси у домена yandex.ru; вот адреса серверов”

данные о серверах домена yandex.ru
сервер домена yandex.ru кэшировал адрес машины cis-01

Запросы демона named используют протокол UDP и порт 53. Если объем ответов превышает 512 байтов, то для их доставки используется протокол TCP.
В зонных пересылках между серверами также применяется протокол TCP

список серверов имен, которым нужно посылать запрос.

search favt.tsure.ru tsure.ru
nameserver 80.250.181.67
nameserver 213.24.19.1
nameserver 80.68.0.9

Если машина сама является сервером имен, она должна быть указана первой. На каждой из указанных машин должен работать рекурсивный сервер имен, рассматриваемый определитель не отслеживает отсылки.

Первый контакт устанавливается с сервером имен, который указан в файле /etc/resolv.conf первым. Если этот сервер на запрос не отвечает, выделенное для ответа время (таим аут) истекает и запрашивается следующий сервер имен, указанный в списке. Все серверы запрашиваются по очереди до четырех раз каждый. С каждой неудачей интервал тайм-аута увеличивается.

В небольшой организации файл /etc/resolv.conf необходимо конфигурировать так, чтобы он указывал на
1.основной сервер имен организации или, если такого сервера нет
2. на сервер Internet-провайдера.

(или файлов) данных, содержащего адресные соответствия для каждой зоны (для основных серверов)

работает непрерывно. Например:
[root@studlin]# /etc/init.d/named start
Возможны варианты [start|restart|stop|reload|…]
Запускаясь, named записывает свой PID в файл /etc/named.pid
Можно послать демону named сигнал, для чего используется такая команда:
kill -СИГНАЛ `cat /var/run/named/named.pid`

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

address * port 53;
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "master/localhost.rev";
};
zone "example.net" {
type master;
file "master/example.net";
};

DNS для каждого домена представляет собой набор текстовых файлов, которые системный администратор ведет на основном сервере имен этого домена.
Элементы базы данных называются записями о ресурсах; иногда их сокращенно обозначают RR.
Типы и форматы записей о ресурсах регламентируются документами RFC882, 1035 и 1183.

ресурсах:
[имя] [время] [класс] тип данные
Поля разделяются знаками табуляции или пробелами и могут содержать специальные символы:
; Вводит комментарии
@ Имя текущего домена
() Позволяют данным занимать несколько строк
* Метасимвол (только в поле имя)

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

время (в секундах), в течение которого элемент данных может оставаться в кэше и считаться при этом достоверным. Это поле часто опускают, но оно обязательно присутствует в файле запуска кэша, который содержит имена и адреса корневых серверов.

тип сети. Распознаются три значения:
IN (Internet)
СН (ChaosNet) ChaosNet — устаревшая сеть, в которой раньше работали Lisp-машины фирмы Symbolics
HS (Hesiod) Hesiod — это служба базы данных, являющаяся надстройкой системы BIND
Значением класса по умолчанию является IN.

домены и их серверы имен;
Базовые записи: преобразовывают имена в адреса и наоборот, обеспечивают маршрутизацию почты;
Факультативные записи: содержат дополнительную информацию о машинах.

Содержимое поля данные зависит от типа записи.

о ресурсах, расположенных в одной области пространства имен DNS.
Домен DNS обычно соответствует минимум двум зонам; одна служит для преобразования имен машин в IP-адреса, а остальные — для обратного преобразования.
Для каждой зоны делается всего одна запись SOA; зона продолжается до тех пор, пока не появляется следующая запись SOA.
Запись SOA содержит имя зоны, адреса, необходимые для установления технических контактов, различные значения тайм-аутов.
Эта запись должна быть первой записью зоны.

for favt.tsure.ru
@ IN SOA ns.favt.tsure.ru. admin.favt.tsure.ru. (
1001 ; Serial
21600 ; Refresh, 6 hours
1800 ; Retry, 30 minutes
1209600 ; Expire, 2 weeks
432000 ) ; Minimum, 5 days
Поле имя содержит символ @, обозначающий имя текущей зоны. В этом примере можно было вместо него использовать favt.tsure.ru.
Поле время отсутствует. Класс - in (Internet), тип —  SOA, а остальные элементы составляют поле данные.
Сервер ns.favt.tsure.ru  — основной сервер имен этой зоны.
Запись admin.favt.tsure.ru. указывает адрес электронной почты для технических контактов в формате пользователь.машина, (а не пользователь@машина). Если необходимо отправить почту администратору домена, просто заменяется первая точка знаком @ и убирается последняя точка. Вместо реального регистрационного имени часто используется псевдоним, например, admin или hostmaster.

for favt.tsure.ru
@ IN SOA ns.favt.tsure.ru. admin.favt.tsure.ru. (
1001 ; Serial
21600 ; Refresh, 6 hours
1800 ; Retry, 30 minutes
1209600 ; Expire, 2 weeks
432000 ) ; Minimum, 5 days
Первый числовой параметр — порядковый номер блока информации о конфигурации зоны. Это может быть любое целое число, которое должно увеличиваться при каждом изменении файла данных зоны. Последовательные номера не обязательно должны быть непрерывными, но должны монотонно возрастать.
Следующие четыре элемента — значения тайм-аутов (в секундах), которые управляют временем, в течение которого данные можно будет кэшировать в различных точках всемирной базы данных DNS

for favt.tsure.ru
@ IN SOA ns.favt.tsure.ru. admin.favt.tsure.ru. (
1001 ; Serial
21600 ; Refresh, 6 hours
1800 ; Retry, 30 minutes
1209600 ; Expire, 2 weeks
432000 ) ; Minimum, 5 days
Первый элемент — тайм-аут регенерации, refresh. Он показывает, как часто вспомогательные серверы должны сверяться с основным сервером и смотреть, не изменился ли порядковый номер конфигурации зоны. Если зона изменилась, вспомогательные серверы должны создать новый экземпляр данных зоны. Общепринятые значения для данного тайм-аута — от одного до шести часов (3600 — 21600 секунд)

for favt.tsure.ru
@ IN SOA ns.favt.tsure.ru. admin.favt.tsure.ru. (
1001 ; Serial
21600 ; Refresh, 6 hours
1800 ; Retry, 30 minutes
1209600 ; Expire, 2 weeks
432000 ) ; Minimum, 5 days
Если вспомогательный сервер пытается проверить порядковый номер основного, а тот не отвечает, вспомогательный сервер сделает повторную попытку по истечении периода времени, заданного тайм-аутом retry.
Нормальное значение для данного параметра — от 20 до 60 минут (1200 ‑ 3600 секунд)

for favt.tsure.ru
@ IN SOA ns.favt.tsure.ru. admin.favt.tsure.ru. (
1001 ; Serial
21600 ; Refresh, 6 hours
1800 ; Retry, 30 minutes
1209600 ; Expire, 2 weeks
432000 ) ; Minimum, 5 days
Если основной сервер длительное время отключен, то вспомогательные серверы будут многократно пытаться регенерировать свои данные, однако эти попытки всегда будут кончаться неудачей. В конце концов все вспомогательные серверы решат, что основной сервер не включится никогда и что его данные, наверняка, устарели.
Параметр expire определяет, как долго вспомогательные серверы будут продолжать обслуживать данные этого домена в отсутствие основного сервера. Система должна выжить, даже если основной сервер не работает неделю, поэтому параметру expire следует присваивать большое значение. Обычно от недели до месяца

for favt.tsure.ru
@ IN SOA ns.favt.tsure.ru. admin.favt.tsure.ru. (
1001 ; Serial
21600 ; Refresh, 6 hours
1800 ; Retry, 30 minutes
1209600 ; Expire, 2 weeks
432000 ) ; Minimum, 5 days
Параметр minimum задает время жизни записей о ресурсах, которое будет приниматься по умолчанию. Он кэшируется вместе с записями и используется для отмены их действия на неавторитетных серверах. Каждая запись может в поле время содержать явно заданное значение; если такое значение не установлено, то используется значение из записи SOA

данной зоны. Обычно эти записи следуют за записью SOA. Запись NS имеет следующий формат:
зона [время] [класс] NS имя_машины
Например:
favt.tsure.ru. IN NS ns.favt.tsure.ru.
favt.tsure.ru. IN NS ns.tsure.ru.
favt.tsure.ru. IN NS 80.68.0.9.
Поскольку имя зоны здесь совпадает с указанным в поле имя записи SOA, которая идет перед записями NS, поле зона можно оставить пустым. Поэтому строки:
IN NS ns.favt.tsure.ru.
IN NS ns.tsure.ru.
IN NS 80.68.0.9.

перевод имен машин в IP–адреса, ранее заданные в файле /etc/hosts. Для каждого из сетевых интерфейсов машины должна быть сделана одна запись А. Эта запись имеет следующий формат:
имя_машины [время] [класс} А ip-адрес
Например:
vvxnb IN A 192.168.180.12

имена машин. Как и в случае с записями А, для каждого сетевого интерфейса машины должна быть сделана одна запись PTR.

называется IN-ADDR.ARPA.
Полностью определенные имена машин можно рассматривать как структуру, в которой "старший бит" стоит справа. Например, в имени
vvxnb.favt.tsure.ru
vvxnb находится в favt, favt находится в tsure, a tsure — в ru.
С другой стороны, в IP-адресах "старший бит" стоит слева:
192.168.180.12
Машина 12 находится в подсети 180, которая является частью сети 192.168.

того, чтобы и для преобразования IP-адресов в имена машин, и для преобразования имен в IP-адреса использовался один и тот же набор программных модулей.
Домены под этим доменом именуются как IP-адреса с байтами, расставленными в обратном порядке.
Например, зона для нашей подсети 243 составлена следующим образом
180.168.192.IN-ADDR.ARPA.

PTR имя_машины
Запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины vvxnb, будет иметь такой вид:
12.180.168.192 IN PTR vvxnb.favt.tsure.ru.
Имя 12.180.168.192 не заканчивается точкой и поэтому является относительным.
Вопрос: относительным относительно чего?

запись можно представить так:
100 IN PTR vvxnb.favt.tsure.ru.
Поскольку favt.tsure.ru и 180.168.192.IN-ADDR.ARPA  разные области пространства имен DNS, они составляют две отдельные зоны.
У каждой из этих зон должна быть своя запись SOA и свои записи о ресурсах. Помимо определения зоны IN-ADDR.ARPA для каждой реальной сети, нужно определить зону, которая заботилась бы о петлевой сети, 127.0.0.

более эффективной маршрутизации почты. Запись MX приоритетно прерывает обслуживание адресата сообщения, в большинстве случаев направляя сообщение в концентратор почты на узле получателя, а не прямо на его рабочую станцию.
Запись MX имеет следующий формат:
имя [время] [класс] MX приоритет машина …
Ниже приведен примера для машины, которая получает адресованную ей почту, несмотря на свое нерабочее состояние.
vvxnb IN MX 10 smtp
IN MX 20 mailhub
IN MX 50 smtp.favt.tsure.ru.

для машины-концентратора, чтобы можно было посылать почту по схеме пользователь@домен.
Это все равно требует наличия уникальных пользовательских имен на машинах данного домена.
Например, чтобы иметь возможность посылать почту пользователю vvx@favt.tsure.ru, нужна либо машина favt, либо запись MX в домене tsure.ru
FAVT IN MX 10 malihub.favt.tsure.ru
IN MX 20 mail.tsure.ru

Мнемонические имена широко применяются для связывания с машиной какой-либо функции, либо просто для сокращения имени.
Реальное имя иногда называют каноническим (отсюда сокращенное название записи CNAME). Например:
WWW IN CNAME favt.tsure.ru.
FTP IN CNAME favt.tsure.ru.
Запись CNAME имеет следующий формат
мнемоимя [время] [класс] CNAME имя_машины
Если у машины есть запись CNAME, которая содержит ее мнемонические имена, другие записи для данной машины должны ссылаться на ее реальное имя, а не на мнемоническое.
Когда программы DNS встречают запись CNAME, они останавливают свои запросы по мнемоническому имени и переключаются на реальное имя.

bind-9.2.1-16asp.i386.rpm
Устанавливаем
rpm –install bind-9.2.1-16asp.i386.rpm
Конфигурируем
Тестируем (dig)

[root@studlin]# man dig

hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
zone "myzone.ru" {
type master;
file "myzone.ru";
};

[root@studlin]# man named.conf

3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241

; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; operated by VeriSign, Inc.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

Expire
3600 ) ; Minimum
IN NS @host@.
1 IN PTR localhost.@domain@.

Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS 127.0.0.1
test IN A 192.168.27.100