"Невидимых" серверах (stealth, см. RFC-1996)

. Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т.к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.

Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.

Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall. В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с "невидимого" Primary master:

Рис.4. Схема организации DNS-серверов с невидимым primary master сервером

Другая причина создания "невидимых" серверов - разгрузка официально зарегистрированных серверов. В этом случае для обслуживания определенного класса клиентов, которые можно настроить на работу с "невидимым" сервером, создается один или несколько slave-серверов зоны. Они являются авторитативными, но неизвестными широкой интернет-общественности.

Рассмотрим еще один тип серверов, которые выделяют при описании системы доменных имен -

Официальный (Authoritative) сервер зоны

В руководстве по BIND данная конфигурация обозначена как "Authoritative-only server". Смысл ее заключается в том, что демонстрируется настройка сервера, который обслуживает запросы от любого хоста Сети, но только к той зоне, за которую он официально отвечает. В терминологии BIND 4.х такой сервер именовался как "primary" для зоны, а в терминологии BIND 8.х- 9.х он именуется как "master". Его файл настройки будет выглядеть следующем образом:

options { directory "/etc/namedb"; // Working directory pid-file "named.pid"; // Put pid file in working allow-query { any; }; // This is default recursion no; // Do not provide recursion service };

zone "." { type hint; file "root.hint"; }; zone "0.0.127.in-addr.arpa" { type master; file "0.0.127.in-addr.arpa"; notify no; };

zone "example.com" { type master; file "example.com"; allow-transfer { 192.168.4.14; 192.168.5.53; }; };

Сначала обратим внимание на отличие в описании опций директивы "options". Во-первых, с запросами к данному серверу позволено обращаться любому хосту Сети, что логично, т.к. никто другой кроме официального сервера в полном объеме за данную зону не отвечает (опция "allow-query"). Есть, конечно, вспомогательные сервера, но они только дублируют master сервер. Вносить изменения в описание зоны можно только на primary master сервере. Именно поэтому при выходе из строя primary master сервера время обслуживания запросов вспомогательными серверами ограничено. Предполагается, что при отказе primary master данные вспомогательных серверов не будут соответствовать исходному описанию зоны, а потому обслуживание запросов лучше прекратить.

Во-вторых, данный сервер не обслуживает запросы рекурсивно. Он только отвечает на запросы к своей зоне (опция "recursion"). Последнее означает, что в отличии от кэширующего сервера, который принимает запросы от клиентов (resolver-ов), опрашивает серверы доменных имен и потом отвечает клиентам, наш сервер запросы клиентов, которые не касаются зоны его ответственности обслуживать не будет.

Описание корневых (root) серверов и обратной зоны для 127.0.0.1 такое же, как и для кэширующего сервера.

При описании зоны ответственности (директива "zone "example.com") в качестве первого параметра указано имя зоны ("example.com") в фигурных скобках определены опции: тип сервера - master, т.е. официальный сервер зоны; файл описания зоны - file "example.com"; список вспомогательных серверов - "allow-transfer { 192.168.4.14; 192.168.5.53 };".

Собственно, опция "allow-transfer" задает список серверов, которым разрешено копировать зону. Официальными вспомогательными серверами они станут только в том случае, если они таковыми были определены в заявке (для доменов второго уровня - корпоративных доменов, например), либо приписаны таковыми при делегировании зоны более глубокого уровня.

Если не установить ограничения на копирование зоны, или указать "any", то любой сервер может скопировать зону, и не только сервер. Из соображений безопасности настоятельно рекомендуется прописывать адреса серверов, которым можно копировать зону.

Описание "прямой" и "обратных" зон

Сначала разберемся с файлами описания зон, которые будет поддерживать наш сервер. Они идентичны за небольшим исключением (параметры записи SOA и $TTL) для различных версий BIND.

Прямая зона, ради которой, собственно, и затевался весь сыр-бор, будет выглядеть следующим образом:

$TTL 3600 @ IN SOA vega-gw.vega.ru. hostmaster.vega.ru. ( 101 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum ) ; Name server IN NS vega-gw.vega.ru. IN NS ns.relarn.ru. IN A 194.226.43.1 IN MX 0 vega-gw.vega.ru. IN MX 10 ns.relarn.ru. ; vega-gw IN A 194.226.43.1 IN MX 0 vega-gw IN MX 10 ns.relarn.ru. www IN CNAME vega-gw ftp IN CNAME vega-gw gopher IN CNAME vega-gw ; dos1 IN A 194.226.43.2 dos2 IN A 194.226.43.3 ; The rest of the net should be presented below.

Символ "@" ссылается на имя зоны (vega.ru) из файла конфигурации named. Директива управления $TTL в BIND 4.x не применяется, и ее лучше для этой версии сервера не использовать. Время жизни записей описания ресурсов в кэше сервера будет определяться в BIND 4.x не директивой управления $TTL, а параметром minimum в записи SOA. В BIND 8.х и 9.х этот параметр используется для определения времени кэширования негативных ответов других серверов, поэтому для времени кэширования записей описания ресурсов по умолчанию нужно задавать директиву управления $TTL.

Из записи SOA следует, что master сервером домена является хост vega-gw.vega.ru, а администратор сервера имеет адрес hostmaster.vega.ru. Кроме того, среди серверов доменных имен, авторитативных для зоны vega.ru (записи NS), указан сервер ns.relarn.ru. Однако, адресной записи для этого доменного имени в описании зоны нет, т.к. его можно найти в зоне relarn.ru.

В BIND 4.x имело смысл прописывать адресную запись ns.relarn.ru, т.к. сервер вернул бы ее в дополнительной секции отклика. BIND 8.х и 9.х игнорируют такого сорта записи, поэтому мы в нашем примере ее не указываем. Собственно, мы поступаем в соответствие с рекомендациями RFC 1912.

Наш домен небольшой. Предполагается, что в нем совсем мало машин.
Администрация сети не может себе позволить разносить сервисы по разным хостам. По этой причине почтовые ящики для vega.ru будут располагаться на сервере доменных имен. Точнее этот хост будет знать, как почту доставлять, т.к. он является почтовым шлюзом с наибольшим приоритетом для домена vega.ru. Об этом говорят записи MX, которые следуют сразу за адресной записью в начале описания зоны.
Сама адресная запись в начале описания зоны призвана назначить для имени зоны IP-адрес, чтобы такие сервисы, как World Wide Web, например, приводили на корпоративную страничку не только по www.vega.ru, но и по vega.ru.
Далее следует адресная запись, которая определяет IP-адрес для master сервера зоны. За ней определены почтовые шлюзы, которые знают, как на этот сервер доставлять почту, и синонимы сервисов (ftp,www,gopher), которые размещены на этом же хосте. Вслед за сервисами размещаются записи адресов для всех остальных хостов зоны.
Здесь следует заметить, что довольно часто вместо CNAME для описания сервисов используют адресные записи. В принципе, это позволяет найти адрес для имени сразу, но, если будет проверяться обратное соответствие, а в "обратной" зоне будет описано каноническое имя, то имена не совпадут, и сервис может отказать клиенту, который запрашивает сервис, в обслуживании.
Еще одно важное замечание касается начала описания зоны. В нашем описании у SOA записи в качестве имени зоны стоит символ "@". Он позволяет сослаться на имя зоны из файла конфигурации named.
Имя зоны в SOA всегда должно содержать какое-либо имя. Иначе все остальные записи окажутся просто бесполезными. Описание зоны можно было начать и по другому:
$TTL 3600 $ORIGIN ru. vega IN SOA vega-gw.vega.ru. hostmaster.vega.ru. ( 101 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum )
Это описание также будет указывать на зону vega.ru. Слово "vega" будет расширяться до "vera.ru" по умолчанию.
Существует еще одно имя, которое стоит обсудить в контексте описания прямой зоны.

Это имя localhost. В нашем случае - это localhost.vega.ru.
Рассмотрим сначала такой пример:
> host localhost.ru. localhost.ru has address 195.68.136.26 localhost.ru mail is handled (pri=100) by mx2.elcomsoft.com localhost.ru mail is handled (pri=200) by mx1.elcomsoft.com >
Из примера следует, что в зоне ru есть хост с адресом localhost.ru. На самом деле это побочное явление того, что существует зона localhost:
> host -t soa localhost.ru. localhost.ru start of authority ns1.localhost.ru noc.elcomsoft.com( 2001040300 ;serial (version) 14400 ;refresh period 3600 ;retry refresh this often 604800 ;expiration period 3600 ;minimum TTL ) >
Если теперь посмотреть адрес localhost.nic.ru, например, то мы получим локальную петлю:
> host localhost.nic.ru. localhost.nic.ru has address 127.0.0.1 >
Такая настройка "прямой" зоны является типовой, а точнее являлась типовой:
> host localhost.demos.ru. localhost.demos.ru has address 127.0.0.1 > host localhost.relcom.ru. localhost.relcom.ru has address 127.0.0.1 > host localhost.msk.ru. localhost.msk.ru has address 127.0.0.1 > host localhost.spb.ru. localhost.spb.ru has address 127.0.0.1 > host localhost.rambler.ru. localhost.rambler.ru has address 127.0.0.1 > host localhost.yandex.ru. localhost.yandex.ru has address 127.0.0.1 >
Современные провайдеры уже поступают иначе:
> host localhost.mail.ru. Host not found. > host localhost.localhost.ru. Host not found. > host localhost.lenta.ru. Host not found. > host localhost.runet.ru. Host not found. >
Приведенный пример показывает, что в соответствующих зонах хоста с именем localhost просто нет. При этом сами зоны прекрасно функционируют. Если бы запросить зоны vega.ru на предмет наличия в ней соответствия IP-адреса доменному имени localhost.vega.ru, то отклик программы host был бы таким же, как и в последнем примере.
На самом деле, это отголоски дискуссии по поводу имени localhost, которая велась в конце 90-х.

В конце концов, в 1996 году вышел документ RFC 1912, в котором этот вопрос был прояснен. Более того, в RFC 2606 для localhost был зарезервирован специальный домен верхнего уровня localhost.
И все-таки, для чего и каким образом используется имя localhost при обращении к системе доменных имен? Ответ на этот вопрос является определяющим при конфигурации локального сервера доменных имен для работы с этим именем.
Имя localhost указывает на "петлю" - адрес 127.0.0.1, который закреплен за хостом исполняющим программу. По какой либо причине эта программа обращается к хосту с именем localhost. Система доменных имен должна вернуть в качестве отклика адрес 127.0.0.1.
Обратиться к системе DNS можно, используя два типа имен: полностью определенные имена (FQDN) и частично определенные имена. В первом случае имя кончается символом ".", т.к. у корневого домена имени нет. Во втором случае имя точкой не кончается.
Если программа обращается к приложению на той же машине, где она сама исполняется, то в качестве имени машины может быть указано FQDN, т.е. "localhost.", или "localhost", т.е. неполное имя.
На данном этапе в дело вступает библиотека resolver. Все будет теперь определяться тем алгоритмом, который реализует эта библиотека при построении FQDN.
С полностью определенным именем все понятно. Локальный сервер начнет искать домен верхнего уровня localhost. Согласно RFC 2606 такой домен должен существовать, и состоит из одной записи, которая имени "localhost." ставит в соответствие адрес 127.0.0.1.
А вот с неполным именем такой ясности нет. Если файл resolv.conf на хосте, где исполняется прикладная программа, составлен стандартным образом, т.е. там только указан сервер доменных имен и имя домена, в который входит хост, то сначала имя localhost будет расширено именем локального домена из resolv.conf, а уж только после этого определено, как имя "localhost." (см. материал "Resolver. Типовые настройки.").

Если на хосте в resolv. conf вместо директивы domain применяется директива search, то процедура поиска может увеличиться на несколько дополнительных подстановок.
Совершенно очевидно, что хочется получить адрес 127.0.0.1 как можно быстрее, и это возможно, если имя типа localhost.domain.ru будет тоже указывать на 127.0.0.1. Быстрее будет потому, что соответствие будет найдено сразу в локальном домене, и обращение к корневым серверам не потребуется. Конечно, это возможно организовать только в том случае, когда имя типа localhost.domain.ru не используется по каком-либо другому назначению.
Таким образом, для ускорения поиска в прямую зону принято вводить запись вида:
$TTL 3600 @ IN SOA vega-gw.vega.ru hostmaster.vega.ru ( 101 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum ) ; Name server IN NS vega-gw.vega.ru. IN NS ns.relarn.ru. IN A 194.226.43.1 IN MX 0 vega-gw.vega.ru. IN MX 10 ns.relarn.ru. ; localhost IN A 127.0.0.1 ; vega-gw IN A 194.226.43.1
Мы представили пример с окружением, чтобы было понятно, куда обычно вставляют эту адресную запись в прямой зоне.
Вообще говоря, это нерекомендованная практика. RFC 1912 Рекомендует создать отдельно зону localhost:
$TTL 1D localhost. IN SOA vega-gw.vega.ru. hostmaster.vega.ru. ( 101 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum ) localhost. IN NS vega-gw.vega.ru. localhost. IN A 127.0.0.1
Соответственно, эта зона должна быть прописана и в файле настройки named.
Идея с наличием этой зоны достаточно прозрачна. Сервер при обращении за адресом хоста "localhost." не будет обращаться к корневым серверам, т.к. сам знает этот адрес.
Однако, если зона localhost не будет прописана на локальном сервере, который выполняет рекурсивные запросы прикладных программ, корневой сервер должен вернуть правильный адрес, т.к. в DNS, согласно RFC 2606, эта зона должна поддерживаться, как домен верхнего уровня localhost.
Если же допустить, что по какой-либо причине корневые серверы недоступны, а зона localhost не прописана, то тогда программа все равно получит правильный адрес, т.к.

в этом случае система перейдет от поиска адреса в DNS к поиску адреса в файле hosts, а там по умолчанию 127.0.0.1 закреплен за именем localhost.
Теперь обратим внимание на зону 0.0.127.in-addr.arpa. она является обратной для зоны localhost. Эта зона всегда прописывается на серверах доменных имен:
$TTL 1D 0.0.127.in-addr.arpa. IN SOA vega-gw.vega.ru paul.vega.ru ( 101 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum ) IN NS vega-gw.vega.ru. ; Localhost declaration 1 IN PTR localhost.
Назначение этой зоны заключается в ответах на запросы поиска доменного имени для IP-адреса 127.0.0.1. Согласно RFC 1912 имя это должно быть "localhost.". Довольно часто на "старых" доменах можно встретить указание на имя типа localhost.domain.ru.
В RFC 1912 определены еще две обратных зоны, которые рекомендуется иметь на сервере доменных имен, но которые обычно не настраивают. О них даже нет упоминания в широко распространенных по сети рекомендациях по настройке серверов доменных имен. Это зоны 255.in-addr.arpa и 0.in-addr.arpa.
Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.
Содержание файлов описания этих зон одинаковое: только SOA и NS записи:
$TTL 1D 255.in-addr.arpa. IN SOA vega-gw.vega.ru paul.vega.ru ( 101 ;serial number 86400 ;refresh 3600 ;retry 3888000 ;expire 3600 ;minimum ) IN NS vega-gw.vega.ru.
Для 0.in-addr.arpa в поле имени зоны нужно "255" заменить на "0".
На самом деле, эффективность с точки зрения времени поиска адресов и имен в зонах "петли" может быть очень высокой, если установить большое время в управляющей директиве $TTL. В этом случае адрес попадает в кэш и может жить там "вечно".
На самом деле все зоны кроме зоны vega.ru должны быть настроены на любом сервере доменных имен, в том числе и на сервере, выполняющем только функции кэширующего сервера. Обычно же на кэширующем сервере ограничиваются только описанием зоны 0.0.127.in-addr.arpa (см.

матерал " Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности."), что оправдано, т.к. зона localhost должна быть прописана на корневых серверах. Кроме того, существует еще файл hosts.
Мы написали "должна быть прописана" не зря. На самом деле на момент написания этого текста она там прописана не была:
> /usr/local/bin/dig localhost.
; > DiG 9.2.1 > localhost. ;; global options: printcmd ;; Got answer: ;; ->>HEADER
И это, не смотря на то, что документ RFC 2606, в котором декларируется организация такой зоны, вышел в 1999 году. Таким образом, зону localhost прописывать все же надо.
На самом деле мы не описали еще одну зону, которую необходимо иметь для запуска named - зону описания корневых серверов. Она описывается обычно в файле named.root, который совпадает в точности с аналогичным файлом, описанном в материале "Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности.".
Теперь перейдем к рассмотрению файлов конфигурации named. Будем рассматривать настройку named по версиям программного обеспечения. Сначала рассмотрим BIND 4.x, а потом BIND 8.x и BIND 9.x.

Описание зоны. Формат записи описания ресурсов (RR).

В данном материале речь пойдет о формате master файла (файла описания зоны) сервера доменных имен, о записях описания ресурсов и их основных типах.

Основная информация, ради которой, собственно, и затевалась система доменных имен, - это соответствия между IP-адресами и именами. Эта информация содержится в файлах описания зон (master files) ответственности серверов, или просто - описаниях зон.

Еще раз обратим внимание на то, что зона и домен - это не одно и тоже. Домен - это все поддерево дерева доменных имен. Зона - это тот же домен, но за вычетом делегированных другим серверам частей домена, которые в свою очередь будут называться делегированными зонами. Подробнее смотри в материале "Как работает система доменных имен".

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

Формат записей описания зон определен "по простому" в RFC-1033 и более академично в RFC-1035. К слову сказать, именно поэтому файлы описания зон во всех версиях BIND одинаковые, и если вы решили сменить BIND 4 на BIND 9, то придется переписать только файл конфигурации named, но не файлы описания зон.

Согласно RFC-1035 (секция 5 "Master Files") в файле описания зоны можно использовать следующие директивы:

[<comment>] $ORIGIN [<comment>] $INCLUDE [] [<comment>] [<comment>] [<comment>]

Соответственно, это: комментарий, определение имени текущего домена, вставка внешнего файла и два формата записи описания ресурсов.

Каждая директива занимает ровно одну строку, но если применить круглые скобки "( )", то текст директивы может быть распространен на несколько строк.
Любая непустая комбинация пробелов и символов табуляции рассматривается как разделитель между элементами директивы.
В приведенной выше нотации в квадратные скобки ([ ]) заключены необязательные параметры, а в угольные скобки (< >) - сущности. Например, <comment> определяет комментарий. В свою очередь, комментарий - это символ ";" с последующим за ним текстом до конца строки. В следующем фрагменте файла описания зоны:
$ORIGIN kyky.ru. ; ; Zone kyky.ru ; ns IN A 192.168.0.1 ; name server www IN A 192.168.0.2 ; web server
Строки со второй по четвертую включительно будут строками комментария. Пятая и шестая строки заканчиваются комментариями.
Все директивы можно разделить на два типа: директивы управления (control entries) и записи описания ресурсов (resource records - RR). Существует две директивы управления ($ORIGIN и $INCLUDE) и множество RR, большая часть из которых по различным причинам не используется в реальной жизни. Даже тот список записей, что перечислен в RFC-1033, является несколько избыточным.
Вообще-то, директив управления в современных пакетах BIND 8-ой и 9-ой версий больше. К стандартным $ORIGIN и $INCLUDE следует добавить $TTL и $GENERATE.

Origin

- это доменное имя primary master сервера зоны. В случае описания зоны kyky.ru в качестве сервера используется машина ns.kyky.ru. Данное доменное имя и должно быть указано в поле origin.

Очень часто в этом поле можно встретить имена, которые начинаются с "ns", например, ns.kiae.su или ns.relarn.ru. В данном случае это означает только то, что primary master сервер зоны размещен на машине с таким именем. Никого специального зарезервированного имени для указания в поле origin нет. Использование, указанных выше имен обосновано тем, что их просто легче запомнить, т.к. "ns" означает "name server".

Довольно часто администраторы зон, которые делегируют части своих зон другим организациям, в ультимативной форме требуют, чтобы имя primary master не совпадало с именем зоны.

Elz и Bush в RFC-2181 отмечали, что это требование повсеместно нарушается и практически является бесполезным. Кроме того, существует документ (ripe-203), в котором написано, что данное требование (отличие имени primary master сервера от имени зоны в SOA) справедливо, за исключением случая, когда доменное имя зоны связано адресной записью с IP-адресом primary master этой зоны. Для небольших зон это случается сплошь и рядом, т.к. и primary master зоны и почтовый транспортный агент и прочие сервисы в мелких организациях устанавливаются на одной и той же машине.

Требование, однако, справедливо при заполнении интерактивных форм регистрации домена, т.к. система в момент регистрации не имеет ни малейшего понятия о том, что администратор зоны напишет в файле описания зоны, т.е. гарантии того, что имя зоны и имя primary master сервера совпадают, в момент регистрации домена нет.

Поле

Вообще говоря, основное назначение $ORIGIN - это упрощение содержания файла описания зоны при определении поддоменов в той же зоне, где описан и выше стоящий домен:

$ORIGIN kyky.ru. ns IN A 192.168.0.1 www IN A 192.168.0.2 $ORIGIN sub1.kyky.ru. host1 IN A 192.168.0.3 host2 IN A 192.168.0.4 $ORIGIN sub2.kyky.ru. host1 IN A 192.168.0.5 host2 IN A 192.168.0.6

В приведенном выше примере мы завели два поддомена в домене kyky.ru, при чем именование машин в них одинаковое, но полные доменные имена различаются, что и не удивительно.

Еще несколько лет назад довольно часто можно было видеть в файлах описания зон следующую картину:

@ IN SOA ns.kyky.ru. adm.kuku.ru. ( 1 2h 30m 2d 30m ) IN NS ns.kyky.ru. IN NS ns.provider.ru. ns IN A 192.168.0.2 $ORIGIN provider.ru. ns IN A 192.168.10.5

Что тут не так? Формально все верно. Для зоны kyky.ru должно быть определено два сервера доменных имен с независимым подключением к сети, т.к. речь идет о корпоративном домене.

Первый сервер определен в сети компании и имеет имя ns.kyky.ru, а второй сервер - это сервер провайдера, который обеспечивает дублирование, т.е. ns.kyky.ru - это master, а ns.provider.ru - это slave.

Вся штука в том, что имя ns.provider.ru не принадлежит домену kyky.ru. На самом деле наш сервер не является авторитативным для зоны provider.ru, поэтому он не вправе отвечать на запросы к этой зоне.

Тем не менее, существует процедура делегирования зон ответственности, и там возникает ситуация, когда IP-адрес сервера доменных имен нельзя получить иначе, как из зоны, в которой описано делегирование.

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

Так вот, присоединять адресную запись для ns.provider.ru нет смысла, т.к. ее можно найти в другой зоне. Более того, там она может оказаться более свежей, чем у нас, и указывающей совсем на другой адрес.Присоединяют только те записи, информацию о которых иначе получить просто нельзя, например, адреса серверов доменных имен, чьи имена находятся в делегируемой нами зоне.

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

О "приклеенных" записях подробно поговорим позже при описании адресных и NS записей.

Директива

Полезные ссылки:

http://www.dns.net/dnsrd/docs/ - коллекция ссылок на документы о системе доменных имен. http://www.internic.net/faqs/authoritative-dns.html - коротенькое описание назначения системы доменных имен. http://www.icann.org/ - сайт организации, которая в ответе за именование в Интернет. http://www.ispras.ru/~grn/dns/index.html - Г.В. Ключников. Служба доменных имен (Domain Name System). 1999. На самом деле, это отличная компиляция приведенных в конце книжки первоисточников. Примеры взяты из этих же первоисточников. Очень качественный перевод и грамотно скомпонованный текст. http://www.ibb.ru/articles/stat_3.phtml - из серии "DNS за пять минут" J, но в качестве введения в тему данный материал может пригодиться. http://www.pi2.ru:8100/prof/techsupp/dns.htm - своеобразное описание системы доменных имен. Во всяком случае, самобытное. Но некоторые аспекты освещены довольно необычно.

http://www.microsoft.com/windows2000/en/server/help/sag_DNS_und_HowDnsWorks.htm?id=1945 - Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы системы доменных имен. Описывает общие принципы построения DNS и взаимодействия resolver и серверов. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_ovr_ClientFeatures.htm?id=1942 - Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы resolver. http://www.nominum.com/resources/documentation/Bv9ARM.pdf - Документация по BIND 9. Справочное руководство системного администратора. Нужно ознакомиться с разделом, посвященном lightweight resolver. http://www.igc.ru/cgi-bin/man-cgi?traceroute - описание команды traceroute, раз уж ее здесь упомянули. http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm - глоссарий терминов DNS.

R. Droms. Dynamic Host Configuration Protocol. ISI, 1997. (ftp://ftp.isi.edu/in-notes/rfc2131.txt) http://www.wia.org/pub/rootserv.html - схема расположения root servers системы доменных имен. http://m.root-servers.org/ - статистика и краткое описание root серверов m.root-servers.org http://k.root-servers.org/ - статистика и краткое описание root серверов k.root-servers.org http://www.isc.org/iepg/notes-mar99.html - протокол встречи IEPG Оклахоме в марте 1999 года. Довольно любопытная статистика обращений к корневой зоне.

http://www.isc.org/products/BIND/bind9.html - страничка BIND 9.2.1 http://www.linuxsecurity.com/feature_stories/conrad_vixie-1.html - интервью авторов BIND сетевому изданию linuxsecurity.com. Наиболее интересна та часть ответов, которые дает Paul Vixie, автор BIND до версии 8 и руководитель работ над версией 9. http://www.osp.ru/os/1998/06/34.htm - описание принципов контрактного проектирования. Всегда полезно прочитать о том, как правильно делать свою работу :)

http://www.ludd.luth.se/~kavli/BIND-FAQ.html - FAQ первоначально написанные Craig Richmond и в настоящее время поддерживаемые Ronny H. Kavli. Предназеачены главным образом для BIND версии 4. http://www.die.net/doc/linux/man/man5/named.conf.5.html - страницы документации по named.conf для любителей Linux. http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=named.cont - то же самое, что и пункт 2, но только для любителей FreeBSD.

http://www.menandmice.com/6000/61_recent_survey.html - результаты исследования Men&Mice по проблемам делегирования зон. Август 2002 года. http://www.dns.net/dnsrd/trick.html#which-server-queried - FAQ. Описание алгоритма выбора сервера среди авторитативных серверов зоны на основе RTT. http://www.caida.org/projects/dns-analysis/#logfile - анализ нагрузки корневых серверов и исследование эффективности алгоритма выбора сервера. http://www2.auckland.ac.nz/net/Internet/rtfm/meetings/47-adelaide/pp-dist/ - материал 2000 года, в котором подмечено совпадение RTT DNS и ping.

P. Mockapetris. RFC-883. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc883.txt?number=883) - документ интересен с точки зрения исторического развития домена IN-ADDR.ARPA как домена "обратного" соответствия. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. RFC 2870. Root Name Server Operational Requirements. 2000. (http://www.ietf.org/rfc/rfc2870.txt?number=2870) D. Crocker. RFC 2142. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. 1997. (http://www.ietf.org/rfc/rfc2142.txt?number=2142) D. Barr. RFC 1912. Common DNS Operational and Configuration Errors. 1996. (http://www.ietf.org/rfc/rfc1912.txt?number=1912) Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region (http://www.ripe.net/ripe/docs/ripe-224.html) - очень коротенькое описание политики делегирования обратных зон в зоне ответственности RIPE NCC. Reverse Delegation. IPv4 Request Procedure (reverse /24, /16) (http://www.ripe.net/ripencc/mem-services/registration/reverse/howtoreverse.html) - документ в стиле "делай раз, делай два, …". Все просто и доступно, но нужно иметь некоторое представление об устройстве сервисов RIPE NCC. http://www.ripe.net/.c/ripencc/mem-services/training/material/c.refbooknew.pdf.txt - материалы учебного курса для LIR, которые зарегистрированы в RIPE. Интересен раздел 9 - "Reverse Delegation". Достаточно сжато и подробно описывается процедура делегирования "обратных" зон из зоны ответственности RIPE NCC. G.Huston. RFC-3172. Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). 2001. (http://www.ietf.org/rfc/rfc3172.txt?number=3172) - статус домена ARPA, начиная с конца апреля 2000 года. Документ фиксирует состояние домена ARPA, ответственность ICAAN и IAB за управление этим доменом, его статус, а также правила делегирования поддоменов. http://www.ripe.net/ripencc/pub-services/stats/revdns/assign/19990426.html - статистика соответствия регистрации пулов адресов и "обратных" зон на 1999 год в RIPE NCC.

Inter-Network Mail Guide (http://www.faqs.org/faqs/mail/inter-network-guide/) - руководство по пересылке почты между различными почтовыми системами. Craig Partridge. RFC 974. MAIL ROUTING AND THE DOMAIN SYSTEM. 1986. (http://www.ietf.org/rfc/rfc974.txt?number=974) - стандарт интернет, который использовался до RFC 2821. http://www.menandmice.com/infobase/mennmys/vefsidur.nsf/index/5.1 - статистика проблем электронной почты, связанных с неточностью настройки DNS

http://www.ispras.ru/~grn/dns/index.html - Г.В. Ключников. Служба доменных имен (Domain Name System). 1999. На самом деле, это отличная компиляция приведенных в конце книжки первоисточников. Примеры взяты из этих же первоисточников. Очень качественный перевод и грамотно скомпонованный текст. http://public.pacbell.net/dedicated/cidr.html - Classless Inter-Domain Routing (CIDR) Overview. Этот обзор позволяет получить представление о CIDR - концепции, которая пришла на смену маршрутизации на основе классов IP-сетей.

http://www.fima.net/bind-8.html - это очень коротко про настройку BIND 8.x.x. На самом деле, прежде, чем это читать, нужно попрактиковаться с named. Но, в принципе С.Минаков снабдил всех желающих исчерповующей справочной информацией.

http://www.isc.org/products/BIND/bind8.html - страничка BIND 8. http://www.isc.org/products/BIND/bind4.html - страничка BIND 4.9.11 http://www.acmebw.com/resources/papers/securing.pdf - Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации. bind9-users-bounce@isc.org - список рассылки и форум пользователей BIND9. Очень забавное чтение. Особенно полемика разработчиков BIND и профессора Бернштейна.

http://www.isc.org/products/BIND/bind8.html - страничка BIND 8. http://www.isc.org/products/BIND/bind4.html - страничка BIND 4.9.11 http://www.acmebw.com/resources/papers/securing.pdf - Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации. http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-dnsop-dontpublish-unreachable-03.txt - хотя на документы этого типа и не принято ссылаться, т.к. они имеют силу только в течение полугода, но в этом файле содержится вразумительное описание мотивации создания зоны localhost и адресных записей в зоне корпоративного домена типа localhost.domain.ru

http://ciisa.isa.utl.pt/cgi-bin/man2html?dig+1 - справочное руководство по dig в стиле Unix manual. Следует иметь в виду, что версия с которой вы работаете можно довольно сильно отличаться от этого описания. По этой причине лучше использовать тот manual, который поставляется с дистрибутивом named и dig. http://tom.imm.uran.ru/cgi-bin/man?nslookup(8) - страница man по nslookup. http://ciisa.isa.utl.pt/cgi-bin/man2html?host+1 - страница man host для операционной системы Linux. Это не полный список ключей, но кое что есть Salamon, Andr‡s. "Tools to manage DNS." 1999. URL: http://www.dns.net/dnsrd/tools.html

Peter Koch. Ripe-203. Recommendations for DNS SOA Values. 1999. (http://www.ripe.net/docs/ripe-203.html) http://tom.imm.uran.ru/cgi-bin/man?nslookup(8) - страница man по nslookup.

Peter Koch. Ripe-203. Recommendations for DNS SOA Values. 1999. (http://www.ripe.net/docs/ripe-203.html) http://ciisa.isa.utl.pt/cgi-bin/man2html?host+1 - страница man host для операционной системы Linux. Это не полный список ключей, но кое что есть.

http://cr.yp.to/djbdns.html -странички djbdns, написанные профессором Бернштейном. Это первоисточник. http://djbdns.org/ - странички группы любителей djbdns. Довольно много информации по патеку, но гораздо больше его особенностей можно получить подписавшись на конференцию BIND. J http://www.canb.auug.org.au/~millerp/dnsutl/dnsutl.html - сайт dnsutl - пакета генерации описания зон. Лучше все же писать зоны самому, а прибегать к автоматизации только в совершенно прозрачных случаях. http://www.visi.com/~barr/dnswalk/ - страница dnswalk. Последня версия программы датируется 2000 годом. Новее найти не удалось. http://www.ripe.net/ripe/mail-archives/dns-wg/1994/msg00013.html - это прототип RFC 1731. Здесь перечислены средства отладки описания зон и основные проблемы, которые могут быть решены при помощи этих средств.

http://www.isc.org/products/BIND/bind9.html - страничка BIND 9.2.1 http://www.ludd.luth.se/~kavli/BIND-FAQ.html - DNS FAQ. Ответы на большинство вопросов, начинающих и "продвинутых" администраторов. Есть только одно большое НО! Этот материал посвящен BIND версии 4. Но все, что касается описания зоны вполне подходит и для более поздних версий BIND. Peter Koch. INTERNET-DRAFT. RIPE DNS WG Guide To Setting Up a DNS Server. 2001. (http://www.techfak.uni-bielefeld.de/~pk/dns/draft-koch-ripe-dns-setup-guide-01.txt.gz)- это рекомендации по установке параметров записи SOA и описание применения других записей RR. R. Elz, R. Bush. RFC 1982. Serial Number Arithmetic. 1996.(http://www.ietf.org/rfc/rfc1982.txt?number=1982)- этот документ для особо дотошных читателей. В нем подробно описана концепция непрерывного арифметического пространства серийного номера и приведены примеры изменения номера и сравнения номеров.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q177883& - это материал службы технической поддержки Microsoft, в котором поясняются детали настройки Round Robin. http://www.ietf.org/rfc/rfc1794.txt?number=1794 - T. Brisco. RFC 1794. DNS Support for Load Balancing. Предложения по использованию DNS для баланса нагрузки. В реальной жизни не используется, но почитать интересно.

http://www.rscott.org/dns/cname.html - о способах верификации ошибок в описании зоны, относящихся к записям CNAME. http://www.adminschoice.com/docs/dns_trouble_shooting.htm - пример правильного и неправильного употребления NS и CNAME. http://support.microsoft.com/default.aspx?scid=KB;EN-US;q159310& - проблемы совмести dns.exe и BIND при обработке откликов NS и CNAME. http://cr.yp.to/im/canme.html - обсуждается проблема работы с DNS программ sendmail и qmail. Основное внимание уделено работе с некорректными CNAME - записями. http://www.acmebw.com/askmrdns/ - FAQ по системе доменных имен. На этот архив ссылаются и разработчики BIND. Вопросам некорректного использования CNAME посвящено около десятка страниц. http://www.menandmice.com/6000/61_recent_survey.html - статистика ошибок при конфигурации серверов системы доменных имен.

Primary Master

. Этот сервер для зоны только один, и он находится в корне процедуры копирования описания зоны.

Типизация серверов относительно процедуры обмена описаниями зон связана с возможностями, которые не описаны в RFC-1034 и RFC-1035, и, соответственно, не поддерживались в ранних версиях программ-серверов доменных имен. Это механизм объявлений об изменениях в описании зоны (RFC-1996), динамическое обновление описания зоны (RFC-2136) и инкрементальное обновление описания зоны (RFC-1995).

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

Сначала о том, что такое уведомления об

"Прямая" и "обратная" зоны для

В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено "обратным" зонам, т.к. "прямая" зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.

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

Предположим, что адресные пулы, которые выделены организации и ее подразделениям, представляют из себя не единое адресное пространство, а нарезку из нескольких блоков адресов. При этом эти блоки нарезаны таким образом, что адреса оказываются из разных областей, если рассматривать адресное пространство с точки зрения нотации CIDR х.х.х.х/24. Например:

192.168.0.0/24 и 192.168.10.0/24

С точки зрения описания соответствия между доменным именем и IP-адресом в "прямой" зоне здесь проблем нет:

$ORIGIN ru. test IN SOA ns.test.ru. hostmaster.test.ru ( 233 3600 300 9999999 3600 ) ; IN NS ns.test.ru. IN NS ns.privider.ru. IN A 192.168.10.1 IN MX 10 mail.test.ru. IN MX 20 mail.provider.ru. ; ns IN A 192.168.10.1 mail IN A 192.168.0.1 www IN A 192.168.10.2 ftp IN A 192.168.0.2

Из примера видно, что адресные записи могут прекрасно "перемешиваться" в описании зоны. Таким образом, прямую зону можно определить на любом множестве наборов адресов, которые могут быть, как угодно разбросаны по адресному пространству.

Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).

Если запросить из Интернет IP-адрес по доменному имени и в ответ получить адрес из немаршрутизируемого пула, то не понятно, что с ним делать. Даже если вы сами находитесь внутри немаршрутизируемой сети полученный снаружи адрес из этой же сети, скорее всего, не является искомым адресом.

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

И так, в "прямой" зоне мы можем "мешать" адреса, но вот как поддерживать обратные соответствия? Ведь в случае "обратных" зон мы имеем дело тоже с доменными именами, хотя они и образованы инверсией IP-адресов. Разделителем в иерархии именования доменов является символ ".", следовательно, границы байтов в адресе будут соответствовать границам вложенности доменов.

Выход простой - создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:

$TTL 3600 $ORIGIN 168.192.in-addr.arpa. 10 IN SOA ns.test.ru. hostmaster.test.ru. ( 75 3600 300 9999999 3600 ) IN NS ns.test.ru. IN NS ns.privider.ru. 1 IN PTR ns.test.ru. 2 IN PTR www.test.ru.

И для 0.168.192.in-addr.arpa. соответственно:

$TTL 3600 $ORIGIN 168.192.in-addr.arpa. 0 IN SOA ns.test.ru. hostmaster.test.ru. ( 75 3600 300 9999999 3600 ) IN NS ns.test.ru. IN NS ns.privider.ru. 1 IN PTR ns.test.ru. 2 IN PTR www.test.ru.

На master сервере должно быть объявлено две "обратных" зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:

directory /etc/namedb

primary test.ru test.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa primary 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa xfrnets 192.168.20.1&255.255.255.255 cache . named.root options no-recursion no-fetch-glue fake-iquery

Собственно, важным с точки зрения контекста данного материала являтся наличие среди директив управления двух директив primary для соответствующих обратных зон.

Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 - это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в "Небольшой корпоративный домен в домене ru.

Описание "прямых" зон. Описание "обратных" зон. Настройки BIND.".

Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:

options { directory "/etc/namedb"; allow-query {any;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; }; //Root server hints zone "." { type hint; file "named.root"; }; // Forward Loopback zone "localhost" { type master; file "localhost"; }; // Reverse Loopback zone "0.0.127.in-addr.arpa" { type master; file "localhosr.rev"; }; // Corporative domain zone "test.ru" { type master; file "test.ru"; allow-transfer { 192.168.20.1; }; }; // Reverse corporative domain zone "0.168.192.in-addr.arpa" { type master; file "0.168.192.in-addr.arpa"; allow-transfer { 192.168.20.1; }; }; // Reverse corporative domain zone "10.168.192.in-addr.arpa" { type master; file "10.168.192.in-addr.arpa"; allow-transfer { 192.168.20.1; }; };

Это описание также содержит две директивы для обратных зон, на которые отображаются имена. Описание несколько более длинное, чем для BIND 4.х в силу иного формата файла конфигурации, но суть его та же.

Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.

Из выше сказанного, следует, что владелец зоны 168.192.in-addr.arpa должен делегировать ответственность за управления двумя обратными зонами своему клиенту, если не хочет управлять ими самостоятельно.

Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е.сетей классов B и A соответственно. Пространство доменных имен "обратных" зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.

В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на "суперсети" сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегировать соответствующие обратные зоны клиентам, а те обеспечить их поддержку способом, похожим на случай 192.168.0.0/23, рассмотренный выше.

Программа интерактивного тестирования серверов DNS - nslookup

В данном материале рассматриваются различные режимы работы программы nslookup - одного из основных средств тестирования работы сервера доменных имен.

Среди средств тестирования системы доменных имен nslookup подвергается наибольшей критике. Во всяком случае, авторы bind рекомендуют использовать dig вместо nslookup, как написано в руководстве по BIND 9 - "из-за загадочности пользовательского интерфейса и часто противоречивого поведения" последней. Тем не менее, nslookup - это одно из самых популярных средств тестирования DNS. Эта программа есть в большинстве версий Unix-систем.

Программа позволяет работать пользователю в двух режимах: интерактивном и режиме неинтерактивном режиме. В первом случае пользователь, попав в командную строку nslookup, имеет возможность исполнять команды nslookup, во втором случае отчеты получают, задавая аргументы командной строки интерпретатора (shell или любого другого командного интерпретатора) nslookup.

Сначала рассмотрим неинтерактивный режим работы. Как уже было сказано, он используется для получения информации из системы DNS непосредственно из командной строки интерпретатора. В аргументах командной строки nslookup можно указывать значения опций, имя или адрес хоста для которого производится поиск, и сервер доменных имен.

% nslookup www.ru Server: polyn.net.kiae.su Address: 144.206.160.32

Non-authoritative answer: Name: www.ru Address: 194.87.0.50

В данном случае мы просто используем сервер доменных имен из resolv.conf для поиска IP-адреса www.ru. Из отчета видим, что этот сервер не является авторитативным для искомого имени.

Для того, чтобы понять выполняет ли nslookup перебор доменных имен, который характерен для библиотеки resolver, зададим имя несуществующего хоста:

% nslookup gaga.ru Server: polyn.net.kiae.su Address: 144.206.160.32

Name: gaga.ru.net.kiae.su

За нашим именем появилась вставка net.kiae.su, которая взята из resolv.conf. Вот его (resolv.conf) содержание:

% more /etc/resolv.conf nameserver 144.206.160.32 nameserver 144.206.192.10 search net.kiae.su polyn.kiae.su . %

На самом деле можно получить более полный отчет, если включить режим отладки:

% nslookup -debug gaga.ru ;; res_mkquery(0, 32.160.206.144.in-addr.arpa, 1, 12) ------------ Got answer: HEADER: opcode = QUERY, id = 22021, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 1, authority records = 3, additional = 3

QUESTIONS: 32.160.206.144.in-addr.arpa, type = PTR, class = IN ANSWERS: -> 32.160.206.144.in-addr.arpa name = polyn.net.kiae.su ttl = 3600 (1 hour) AUTHORITY RECORDS: -> 160.206.144.in-addr.arpa nameserver = polyn.net.kiae.su ttl = 3600 (1 hour) -> 160.206.144.in-addr.arpa nameserver = ns.spb.su ttl = 3600 (1 hour) -> 160.206.144.in-addr.arpa nameserver = ns.ussr.eu.net ttl = 3600 (1 hour) ADDITIONAL RECORDS: -> polyn.net.kiae.su internet address = 144.206.160.32 ttl = 49698 (13 hours 48 mins 18 secs) -> ns.spb.su internet address = 193.124.83.69 ttl = 49556 (13 hours 45 mins 56 secs) -> ns.ussr.eu.net internet address = 193.125.152.3 ttl = 3083 (51 mins 23 secs)

------------ Server: polyn.net.kiae.su Address: 144.206.160.32

;; res_mkquery(0, gaga.ru, 1, 1) ------------ Got answer: HEADER: opcode = QUERY, id = 22022, rcode = NXDOMAIN header flags: response, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: gaga.ru, type = A, class = IN AUTHORITY RECORDS: -> ru ttl = 10530 (2 hours 55 mins 30 secs) origin = ns.ripn.net mail addr = hostmaster.ripn.net serial = 4005295 refresh = 7200 (2 hours) retry = 900 (15 mins) expire = 2592000 (30 days) minimum ttl = 345600 (4 days)

------------ ;; res_mkquery(0, gaga.ru.net.kiae.su, 1, 1) ------------ Got answer: HEADER: opcode = QUERY, id = 22023, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: gaga.ru.net.kiae.su, type = A, class = IN AUTHORITY RECORDS: -> kiae.su ttl = 10530 (2 hours 55 mins 30 secs) origin = ns.kiae.ru mail addr = noc-dns.relarn.ru serial = 650127450 refresh = 28800 (8 hours) retry = 3600 (1 hour) expire = 604800 (7 days) minimum ttl = 86400 (1 day)

------------ Name: gaga.ru.net.kiae.su

%

О чем говорит этот отчет. Сначала производится поиск по обратной зоне имени сервера доменных имен, который имеет IP-адрес 144.206.160.32. Затем производится поиск gaga.ru, а затем gaga.ru.net.kiae.su. По идее, следовало бы выполнить и другие подстановки, но nslookup этого не сделала. И вообще, в данном случае программа ведет себя несколько не так, как это предписано для системы resolver.

В данном случае аргумент -debug - это опция командной строки, которая позволяет управлять объемом и типом информации в отчетах nslookup при неинтерактивном режиме работы.

Вот еще один пример применения опционного аргумента:

% nslookup -type=SOA ru. Server: polyn.net.kiae.su Address: 144.206.160.32

Non-authoritative answer: ru origin = ns.ripn.net mail addr = hostmaster.ripn.net serial = 4005295 refresh = 7200 (2 hours) retry = 900 (15 mins) expire = 2592000 (30 days) minimum ttl = 345600 (4 days)

Authoritative answers can be found from: ru nameserver = NS2.NIC.FR ru nameserver = ns.ripn.net ru nameserver = NS2.ripn.net ru nameserver = SUNIC.SUNET.SE ru nameserver = NS.UU.net ru nameserver = NS1.RELCOM.ru NS2.NIC.FR internet address = 192.93.0.4 ns.ripn.net internet address = 194.85.119.1 NS2.ripn.net internet address = 194.226.96.30 SUNIC.SUNET.SE internet address = 192.36.125.2 NS.UU.net internet address = 137.39.1.3 NS1.RELCOM.ru internet address = 193.125.152.3 %

В данном случае мы просим доставить нам информацию о записи SOA зоны ru. Точка в конце имени зоны указана для определенности. Сервер выдает не авторитативный ответ и сообщает, где можно получить авторитативные ответы.

Опции всегда указываются перед именем или IP-адресом хоста, для которого ищется информация. На самом деле опции - это аргументы команды set интерактивного режима работы, о котором речь пойдет несколько позже.

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

Ниже приведен пример содержания этого файла:

% more .nslookuprc type=NS db2 %

Первая строка задает тип записей описания зоны, которые ищутся. В данном случае это записи NS. А вторая запись задает уровень подробности отчета (отладка - debug второго уровня).

До сих пор мы рассматривали работу nslookup с сервером доменных имен, который определен в resolv.conf. Имя сервера доменных имен, который будет выполнять рекурсивные запросы, можно задать в качестве последнего аргумента командной строки nslookup:

% nslookup -type=A www.ru. ns.relarn.ru. Server: ns.relarn.ru Address: 194.226.65.3

Non-authoritative answer: Name: www.ru Address: 194.87.0.50

%

В данном случае мы посылаем рекурсивный запрос не серверу умолчания из resolv.conf, а ns.relarn.ru, который присылает нам неавторитативный ответ.

Теперь разберем интерактивный режим работы nslookup. В него попадают двумя способами. Во-первых, просто введя nslookup в командной строке интерпретатора:

% nslookup Default Server: polyn.net.kiae.su Address: 144.206.160.32

>

В данном случае, в качестве сервера доменных имен программа использует сервер доменных имен умолчания, который указывается в файле настройки resolver (resolv.conf).

Во-вторых, в интерактивный режим можно попасть, задав nslookup c двумя аргументами: символом "-" и именем или IP-адресом сервера доменных имен, который будет использоваться для выполнения рекурсивных запросов:

% nslookup - 144.206.192.10 Default Server: IRIS.polyn.kiae.su Address: 144.206.192.10

>

Для того, чтобы покинуть интерактивный режим nslookup и вернуться в командную строку интерпретатора следует выполнить команду exit:

% nslookup Default Server: polyn.net.kiae.su Address: 144.206.160.32 > exit %

Вообще говоря, у nslookup довольно большое множество команд интерактивного режима, но мы их все рассматривать не будем. Для этого существуют руководства и система man. Рассмотрим только наиболее часто используемые случаи.

Самый простой из них - это поиск IP-адреса по доменному имени:

> quest.polyn.kiae.su. Server: polyn.net.kiae.su Address: 144.206.160.32

Name: quest.polyn.kiae.su Address: 144.206.192.2

>

Лучше всего задавать на конце доменного имени символ ".". По умолчанию nslookup включает перебор доменных имен, а работает он не совсем корректно, как мы уже убедились выше.

Теперь попробуем найти обратное соответствие:

> 144.206.192.11 Server: polyn.net.kiae.su Address: 144.206.160.32

Name: www.kiae.ru Address: 144.206.192.11

>

Как мы видим из полученного отчета, этому адресу соответствует имя www.kiae.ru. Увеличим подробность отчета:

> set debug > 144.206.192.11 Server: polyn.net.kiae.su Address: 144.206.160.32

;; res_mkquery(0, 11.192.206.144.in-addr.arpa, 1, 12) ------------ Got answer: HEADER: opcode = QUERY, id = 31436, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 2, authority records = 3, additional = 2

QUESTIONS: 11.192.206.144.in-addr.arpa, type = PTR, class = IN ANSWERS: -> 11.192.206.144.in-addr.arpa name = www.kiae.ru ttl = 3600 (1 hour) -> 11.192.206.144.in-addr.arpa name = kiae.polyn.kiae.su ttl = 3600 (1 hour) AUTHORITY RECORDS: -> 192.206.144.in-addr.arpa nameserver = polyn.net.kiae.su ttl = 3600 (1 hour) -> 192.206.144.in-addr.arpa nameserver = ns.spb.su ttl = 3600 (1 hour) -> 192.206.144.in-addr.arpa nameserver = ns.ussr.eu.net ttl = 3600 (1 hour) ADDITIONAL RECORDS: -> polyn.net.kiae.su internet address = 144.206.160.32 ttl = 46562 (12 hours 56 mins 2 secs) -> ns.spb.su internet address = 193.124.83.69 ttl = 46420 (12 hours 53 mins 40 secs)

------------ Name: www.kiae.ru Address: 144.206.192.11

>

Подробность отчета мы увеличиваем командой set debug. Из полученного отчета видно, что nslookup производит поиск в обратной зоне, предварительно преобразовав соответствующим образом введенную нами строку IP-адреса.

Обратим внимание еще на один момент. Если при поиске IP-адреса тип запроса был A, то, как видно из выше приведенного примера, в случае поиска доменного имени по IP-адресу мы посылаем запрос на указатель (PTR).

Среди ответов мы находим два имени, которые соответствуют IP-адресу: www.kiae.ru и kiae.polyn.kiae.ru. Это отражает тот факт, что в описании обратной зоны 192.206.144.in-addr.arpa у нас есть что-то похожее на:

11 IN PTR www.kiae.ru. IN PTR kiae.polyn.kiae.su.

Если теперь мы захотим получить параметры SOA записи для этой обратной зоны, то нам следует заказать именно эту запись описания зоны:

> set type=soa > 192.206.144.in-addr.arpa. Server: polyn.net.kiae.su Address: 144.206.160.32

192.206.144.in-addr.arpa origin = polyn.net.kiae.su mail addr = paul.kiae.su serial = 80 refresh = 3600 (1 hour) retry = 300 (5 mins) expire = 9999999 (115 days 17 hours 46 mins 39 secs) minimum ttl = 3600 (1 hour) 192.206.144.in-addr.arpa nameserver = polyn.net.kiae.su 192.206.144.in-addr.arpa nameserver = ns.spb.su 192.206.144.in-addr.arpa nameserver = ns.ussr.eu.net polyn.net.kiae.su internet address = 144.206.160.32 ns.spb.su internet address = 193.124.83.69 ns.ussr.eu.net internet address = 193.125.152.3 >

На самом деле мы получили не только параметры записи SOA, но и информацию о серверах доменных имен, которые эту зону поддерживают.

Приведенный выше отчет ни чем не отличается от того, который мы получили бы, если вместо обратной зоны использовали имя прямой зоны, например, polyn.kiae.su:

> set type=soa > polyn.kiae.su. Server: polyn.net.kiae.su Address: 144.206.160.32

polyn.kiae.su origin = polyn.net.kiae.su mail addr = paul.kiae.su serial = 80 refresh = 3600 (1 hour) retry = 300 (5 mins) expire = 9999999 (115 days 17 hours 46 mins 39 secs) minimum ttl = 3600 (1 hour) 192.206.144.in-addr.arpa nameserver = polyn.net.kiae.su 192.206.144.in-addr.arpa nameserver = ns.spb.su 192.206.144.in-addr.arpa nameserver = ns.ussr.eu.net polyn.net.kiae.su internet address = 144.206.160.32 ns.spb.su internet address = 193.124.83.69 ns.ussr.eu.net internet address = 193.125.152.3 >

Внимательный читатель обнаружит в приведенных выше примерах чудовищно большое время автономной работы для slave серверов для обеих зон (Устанавливается в SOA записи).

Лучше всего следовать рекомендациям RIPE-203.

Рассмотрим еще два параметра интерактивного режима: server и lserver. Они нужны для изменения сервера доменных имен, которому nslookup посылает рекурсивные запросы (текущий сервер):

origin 16% nslookup Default Server: IRIS.polyn.kiae.su Address: 144.206.192.10

>

В данном случае в nslookup работает в качестве клиента и посылает рекурсивные запросы на сервер IRIS.polyn.kiae.su (144.206.192.10). Мы можем изменить этот сервер при помощи команд server или lserver:

> server 144.206.160.32 Default Server: polyn.net.kiae.su Address: 144.206.160.32

>

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

> server 144.206.130.137 Default Server: [144.206.130.137] Address: 144.206.130.137

> 144.206.160.1 Server: [144.206.130.137] Address: 144.206.130.137

В этом месте мы "залипли", т.к. по адресу 144.206.130.137 до сервера доменных имен мы достучаться не можем (он там когда-то был, но сейчас его уже там нет). Нам нужно поменять текущий сервер, т.е. тот, которые мы используем для рекурсивных запросов:

> lserver 144.206.160.32 Default Server: polyn.net.kiae.su Address: 144.206.160.32

> 144.206.160.1 Server: polyn.net.kiae.su Address: 144.206.160.32

*** polyn.net.kiae.su can't find 144.206.160.1: Non-existent host/domain >

Перед тем, как выдать команду мы вернулись в режим командной строки (^c) и потом выдали команду на изменение текущего сервера доменных имен.

Следует признать, что отклик nslookup на наш запрос не очень информативен. На самом деле просто в обратной зоне нет записи, которая бы устанавливала соответствие между IP адресом 144.206.160.1 и доменным именем. Впрочем, и более "свежие" программы тестирования DNS не более информативны. Вот пример отчета команды host:

> host 144.206.160.32 32.160.206.144.IN-ADDR.ARPA domain name pointer polyn.net.kiae.su > host 144.206.160.1 Host not found. >

В случае присутствия PTR записи, она выдается, при ее отсутствии - "хост не найден".

Теперь рассмотрим еще один важный момент тестирования - передачу зоны. В этом случаи nslookup выступает как slave сервер, которые "срисовывает" зону с master сервера. Делается это при помощи команды интерактивного режима ls:

> ls bard.kiae.ru [IRIS.polyn.kiae.su] $ORIGIN bard.kiae.ru. @ 1H IN A 144.206.192.32 mail 1H IN A 144.206.192.32 www 1H IN A 144.206.192.32 >

На самом деле по команде ls в данном случае мы получили в отчете только адресные записи. Для того, чтобы получить все записи нужно указать либо флаг "-d", либо "-t any":

> ls -d bard.kiae.ru [IRIS.polyn.kiae.su] $ORIGIN bard.kiae.ru. @ 1H IN SOA ns.polyn.kiae.ru. paul.polyn.kiae.su. ( 7 ; serial 1H ; refresh 5M ; retry 16w3d17h46m39s ; expiry 1H ) ; minimum

1H IN NS polyn.kiae.ru. 1H IN NS iris.polyn.kiae.su. 1H IN MX 10 mail 1H IN MX 20 iris.polyn.kiae.ru. 1H IN A 144.206.192.32 mail 1H IN A 144.206.192.32 1H IN MX 10 mail www 1H IN A 144.206.192.32 @ 1H IN SOA ns.polyn.kiae.ru. paul.polyn.kiae.su. ( 7 ; serial 1H ; refresh 5M ; retry 16w3d17h46m39s ; expiry 1H ) ; minimum

>

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

Следует еще раз напомнить, что nslookup считается не самым лучшим средством тестирования работы системы DNS и настройки серверов. Тем не менее, эта программа есть на любой Unix-платформе, и по этой причине ее применяют достаточно часто.

Программа тестирования системы доменных имен - dig

В данном материале рассматривается применение различных опций программы dig - одного из основных средств тестирования работы системы доменных имен, поставляемого вместе с BIND сервером системы доменных имен.

Программа dig входит в комплект поставки BIND. Ее основное назначение - проверка правильности работы сервера доменных имен. При исполнении программы она сообщает свою версию, которая, как правило, совпадает с версией BIND.

Для того, чтобы просто получить IP-адрес по имени хоста достаточно выполнить:

> /usr/local/bin/dig quest.polyn.kiae.su.

; > DiG 9.2.1 > quest.polyn.kiae.su. ;; global options: printcmd ;; Got answer: ;; ->>HEADER

На самом деле, это довольно пространный ответ, если сравнивать его с отчетом host, например. Он больше похож на отладочные сообщения системы тестирования нового сервера доменных имен. Видимо, так оно и есть.

Еще одной особенностью dig является отключенный по умолчания список поиска (подстановка имен доменов по умолчанию):

/usr/local/bin/dig quest ; > DiG 9.2.1 > quest ;; global options: printcmd ;; Got answer: ;; ->>HEADER

Как видно из этого примера имя quest не расширяется именем домена. В конце имени хоста просто ставится символ ".", и запрос через локальный сервер доменных имен, который выполняет рекурсивные запросы, переправляется на корневой сервер A.

Оба предыдущих примера хорошо демонстрируют тот факт, что dig просто распечатывает секции DNS сообщения и его заголовок, т.е. формат отчета dig предполагает определенную "подкованность" пользователя в форматах и спецификациях системы доменных имен.

В отличие от других средств отладки DNS dig при получении доменного имени по IP-адресу требует указания соответствующей опции для поиска в обратных зонах, сам адрес по умолчанию не "выворачивает": >/p>

> /usr/local/bin/dig 144.206.192.1

; > DiG 9.2.1 > 144.206.192.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER

В данном случае адрес воспринят просто как доменное имя и вместо записи PTR dig ищет адресную запись.
Для того чтобы адрес инвертировался нужно указать опцию "-x":

> /usr/local/bin/dig -x 144.206.192.2

; > DiG 9.2.1 > -x 144.206.192.2 ;; global options: printcmd ;; Got answer: ;; ->>HEADER

Вот теперь все правильно, и имя преобразовано в имя домена зоны in-addr.arpa, и запрашивается запись типа PTR.

На самом деле можно и самому попробовать поискать "в лоб", задавая имя хоста в зоне in-addr.arpa и тип записи PTR, но это будет многоступенчатый процесс. Сначала dig отправит вас на корневые сервера, потом, на сервера зоны 144.in-addr.arpa и т.д., до тех пор, пока не откликнется авторитативный сервер зоны 192.206.144.in-addr.arpa:

> dig @ns.spb.su. 2.192.206.144.in-addr.arpa. -t ptr -c IN

; > DiG 8.3 > @ns.spb.su. 2.192.206.144.in-addr.arpa. -t -c ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER

На самом деле, для интереса можно вручную проделать весь этот путь, для того, чтобы оценить полезность опции "-х" J.

Если объем информации по умолчанию вас раздражает, и Вы хотите получить более краткие отчеты, то можно применить опцию запроса "+short":

> /usr/local/bin/dig -x 144.206.192.2 +short quest.polyn.kiae.su. >

т.е. ничего лишнего. Получили только имя хоста. Естественно, что эту опцию можно применять к любому запросу dig, если она (опция) не противоречит логике запроса.

Например, мы хотим получить в отчете сам запрос (опция +qr). При этом ясно, что получение краткого отчета противоречит нашему желанию. Если мы зададим опцию краткого отчета, то запроса в отчете не будет:

> /usr/local/bin/dig -x 144.206.192.2 +qr +short quest.polyn.kiae.su. >

Если убрать "+sort", запрос в отчете dig появится (от ";;Sending:" до ";;Got answer:"):

> /usr/local/bin/dig -x 144.206.192.2 +qr

; > DiG 9.2.1 > -x 144.206.192.2 +qr ;; global options: printcmd ;; Sending: ;; ->>HEADER>HEADER

Теперь вернемся к вопросу применения списка поиска, который по умолчанию отключен в dig.

Для включения необходимо указать опцию запроса "+search":

> /usr/local/bin/dig quest +search +short 144.206.192.2 >

На самом деле, мы получили то, что запрашивали. Вот только полного имени хоста нам так и не сообщили. К какому домену принадлежит имя quest. На первый взгляд мы и так знаем, в каком домене находимся, но ведь список поиска может состоять из нескольких доменных имен. Если /etc/resolv.conf будет иметь следующее содержание:

domain polyn.kiae.su nameserver 144.206.192.10 nameserver 144.206.160.32

то при поиске IP-адреса для хоста polyn мы ничего не получим, т.к. хоста polyn.polyn.kiae.su в описании зоны нет:

generate# /usr/local/bin/dig polyn +search +nocomments

; > DiG 9.2.1 > polyn +search +nocomments ;; global options: printcmd ;polyn. IN A . 251 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISI GN-GRS.COM. 2002110501 1800 900 604800 86400 ;; Query time: 2 msec ;; SERVER: 144.206.192.10#53(144.206.192.10) ;; WHEN: Wed Nov 6 13:11:53 2002 ;; MSG SIZE rcvd: 98

generate#

В данном отчете мы отключили печать комментариев (+nocomments), поэтому он получился более компактным, чем стандартный отчет.

Теперь изменим resolv.conf:

nameserver 144.206.192.10 nameserver 144.206.160.32 search polyn.kiae.su kiae.su .

Результат будет совсем иным:

generate# /usr/local/bin/dig polyn +search +nocomments

; > DiG 9.2.1 > polyn +search +nocomments ;; global options: printcmd ;polyn.kiae.su. IN A polyn.kiae.su. 3600 IN A 144.206.160.32 polyn.kiae.su. 3600 IN NS ns.spb.su. polyn.kiae.su. 3600 IN NS ns.ussr.eu.net. polyn.kiae.su. 3600 IN NS polyn.net.kiae.su. ns.spb.su. 98951 IN A 193.124.83.69 ns.ussr.eu.net. 105552 IN A 193.124.22.65 polyn.net.kiae.su. 9704 IN A 144.206.160.32 ;; Query time: 3 msec ;; SERVER: 144.206.192.10#53(144.206.192.10) ;; WHEN: Wed Nov 6 13:19:07 2002 ;; MSG SIZE rcvd: 175

generate#

Dig начала перебор доменных имен из resolv.conf. При этом, если бы мы попросили короткий отчет, то не имели бы представления о полном имени хоста:

generate# /usr/local/bin/dig polyn +search +nocomments +short 144.206.160.32 generate#

Для демонстрации трассы поиска информации в системе доменных имен, в dig предусмотрена опция "+trace":

generate# /usr/local/bin/dig www.ru +trace

; > DiG 9.2.1 > www.ru +trace ;; global options: printcmd . 352895 IN NS F.ROOT-SERVERS.NET. . 352895 IN NS B.ROOT-SERVERS.NET. . 352895 IN NS J.ROOT-SERVERS.NET. . 352895 IN NS K.ROOT-SERVERS.NET. . 352895 IN NS L.ROOT-SERVERS.NET. . 352895 IN NS M.ROOT-SERVERS.NET. . 352895 IN NS I.ROOT-SERVERS.NET. . 352895 IN NS E.ROOT-SERVERS.NET. . 352895 IN NS D.ROOT-SERVERS.NET. . 352895 IN NS A.ROOT-SERVERS.NET. . 352895 IN NS H.ROOT-SERVERS.NET. . 352895 IN NS C.ROOT-SERVERS.NET. . 352895 IN NS G.ROOT-SERVERS.NET. ;; Received 436 bytes from 144.206.192.10#53(144.206.192.10) in 3 ms

ru. 172800 IN NS NS2.NIC.FR. ru. 172800 IN NS NS.RIPN.NET. ru. 172800 IN NS NS2.RIPN.NET. ru. 172800 IN NS SUNIC.SUNET.SE. ru. 172800 IN NS NS.UU.NET. ru. 172800 IN NS NS1.RELCOM.ru. ;; Received 260 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 242 ms

www.ru. 86400 IN NS ns.demos.su. www.ru. 86400 IN NS ns1.demos.net. ;; Received 76 bytes from 192.93.0.4#53(NS2.NIC.FR) in 170 ms

www.ru. 86400 IN A 194.87.0.50 www.ru. 86400 IN NS ns.demos.su. www.ru. 86400 IN NS ns1.demos.net. ;; Received 140 bytes from 194.87.0.9#53(ns.demos.su) in 7 ms

generate#

В данном случае dig в отчете показывает отклики от серверов, которые она опрашивает. Для начала dig сообщила нам, что локальный сервер 144.206.192.10 за зону ru не отвечает и, что он отправил нас к корневым серверам. Те, в свою очередь, отправили нас на серверы зоны ru. Серверы зоны ru отправили нас на серверы зоны www.ru. Первый из этих серверов (ns.demos.ru) сообщил нам искомый адрес. Еще раз обратите внимание на то, что поиск адреса осуществляла сама dig, а не локальный сервер доменных имен. По этой причине проверять этой опцией работу локального сервера по обработке рекурсивных запросов не стоит.

Dig обладает еще одной интересной особенностью - выполнением нескольких команд за один раз. При чем, это не выборка нескольких опций из файла, а исполнение нескольких запросов, указанных в командной строке:

generate# /usr/local/bin/dig news.ru +short -x 144.206.160.32 www.ru ns 194.87.0.23 polyn.net.kiae.su. ns.demos.su. ns1.demos.net. generate#

В данном случае мы хотим получить IP адрес news.ru, имя для хоста 144.206.160.32 и все NS записи для зоны www.ru . Dig прекрасно справляется с поставленной задачей, мешаю, правда, все ответы в одну кучу.

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

quest.polyn.kiae.su. +short -x 144.206.192.2 +short www.rambler.su. +trace +noshort

Первая строка - это запрос на короткий отчет, который должен нам сообщить IP-адрес хоста auest.polyn.kiae.su, вторая срока запрашивает короткий отчет при поиске имени хоста с IP-адресом 144.206.192.2, в третьей строке мы запрашиваем трассу опроса серверов для имени www.rambler.ru и отменяем короткий отчет. Таким образом, каждый запрос dig - это отдельная строка файла. При запуске dig мы получим следующий отчет:

generate# /usr/local/bin/dig -f comd.txt 144.206.192.2 quest.polyn.kiae.su. . 332654 IN NS A.ROOT-SERVERS.NET. . 332654 IN NS H.ROOT-SERVERS.NET. . 332654 IN NS C.ROOT-SERVERS.NET. . 332654 IN NS G.ROOT-SERVERS.NET. . 332654 IN NS F.ROOT-SERVERS.NET. . 332654 IN NS B.ROOT-SERVERS.NET. . 332654 IN NS J.ROOT-SERVERS.NET. . 332654 IN NS K.ROOT-SERVERS.NET. . 332654 IN NS L.ROOT-SERVERS.NET. . 332654 IN NS M.ROOT-SERVERS.NET. . 332654 IN NS I.ROOT-SERVERS.NET. . 332654 IN NS E.ROOT-SERVERS.NET. . 332654 IN NS D.ROOT-SERVERS.NET. ;; Received 436 bytes from 144.206.192.10#53(144.206.192.10) in 4 ms

ru. 172800 IN NS NS2.NIC.FR. ru. 172800 IN NS NS.RIPN.NET. ru. 172800 IN NS NS2.RIPN.NET. ru. 172800 IN NS SUNIC.SUNET.SE. ru. 172800 IN NS NS.UU.NET.

ru. 172800 IN NS NS1.RELCOM.ru. ;; Received 268 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 139 ms

rambler.ru. 86400 IN NS ns.park.rambler.ru. rambler.ru. 86400 IN NS ns.rambler.ru. ;; Received 103 bytes from 192.93.0.4#53(NS2.NIC.FR) in 170 ms

www.rambler.ru. 3600 IN A 81.19.66.131 www.rambler.ru. 3600 IN A 81.19.66.50 rambler.ru. 3600 IN NS ns.rambler.ru. rambler.ru. 3600 IN NS ns.park.rambler.ru. ;; Received 135 bytes from 217.73.193.23#53(ns.park.rambler.ru) in 4 ms

generate#

Теперь от запросов к серверу, как рекурсивных, так и нерекурсивных, перейдем к копированию зоны. Для этого в качестве типа запроса нужно задать тип AXFR. При этом мы будем иммитировать работу slave сервера системы доменных имен, который пытается скопировать зону:

generate# /usr/local/bin/dig @localhost webstatistics.ru. axfr +multiline

; > DiG 9.2.1 > @localhost webstatistics.ru. axfr +multiline ;; global options: printcmd webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. ( 2 ; serial 3600 ; refresh (1 hour) 600 ; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) ) webstatistics.ru. 3600 IN NS ns.webstatistics.ru. webstatistics.ru. 3600 IN NS ns4.nic.ru. webstatistics.ru. 3600 IN A 144.206.192.60 host.webstatistics.ru. 3 IN A 144.206.192.63 ns.webstatistics.ru. 3600 IN CNAME webstatistics.ru. user.webstatistics.ru. 3 IN CNAME host.webstatistics.ru. user1.webstatistics.ru. 3 IN CNAME user.webstatistics.ru. www.webstatistics.ru. 3 IN A 144.206.160.32 www.webstatistics.ru. 3 IN A 144.206.192.60 www.webstatistics.ru. 3 IN A 144.206.192.61 www.webstatistics.ru. 3 IN A 144.206.192.62 www1.webstatistics.ru. 3 IN CNAME www.webstatistics.ru. zone.webstatistics.ru. 3 IN NS ns.webstatistics.ru. webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. ( 2 ; serial 3600 ; refresh (1 hour) 600 ; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) ) ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Wed Nov 6 19:13:48 2002 ;; XFR size: 16 records

generate#

В этом примере мы применили сразу два атрибута командной строки, которые не применяли раньше. Во-первых, мы явным образом указали сервер (@loacalhost), с которого мы хотим списать зону, во-вторых, указали явным образом тип запроса (axfr). Последний параметр (+multilane) позволил нам в удобочитаемом виде расположить опции SOA записи. Как и положено (RFC-1034) при копировании зоны SOA запись появляется дважды - в начале и конце передачи данных.

Вообще говоря, dig позволяет проиммитировать и инкрементальный обмен данными - тип запроса ixfr:

generate# /usr/local/bin/dig @193.0.0.236 example.com ixfr=2002010300

; > DiG 9.2.1 > @193.0.0.236 example.com ixfr=2002010300 ;; global options: printcmd example.com. 172800 IN SOA dns1.icann.org. hostmaster.icann .org. 2002020400 7200 3600 1209600 21600 example.com. 21600 IN NS a.iana-servers.net. example.com. 21600 IN NS b.iana-servers.net. example.com. 172800 IN A 192.0.34.72 www.example.com. 172800 IN A 192.0.34.72 example.com. 172800 IN SOA dns1.icann.org. hostmaster.icann .org. 2002020400 7200 3600 1209600 21600 ;; Query time: 62 msec ;; SERVER: 193.0.0.236#53(193.0.0.236) ;; WHEN: Wed Nov 6 19:30:16 2002 ;; XFR size: 7 records

generate#

Номер, который задается в качестве параметра ixfr - это серийный номер описания зоны. На самом деле, из данного отчета мало что понятно, т.к. мы не знаем, когда проводились реальные обновления зоны, и в чем они состояли.

Для того, чтобы проверить при помощи dig работу динамического обновления зоны, необходимо это свойство named настроить. Для этого следует выполнить две вещи:

разрешить динамическое обновление зоны в файле конфигурации named.conf настроить систему ведения журналов named таким образом, чтобы она фиксировала изменения в зоне

Разрешение динамического обновление настраивается следующим образом: в файл конфигурации named в правила, относящиеся к конкретной зоне добавляют опцию allow-update:

zone "webstatistics.ru" { type master; file "webstatistics.ru"; allow-update { { 144.206.192.55; 144.206.160.32; 127.0.0.1; }; }; };

Специалисты по безопасности в этом месте заклеймят нас позором, т.к. мы только перечислили IP-адреса, с которых можно проводить обновление, но не установили дополнительных условий типа подписей транзакций (TSIG - transaction signature). Но на наш взгляд в данном случае упоминание дополнительных "наворотов" не способствует прозрачности изложения материала, а потому вопросы безопасности мы пока отодвинем на второй план. Мы просто хотим убедиться в работе dig с ixfr.

Теперь нам нужно быть уверенными в том, что сервер действительно принимает запросы динамического обновления и реагирует на них. Для этого нужно настроить соответствующим образом журнал обращений к серверу доменных имен. За эту часть работы отвечает опция logging в файле конфигурации named:

logging { channel "update_log"{ file "update.log"; severity debug 3; }; category "default" { "default_syslog"; "default_debug"; }; category "update" { "update_log"; }; };

Мы создали новый канал для ведения журнала - update_log. Связали с этим каналом файл update.log, который будет размещаться в рабочем каталоге сервера. Серьезность сообщений, которые туда будут писаться, определили как отладку третьего уровня. Сам канал отнесли к категории Update (список категорий, по которым ведутся журналы в named, ограничен и приведен в руководстве системного администратора сервера).

Теперь перезапустим сервер и попробуем внести изменение в зону "на лету", воспользовавшись программой nsupdate:

generate# /usr/local/bin/nsupdate -d > server 127.0.0.1 > zone webstatistics.ru > update add newhost 3600 in cname host >

Reply from update query: ;; ->>HEADER

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

Смотрим в журнал динамических обновлений зоны сервера доменных имен:

generate# more namedb/update.log client 144.206.192.55#3187: updating zone 'webstatistics.ru/IN': adding an RR generate#

Наш уровень сообщений позволил нам узнать, что что-то обновилось, но вот что? Сначала запустим dig для того, чтобы узнать серийный номер зоны. Это нам даст первую информацию о том, было или не было обновление, если мы, конечно, помним предыдущий серийный номер:

generate# /usr/local/bin/dig @localhost webstatistics.ru soa +short ns.webstatistics.ru. paul.webstatistics.ru. 7 3600 600 86400 3600 generate#

Вот теперь запускаем dig для тестирования состояний динамических обновлений:

generate# /usr/local/bin/dig @localhost webstatistics.ru ixfr=6 +nocomments

; > DiG 9.2.1 > @localhost webstatistics.ru ixfr=6 +nocomments ;; global options: printcmd webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 7 3600 600 86400 3600 webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 6 3600 600 86400 3600 webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 7 3600 600 86400 3600 newhost.webstatistics.ru. 3600 IN CNAME host.webstatistics.ru. webstatistics.ru. 3600 IN SOA ns.webstatistics.ru. paul.websta tistics.ru. 7 3600 600 86400 3600 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Thu Nov 7 10:55:35 2002 ;; XFR size: 5 records

generate#

Вполне прогнозируемый результат. Dig сообщил нам, что не только была добавлена запись CNAME, но и изменилась запись SOA. Таким образом, мы можем с удовлетворением отметить, что все прекрасно работает.

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

Вообще говоря, у нас в запасе есть еще один способ убедиться в том, что все работает прекрасно - это файл журнала обновлений, но не наш, а системный для зоны webstatistics.ru - webstatistics.ru.jnl. В этом файле должны сохраняться все динамические обновления зоны.

Следует, правда, иметь в виду, что информация пишется туда не для чтения ее человеком, но бездушной машиной. Разобрать, конечно, кое-что можно, но dig удобнее.

В конце концов, если не очень торопиться, то изменения должны появиться и в описании зоны, но при этом нужно будет подождать некоторое время (примерно час). Понятно, что в этих условиях Dig позволит получить информацию быстрее.

Dig позволяет получать информацию не только об интернет зонах. Например, в BIND есть такая особенность: named дает возможность удаленному пользователю узнать версию пакета. На самом деле это не очень хорошо. Если данная версия обладает "дыркой" в системе безопасности, то сервер доменных имен только помогает определить инструмент для своего взлома.

generate# /usr/local/bin/dig -t txt -c chaos VERSION.BIND @localhost

; > DiG 9.2.1 > -t txt -c chaos VERSION.BIND @localhost ;; global options: printcmd ;; Got answer: ;; ->>HEADER

На самом деле, настраивая BIND, можно "прикинуться" другой версией пакета. Для этого в файл конфигурации named нужно указать:

zone "bind" chaos { type master ; file "bind"; allow-query { localhost ; } ; allow-transfer { none; } ; };

И создать описание зоны (файл bind):

$ORIGIN bind. @ 1D CHAOS SOA localhost. root.localhost. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum CHAOS NS localhost.

Собственно, пример с запросом на версию BIND призван был показать тот факт, что dig, как и любая другая система тестирования DNS, может запрашивать записи не только из Internet (класс IN), но и из других поддерживаемых в DNS классах.

В новых версиях BIND можно поступить еще проще, вставив в options (в файле named.conf) следующий фрагмент:

options { version "Ne znaju"; };

В этом случае текст у директивы version будет отображаться в качестве txt RR-записи в зоне version.bind класса chaos.

Программа тестирования системы доменных имен - host

В данном материале рассматривается применение различных опций программы host - одного из основных средств тестирования работы системы доменных имен.

Программа host среди трех наиболее используемых средств тестирования DNS (nslookup, dig, host) самая "свежая". В ней учтены нарекания пользователей, которые вызывают ее аналоги - nslookup и dig, а также реализованы возможности диагностирования ошибок и подсчета статистики.

Host не является средством отладки серверов доменных имен, каковым по сути является dig. Host не имеет интерактивного режима работы, который присутствует в nslookup. Зато host проста в использовании, не перегружена опциями и атрибутами, имеет ясный и лаконичный синтаксис и отчетность. Кроме того, ее любят применять в качестве компонента скриптов, которые кроме всего прочего призваны проверять наличие или отсутствие описания хостов в системе DNS.

Самый простой пример использования Host - это поиск IP-адреса по доменному имени:

> host quest quest.polyn.kiae.su has address 144.206.192.2 quest.polyn.kiae.su mail is handled (pri=10) by quest.polyn.kiae.su quest.polyn.kiae.su mail is handled (pri=20) by relay1.relcom.ru >

В данном случае мы задали короткое имя хоста. Оно было расширено именем домена, в котором находится хост, с которого осуществляется запрос к системе доменных имен (polyn.kiae.su). В качестве отклика мы получили не только IP-адрес, но и информацию о том, как на хост polyn.kiae.su доставляется почта, т.е. какие хосты являются почтовыми шлюзами.

При решении обратной задачи, поиска имени по IP-адресу можно также воспользоваться программой host:

> host 144.206.192.2 2.192.206.144.IN-ADDR.ARPA domain name pointer quest.polyn.kiae.su >

Как мы видим из этого примера, отчет host гораздо лаконичнее, чем отчет nslookup, например, - это просто сообщение о наличии записи в обратной зоне. Если бы с данным адресом, а точнее с именем 2.192.206.144.in-addr.arpa, в обратной зоне было бы связано более одной записи, то host сообщила бы о наличии всех этих записей:

> host 144.206.192.11 11.192.206.144.IN-ADDR.ARPA domain name pointer www.kiae.ru 11.192.206.144.IN-ADDR.ARPA domain name pointer kiae.polyn.kiae.su >

Host принимает в качестве аргументов не только короткие имена, но и более длинные последовательности, которые могут быть как полными именами (FQDN), так и неполными именами:

> host quest.polyn quest.polyn.kiae.su mail is handled (pri=20) by relay1.relcom.ru quest.polyn.kiae.su mail is handled (pri=10) by quest.polyn.kiae.su >

В контексте этого примера интересно рассмотреть, как host перебирает доменные имена и, вообще, что реально происходит. Для этого воспользуемся опцией отладки "-d":

> host -d quest.polyn ;; res_nmkquery(QUERY, quest.polyn, IN, A) ;; res_send() ;; ->>HEADER>HEADER>HEADER>HEADER>HEADER>HEADER>HEADER>HEADER

Как видно из этого примера, сначала host просто запрашивает IP-адрес для имени quest.polyn у сервера 144.206.192.10. Получает ответ, что такого домена (polyn) нет. Запрос host посылала рекурсивный, поэтому опрос корневого сервера, ответ которого приведен в примере, был получен сервером 144.206.192.10.

Затем host формирует запрос на поиск MX записи по тому же неполному имени. Естественным образом получаем также отрицательный ответ от корневого сервера об отсутствии домена polyn.

Теперь host расширяет наше неполное имя именем домена по умолчанию. Берет его из resolv.conf. Домена polyn.polyn.kiae.su также не существует.

Теперь host хост расширяет неполное имя только частью имени домена kiae.su. Тип записи при этом не модифицируется и остается равным MX, хотя по умолчанию сначала использовался тип A.

Хост quest в зоне polyn.kiae.su существует и для него есть MX записи, о чем нас с радастью и информируют. Кроме того, мы получаем информацию о том, какие серверы доменных имен являются авторитативными для зоны polyn.kiae.su.

Мягко говоря мы получили не совсем то, что хотели. Для того чтобы получить IP-адрес в данном случае, нужно явно задать тип записи A - "-t a":

> host -t a quest.polyn quest.polyn.kiae.su has address 144.206.192.2 >

Если попросить host выдать более подробную информацию, то можно получить следующее:

> host -v -t a quest.polyn Trying null domain rcode = 3 (Non-existent domain), ancount=0 Trying domain "polyn.kiae.su" rcode = 3 (Non-existent domain), ancount=0 Trying domain "kiae.su" rcode = 0 (Success), ancount=1 The following answer is not verified as authentic by the server: quest.polyn.kiae.su 3600 IN A 144.206.192.2 For authoritative answers, see: polyn.kiae.su 3600 IN NS ns.spb.su polyn.kiae.su 3600 IN NS ns.ussr.eu.net polyn.kiae.su 3600 IN NS polyn.net.kiae.su Additional information: ns.spb.su 59905 IN A 193.124.83.69 ns.ussr.eu.net 59447 IN A 193.124.22.65 polyn.net.kiae.su 54092 IN A 144.206.160.32 >

Таким образом, мы видим ту же самую последовательность проверки зон, но только теперь host не запрашивает MX записи, а пытается получить только адресные записи (A).

Внимательный читатель уже заметил, что вместо флага "-d" мы в последнем примере использовали флаг "-v". Флаг "-d" - это флаг отладочного отчета. В нем (отладочном отчете) расшифрованы значения флагов заголовка сообщений протокола DNS и содержание самих запросов. При флаге "-v" мы просто получаем подробный отчет вместо обычного укороченного отчета.

Теперь посмотрим еще один пример:

> host kuku.polyn.kiae.su kuku.polyn.kiae.su.kiae.su mail is handled (pri=80) by relay1.kiae.su kuku.polyn.kiae.su.kiae.su mail is handled (pri=90) by relay2.kiae.su > host -v kuku.polyn.kiae.su. rcode = 3 (Non-existent domain), ancount=0 Host not found. > host -v kuku.polyn.kiae.su Trying null domain rcode = 3 (Non-existent domain), ancount=0 Trying domain "polyn.kiae.su" rcode = 3 (Non-existent domain), ancount=0 Trying domain "kiae.su" rcode = 0 (Success), ancount=0 For authoritative answers, see: kiae.su 86400 IN SOA ns.kiae.ru noc-dns.relarn.ru( 650127450 ;serial (version) 28800 ;refresh period 3600 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) >

Сначала мы запросили адреса несуществующего имени. В домене polyn.kiae.su нет хоста с именем kuku. Во всяком случае, в описании зоны его нет точно. Host, тем не менее, в коротком отчете выдает MX записи для этого имени.

Мы задаем на конце имени символ ".", чтобы избежать перебора доменных имен. В этом случае мы получаем ответ, который и должны были получить. Теперь нам интересно, а почему в первом случае появились MX записи. Повторяем расширенный отчет, но без символа "." на конце имени хоста. Мы получаем положительный отклик, который говорит нам, что домен kiae.su существует. Но откуда адресные записи? Смотрим отладку, точнее только последнюю ее часть, которая касается домена kiae.su:

;; res_nmkquery(QUERY, kuku.polyn.kiae.su.kiae.su, IN, MX) ;; res_send() ;; ->>HEADER>HEADER

Теперь понятно, что наш запрос в процессе обработки превратился в запрос MX записи, а для домена kiae.su установлены два почтовых шлюза. Мораль проста - нужно заказывать точный тип записи, и задавать полное доменное имя хоста с магической "." на конце.

До этого момента мы использовали host в качестве имитатора клиента DNS. Теперь попробуем изобразить сервер доменных имен, а точнее slave, который копирует зону:

> host -d -l vega.ru. ;; res_nmkquery(QUERY, vega.ru, IN, NS) ;; res_send() ;; ->>HEADER>HEADER

Из отладочного отчета мы видим, что сначала определяются авторитативные сервера, а потом с них запрашивается передача зоны (AXFR). Но серверы macomnet.ru не дают нам списать зону. Наш запрос ими "отражен". Однако сервер ns1.psychol.ras.ru нам разрешает списать зону.

Любопытно, что именно он и является master домена vega.ru:

> host -t soa vega.ru vega.ru start of authority ns1.psychol.ras.ru serge.psychol.ras.ru( 2001121202 ;serial (version) 7200 ;refresh period 1800 ;retry refresh this often 3600000 ;expiration period 107800 ;minimum TTL ) >

Если бы мы не включали режим отладочного отчета, то получили бы только:

> host -l vega.ru vega.ru name server ns1.psychol.ras.ru vega.ru name server ns.macomnet.ru vega.ru name server ns2.macomnet.ru vega.ru has address 194.67.107.8 vega-gw.vega.ru has address 194.67.107.8 localhost.vega.ru has address 127.0.0.1 belti.vega.ru has address 213.59.3.161 www.belti.vega.ru has address 213.59.3.161 ns1.vega.ru has address 194.67.107.1 ns2.vega.ru has address 194.67.107.1 >

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

> host -l -t any vega.ru. vega.ru start of authority ns1.psychol.ras.ru serge.psychol.ras.ru( 2001121202 ;serial (version) 7200 ;refresh period 1800 ;retry refresh this often 3600000 ;expiration period 107800 ;minimum TTL ) vega.ru name server ns1.psychol.ras.ru vega.ru name server ns.macomnet.ru vega.ru name server ns2.macomnet.ru vega.ru mail is handled (pri=0) by vega-gw.vega.ru vega.ru mail is handled (pri=10) by new.psychol.ras.ru vega.ru has address 194.67.107.8 smtp.vega.ru is a nickname for vega.ru nntp.vega.ru is a nickname for vega.ru news.vega.ru is a nickname for vega.ru gopher.vega.ru is a nickname for vega.ru vega-gw.vega.ru mail is handled (pri=0) by vega-gw.vega.ru vega-gw.vega.ru mail is handled (pri=10) by new.psychol.ras.ru vega-gw.vega.ru mail is handled (pri=30) by polyn.net.kiae.su vega-gw.vega.ru has address 194.67.107.8 mail.vega.ru is a nickname for vega.ru localhost.vega.ru has address 127.0.0.1 www.vega.ru is a nickname for vega.ru belti.vega.ru mail is handled (pri=10) by pms.belti.ru belti.vega.ru mail is handled (pri=20) by mail.belti.ru belti.vega.ru has address 213.59.3.161 www.belti.vega.ru has address 213.59.3.161 ns1.vega.ru has address 194.67.107.1 ftp.vega.ru is a nickname for vega.ru ns.vega.ru is a nickname for vega.ru ns2.vega.ru has address 194.67.107.1 vega.ru start of authority ns1.psychol.ras.ru serge.psychol.ras.ru( 2001121202 ;serial (version) 7200 ;refresh period 1800 ;retry refresh this often 3600000 ;expiration period 107800 ;minimum TTL ) >

Как это не выглядит странным, но расширенный отчет, в котором для сокращения его объема мы удалили несколько записей, выглядит гораздо более привычно, чем стандартный отчет host. Во всяком случае, в нем читаются обычные записи описания ресурсов для зоны vega.ru:

> host -l -v -t any vega.ru rcode = 0 (Success), ancount=3 Found 1 addresses for ns.macomnet.ru Found 1 addresses for ns1.psychol.ras.ru Found 1 addresses for ns2.macomnet.ru Trying 195.128.64.3 Server failed, trying next server: Query refused Trying 62.117.88.14 vega.ru 107800 IN SOA ns1.psychol.ras.ru serge.psychol.ras.ru( 2001121202 ;serial (version) 7200 ;refresh period 1800 ;retry refresh this often 3600000 ;expiration period 107800 ;minimum TTL ) vega.ru 107800 IN NS ns1.psychol.ras.ru vega.ru 107800 IN NS ns.macomnet.ru vega.ru 107800 IN NS ns2.macomnet.ru vega.ru 107800 IN MX 0 vega-gw.vega.ru vega.ru 107800 IN MX 10 new.psychol.ras.ru vega.ru 107800 IN A 194.67.107.8 smtp.vega.ru 107800 IN CNAME vega.ru nntp.vega.ru 107800 IN CNAME vega.ru news.vega.ru 107800 IN CNAME vega.ru gopher.vega.ru 107800 IN CNAME vega.ru vega-gw.vega.ru 107800 IN A 194.67.107.8 mail.vega.ru 107800 IN CNAME vega.ru www.vega.ru 107800 IN CNAME vega.ru ftp.vega.ru 107800 IN CNAME vega.ru ns.vega.ru 107800 IN CNAME vega.ru ns2.vega.ru 107800 IN A 194.67.107.1 vega.ru 107800 IN SOA ns1.psychol.ras.ru serge.psychol.ras.ru( 2001121202 ;serial (version) 7200 ;refresh period 1800 ;retry refresh this often 3600000 ;expiration period 107800 ;minimum TTL ) >

Любопытно, что SOA запись повторяется дважды, но это не какая-то особенность host. Сами разработчики host пишут о том, что это происходит по таинственной причине ("arcane reasons"). На самом деле в RFC-1034 черным по белому написано, что при передаче зоны по AXFR запросу, а именно им и пользуются при копировании зоны, в качестве первого и последнего сообщений в потоке обмена данными передается узел начала описания зоны (top authoritative node of the zone), а это, собственно, и есть SOA запись.

На самом деле так себя ведут все программы, если они правильно соблюдают рекомендации RFC.

Пока в своих запросах мы использовали только серверы умолчания, которые указаны в resolv.conf. Host позволяет использовать в качестве сервера доменных имен для клиента, который хочет получить обслуживание свих рекурсивных запросов, любой сервер сети. Точнее, мы можем попытаться использовать "чужой" сервер таким образом:

> host -t a polyn.kiae.su ns.spb.su Using domain server: Name: ns.spb.su Address: 193.124.83.69 Aliases:

polyn.kiae.su has address 144.206.160.32 >

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

> host -t a polyn.kiae.su A.ROOT-SERVERS.NET. Using domain server: Name: A.ROOT-SERVERS.NET Address: 198.41.0.4 Aliases:

>

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

Теперь несколько замечаний по поводу работы с серверами. Во-первых, в качестве корневого сервера host всегда использует A сервер, а, во-вторых, при работе с серверами доменных имен умолчания, хост не выбирает лучший из них, а просто пользуется первым, если он работает, а если не работает, то берет второй из списка:

generate# host -d demin ;; res_nmkquery(QUERY, demin.polyn.kiae.su, IN, A) ;; res_send() ;; ->>HEADER>HEADER

Это не весь отладочный отчет, а только его фрагмент, который позволяет зафиксировать перебор серверов. Если мы снова обратимся к услугам host, то перебор серверов будет выполнен вновь.

На самом деле, вовсе не факт, что в вашей системе стоит программа host, а если даже она установлена, то, скорее всего, в ней нет множества полезных функций, из-за которых ее предпочитают другим системам тестирования DNS. Просто версия старая. По этой причине лучше всего ее (программу Host) скопировать с ftp сервера ftp://ftp.nikhef.nl/pub/network/host.tar.Z. На момент написания этого материала наиболее свежей версией была версия от 2000 года.

Что полезного можно найти в свежих версиях программы. Например, проверку записи SOA:

> ./host -C webstatistics.ru. 144.206.192.55 webstatistics.ru (generate.polyn.kiae.su) ns.webstatistics.ru paul.webstatistics.ru (1 3600 600 86400 3600) !!! webstatistics.ru SOA expire is less than 1 week (1 day) >

Host в данном случае указала на слишком короткий срок отключения slave сервера при отказе основного сервера доменных имен.

А вот пример проверки записей NS и теста серверов доменных имен:

generate# host -t ns webstatistics.ru. 144.206.192.55 webstatistics.ru NS ns.webstatistics.ru !!! webstatistics.ru NS host ns.webstatistics.ru is not canonical webstatistics.ru NS ns4.nic.ru generate# /stats/archive/host/host -C webstatistics.ru. ns4.nic.ru webstatistics.ru (ns4.nic.ru) webstatistics.ru SOA record currently not present at ns4.nic.ru generate#

Две последовательно примененные команды host позволяют выявить отсутствие описания зоны на сервере ns4.nic.ru.

Вот еще один пример применения host:

generate# ./host -L 1 webstatistics.ru. 144.206.192.55 webstatistics.ru. NS ns.webstatistics.ru. !!! webstatistics.ru NS host ns.webstatistics.ru is not canonical

В данном случае host сообщает нам, что имя сервера ns.webstatistics.ru - это синоним, а не каноническое имя. Параметр "-L 1" позволяет управлять рекурсий перебора синонимов, т.е. несколько раз обращаться системе DNS для поиска канонического имени при наличии цепочки синонимов.

Host позволяет реализовать множество полезных отчетов. Именно по этой причине его применяют для получения статистики в RIPE. Вот в заключении фрагмент отчета по зоне ru:

generate# ./host -H ru. ru AXFR record query refused by NS2.RIPN.NET !!! WINUP.ru NS host hw.prometeus.nsc.ru is not canonical !!! AK.ru NS host ns4.piter.net does not exist AK.ru has lame delegation to ns4.piter.net !!! DC.ru NS host dc.netway.ru does not exist DC.ru has lame delegation to dc.netway.ru …

Речь идет о некорректном делегировании. Для указанных в NS записях имен серверов нет IP-адресов.

Проверка работоспособности кэширующего named.

Первое, что нужно выполнить после запуска сервера, посмотреть, появился ли он в списке исполняемых процессов:

polyn: {26} ps -ax | grep named 74541 ?? Ss 0:13.95 /usr/sbin/named polyn: {27}

Если процесса нет, то нужно обратиться к файлу системного журнала и посмотреть, почему сервер не запустился:

Nov 20 13:48:09 quest named[34110]: starting BIND 9.2.1 Nov 20 13:48:09 quest named[34110]: /etc/named.conf:4: missing ';' before 'zone' Nov 20 13:48:09 quest named[34110]: loading configuration: failure Nov 20 13:48:09 quest named[34110]: exiting (due to fatal error)

Например, в данном случае при запуске были обнаружены ошибки в синтаксисе файла named.conf. По этой причине BIND 9.2.1 не запустился.

Если сервер запустился, то можно обратиться к нему при помощи команды dig или другой команды проверки работоспособности DNS:

generate# dig @localhost -t txt -c chaos version.bind.

; > DiG 8.3 > @localhost -t -c version.bind. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER

Можно также попросить статистику его работы. Для сервера BIND 4.x в его работу нужно просто вмешаться сигналом ABRT:

IRIS 1# ps -ae | grep named 204 ? 36:00 named IRIS 2# kill -ABRT 204 IRIS 3#more /var/tmp/named.stats +++ Statistics Dump +++ (1037807339) Wed Nov 20 18:48:59 2002 2434023 time since boot (secs) 2434023 time since reset (secs) 12427 Unknown query types 518901 A queries 147 NS queries 33 SOA queries 177315 PTR queries 47964 MX queries 92 TXT queries 190 AAAA queries 60 type 33 queries 112 type 38 queries 24 AXFR queries 99118 ANY queries ++ Name Server Statistics ++ (Legend) RR RNXD RFwdR RDupR RFail RFErr RErr RAXFR RLame ROpts SSysQ SAns SFwdQ SDupQ SErr (Global) …

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

quest# more /etc/namedb/named.stats +++ Statistics Dump +++ (1037800585) success 0 referral 0 nxrrset 0 nxdomain 0 recursion 0 failure 0 --- Statistics Dump --- (1037800585) quest#

Для того, чтобы появилась хоть какая-то статистика нужно его о чем-нибудь спросить:

quest# /usr/local/bin/dig @localhost www.ru +short 194.87.0.50 quest#

Теперь если посмотреть статистику обращений, то получим:

quest# more /etc/namedb/named.stats +++ Statistics Dump +++ (1037800853) success 3 referral 0 nxrrset 0 nxdomain 0 recursion 1 failure 0 --- Statistics Dump --- (1037800853) quest#

На самом деле для того, чтобы "прочувствовать" на нашем сервере кэширование, мы спросили сервер не один, а три раза. Именно это и отражено в отчете (success). А рекурсивный запрос был выполнен только один (recursion).

Для BIND 8.х статистику получают командой ndc. Записывается статистика при этом не в /var/tmp, а уже в директорию файлов описания зоны. При этом мы запускаем ndc в интерактивном режиме:

polyn: {1} ndc Type help -or- /h if you need help. ndc> stats Statistics dump initiated. ndc> /exit polyn: {2}

При помощи ndc можно не только собирать статистику, но и управлять сервером.

На самом деле приведенные примеры файлов статистики (кроме первого) сделаны при помощи команды rndc для сервера BIND 9.2.1. Для того, чтобы их получить, настройка сервера без удаленного контроля не годится. Нужно включить удаленный контроль.

Для того, чтобы его включить, нужно сгенерировать ключ. Это можно сделать любой из программ: dnskeygen из пакета BIND 8 или dnssec-keygen. На самом деле, вторая программка на некоторых системах не работает из-за ошибки взаимодействия с /dev/random, поэтому мы воспользовались первой.

quest# dnskeygen -H 128 -h -n rndc-key ** Adding dot to the name to make it fully qualified domain name** Generating 128 bit HMAC-MD5 Key for rndc-key.

Generated 128 bit Key for rndc-key.

id=0 alg=157 flags=513

quest#

Теперь нужно поправить named.conf:

quest# more named.conf options { directory "/etc/namedb"; }; zone "." { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" { type master; file "localhost.rev"; }; key "rndc-key" { algorithm hmac-md5; secret "0V5661f2iotUKMKVDXNydQ=="; }; controls { inet 127.0.0.1 allow { localhost; } keys {"rndc-key"; }; };

quest#

Появилась директива key и изменилась директива controls. Собственно, нам нужен был только ключ, который записан в опции secret. Он был сгенерирован программой dnskeygen по имени rndc-key и помещен в файл Krndc-key.+157+00000.private в том же каталоге, из которого запускалась программа генерации ключа. На самом деле там появился еще один файл Krndc-key.+157+00000.key с KEY записью описания ресурсов. Ключ можно взять и оттуда.

Само слово "rndc-key" в директиве key файла named.conf - это просто имя ключа, на которое мы ссылаемся в директиве controls.

Теперь нужно создать файл настройки rndc - rndc.conf в каталоге /etc:

options { default-server localhost; default-key "rndc-key"; }; key "rndc-key" { algorithm hmac-md5; secret "0V5661f2iotUKMKVDXNydQ=="; };

Директива key в точности повторяет директиву из файла настройки named. Теперь запускаем named:

>named

Все должно работать. При этом можно выполнять команду rndc.

На самом деле существует более простой путь. Нужно было просто создать файл rndc.key в каталоге /etc, который содержал бы описание ключа:

key "rndc-key" { algorithm hmac-md5; secret "0V5661f2iotUKMKVDXNydQ=="; };

При этом из файла конфигурации named можно вообще убрать директивы controls и key:

options { directory "/etc/namedb"; }; zone "." { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" { type master; file "localhost.rev"; };

BIND 9.2.1 сам прочитает rndc.key и запуститься с каналом управления для локальной машины:

Nov 20 17:39:46 quest named[34430]: starting BIND 9.2.1 Nov 20 17:39:46 quest named[34430]: command channel listening on 127.0.0.1#953

Программа rndc при этом также не нуждается в файле настройки rndc.conf, а использует файл ключа rndc.key.

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

Refresh

определяет интервал времени, после которого slave сервер обязан обратиться к master серверу с запросом на верификацию своего описания зоны. Как уже было сказано в разделе "Типы серверов доменных имен", при этом проверяется серийный номер описания зоны.

Описание зоны загружается slave сервером каждый раз, когда он стартует или перегружается. Однако, при стабильной работе может пройти достаточно большой интервал времени, пока эти события не произойдут в действительности. Кроме того, большинство систем, которые поддерживают сервис доменных имен, работают круглосуточно. Следовательно, необходим механизм синхронизации баз данных master и slave серверов.

Поле

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

Атрибут

Resolver. Типовые настройки

В данном материале разбираются настройки и принципы функционирования resolver в различных версиях BIND. Обсуждаются также особенности resolver, поставляемого в дистрибутиве клонов Unix.

Как уже говорилось выше, система разрешения доменных имен IP-адресами и обратная процедура построены по схеме "клиент-сервер". Функции из библиотеки libc.a (или libc.so) выступают в качестве клиентов, а вся их совокупность носит название resolver. Для того, чтобы клиент мог обратиться к серверу, он должен знать следующее:

Установлен ли вообще сервер доменных имен, Если сервер установлен, то где (IP-адрес сервера доменных имен). Если сервер установлен, то к какому домену относится машина.

Иногда название BIND (Berkeley Internet Name Domain) вводит новичков в заблуждение. Им кажется, что речь идет не о программе, а некой альтернативе другой системе доменных имен. Для того чтобы этого избежать, иногда вместо слова "domain" используют слово "daemon", обычно употребляющиеся для обозначения программ-демонов в системах Unix, которые находятся в памяти компьютера и выполняют служебные операции. Для того чтобы потом не повторяться, сразу поясним различия между DNS и BIND.

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

Главная задача resolver - принять запрос от прикладного программного обеспечения, провзаимодействовать с серверами DNS и вернуть в зависимости от запроса либо IP-адрес, либо доменное имя.

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

Рис.1. Типовая схема взаимодействия Resolver с локальным сервером доменных имен.

На практике второй способ является наиболее распространенным. При этом согласно RFC-1034 речь идет о так называемом "усеченном" resolver (stub resolver).

В RFC- 1034 указано также, что основной задачей resolver является обеспечение максимально быстрого обслуживания запросов прикладных программ к системе DNS. Основное место здесь отводится кэширующим resolver-ам. Однако, stub resolver таковым не является. Это значит, что каждый раз, когда прикладная программа запрашивает систему DNS resolver посылает запрос локальному серверу доменных имен.

Любопытно, что в стандартном resolver (см. man resolver - http://ddb.kharkov.ua/cgi-bin/bsdi-man?proto=1.1&query=resolver&msection=3&apropos=0, например) предусмотрена возможность итеративного опроса серверов доменных имен, но не предусмотрена возможность кэширования.

В Windows 2000 предусмотрен кэширующий resolver, который запускается в системе в качестве сервиса по умолчанию. Существует возможность остановки и повторного пуска этого сервиса, а также просмотра результатов его работы. Важно отметить, что данный resolver умеет осуществлять "отрицательное" кэширование (negative caching). Это значит что, если на какой-либо запрос поступает отрицательный ответ, например, отсутствие данного доменного имени, то этот ответ запоминается, и в следующий раз прикладная программа получит "отлуп" прямо из кэша resolver, а не после процедуры безуспешного поиска по серверам доменных имен. Естественно, что "отрицательный" ответ хранится в кэше resolver ограниченное время (Windows 2000 TCP/IP. DNS Resolver Cache Service.).

На самом деле, появление нового resolver в Windows 2000 позволило решить некоторые проблемы, которые windows-системы доставляли системе доменных имен (см. "Полезные ссылки" [2]). Впрочем всех проблем новый resolver Microsoft так и не решил.

В рамках пакета BIND также существует кэширующий resolver, который фактически реализует функции кэширующего сервера доменных имен. При этом он реализован как процесс-демон. О его настройках и использовании мы остановимся в конце данного раздела.

Рассуждения о настройке resolver мы будем вести в терминах Unix системы, если речь пойдет о другом операционном окружении, то это будет оговорено отдельно.

Традиционно вся совокупность параметров настройки resolver задается в файле /etc/resolv.conf. Приведем примера этого файла и разберем назначение каждой из команд, которая может быть использована в файле настройки resolver.

# # Resolver config for paul. # domain polyn.kiae.su nameserver 144.206.130.137

Строки, начинающиеся с символа "#" - это комментарии. Среди них следует выделить строку "nonameserver". В нашем примере она не влияет на работу системы разрешения доменных имен, но если в сети нет сервера доменных имен, то следует с этой строки снять символ комментария, а прочие команды напротив превратить в комментарии. При отсутствии сервера доменных имен система будет использовать файл /etc/hosts (см. "История и правила именования хостов").

По директиве domain resolver определяет, в каком домене он функционирует. Это локальное доменное имя. Локальным доменным именем называют имя домена, в который входит хост, где выполняется прикладная программа, использующая библиотеку resolver-а. Например, если хост имеет имя host.kuku.ru, то локальным доменным именем будет kuku.ru.

Узанать локальное доменное имя просто - нужно выполнить команду Hostname:

> hostname generate.polyn.kiae.su >

В данном случае локальное доменное имя - polyn.kiae.su.

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

/usr/paul> telnet radleg

то система расширит имя radleg именем домена, и будет искать машину с именем radleg.polyn.kiae.su.

Указанный выше пример - это только частный случай процедуры расширения неполного имени, которая используется функциями resolver. В литературе этот процесс называется применением списка поиска.

Различают два алгоритма применения списка поиска. Ниже представлен алгоритм, который использует resolver стандартной библиотеки libc.a. Большинство клонов Unix (различные версии этой операционной системы) поставляются именно с таким алгоритмом.

Обычно именно он применялся в 4-ых версиях пакета BIND.

В общем виде он выглядит следующим образом:

Если в прикладной программе указано имя хоста с точкой на конце, то расширение имени не производится:

/usr/paul>ping polyn.

В данном случае имя "polyn." завершено точкой. Если имя указано без точки, расширение производится по следующим правилам: либо происходит добавление локального домена, либо происходит обращение к файлу синонимов. Вообще говоря, в различных системах это расширение может быть организовано различными способами. Например, HP-UX имя файла синонимов указывается в переменной окружения HOSTALIASES. Пример расширения доменным именем был приведен выше. Если в качестве имени указывается составное имя, то производится серия подстановок, при помощи которых пытаются получить IP-адрес хоста. Например, для выполнения команды Ping из ниже приведенного примера:

/usr/paul> ping paul.polyn

Будет выполнена подстановка по следующим правилам: если в качестве домена в resolv.conf указан домен polyn.kiae.su, то будет проверена следующая последовательность имен: paul.polyn; paul.polyn.polyn.kiae.su; paul.polyn.kiae.su. Последнее имя будет разрешено сервером доменных имен. Ниже приведен пример поиска IP-адреса по списку поиска для неполного имени paul.polyn:

> paul.polyn Server: IRIS.polyn.kiae.su Address: 144.206.192.10

;; res_nmkquery(QUERY, paul.polyn, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 53781, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: paul.polyn, type = A, class = IN AUTHORITY RECORDS: -> (root) ttl = 325 (5m25s) origin = A.ROOT-SERVERS.NET mail addr = NSTLD.VERISIGN-GRS.COM serial = 2002091600 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D)

------------ ;; res_nmkquery(QUERY, paul.polyn.polyn.kiae.su, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 53782, rcode = NXDOMAIN header flags: response, auth.

answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: paul.polyn.polyn.kiae.su, type = A, class = IN AUTHORITY RECORDS: -> polyn.kiae.su ttl = 3600 (1H) origin = polyn.net.kiae.su mail addr = paul.kiae.su serial = 231 refresh = 3600 (1H) retry = 300 (5M) expire = 9999999 (16w3d17h46m39s) minimum ttl = 3600 (1H)

------------ ;; res_nmkquery(QUERY, paul.polyn.kiae.su, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 53783, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 1, authority records = 3, additional = 3

QUESTIONS: paul.polyn.kiae.su, type = A, class = IN ANSWERS: -> paul.polyn.kiae.su internet address = 144.206.192.34 ttl = 3600 (1H) AUTHORITY RECORDS: -> polyn.kiae.su nameserver = polyn.net.kiae.su ttl = 3600 (1H) -> polyn.kiae.su nameserver = ns.spb.su ttl = 3600 (1H) -> polyn.kiae.su nameserver = ns.ussr.eu.net ttl = 3600 (1H) ADDITIONAL RECORDS: -> polyn.net.kiae.su internet address = 144.206.160.32 ttl = 85775 (23h49m35s) -> ns.spb.su internet address = 193.124.83.69 ttl = 159806 (1d20h23m26s) -> ns.ussr.eu.net internet address = 193.124.22.65 ttl = 170465 (1d23h21m5s)

------------ Name: paul.polyn.kiae.su Address: 144.206.192.34

>

В этом примере адрес был успешно найден. А вот пример, в котором адрес не был найден:

> paul.polyn.kiae Server: IRIS.polyn.kiae.su Address: 144.206.192.10

;; res_nmkquery(QUERY, paul.polyn.kiae, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 53784, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: paul.polyn.kiae, type = A, class = IN AUTHORITY RECORDS: -> (root) ttl = 86400 (1D) origin = A.ROOT-SERVERS.NET mail addr = NSTLD.VERISIGN-GRS.COM serial = 2002091600 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D)

------------ ;; res_nmkquery(QUERY, paul.polyn.kiae.polyn.kiae.su, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 53785, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: paul.polyn.kiae.polyn.kiae.su, type = A, class = IN AUTHORITY RECORDS: -> polyn.kiae.su ttl = 3600 (1H) origin = polyn.net.kiae.su mail addr = paul.kiae.su serial = 231 refresh = 3600 (1H) retry = 300 (5M) expire = 9999999 (16w3d17h46m39s) minimum ttl = 3600 (1H)

------------ ;; res_nmkquery(QUERY, paul.polyn.kiae.kiae.su, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 53786, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS: paul.polyn.kiae.kiae.su, type = A, class = IN AUTHORITY RECORDS: -> kiae.su ttl = 86400 (1D) origin = ns.kiae.ru mail addr = noc-dns.relarn.ru serial = 650127450 refresh = 28800 (8H) retry = 3600 (1H) expire = 604800 (1W) minimum ttl = 86400 (1D)

------------ Name: paul.polyn.kiae.kiae.su

>

Запрашивался адрес для неполного имени paul.polyn.kiae, в resolv.conf в качестве локального имени домена было указано:

domain polyn.kiae.su

Почему же мы не нашли адреса для имени? Потому, что список поиска остановился на paul.polyn.kiae.kiae.su, т.е. при переборе имен локальное доменное имя можно усечь только до имени состоящего из меток двух доменов. В нашем случае - это kiae.su.

Если ваш resolver ведет себя приведенным выше способом, то следует проверить, что в директиве domain срока заканчивается не пробелом, а отображаемым символом. В противном случае возможны ошибки при разрешении имен.

Усечение до двухзвенного имени вызвано проблемой, которая описана в RFC-1535. Суть ее заключается в том, при полном поиске, т.е. при подстановке и однозвенного имени появлялась реальная возможность "улететь" совсем на другой хост.

Например, если зарегистрировать в com домен ru (ru.com), то для всех пользователей машин из домена com, которые хотят попасть в домен ru, появляется возможность попасть в приватный домен ru.com, т.к. обычно пользователи не указывают на конце символа ".". При этом у администратора домена ru.com появляется возможность по своему усмотрению накручивать, например, сайт www.ru.com.

К слову сказать, ru.com уже зарегистрирован. Вот отчет whois:

Registrant: Central Nic Ltd (RU70-DOM) 13 Bowerdean St Fulham London, SW6 3TU UK

Domain Name: RU.COM

Administrative Contact, Technical Contact: Hostmaster (HO4073-ORG) hostmaster@CENTRALNIC.NET CentralNic Ltd 163 New Kings Road London UK +44 20 7384 3050Fax- +44 20 7736 9253 Fax- - +44 20 7736 9253

Record expires on 23-Jun-2010. Record created on 23-Jun-2000. Database last updated on 16-Sep-2002 10:56:25 EDT.

Domain servers in listed order:

NS0.CENTRALNIC.NET 195.82.125.70 NS1.CENTRALNIC.NET 212.18.224.66 LON-NS-2.CENTRALNIC.NET 195.149.39.141 ESS-NS-0.CENTRALNIC.NET 194.221.62.8 NS0.JML.NET 195.149.39.76

Кроме того, www.ru.com тоже уже занят.

Новые (с BIND 4.9) версии resolver, которые входят в состав BIND работают иначе:

Если введено имя хоста без точек, то оно расширяется локальным доменным именем Если пункт 1 не дал результата, то введенное имя используется в качестве имени TLD. Если введенное имя содержит составное, но не полное (fully qualified domain name - FQDN), имя, то в этом случае сначала проверяется введенное имя без расширения его локальным доменным именем. Если пункт 3 не дал результата, то введенное имя расширяется локальным доменным именем.

Усечений локального доменного имени в этом алгоритме не предусмотрено.

Если по каким-либо причинам стандартный алгоритм применения списка поиска не устраивает, то тогда вместо директивы damin в resolv.conf применяют директиву search:

search corp.ru .

После директивы search через пробел или табуляцию указывают доменные имена, которые будут расширять введенное пользователем имя, если оно не относится к FQDN.

Следует заметить, что размер списка не безграничен. Всего он может содержать 256 символов.

При указании имени домена следует учитывать то, как будет в этом случае работать весь комплекс программного обеспечения, установленный на данном компьютере. Дело в том, что некоторые программы, sendmail, например, способны сами решать проблему определения IP-адресов по именам (то бишь использовать свои собственные функции при обращении к DNS, например, sm_gethostbyname()). В ряде случаев это может привести к противоречиям и ошибкам при функционировании такого сорта программ.

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. Возможно указание нескольких серверов. Обычно - это не более трех серверов доменных имен.

На самом деле, если собирать библиотеку resolver самостоятельно, то число сервер, которое можно указывать в resolv.conf может быть установлено произвольно Определяется переменной MAXNS в файле /usr/include/resolv.h.

Вообще говоря, многие ограничения resolver заданы переменными в этом файле. Например, максимальное число элементов списка поиска - MAXDNSRCH, минимальный уровень вложенности локального доменного имени - LOCALDOMAINPARTS и т.п..

Если нет указаний на сервер доменных имен, то предполагается, что существует локальный сервер доменных имен. В старых версиях предполагалось, что он размещен по адресу 127.0.01, в новых версиях предполагается, что локальный адрес 0.0.0.0. Изменение адреса связано с проблемами, которые возникали при работе хоста через коммутируемые соединения. Предполагалось, что адрес умолчания - это адрес полученный через ifconfig в момент начальной загрузки машины. В этом случае интерфейс должен быть поднят и активен. Все такого сорта адреса интерфейсов маршрутизировались через 127.0.0.1. Но если интерфейс не поднимался, то возникало "залипание" и машина висла на этапе начальной загрузки. Изменение адреса позволяет решить эту проблему в рамках самого пакета.

Общая рекомендация такова: всегда нужно создавать файл resolv.conf и указывать в нем адрес локального сервера доменных имен.

Если указано несколько серверов доменных имен, то адрес каждого сервера указывается отдельной строкой в файле resolv.conf:

# resolv.conf search corp.ru . nameserver 192.168.0.1 nameserver 192.168.0.2 nameserver 192.168.0.3

Опрос серверов осуществляется по порядку их указания в файле resolv.conf. Сначала будет опрашиваться 192.168.0.1, потом, если первый сервер не ответил, - 192.168.0.2, и последним, если не ответили первые два, - 192.168.0.3. Минимальный интервал времени между попытками по умолчанию (переменная RES_TIMEOUT в файле resolv.conf - 5 секунд). Обычно resolver делает 2 или 3 серии попыток (зависит от версии).

Resolver не упорядочивает сервера из директив nameserver по продолжительности времени отклика от них. Он их всегда опрашивает в том порядке, в котором они указаны в файле resolv.conf. Наиболее целесообразно первым указывать основной сервер доменных имен данного домена, а вторым дублирующий сервер доменных имен данного домена .

Обычно директивами domain, search, nameserer и ограничиваются при описании файла настройки resolv.conf. Более подробную информацию можно найти на страницах руководств системных администраторов операционных систем (ссылка на man Unix приведен в "полезных" ссылках).

И в заключении несколько слов об "умном" resolver пакета BIND 9. Он носит название lwresd и запускается в момент начальной загрузки системы как демон. Прикладные программы для работы с ним должны быть отредактированы с библиотекой вызовов этого resolver (BIND 9 lightweight resolver library).

Lwresd - это практически кеширующий локальный сервер доменных имен, который общается с клиентами не по протоколу DNS, а по своему собственному, посылая в сеть запросы. Если в resolv.conf указан сервер доменных имен, который может обрабатывать рекурсивные запросы, то lwresd будет пересылать ему запросы клиентов, если нет, то он может, используя встроенный список корневых серверов сам выполнять запросы клиентов.

Retry

начинает играть роль тогда, когда master сервер по какой-либо причине не способен удовлетворить запрос slave сервера за время определенное атрибутом refresh. А если говорить точнее, то в момент наступления времени синхронизации описания зоны master сервер по какой-либо причине не отвечает на запросы slave сервера.

Атрибут retry определяет интервал времени, после которого slave сервер должен повторить попытку синхронизовать описание зоны с master сервером. Ограничения на значение этого атрибута те же, что и для атрибута refresh.

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

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

Атрибут

Serial

- определяет серийный номер файла зоны. Если говорить проще, то в этом поле ведется учет изменений файла описания зоны. Serial - это 32-битное целое число, и ограничение по числу цифр, которое можно встретить в руководствах по BIND, на самом деле условно.

В принципе это могут быть любые числа, но чаще всего администраторы используют в качестве серийного номера год (4 позиции), месяц (две позиции), день (две позиции) и версию внесения изменений в файл описания зоны (две позиции). Таким образом эта нотация будет выглядеть как:

Сервера, которые обслуживают корневую зону (Root servers)

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

Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:

> . Server: [144.206.192.60] Address: 144.206.192.60

Non-authoritative answer: (root) origin = A.ROOT-SERVERS.NET mail addr = NSTLD.VERISIGN-GRS.COM serial = 2002091100 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D)

Authoritative answers can be found from: (root) nameserver = A.ROOT-SERVERS.NET (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET (root) nameserver = G.ROOT-SERVERS.NET (root) nameserver = H.ROOT-SERVERS.NET (root) nameserver = I.ROOT-SERVERS.NET (root) nameserver = J.ROOT-SERVERS.NET (root) nameserver = K.ROOT-SERVERS.NET (root) nameserver = L.ROOT-SERVERS.NET (root) nameserver = M.ROOT-SERVERS.NET A.ROOT-SERVERS.NET internet address = 198.41.0.4 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 F.ROOT-SERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 I.ROOT-SERVERS.NET internet address = 192.36.148.17 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOT-SERVERS.NET internet address = 202.12.27.33 >

Согласно этому отчету Primary master сервером для корневой зоны является сервер A.ROOT-SERVERS.NET. Именно он отвечает за все изменения в описании зоны. Остальные серверы относительно корневой зоны являются slave-серверами.
Slave- серверы обновляют свои описания зоны каждые 30 минут. Если в течении недели Primary master будет неработоспособен, то по идее вся система доменных имен потеряет связность. В RFC-2870, где описаны требования к работе root серверов, содержатся общие слова о том, как не допустить такого развития событий, но там нет конкретного плана действий.

На самом деле каждый из 13 серверов - это не одна машина. Так, например, k.root-servers.net (европейский) состоит из k1, k2 и k3, m.root-servers.net (японский) состоит из двух основных серверов и двух серверов горячего резерва, которые подключены к трем независимым точкаv обмена трафиком, f.root-servers.net состоит из двух двухпроцессорных Alpha, по 4GB оперативной памяти в каждой, с балансировкой нагрузки через маршрутизатор Cisco.

И еще несколько слов о root серверах в заключении этого раздела. Существует такая организация - IEPG (Internet Operational Group), задача которой помогать Интернет Сервис Провайдерам взаимодействовать в Сети Интернет. В 1999 году на очередной встрече этой группы обсуждались проблемы DNS И приводилась некоторая статистика по запросам к root серверам:

Средние цифры таковы:

	Исходящий трафик:		600 Kbps
	Входящий трафик:		2.2 Kbps
	Число пакетов за сутки:		26M

Распределение запросов по типам:

	Поиск IP-адреса(A)		77%
	Поиск сервера доменных имен (NS)		15%
	Поиск почтового шлюза(MX)		5%

Статистика обслуживания запросов, которая названа ужасающей(Scary statistics):

- Только 26% правильных(valid) запросов к корневой зоне.

- В 6% случаев на правильный запрос нельзя получить авторитативного отклика (.com, .net etc.)

- 66% запросов к несуществующим доменам верхнего уровня (non existent TLDs)

По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствие негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду. Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности приреализации протоколов.

К слову сказать, в 2002 году на встрече IEGP также обсуждались проблемы DNS, а точнее масштаб ошибок при делегировании и описании зон.

Система доменных имен Internet. Немного истории и принципы построения иерархии имен.

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

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

В адресе электронной почты формально доменным именем можно считать то, что написано после символа коммерческого ат - "@". Например, в user@corp.ru доменное имя почтового узла - corp.ru.

Имя Web-узла - это доменное имя этого узла. Например, Web-узел компании Microsoft имеет доменное имя Microsoft.com.

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

Довольно часто наряду со словосочетанием "интернет-адрес" употребляют "доменный адрес". Вообще говоря, ни того, ни другого понятий в сетях TCP/IP не существует. Есть числовая адресация, которая опирается на IP-адреса, (группа из 4-ех чисел, разделенных символом ".") и Internet-сервис службы доменных имен (Domain Name System - DNS).

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

Тем не менее, установка соединений для обмена информацией в Интернет осуществляется по IP-адресам. Символьные имена системы доменных имен - суть сервис, который помогает найти необходимые для установки соединения IP-адреса узлов сети.

Тем не менее, для многих пользователей именно доменное имя выступает в роли адреса информационного ресурса. В практике администрирования локальных сетей нередки ситуации, когда пользователи жалуются администратору сети на недоступность того или иного сайта или долгую загрузку страниц. Причина может крыться не в том, что сегмент сети потерял связь с остальной сетью, а в плохой работе DNS - нет IP-адреса, нет и соединения.

DNS существовала не с момента рождения TCP/IP сетей. Поначалу для облегчения взаимодействия с удаленными информационными ресурсами в Интернет стали использовать таблицы соответствия числовых адресов именам машин.

Авторство создания этих таблиц принадлежит доктору Постелю (Dr. Jon Postel - автор многих RFC - Request For Comments). Именно он первым поддерживал файл hosts.txt, который можно было получить по FTP.

Современные операционные системы тоже поддерживают таблицы соответствия IP-адреса и имени машины (точнее хоста) - это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид:

127.0.0.1 localhost 144.206.130.137 polyn Polyn polyn.net.kiae.su polyn.kiae.su 144.206.160.32 polyn Polyn polyn.net.kiae.su polyn.kiae.su 144.206.160.40 apollo Apollo www.polyn.kiae.su

Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). Как видно из примера, синонимов может быть много, и, кроме того, для разных IP-адресов может быть указано одно и то же имя.

Напомним еще раз, что по самому мнемоническому имени никакого доступа к ресурсу получить нельзя. Процедура использования имени заключается в следующем:

сначала по имени в файле hosts находят IP-адрес, затем по IP-адресу устанавливают соединение с удаленным информационным ресурсом.

Обращения, приведенные ниже аналогичны по своему результату - инициированию сеанса telnet с машиной Apollo:

telnet 144.206.160.40

или

telnet Apollo

или

telnet www.polyn.kiae.su

В локальных сетях файлы hosts используются достаточно успешно до сих пор.

Практически все операционные системы от различных клонов Unix до Windows последних версий поддерживают эту систему соответствия IP-адресов именам хостов.

Однако такой способ использования символьных имен был хорош до тех пор, пока Интернет был маленьким. По мере роста Сети стало затруднительным держать большие согласованные списки имен на каждом компьютере. Главной проблемой стал даже не размер списка соответствий, сколько синхронизация его содержимого. Для того, что бы решить эту проблему, была придумана DNS.

DNS была описана Полом Мокапетрисом (Paul Mockapetris ) в 1984. Это два документа: RFC-882 и RFC-883 (Позже эти документы были заменены на RFC-1034 и RFC-1035). Пол Мокапетрис написал и реализацию DNS - программу JEEVES для ОС Tops-20. Именно на нее в RFC-1031 предлагается перейти администраторам машин с ОС Tops-20 сети MILNET. Не будем подробно излагать содержание RFC-1034 и RFC-1035. Ограничимся только основными понятиями.

Роль имени (доменного имени) в процессе установки соединения осталось прежним. Это значит, что главное, для чего оно нужно, - получение IP адреса. Соответственно этой роли, любая реализация DNS является прикладным процессом, который работает над стеком протоколов межсетевого обмена TCP/IP. Таким образом, базовым элементом адресации в сетях TCP/IP остался IP-адрес, а доменное именование (система доменных имен) выполняет роль вспомогательного сервиса.

Система доменных имен строится по иерархическому принципу. Точнее по принципу вложенных друг в друга множеств. Корень системы называется "root" (дословно переводится как "корень") и никак не обозначается (имеет пустое имя согласно RFC-1034).

Часто пишут, что обозначение корневого домена - символ ".", но это не так, точка - разделитель компонентов доменного имени, а т.к. у корневого домена нет обозначения, то полное доменное имя кончается точкой. Тем не менее символ "." достаточно прочно закрепился в литературе в качестве обозначения корневого домена.

От части это вызвано тем, что в файлах конфигурации серверов DNS именно этот символ указывается в поле имени домена (поле NAME согласно RFC-1035) в записях описания ресурсов, когда речь идет о корневом домене.

Корень - это все множество хостов Интернет. Данное множество подразделяется на домены первого или верхнего уровня (top-level или TLD). Домен ru, например, соответствует множеству хостов российской части Интернет. Домены верхнего уровня дробятся на более мелкие домены, например, корпоративные.

В 80-е годы были определены первые домены первого уровня (top-level): gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа: uk, jp, au, ch, и т.п. Для СССР также был выделен домен su. После 1991 года, когда республики Союза стали суверенными, многие из них получили свои собственные домены: ua, ru, la, li, и т.п.

Однако Интернет не СССР, и просто так выбросить домен su из системы доменных имен нельзя. На основе доменных имен строятся адреса электронной почты и доступ ко многим другим информационным ресурсам Интернет. Поэтому гораздо проще оказалось ввести новый домен к существующему, чем заменить его.

Если быть более точным, то новых имен с расширением su в настоящее время ни один провайдер не выделяет (делегирует). Однако у многих существует желание возобновить процесс делегирования доменов в зоне SU.

Со списком доменов первого уровня (top-level) и их типами можно ознакомиться, например, в материале "Общая информация о системе доменных имен".

Как уже было сказано, вслед за доменами первого уровня(top-level) следуют домены, определяющие либо регионы (msk), либо организации (kiae). В настоящее время практически любая организация может получить свой собственный домен второго уровня. Для этого надо направить заявку провайдеру и получить уведомление о регистрации (см. "Как получить домен").

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

Часть дерева доменного именования можно представить следующим образом:

Рис.1. Пример части дерева доменных имен.

Корень дерева не имеет имени метки. Поэтому его обозначают как "". Остальные узлы дерева метки имеют. Каждый из узлов соответствует либо домену, либо хосту. Под хостом в этом дереве понимают лист, т.е. такой узел ниже которого нет других узлов.

Именовать хост можно либо частичным именем, либо полным именем. Полное имя хоста - это имя, в котором перечисляются слева направо имена всех промежуточных узлов между листом и корнем дерева доменного именования, при этом начинают с имени листа, а кончают корнем, например:

polyn.net.kiae.su.

Частичное имя - это имя, в котором перечислены не все, а только часть имен узлов, например:

polyn apollo.polyn quest.polyn.kiae

Обратите внимание на то, что в частичных (неполных именах) символ точки в конце имени не ставится. В реальной жизни программное обеспечение системы доменных имен расширяет неполные имена до полных прежде, чем обратиться к серверам доменных мен за IP-адресом.

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

Еще раз обратим внимание на то, что именование идет слева направо, от минимального имени хоста (от листа) к имени корневого домена. Разберем, например, полное доменное имя demin.polyn.kiae.su. Имя хоста - demin, имя домена, в который данный хост входит, - polyn, имя домена, который охватывает домен polyn, т.е. является более широким по отношению к polyn, - kiae, в свою очередь последний (kiae) входит в состав домена su.

Имя polyn.kiae.su - это уже имя домена. Под ним понимают имя множества хостов, у которых в их имени присутствует polyn.kiae.su.

Вообще говоря, за именем polyn.kiae.su может быть закреплен и конкретный IP-адрес. В этом случае кроме имени домена данное имя будет обозначать и имя хоста. Такой прием довольно часто используется для обеспечения коротких и выразительных адресов в системе электронной почты.

Имена хоста и доменов отделяются друг от друга в этой нотации символом ".". Полное доменное имя должно оканчиваться символом ".", т.к. последняя точка отделяет пустое имя корневого домена от имени домена верхнего уровня. Часто в литературе и в приложениях эту точку при записи доменного имени опускают, используя нотацию неполного доменного имени даже в том случае, когда перечисляют все имена узлов от листа до корня доменного именования.

Следует иметь в виду, что доменные имена в реальной жизни достаточно причудливо отображаются на IP-адреса, а тем более на реальные физические объекты (компьютеры, маршрутизаторы, коммутаторы, принтеры и т.п.), которые подключены к сети.

Компьютер, физически установленный и подключенный к Сети в далекой Америке, может совершенно спокойно иметь имя из российского корпоративного домена, например, chalajva.ru, и наоборот, компьютер или маршрутизатор российского сегмента может иметь имя из домена com. Последнее, к слову сказать, встречается гораздо чаще.

Более того, один и тот же компьютер может иметь несколько доменных имен. Возможен вариант, когда за одним доменным именем может быть закреплено несколько IP-адресов, которые реально назначены различным серверам, обслуживающим однотипные запросы. Таким образом, соответствие между доменными именами и IP-адресами в рамках системы доменных имен не является взаимно однозначным, а строится по схеме "многие к многим".

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

Следует также упомянуть о канонических доменных именах.

Это понятие встречается в контексте описания конфигураций поддоменов и зон ответственности отдельных серверов доменных имен. С точки зрения дерева доменных имена не разделяют на канонические и неканонические, но с точки зрения администраторов, серверов и систем электронной почты такое разделение является существенным. Каноническое имя - это имя, которому в соответствие явно поставлен IP-адрес, и которое само явно поставлено в соответствие IP-адресу. Неканоническое имя - это синоним канонического имени. Более подробно см. "настройка BIND".

Наиболее популярной реализацией системы доменных имен является Berkeley Internet Name Domain (BIND). Но эта реализация не единственная. Так в системе Windows NT 4.0 есть свой сервер доменных имен, который поддерживает спецификацию DNS.

Тем не менее, даже администраторам Windows желательно знать принципы функционирования и правила настройки BIND, т.к. именно это программное обеспечение обслуживает систему доменных имен от корня до TLD (Top Level Domain).

Slave сервер для корпоративного домена. Настройки BIND.

В данном материале мы рассмотрим конфигурацию программы named при организации slave сервера. Основное внимание будет уделено вопросам контроля работы сервера и управления копированием зон с master сервера зоны.

Наличие slave сервера у корпоративного домена не менее важно, чем организация master сервера. При регистрации домена надежность slave сервера проверяется точно таким же способом, что и надежность master сервера. По этой причине подходить к выбору места размещения slave сервера следует также тщательно, как и к выбору хоста, на котором будет размещен master сервер.

При организации slave сервера не нужно создавать никаких файлов описания зон. Они сами создаются при выполнении копирования зоны. Необходимо только правильно настроить named, т.е. прописать все необходимые опции в файле конфигурации программы.

Slave сервер выполняет процедуру автоматической синхронизации описания зоны на авторитативных серверах, которая в общем виде описана в разделе 4.3.5 RFC 1034.

Согласно этому документу обмен данными между серверами рекомендовано производить по TCP протоколу, используя тип запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).

Важным моментом при обмене данными зоны являются настройки как master, так и slave серверов. Рассмотрим эти настройки более подробно, разбив рассмотрение по версиям BIND.

Slave-сервер (secondary, вторичный, дублирующий)

также является ответственным (authoritative) за зону. Его основное назначение заключается в том, чтобы подстраховать работу основного сервера доменных имен (master server), ответственного за зону, на случай его выхода из строя, а также для того, чтобы разгрузить основной сервер, приняв часть запросов на себя. Так, например, из 13 серверов, которые обслуживают корневую зону, 12 являются slave-серверами.

Администратор slave-сервера не прописывает данные описания зоны. Он только обеспечивает настройку своего сервера таким образом, чтобы его сервер копировал описание зоны с master-сервера, поддерживая его (описание зоны) в актуальном согласованном с master-сервером состоянии.

Обычно, время согласования описания зоны между slave-сервером и master-сервером задается администратором master-сервера в описании зоны. Slave-сервер в момент своего запуска копирует это описание и затем руководствуется им при обновлении информации о зоне. Slave-сервера периодически через заданный интервал времени опрашивают master-сервер на предмет изменения описания зоны. Если изменения имеют место быть, то описание зоны копируется на slave-сервер.

Спецификация DNS позволяет реализовать и другой механизм обновления информации - оповещение об изменениях. В этом случае инициатива обновления описаний зоны на slave-серверах принадлежит не этим серверам, а master-серверу. Последний оповещает slave-серверы от том, что в базу были внесены изменения, и необходимо эти изменения скопировать на slave-серверы.

Существует оговоренная практика резервирования серверов, которая описана в рекомендациях по ведению зон. Она заключается в том, что для домена второго уровня необходимо иметь как минимум два сервера, ответственных за зону, т.е. дающих авторитативные отклики на запросы. Один master-сервер и один slave-сервер. При этом эти серверы должны иметь независимые подключения к Интернет, чтобы обеспечить бесперебойное обслуживание запросов к зоне в случае потери связи с одним из сегментов сети, в котором находится один из серверов.

Рис.1. Схема подключения master и slave серверов зоны

Из рисунка 1 видно, что корпоративная локальная сеть и сеть регистратора имеют независимые подключения к Интернет, через разных канальных провайдеров. В частности резервирование серверов в ru-center (www.nic.ru) обеспечивает такую схему подключения, т.е. master-сервер может быть размещен на площадке корпоративной локальной сети, а slave на площадке ru-center.

Размещение обоих серверов на площадке регистратора, например, ru-center, также обеспечивает независимое подключение серверов, т.к. обычно регистратор имеет несколько точек подключения к Интернет.

Как уже было сказано, slave-сервер копирует описание зоны c master-сервера. В настоящее время существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

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

Так slave-сервером называют сервер, который использует механизм передачи зоны для получения копии зоны, а master-сервером называют сервер, с которого осуществляется копирование зоны. При этом зону можно скопировать с любого сервера, который является авторитативным. Т.е. зону можно скопировать и со slave-сервера, который относительно самой процедуры копирования зоны будет считаться master-сервером. Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие

Тестирование серверов и системы доменных имен

Этот материал пытается дать ответ на вопрос - "за чем нужно, вообще, тестировать систему доменных имен и серверы доменных имен". Названы типовые запросы к системе доменных имен и к серверам системы доменных имен.

В тот момент, когда получен корпоративный домен, осуществлено делегирование зоны корпоративного домена, настроены и запущены серверы зоны, наступает следующий этап работы администратора домена - этап эксплуатации.

Главным на этапе эксплуатации становится контроль работы серверов доменных имен зоны и "видимость" зоны (как совокупности хостов) в пространстве доменных имен. При этом, как правило, администратор решает несколько стандартных задач.

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

Это происходит по той простой причине, что slave серверы к моменту проведения поиска еще не обновили зону. Поэтому нужно попытаться использовать для поиска какой-либо "чужой" сервер для исполнения вашего рекурсивного запроса. Хост должен стать "видимым" после обновления описаний зон на всех серверах, ответственных за зону.

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

Третья стандартная задача, которая возникает в контексте почтовых проблем, - это перебор имен resolver-ом. На самом деле, здесь существует масса подводных камней связанных и с почтовым программным обеспечением и с версией пакета BIND.

Четвертая стандартная задача - передача описания зоны. Она возникает при выявлении рассогласования между master сервером зоны и slave серверами. Кроме того, "скачивание" всей зоны, как правило, разрешено далеко не всем, что тоже требует проверки.

Пятая стандартная задача - это выявление типовых ошибок при управлении зоной, к которым обычно относят: некорректное делегирование зон, проблемы установки синонимов на канонические имена в контексте MX и NS записей описания зоны, "проброс" запросов на несуществующие корпоративные домены различным прикладным ПО.

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

Седьмая стандартная задача - это анализ запросов к вашему серверу на предмет его загруженности и безопасности. Оба этих вопроса тесно связаны. Чрезмерная загруженность сервера может сделать его "невидимым" в Интернет, что в свою очередь является в большинстве случаев основной целью злоумышленников.

Мы не претендуем на полноту предложенного выше списка. Тем не менее, на наш взгляд основные проблемы, на которые следует обратить внимание, в нем перечислены. Современные средства тестирования DNS позволяют тем или иным способом решить все задачи, порожденные этими проблемами.

Наиболее известными средствами тестирования работы системы DNS и серверов среди администраторов системы DNS и пользователей сети являются: nslookup, host и dig.

Nslookup является старшей из всех перечисленных средств тестирования DNS. Ее основное преимущество - наличие практически во всех операционных системах (В Windows 9х, ее, правда, нет, но на серверных платформах Microsoft nslookup присутствует). Программа работает в интерактивном и неинтерактивном режимах. Для ее применения, в прочем, как и для host с dig, нужно быть готовым к работе в командной строке.

Основной недостаток nslookup - невозможность работы с новыми возможностями серверов (ixfr, например). Однако, для исполнения основных функций администратора домена она вполне пригодна.

Про dig можно, наверное, сказать, что это основное средство отладки BIND. Программа поставляется в одном дистрибутиве с серверами BIND. Единственная программа из нашей тройки, которая продолжает развиваться и совершенствоваться. Однако, очевиден ее уклон сторону тестирования named. В отчетах много важной с точки зрения отладки ПО информации, в частности возможность контроля флагов заголовков DNS сообщений.

Host интересна своей направленностью на удовлетворение нужд администраторов зон, а не разработчиков серверов. В ней реализованы дополнительные возможности по составлению отчетов по зонам. RIPE, например, использует Host для сбора и опубликования статистики по зонам своей ответственности. К сожалению, с более свежую версию программы, чем версия от 2000 года в сети найти, видимо, не удастся. Во всяком случае, у нас это не получилось.

Существует еще несколько средств тестирования DNS для разных платформ, направленных на облегчение жизни администраторов, но все они менее популярны, чем nslookup, host и dig.

Типовые примеры описания зон и файлов конфигурации BIND

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

Архитектура "клиент-сервер", положенная в основу системы доменных имен заставляет сетевых администраторов решать задачи взаимодействия с DNS как со стороны обычных пользователей, так и с обратной стороны - точки зрения администраторов DNS.

Когда речь заходит об организации поиска информационных ресурсов по их доменному имени, то сетевой администратор должен обеспечить для своих пользователей быстрый поиск IP-адресов по доменным именам в "прямых зонах" и поиск доменных имен по IP-адресам в "обратных" зонах.

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

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

Вообще говоря, под "корпоративными хостами" мы понимаем некоторую группу хостов, которую обслуживает администратор DNS. Это могут быть хосты компании, вуза, министерства, отдела научно-исследовательского института и т.п. Эти хосты мы называем "корпоративными" по аналогии с "корпоративными доменами". Последнее словосочетание принято применять для доменов второго уровня, принадлежащим организациям.

Второй круг проблем возникает в том случае, когда сетевой администратор реально отвечает за сервер, который является авторитативным для зоны. Это означает, что мы имеем дело либо с master сервером, либо со slave сервером зоны.

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

Простейший переход от кэширующего сервера к master серверу зоны мы разберем в материале "Небольшой корпоративный домен в зоне ru". При этом мы постараемся указать на возможность повышения безопасности эксплуатации сервера.

Поддержка slave сервера еще проще, чем поддержка master. В этом случае не нужно самому прописывать информацию в файлы описания зоны. Зона просто скачивается с master сервера. Этот вариант настройки сервера мы рассмотрим в материале "Настройка slave сервера для корпоративного домена".

Кроме перечисленных случаев интерес представляют случай размещения зоны на двух сетях класса C (в нотации CIDR x.x.x.x/24) и размещение зоны на подсети класса C. Особенности работы с такого сорта доменами заключены в организации "обратных" зон. Этим вопросам будут посвящены материалы: "Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях типа /24" и "Делегирование обратных зон для подсетей сетей сети класса С (/24)"

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

Проблемы с вязанные с повышением безопасности, организацией "расщепленных" доменов, работа из-под firewall (защищенных сегментов сети), настройкой динамического обновления описания зон и уведомлений об этих изменениях мы рассмотри несколько позже.

Типы серверов доменных имен. Master, Slave, Cache, Stealth, Root.

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

Сразу оговоримся, что в данном материале речь не идет о серверах, как о программах, которые реализуют функцию сервера доменных имен, например named или сервер доменных имен Windows Server 2000. Мы будем рассматривать серверы, как процессы, которые должны выполнять определенные функции по обслуживанию DNS запросов.

В документах RFC-1034 и RFC-1035 выделяют несколько типов DNS-серверов. В соответствии с типами откликов на запрос к системе доменных имен серверы можно разделить на авторитативные (authoritative) и неавторитативные (non authoritative).

Ttl

в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается либо последним аргументом данных записи SOA (версии BIND до 8.2.), либо директивой управления $TTL. Запрет на кэширование SOA определен в RFC 1035.

Вообще говоря, данное жесткое ограничение (наличие 0 в поле ttl) было снято в 1997 году (RFC 2181). Связано это было с тем, что реально требование наличия нуля в поле ttl записи SOA нигде не использовалось и не проверялось. С тех пор записи SOA могут содержать значения в поле ttl.

Поле

Очень полезна данная запись в случае, когда нужно определять обратную зону для сети класса С (в нотации CIDR маскированы первые 24 бита), которая разбита провайдером на подсети, и эти подсети розданы различным клиентам (см. RFC 2317). Оставим саму проблему за кадром до того момента, когда нам действительно понадобится делегировать подобного рода обратные зоны, а здесь приведем только ту часть файла описания "обратной" зоны, в которой применяется директива управления $GENERATE:

$GENERATE 1-63 $.0.168.192.in-addr.arpa IN CNAME $.0-63.0.168.192.in-addr.arpa. 0-63.0.168.192.in-addr.arpa. IN NS ns.kyky.ru.

$GENERATE 65-127 $.0.168.192.in-addr.arpa IN CNAME $.64-128.0.168.192.in-addr.arpa. 64-128.0.168.192.in-addr.arpa. IN NS ns.corp.ru.

В данном случае $GENERATE используется для производства однотипных RR.

Следует отметить, что $GENERATE это не стандартная директива, а расширение директив управления пакета BIND.

Ttl (Time To Live)

- это поле определяет время, в секундах, в течение которого данная запись сохраняется в кэше. Максимальное значение поля TTL 4294967295. Ровно такое максимальное положительное число может быть задано при помощи 32 битов (RFC-1035, секция 6.1.3).

В реальной жизни все гораздо менее масштабно. Записи обычно хранятся в кэше часа или около того, что составляет 3600 секунд. Правда для записей корневой зоны TTL умолчания составляет 1 день или 86400 секунд (см. распечатку корневых серверов в материале "Типы серверов доменных имен. Master, Slave, Cache, Stealth, Root.".

Если это поле оставлено пустым, то по умолчанию принемается значение, указанное в параметре minimum поля данных (data) записи SOA для данной зоны(см. описание записи SOA).

Написав предыдущий абзац, мы остались в эпохе до 1998 года, когда вышло RFC-2308 (Отрицательное кэширование DNS запросов). Тем не менее, не стоит его вымарывать их своей памяти, т.к. до версии 8 BIND минимальное время TTL определял согласно RFC-1035, т.е. в записи SOA. Точнее говоря, это было не минимальное время хранения в кэше, а время умолчания.

RFC-2308 ввел два новых понятия: время негативного кэширования и директиву управления $TTL.

Негативное кэширование - это кэширование запросов, которые доставляют информацию о том, что установить соответствие между доменным именем и IP-адресом нельзя по разным причинам.

Если не использовать негативного кэширования, то локальный сервер доменных имен, который обслуживает рекурсивный запрос resolver, либо сам resolver, если он "умный", будут совершать от 2 до 3 попыток разрешить (установить соответствие между доменным именем и IP-адресом) доменное имя, как только какая-либо из прикладных программ, данное имя запросит. При чем повторяться это будет каждый раз, как только новый запрос поступит, т.к. система не помнит результатов предыдущего выполнения запроса.

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

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

Поле

Вспомогательный сервер (secondary, slave)

В документации по BIND описание master сервера доменных имен и slave сервера совпадают. Но методически правильнее их разнести, что здесь и сделано.

options { directory "/etc/namedb"; // Working directory pid-file "named.pid"; // Put pid file in working allow-query { any; }; // This is default recursion no; // Do not provide recursion service };

zone "." { type hint; file "root.hint"; }; zone "0.0.127.in-addr.arpa" { type master; file "0.0.127.in-addr.arpa"; notify no; };

zone "eng.example.com" { type slave; file "eng.example.com"; masters { 192.168.4.12;}; };

То, что мы имеет дело с вспомогательным сервером для зоны "eng.example.com" определено в соответствующей директиве "zone". В качестве типа сервера (type) указано значение "slave", что и определяет сервер как вспомогательный. В опции "masters" определяется список официальных серверов, с которых вспомогательный сервер может списывать зону в файл "eng.example.com". В данном случае указан только один - 192.168.4.12.

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

Запись Mail exchanger (MX). Электронная почта и DNS

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

Если просуммировать все записи описания ресурсов, которые предлагалось указывать в описании зоны, то посвященных электронной почте RR-ов (Resource Records) было бы большинство.

В реальной жизни (лучше, наверное, подошло бы слово "виртуальной") используется запись одного типа - MX (Mail exchanger - почтовый шлюз). Смысл использования этой записи заключается в том, чтобы определить хост, который отвечает за доставку почты в определенный домен или знает, как это делается.

Запись MX может быть определена как для всей зоны, так и для отдельно взятой машины. MX RR имеет следующий формат:

[name] [ttl] IN MX [prference] [host]

Поле name определяет имя машины или домена, на который может отправляться почта. Это может быть как полностью определенное имя, так и частичное имя машины. Поле ttl обычно оставляют пустым. В поле preference указывается приоритет почтового сервера, имя которого указано последним аргументом в поле данных MX-записи.

Прежде чем перейти к подробному обсуждению назначения и практики применения MX записей следует понять основные принципы построения обмена электронной почтой в Интернет.

В своих рассуждениях мы будем опираться на концепцию, которая изложена в RFC 2821. Данный документ заменил старожилов - RFC 821 и RFC 974.

RFC 821 определяло протокол доставки почты - SMTP, а второй документ - взаимодействие электронной почты с системой доменных имен. Новый документ обобщил опыт применения первых двух на практике (например, отменил требование проверки наличия WKS записи для хоста, указанного в качестве шлюза в MX записи, которое все равно никто не соблюдал) и прояснил некоторые недостаточно четко сформулированные требования.

Во-первых, следует остановиться на самом понятии почтового шлюза.
Наиболее распространенным в этом контексте были термин MTA (Mail Transfer Agent) и термин MUA (Mail User Agent). Данные термины применяли для того, чтобы подчеркнуть некоторое отличие MTA от почтового сервера, который являлся конечным получателем почты и от клиентского программного обеспечения (MUA), которое обеспечивало только "первую и последнюю мили" пути почтовго сообщения.

Сейчас предпочтение отдано терминологии "клиент-сервер" и термины МТА MUA следует употреблять с осторожностью.

Все дело в том, что ситуация в почтовой службе несколько изменилась. Раньше (во времена существования UUCP, которому посвящено не меньше места в старых RFC) наиболее распространенной процедурой доставки почты была многозвенная доставка с использованием большого числа промежуточных узлов. При этом почта передавалась из одних сетей в другие, в том числе, и с использованием сетей посредников.

При такой технологии работа электронной почты напоминала работу обычной почты, основанную на отделениях связи. Существовали и существуют до сих пор многочисленные узлы-шлюзы. С их списком можно ознакомиться по адресу http://www.faqs.org/faqs/mail/inter-network-guide/.

В настоящее время, когда доминирует SMTP, в понятие шлюза как бы расщепилось на relay (пересылка по SMTP) и gateway (шлюз в другую почтовую систему). В контексте DNS разницы между этими понятиями нет. MX запись указывает на любой хост, на который следует направлять почту, чтобы она попала в требуемый домен.

Рисунок.1. Схема доставки и отправки почты.

Кроме того, в почте от первых двух названных (relay и gateway) еще отличают хост, который, собственно, является хранителем почтовых ящиков. Локальная доставка писем адресатам.

Все попытки внедрить в обиход подобное разделение и для системы DNS пока ни к чему не привели. Записи типа MB (Mail Box) в описаниях зон Вы не найдете "днем с огнем, а ночью ощупью".

Поэтому в контексте системы DNS мы все почтовые хосты, для которых устанавливается запись MX, будем называть почтовыми шлюзами.

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

Ключевым элементом в почтовом сообщении являются адреса отправителя и получателя. Адреса принято записывать в виде:

local-part@domain

Нас с точки зрения DNS интересует только та часть, которая называется "domain". На самом деле, вовсе не обязательно, что domain представляет из себя правильное доменное имя. Просто название этой части адреса созвучно DNS доменам.

Все обмены данными между шлюзам в рамках интернет производятся по протоколу SMTP (Simple Mail Transfer Protocol). Наверное, каждый пользователь, а уж тем паче администратор, имеет опыт настройки программ чтения и отправки почтовых сообщений на работу с таким шлюзом или, как их еще называют, relay-ем.

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

Во-первых, в рамках SMTP-обмена в качестве доменных имен допускаются только полные доменные имена (fully-qualified domain names), которые можно разрешить при помощи поиска MX или A записей в системе DNS. Т.е. в поле domain почтового адреса должно быть имя, для которого есть MX или A запись. В принципе, допускаются и синонимы, т.е. имена для которых в DNS можно найти записи CNAME, перенаправляющие на MX или A записи. На самом деле многие шлюзы настроены таким образом, что CNAME записи игнорируются.

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

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

Если нет MX записей, но есть адресная запись, то делается попытка доставить почту по этому адресу. Если найден список MX записей, то адресная запись игнорируется.

Более того, если в последующем ни одна из MX записей не подойдет для отправки почты, то попытка доставить почту по IP-адресу, взятому из адресной записи, не будет предпринята (на самом деле эта опция может быть настроена в конкретном программном обеспечении обмена почтой).

Если шлюз нашел список MX записей, то он сортирует его в порядке возрастания значений поля preference. Записи с меньшим значением этого поля считаются более предпочтительными. Затем шлюз пытается установить SMTP соединение и отправить почту, перебирая MX записи в порядке выставленных предпочтений.

Если MX записи имеют одинаковые предпочтения, то на практике шлюз выбирает наиболее предпочтительную из них случайным образом (во всяком случае, так делают Sendmail и Postfix).

Как только почта успешно отправлена, перебор шлюзов-получателей прекращается.

Приведем пример использования записей MX в описании зоны:

$TTL 3600 $ORIGIN vega.ru. @ IN SOA vega-gw.vega.ru paul.kiae.su ( 101 ; serial number 86400 ; refresh within a day 3600 ; retry every hour 3888000 ; expire after 45 days 3600 ) ; negative caching IN NS vega-gw.vega.ru. IN NS ns.relarn.ru. IN NS polyn.net.kiae.su. IN A 194.226.43.1 IN MX 10 vega-gw.vega.ru. IN MX 20 ns.relarn.ru. IN MX 30 relay.relarn.ru. ; vega-gw IN A 194.226.43.1 IN MX 0 vega-gw IN MX 10 ns.relarn.ru. IN MX 20 relay.relarn.ru. ; www IN CNAME vega.ru.

В данном примере мы определили несколько записей типа MX для почтовой рассылки.

Записи в описании зоны, сразу после A-записи, следующей за записью SOA, определяют пути поступления почты на хост-тезку данного домена. Для получения почты по имени домена эта адресная запись не нужна. Ее используют для других интернет-сервисов, скажем для доступа к web-сайту домена не только по доменному имени www.vega.ru, но и по доменному имени vega.ru.

Самый высокий приоритет здесь имеет прямая отправка почты на шлюз vega-gw.vega.ru.

Если отправить почту на эту машину не удастся, то почтовый агент должен попробовать путь через почтовый сервер ns.relarn.ru . Если и этот путь окажется невозможным, то почту можно попытаться отправить на пересыльный пункт relay.relarn.ru . Такой порядок опроса почтовых серверов определяется полем preference - чем меньше значение поля, тем выше приоритет сервера в записи MX.

В нашем домене, который мы использует в качестве примера, большинство почтовых ящиков пользователей расположено на машине vega-gw.vega.ru. Для этой машины также указаны несколько записей MX. Наибольший приоритет среди них имеет запись с именем почтового сервера vega-gw. Обратите внимание на то, что данное имя не оканчивается точкой. Это значит, что оно расширяется именем текущей зоны. Все же другие имена серверов - это полностью определенные доменные имена (fully-qualified).

Одной из главных проблем пересылки почты является зацикливание при невозможности отправки непосредственно адресату. Представим ситуацию, когда хост vega-gw.vega.ru недоступен.

Тогда согласно процедуре, описанной выше, почта должна быть отправлена на ns.relarn.ru, он, в свою очередь, не может отправить почту на vega-gw.vega.ru. Себе он отправлять почту тоже не будет, поэтому отправит на relay.relarn.ru, а тот снова на ns.relarn.ru, и так по кругу.

На самом деле ничего подобного не произойдет, т.к. шлюзы обязаны исключать из списка MX записи, которые имеют больший или такой же приоритет, как и они сами. В нашем случае почта будет "отлеживаться" на ns.relarn.ru.

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

MX записи - это один из немногих случаев, где действительно имеет смысл применять wildcard в доменном имени. Если в описании зоны поместить запись вида:

*.domain.ru. IN MX 10 host.domain.ru.

то для любого хоста из зоны domain.ru, у которого не будет своих MX записей, почта будет отправляться на host.domain.ru, а почтовая программа-шлюз этого хоста сама разберется куда дальше посылать почту.

В настоящее время среди прочих коммерческих услуг достаточно популярной стала услуга перенаправления почты - mail forwarding. Ее идея заключается в том, что регистрируется домен с коротким легкозапоминающемся именем и почтовые адреса указываются относительно этого домена. При этом реальные почтовые ящики могут находиться где угодно.

Перенаправление почты осуществляется за счет добавления MX записи в описание зоны почтового домена, которая будет указывать на хост, который знает, как почту в этот домен доставлять.

Естественно, что на самом хосте соответствующим образом должен быть настроен и почтовый шлюз. Типичный пример можно найти в ru-rucenter (http://www.nic.ru/dns/service/no_primary.html)

И напоследок несколько цифр характеризующих проблему обмена электронной почтой с точки зрения DNS. Согласно отчету 2002 года компании men&mice в TLD com из 5000 обследованных доменов не имеют MX записей 18.68% зон. В эти зоны нельзя отправить почту. В 3.3% случаев МХ записи указывают на CNAME, т.е. на синонимы, что для некоторых почтовых программ недопустимо. В 4.16%-ах случаев почтовые серверы соответствующих доменов не работают с DNS правильно, т.е. согласно принятым спецификациям.

Запись "Name Server"(NS), проблема

Здесь мы обсуждаем вопросы применения записи описания ресурсов NS (Name Server). Подробно разбираем вопрос некорректного делегирования зон, а также алгоритм выбора наиболее подходящего авторитативного сервера для обслуживания запросов к зоне.

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

Кроме того, запись NS позволяет делегировать поддомены, поддерживая тем самым иерархию доменов системы доменных имен Internet. Для того, чтобы домен был виден в сети в зоне описания домена старшего уровня должна быть указана запись типа NS для этого поддомена. Формат записи NS можно записать в виде:

[domain][ttl] IN NS [server]

В поле domain указывается имя домена, для которого сервер, указанный последним аргументом записи NS, поддерживает описание зоны. Значение поля ttl обычно оставляют пустым, тем самым, заставляя named устанавливать значение по умолчанию (поле minimum из записи SOA для данной зоны в старых версиях BIND или значение директивы управления $TTL).

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

Записи NS указывают как на master, так и на slave серверы. Последние, обычно, принадлежат другим зонам, и для них следует указывать полное доменное имя сервера с указанием имени машины и имени зоны. Например, для сервера из домена polyn.kiae.su c именем ns следует писать полностью ns.polyn.kiae.su. Для того чтобы придерживаться какого-то единого стиля и во избежание ошибок, рекомендуется писать всегда полное имя сервера.

Какой либо разницы между master и slave в NS не указывается. Обычно primary master записывают первым, а резервные серверы указывают вслед за ним.

Приведем пример записи описывающей сервер доменных имен для поддомена:

$ORIGIN vega.ru. zone1 IN NS ns.zone1.vega.ru.

В данном примере в качестве первой строки используется команда $ORIGIN, которая определяет имя текущей зоны (см. материал "Файлы описания зоны. Директивы управления"). Здесь она введена только для того, чтобы определить текущую зону.

В поле имени зоны указано имя zone1 без точки на конце. В данном контексте это означает делегирование зоны в домене vega.ru, полное имя которой будет zone1.vega.ru.

В качестве имени сервера, который управляет делегированной зоной указано имя ns.zone1.vega.ru, т.е. полное имя машины в делегированном домене. В принципе, в данном случае можно было бы написать и по другому:

$ORIGIN vega.ru. zone1 IN NS ns.zone1

т.к. имя принадлежит текущему домену и может быть расширено его именем.

В этом месте, видимо, следует обратить внимание на тот факт, что для записи доменных имен и имен зон существуют не только синтаксические ограничения, о которых упоминалось в материале "Правила именования хостов", а также при описании записи SOA, но и численные ограничения.

Длина метки узла дерева доменных имен должна находится в пределах от 1 до 63 октетов (RFC 2181). Любопытно, что написано не "символов", а октетов, то бишь байтов.

При этом длина полного имени (Full Qualified Doman Name -FQDN) не должна превышать 255 октетов, включая разделители ( те самые символы ".", которые ставятся между именами меток узлов). Полное имя узла - это имя от узла до корня дерева доменных имен.

Таким образом, максимальное имя корпоративного домена в зоне ru (что-то типа "corporative-name.ru") не может быть больше 63 символов, а вместе с двумя точками и "ru" не должно превышать 67 символов.

Теперь вернемся к NS записям. NS-записи обычно следуют сразу за записью SOA в файле описания зоны и указывают на серверы, которые ответственны за эту зону:

$ ORIGIN ru. Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru.

В данном случае описана зона webstatistics.ru и для нее вслед за SOA указано два сервера доменных имен: ns.webstatistics.ru - primary master и ns4.nic.ru - slave.

Такого простого указания на серверы доменных имен зоны для нормальной работы недостаточно. Нужно еще знать IP-адреса этих серверов. Для slave его можно найти в зоне nic.ru, а вот для ns.webstatistics.ru нужно использовать "приклеенную" адресную запись (см. подробнее материал "Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.").

Рассмотрим еще одну причину использования NS-записей в описаниях зон - делегирование зоны.

До сих пор мы рассматривали NS запись только для объявления сервера доменных имен для той зоны, которую описываем, например, zone.ru:

@ IN SOA ns.zone.ru. hostmaster.zone.ru. ( 2002092602 1d 3h 4w 3h ) IN NS ns.zone.ru. IN NS ns.provider.ru.

Но это только часть функций NS записи. Теперь делегируем право ответственности за часть зоны другому администратору и выделяем в домене zone.ru зону subzone1. Этот факт мы должны отобразить в описании зоны zone.ru:

@ IN SOA ns.zone.ru. hostmaster.zone.ru. ( 2002092602 1d 3h 4w 3h ) IN NS ns.zone.ru. IN NS ns.provider.ru. ns IN A 192.168.0.1 ; subzone1 IN NS ns.subzone1.zone.ru. IN NS ns.zone.ru. ns.subzone1 IN A 192.168.1.1

В данном случае имя subzone1 будет расширено именем текущей зоны (zone.ru), т.к. оно не завершается символом ".", а текущим является zone.ru, которое берется из файла конфигурации named потому, что указан символ "@" в записи SOA описания зоны.

На то, что subzone1 - это имя поддомена, указывает запись NS, потому, как у нее первое поле принимает значение имени домена (зоны).

При этом для зоны subzone1.zone.ru определено два авторитативных сервера: ns.subzone1.zone.ru и ns.zone.ru. Теперь, если к нашему серверу обратятся за адресом хоста из subzone1.zone.ru, то отошлем их к другим серверам, которые ответственны за эту зону.

Фраза "отошлем к другим серверам" означает то, что наш сервер вернет запрашивающему его клиенту или серверу, который выполняет рекурсивный запрос, имена и, если в зоне они прописаны, IP-адреса серверов доменных имен, ответственных за зону, где находится хост с заданным клиентом именем или адресом.

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

ns.subzone1 IN A 192.168.1.1

Если внимательно присмотреться к описанию этого примера, то становится ясно, что наш сервер никуда никого отправлять не будет, т.к. он сам является авторитативным для зоны subzone1.zone.ru. Скорее всего, он является slave-ом, а ns.subzone1.zone.ru - это master.

Просто мы имеем еще один файл описания зоны, который копируем с ns.subzone1.zone.ru, и где находится описание зоны subzone1.zone.ru.

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

Теперь, когда понятна процедура делегирования зоны, вернемся к NS записям, описывающим серверы нашей зоны в нашем же описании зоны, а не там, где нам эту зону (нашу зону) делегировали.

С нашим сервером проблем не возникает. Мы сами его администрируем. А вот с администраторами серверов, которые (серверы) мы прописываем в зоне в качестве авторитативных, следует сначала договориться. Не нужно прописывать имена серверов "от балды". Эти серверы должны быть действительно slave для вашей зоны. Как правило, при регистрации домена проверяются все серверы, указанные в заявке.

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

BIND не проверяет соответствие серверов в родительской зоне и в зоне-потомке. Другое дело неправильное делегирование (lame delegation), когда сервер родительской зоны перенаправляет клиента к серверу, который не является авторитативным для зоны-потомка.

В нашем случае, например, сервер ns.zone.ru может быть не настроен в качестве slave для зоны subzone1.zone.ru. Тогда ряд запросов может быть отвергнут, что, конечно, плохо.

Еще раз подитожим, что под некорректным делегированием понимают:

наличие NS-записи, в которой указано имя сервера доменных имен, чей адрес невозможно найти; наличие NS-записи, в которой указано имя сервера доменных имен, не отвечающего на запросы; наличие NS-записи, в которой указано имя сервера доменных имен, негативно отвечающего на запросы.

На самом деле проблема некорректного делегирования достаточно серьезна. Так, например, Men&Mice в августе 2002 провела исследование 5000 случайно выбранных доменов в зоне com. Некорректное делегирование зоны было выявлено в 20% случаев. Это на один процент лучше, чем было в мае 2002 года, но все равно достаточно много. Любопытно, что в 14% случаев информация о делегировании зоны не совпадала с данными, указанными в самой зоне, а 17% случаев не удалось найти авторитативных серверов зоны.

Вообще говоря, проблема некорректного делегирования имеет решение, если сервер родительской зоны поддерживает механизм зон-заглушек (stub zone). Этот реализован в современных версиях BIND. Он позволяет серверу родительской зоны отслеживать изменения NS-записей делегированной зоны.

Для создания stub зоны следует в файл конфигурации named добавить:

zone "webstatistics.ru" { type stub; file "webstatistics.ru"; masters {144.206.192.60;}; }

В этом случае сервер, на котором организована stub зона будет срисовывать в соответствующий файл запись SOA и NS-записи описания зоны.

Пусть описание зоны будет иметь вид:

$ORIGIN ru. Webstatistics 3600 IN SOA webstatistics.ru. paul.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru.

IN A 144.206.192.60 $ORIGIN webstatistics.ru. ns 3600 IN A 144.206.192.60 $ORIGIN nic.ru. ns4 IN A 194.226.96.8 $ORIGIN webstatistics.ru. www 3 IN A 144.206.192.60 3 IN A 144.206.192.61 3 IN A 144.206.192.62 3 IN A 144.206.160.32

Содержание файла типа stub на для зоны webstatistics.ru будет иметь следующий вид:

; BIND version named 8.2.2-P5-NOESW Mon Mar 20 20:39:05 GMT 2000 ; BIND version root@monster.cdrom.com:/usr/obj/usr/src/libexec/named-xfer ; zone 'webstatistics.ru' first transfer ; from 144.206.192.60:53 (local 144.206.160.32) using AXFR at Mon Oct 7 19:31:1 ; 7 2002 $ORIGIN ru. Webstatistics 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru. $ORIGIN webstatistics.ru. ns 3600 IN A 144.206.192.60 ; Ignoring info about ns4.nic.ru, not in zone webstatistics.ru. ; $ORIGIN nic.ru. ; ns4 60575 IN A 194.226.96.8

Из этого примера хорошо видно, что в зону были скопированы записи SOA, NS и "приклеенные" адресные записи. При этом адресная запись для slave сервера была проигнорирована, т.к. она принадлежит другой зоне и в ней нет необходимости (подробнее см. материал "Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.").

На самом деле есть одна загвоздка, которая делает указанный выше метод не достаточно удобным. Дело в том, что серийный номер родительской зоны не изменяется и, следовательно, slave-ы родительской зоны об изменениях в делегировании ничего знать не будут, если на них не настроить поддержку stub зоны.

В документации по BIND версии 9 не рекомендовано использовать зоны-заглушки для вновь создаваемых зон. Разработчики BIND советуют просто строго следовать правилам делегирования зоны.

При делегировании зоны нужно четко отдавать себе отчет в том, что администраторы делегированного домена не обязаны сообщать нам адрес primary master, т.е. того сервера, на котором происходит реальное редактирование информации о зоне.

Они (администраторы) могут просто сообщить нам адреса своих slave серверов, которые тоже являются авторитативными для зоны. В этом случае мы будем иметь невидимый primary master сервер. Делается это, главным образом, из соображений безопасности.

На самом деле, остался не выясненным еще один вопрос, который тесно увязан с авторитативными серверами доменных имен. Это вопрос о порядке их опроса локальным сервером доменных имен, который выполняет рекурсивный запрос resolver-а.

На самом деле все достаточно просто. Когда сервер получает рекурсивный запрос, и в итоге опроса серверов доменных имен в конце концов получает список авторитативных серверов требуемой зоны, он для каждого из них включает метрику RRT (round trip time). Эта метрика в миллисекундах измеряет время отклика от каждого из серверов. В начальный момент времени, т.е. при первом запросе, она устанавливается в 0.

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

Наиболее эффективен этот алгоритм при работе с корневыми серверами,т.к. к ним приходится обращаться постоянно.

Следует заметить, что серверы, отличные от BIND могу реализовывать другие алгоритмы выбора сервера, т.к. в спецификации DNS этот вопрос не прояснен.

Любопытно, что измерения RTT для корневых серверов проведенные в 2000 году, хорошо совпали с RTT команды ping. Не обобщая этот вывод на все случаи жизни, тем не менее можно сказать, что доступность DNS сервера можно оценивать по скорости отклика ping.

Вообще говоря, описанный алгоритм выбора аторитативного сервера на основе RTT не догма и его эффективность постоянно подвергается оценке. Основной вопрос, на который хотят получить ответ службы поддержки корневых серверов- это почему основная нагрузка падает на A сервер, в то время как ближайший к нему M сервер имеет нагрузку почти на четверть меньшую.

Запись назначения синонима каноническому

Здесь рассматриваются особенности применения синонимов доменных имен, которые задаются записью описания ресурсов CNAME. Разбираются основные ошибки при комбинировании записи определения синонимов с записями MX и NS.

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

Запись CNAME больше всего подходит для точки начала и окончания, т.к. больше всего ошибок при настройке описания зон связано с применением этой записи в сочетании с другими записями описания зоны.

Запись CNAME определяет синонимы для реального (канонического) доменного имени машины, которое определено в записи типа A. Имя в записи типа A называют каноническим именем машины. Формат записи CNAME можно определить следующим образом:

[nickname] [ttl] IN CNAME [host]

Поле nickname определяет синоним для канонического имени, которое задается в поле host.

Запись CNAME чаще всего используется для определения имен информационных сервисов Internet, которые установлены на хосте. Так следующий пример определяет синонимы, для компьютера, на котором установлены серверы протоколов http и gopher:

$ORIGIN polyn.kiae.su. olga IN A 144.206.192.2 www IN CNAME olga.polyn.kiae.su. gopher IN CNAME olga.polyn.kiae.su.

Директива управления $ORIGIN введена здесь только для определения текущего имени зоны. Две записи типа CNAME позволяют организовать доступ к серверам, используя имена, характерные для соответствующих Интернет-сервисов.

Именно такие синонимы и используются в описаниях зон при обращении к таким системам как Yahoo(www.yahoo.com) или Altavista (www.altavista.digital.com).

Ниже приведен пример обращения к www.netscape.com:

> www.netscape.com Server: IRIS.polyn.kiae.su Address: 144.206.192.10

;; res_nmkquery(QUERY, www.netscape.com, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 12635, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 5, authority records = 3, additional = 3

QUESTIONS: www.netscape.com, type = A, class = IN ANSWERS: -> www.netscape.com canonical name = netscape.com ttl = 900 (15M) -> netscape.com internet address = 64.12.180.19 ttl = 900 (15M) -> netscape.com internet address = 64.12.180.22 ttl = 900 (15M) -> netscape.com internet address = 64.12.151.211 ttl = 900 (15M) -> netscape.com internet address = 64.12.151.215 ttl = 900 (15M) AUTHORITY RECORDS: -> netscape.com nameserver = ns.netscape.com ttl = 86400 (1D) -> netscape.com nameserver = ns1.netscape.com ttl = 86400 (1D) -> netscape.com nameserver = ns2.netscape.com ttl = 86400 (1D) ADDITIONAL RECORDS: -> ns.netscape.com internet address = 198.95.251.10 ttl = 3600 (1H) -> ns1.netscape.com internet address = 149.174.213.7 ttl = 3600 (1H) -> ns2.netscape.com internet address = 207.200.73.80 ttl = 3600 (1H)

------------ Name: netscape.com Addresses: 64.12.180.19, 64.12.180.22, 64.12.151.211, 64.12.151.215 Aliases: www.netscape.com

>

Из отчета nslookup видно, что www.netscape.com является синонимом netscape.com, которая, в свою очередь, имеет несколько адресных записей. В авторитативной секции отклика указаны доменные имена серверов зоны netscape.com, а в дополнительной секции их IP-адреса.

Правда, при обращении к серверу протокола http, который является базовым для системы World Wide Web, изменение имени машины, с которой осуществляют обслуживание, может быть вызвано многими причинами: перенаправлением запроса на другой сервер, использование виртуального сервера и т.п.

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

На самом деле, применение записей CNAME строго регламентировано в RFC 1034 и RFC 1912. Смысл применения CNAME - назначение синонима для канонического имени. Описание ресурсов для канонического имени и для синонима должны совпадать.

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

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

Администратору зоны следует понимать, как DNS работает с CNAME записями описания зоны. Поиск CNAME осуществляется только в том случае, если запросы другого типа, скажем поиск адресной записи, не дали положительного отклика. Т.е. сервер получает запрос к своей зоне на адресную запись; он не находит такой записи, но в описании зоны есть CNAME запись, которая соответствует запрашиваемому доменному имени; сервер на запрос возвращает эту запись и адресную запись, если последняя находится в описании этой же зоны. Если же CNAME ссылается на каноническое имя из другой зоны, то в отклике будет только CNAME.

Вот часть отчета nslookup, где указан запрос и ответ на него без секции данных секции авторитативности отклика сервера и дополнительной секции:

------------ Got answer: HEADER: opcode = QUERY, id = 51763, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 2, authority records = 2, additional = 2

QUESTIONS: user.webstatistics.ru, type = A, class = IN ANSWERS: -> user.webstatistics.ru canonical name = host.webstatistics.ru ttl = 3 (3S) -> host.webstatistics.ru internet address = 144.206.192.63 ttl = 3 (3S)

Из этого отчета следует, что мы искали адресную запись для user.webstatistics.ru, но ее в описании зоны нет, поэтому сервер нашел CNAME и адрес для канонического имени синонима.

При этом в RFC 1034 есть строгое указание, что если CNAME будет указывать не на каноническое имя, а опять на синоним, в этом случае сервер должен вернуть негативный отклик, а не CNAME. При появлении такой цепочки в одной зоне определить цепочку можно, но при наличии CNAME цепочки через границы зон выявить ее практически невозможно.

Последнее проверить очень трудно, т.к.

клиент при поиске в поле типа записи запроса укажет тип A (адресная запись). Новый сервер не будет знать о результатах предыдущего поиска и снова будет при отрицательном результате искать CNAME.

Вот пример из той же зоны, что и раньше, но мы в зоне реализовали цепочку CNAME:

;; res_nmkquery(QUERY, user1.webstatistics.ru, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 47112, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 3, authority records = 2, additional = 2

QUESTIONS: user1.webstatistics.ru, type = A, class = IN ANSWERS: -> user1.webstatistics.ru canonical name = user.webstatistics.ru ttl = 3 (3S) -> user.webstatistics.ru canonical name = host.webstatistics.ru ttl = 3 (3S) -> host.webstatistics.ru internet address = 144.206.192.63 ttl = 3 (3S) AUTHORITY RECORDS: -> webstatistics.ru nameserver = ns.webstatistics.ru ttl = 3600 (1H) -> webstatistics.ru nameserver = ns4.nic.ru ttl = 3600 (1H) ADDITIONAL RECORDS: -> ns.webstatistics.ru internet address = 144.206.192.60 ttl = 3600 (1H) -> ns4.nic.ru internet address = 194.226.96.8 ttl = 19465 (5h24m25s)

------------ Name: host.webstatistics.ru Address: 144.206.192.63 Aliases: user1.webstatistics.ru, user.webstatistics.ru

Сервер (BIND версии 9) вернул нам правильный IP-адрес, перебрав цепочку CNAME.

На самом деле многие "глупые"(stub) клиенты не умеют работать с цепочками CNAME, и по это причине информационный ресурс, к которому обращаются по имени-синониму, будет не доступен.

Таким образом, не смотря на то, что в спецификации цепочки синонимов запрещены явным образом, в реальной жизни они могут появляться и появляются.

Наш пример показывает цепочку в одной зоне, но гораздо хуже межзонные цепочки. Межзонная цепочка CNAME плоха тем, что не отслеживает исчезновение адресной записи в другой зоне, за которую сервер, содержащий в своей зоне CNAME, не отвечает. Как итог - появление "подвешенных" CNAME записей.

Теперь вернемся к вопросу о том, что для доменного имени, которое является синонимом, может существовать только одна запись описания ресурса и эта запись - CNAME. Что происходит, когда это правило нарушается?

Первая распространенная ошибка, на которую указывают и все RFC и FAQ - использование CNAME в совокупности с NS записями. Рассмотрим пример (RFC 1912):

podunk.xx. IN NS ns1 IN NS ns2 IN CNAME mary mary IN A 1.2.3.4

В данном случае для домена Podunk.xx. определено два сервера доменных имен ns1 и ns2, но одновременно указано, что Podunk.xx. - это синоним для канонического имени mary. Mary, ns1 и ns2 - это не полные имена. В нашем случае данное обстоятельство значения не имеет. BIND, встретив CNAME, обе записи NS проигнорирует, т.к. будет следовать соответствующим стандартам и рекомендациям.

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

Все правильно, если NS записи будут загружены в память сервером доменных имен при его запуске. Но сервер проверяет при своем запуске корректность описания зоны. Он просто проигнорирует все записи, отличные от CNAME, которые содержат синоним в первом поле записи описания ресурсов.

Вот пример сообщения сервера для этого случая (BIND 9):

Oct 14 12:55:51 generate named[136]: dns_master_load: webstatistics.ru:21: zone. webstatistics.ru: CNAME and other data Oct 14 12:55:51 generate named[136]: zone webstatistics.ru/IN: loading master fi le webstatistics.ru: CNAME and other data

А вот фрагмент описания зоны, на которую он ругается:

zone IN NS ns.wenstatistics.ru. IN CNAME subzone subzone IN A 144.206.192.61

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

На самом деле ситуация " CNAME на NS" часто встречается в том случае, когда хотят определить IP адрес для доменного имени зоны. Если быть более точным, то администратор хочет некоторому хосту в зоне присвоить то же имя, что и всему домену. Например, это нужно для обеспечения доступа к веб-серверу по именам www.kyky.ru и kyky.ru. В этом случае описание вида:

$TTL 3600 @ IN SOA ns.kyky.ru hostmaster.kyky.ru ( 20021013 3h 30m 30d 3600 ) IN NS ns.kyky.ru. IN NS ns.provider.ru. IN CNAME server.kyky.ru. server IN A 192.168.0.1 www IN CNAME server.kyky.ru. ns IN CNAME server.kyky.ru.

будет ошибочным. Мы потеряем не только NS записи зоны kyky.ru, но и вообще все записи этой зоны. Правильным был бы следующий вариант:

$TTL 3600 @ IN SOA ns.kyky.ru hostmaster.kyky.ru ( 20021013 3h 30m 30d 3600 ) IN NS ns.kyky.ru. IN NS ns.provider.ru. IN A 192.168.0.1 server IN A 192.168.0.1 ns IN A 192.168.0.1 www IN CNAME kyky.ru.

В принципе, вместо "kyky.ru." в CNAME можно было бы указать и символ @.

Раз уж мы заговорили о символе "@", то следует заметить, что этот символ в поле nickname применяться не должен, т.к., фактически, тем самым утверждается, что текущее имя зоны - это синоним другого имени, и, следовательно, описание этой зоны следует проигнорировать.

Скорее всего, идея об использовании символа "@" в CNAME возникла при желании назначить имя зоны конкретному хосту, который имеет IP-адрес. Движение мысли в этом случае понятно: хост - это синоним зоны, поэтому мы и назначаем зоне IP-адрес через имя хоста. Если вдуматься, то такая логика неверна. Хост и домен - это совершенно разные понятия. Если вы хотите хосту, а точнее IP-адресу поставить в соответствие еще одно имя, то делать это следует посредством адресной записи, как в приведенном выше примере. При этом совершенно не имеет значения тот факт, что назначаемое имя - это имя зоны.

На самом деле, при исправлении описания зоны мы поправили еще одну запись. В первоначальном варианте имя ns.kyky.ru является синонимом для server.kyky.ru.

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

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

Косвенно понятно, почему введен запрет. В конце концов, число серверов корневой зоны ограничено числом 13 по одной простой причине - размеру пакета UDP. На самом деле цепочки без конца и края также упрутся в то же ограничение, ведь в пакете нужно передавать и CNAME-ы и IP-адрес. Если изменять логику обработки запросов и заставлять клиента итеративно обращаться к серверу по CNAME цепочке, то где предел такого цикла обращений.

На самом деле есть еще одна причина запрета на использование CNAME для NS и MX, но прежде, чем ее назвать и обсудить, мы рассмотрим проблемы, связанные с совместным использованием MX и CNAME.

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

Ошибки совместного применения CNAME и MX заключается в том, что в записи MX синоним используют как в первом поле MX, так и в последнем поле MX. Ни первое, ни второе делать не следует.

Первый вариант:

$ORIGIN kyky.ru @ IN A 192.168.0.2 kuku IN CNAME kyky.ru. IN MX 10 kyky.ru.

В данном случае, мы хотим отправлять почту на kuku.kyky.ru через kyky.ru. Правило запрета существования других записей описания ресурса для синонима кроме единственной CNAME записи, которая этот синоним и вводит, заставляет сервер проигнорировать MX.

Правильным бы было:

$ORIGIN kyky.ru @ IN A 192.168.0.2 IN MX 10 kyky.ru. kuku IN CNAME kyky.ru.

В данном случае, если почта отправляется на kuku.kyky.ru, то по CNAME сервер доменных имен возвращает kyky.ru адресную запись для kyky.ru.

Почтовый клиент соединяется с этим IP-адресом и отправляет на него почту. Другое дело настройки почтового шлюза на kyky.ru. Если он не распознает имя kuku.kyky.ru как свое собственное, либо, если у него нет правил пересылки для kuku.kyky.ru, то возникнут проблемы с доставкой почты, но это уже не проблема DNS.

Теперь другой вариант. Синоним используется в последнем поле записи MX:

$ORIGIN kyky.ru @ IN A 192.168.0.2 IN MX 10 kuku.kyky.ru. kuku IN CNAME kyky.ru.

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

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

Следовательно, клиент, который попадает при поиске MX или NS на синоним Должен инициировать дополнительный запрос адресной записи. Особенность почтовых систем такова, что они такого запроса в большинстве случаев не инициируют. Как следствие - почта не может быть доставлена, если речь идет о MX записи.

Вот пример с записью NS:

> set debug > set q=ns > webstatistics.ru. Server: [144.206.192.60] Address: 144.206.192.60

;; res_nmkquery(QUERY, webstatistics.ru, IN, NS) ------------ Got answer: HEADER: opcode = QUERY, id = 41793, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 2, authority records = 0, additional = 1

QUESTIONS: webstatistics.ru, type = NS, class = IN ANSWERS: -> webstatistics.ru nameserver = ns.webstatistics.ru ttl = 3600 (1H) -> webstatistics.ru nameserver = ns4.nic.ru ttl = 3600 (1H) ADDITIONAL RECORDS: -> ns4.nic.ru internet address = 194.226.96.8 ttl = 86297 (23h58m17s)

------------ webstatistics.ru nameserver = ns.webstatistics.ru ttl = 3600 (1H) webstatistics.ru nameserver = ns4.nic.ru ttl = 3600 (1H) ns4.nic.ru internet address = 194.226.96.8 ttl = 86297 (23h58m17s) >

Мы запрашиваем NS для зоны webstatistics.ru. В качестве ответа получаем доменные имена серверов доменных имен, но ns.webstatistics.ru - это синоним для webstatistics.ru, поэтому его адресной записи в дополнительной секции отклика сервера доменных имен нет. Ниже представлен пример описания этой зоны:

$ORIGIN ru. webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru. IN A 144.206.192.60 $ORIGIN webstatistics.ru. ns IN CNAME @ $ORIGIN nic.ru. ns4 IN A 194.226.96.8

Любопытно, что при запуске BIND 9-ой версии не сообщил о некорректном применении CNAME.

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

На самом деле ошибка может проистекать из-за обычной невнимательности администратора.

Приведем пример правильного и неправильного использования записи CNAME:

$ORIGIN polyn.net.kiae.su. olga IN A 144.206.192.2 IN MX 0 olga IN MX 10 ns.polyn.kiae.su. www IN CNAME olga.polyn.kiae.su. gopher IN CNAME olga.polyn.kiae.su.

В данном случае записи типа CNAME указаны правильно, т.к. не мешают переадресации почты на машину olga.polyn.kiae.su. Но если их поменять местами с записями типа MX, то скорее всего почта работать не будет:

$ORIGIN polyn.net.kiae.su. olga IN A 144.206.192.2 www IN CNAME olga.polyn.kiae.su. gopher IN CNAME olga.polyn.kiae.su. IN MX 0 olga IN MX 10 ns.polyn.kiae.su.

В данном случае можно предположить, что при редактировании зоны администратор просто неаккуратно скопировал блоки записей. Результат - неправильное применение CNAME.

Теперь от грустного - ошибок, перейдем к особенностям применения CNAME. Случай, когда CNAME используется для простого определения синонимов, мы уже рассматривали.

Ниже приведем пример описанного только что случая:

$ORIGIN ru. Webstatistics 3600 IN SOA webstatistics.ru. paul.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru. IN A 144.206.192.60 $ORIGIN webstatistics.ru. ns 3600 IN A 144.206.192.60 $ORIGIN nic.ru. ns4 IN A 194.226.96.8 $ORIGIN webstatistics.ru. www 3 IN A 144.206.192.60 www 3 IN A 144.206.192.61 www 3 IN A 144.206.192.62 www 3 IN A 144.206.160.32 www1 IN CNAME ns.webstatistics.ru. www1 IN CNAME www

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

Если теперь обратиться за IP-адресом www1.webstatistics.ru, то мы получим следующее (тестирование программой nslookup):

> set debug > www1.webstatistics.ru. Server: [144.206.192.60] Address: 144.206.192.60

;; res_nmkquery(QUERY, www1.webstatistics.ru, IN, A) ------------ Got answer: HEADER: opcode = QUERY, id = 33822, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 5, authority records = 2, additional = 2

QUESTIONS: www1.webstatistics.ru, type = A, class = IN ANSWERS: -> www1.webstatistics.ru canonical name = www.webstatistics.ru ttl = 3 (3S) -> www.webstatistics.ru internet address = 144.206.192.60 ttl = 3 (3S) -> www.webstatistics.ru internet address = 144.206.192.61 ttl = 3 (3S) -> www.webstatistics.ru internet address = 144.206.192.62 ttl = 3 (3S) -> www.webstatistics.ru internet address = 144.206.160.32 ttl = 3 (3S) AUTHORITY RECORDS: -> webstatistics.ru nameserver = ns.webstatistics.ru ttl = 3600 (1H) -> webstatistics.ru nameserver = ns4.nic.ru ttl = 3600 (1H) ADDITIONAL RECORDS: -> ns.webstatistics.ru internet address = 144.206.192.60 ttl = 3600 (1H) -> ns4.nic.ru internet address = 194.226.96.8 ttl = 79606 (22h6m46s)

------------ Name: www.webstatistics.ru Addresses: 144.206.192.60, 144.206.192.61, 144.206.192.62, 144.206.160.32 Aliases: www1.webstatistics.ru

>

На запрос адреса мы в основной секции отклика получаем CNAME и все адресные записи, в авторитативной секции получаем доменные имена серверов зоны (записи NS), а в дополнительной секции IP-адреса этих серверов доменных имен.

И в заключении о реальном масштабе ошибок, связанных с применением CNAME в системе доменных имен. Согласно исследованиям компании Men & Mice проведенным на 5000 случайно выбранных зонах домена com в августе 2002 года в 3.3%-ах случаев была зафиксирована ссылка в MX записи на синоним, т.е. неправильное совместное применение CNAME и MX.

Запись "Start Of Authority"

В данном материале мы обсудим одну из самых важных записей описания ресурсов "Start of Authority"(SOA). Именно эта запись определяет ту зону, к которой относятся все описания ресурсов - прочие Resource Records.

Описание зоны по традиции начинают с записи SOA (Start Of Authority). На самом деле, после 1998 года, когда появился документ RFC 2308, описание зоны начинают с директивы управления $TTL, которая задает время хранения соответствий в кэше resolver или сервера доменных имен.

Запись SOA отмечает начало описания зоны. Обычно, это первая запись описания ресурсов (Resource Record - RR). Настоятельно рекомендуется наличие одной и только одной записи типа SOA в каждом файле описания зоны, который указан в записи primary файла named.boot или в директиве zone файла named.conf.

Формат записи SOA можно представить как:

[zone] [ttl] IN SOA origin contact ( serial refresh retry expire minimum)

В этой записи каждое из полей обозначает следующее:

Поле

Записи типа "Pointer". Домен IN-ADDR.ARPA. Делегирование "обратных" зон. Инверсные запросы.

В этом материале мы рассмотрим, как решается в DNS задача поиска доменного имени по IP-адресу, что из себя представляет загадочный домен IN-ADDR.ARPA, какие проблемы возникают при делегировании "обратных" зон.

Задача поиска доменного имени по IP-адресу является обратной к прямой задаче - поиску IP-адреса по доменному имени. Как было рассмотрено в материале "Адресная запись "Address"…" прямая задача решается в DNS при помощи записей типа A (Address). Обратная же задача решается при помощи записей-указателей типа PTR (Pointer), которые совместно с записями SOA и NS составляют описание так называемой "обратной" зоны.

На самом деле в DNS решение задачи поиска доменного имени по IP-адресу несколько необычно. Казалось бы, что для решения этой задачи можно использовать описание "прямой" зоны. В ней ведь вся информация есть!

На самом деле решать "обратную" задачу по "прямой" зоне неудобно. Поиск сведется к полному перебору всех зон, т.к. удобного аппарата рефералов (отсылок по NS записям) для IP-адресов в прямых зонах нет.

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

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

Вот здесь и возникает довольно логичное и простое решение, которое позволяет использовать стандартный механизм поиска доменного имени для решения "обратной" задачи, - специальный домен, структура которого совпадает со структурой IP-адресов. Называется этот домен IN-ADDR.ARPA.

Сначала немного истории. В то время когда затевалась система доменных имен (примерно 1983 год - год выхода RFC 882 и 883) под Internet подразумевалась сеть ARPA, а кроме нее еще обсуждалась возможность построения единого адресного пространства с CSNET.
По этой причине кроме класса записей описания ресурсов IN - INTERNET (в то время ARPA) был еще класс описания ресурсов CS - CSNET (Computer Science Network).

В рамках этой концепции в сети ARPA вводился домен для адресов интернет (IN-ADDR - Internet ADDRess). При этом отдельно оговаривалось, что для других сетей алгоритм поиска доменного имени по IP-адресу может отличаться от того, который предложен для адресного пространства сети ARPA.

При этом доменные адреса в ARPA оканчивались словом "ARPA", вот пример из RFC 883:

.. 9999999 IN NS B.ISI.ARPA 9999999 CS NS UDEL.CSNET B.ISI.ARPA 9999999 IN A 10.3.0.52 UDEL.CSNET 9999999 CS A 302-555-0000

В нем мы видим, что у записей класса IN доменное имя оканчивается на ARPA, а у всех записей класса CS - на CSNET. Таким образом домен IN-ADDR был доменном верхнего уровня в рамках Internet (ARPA) в то время.

Сейчас уже нет ни CSNET, ни более поздних CH (CHAOS) и HS(Hesiod), которые можно найти в спецификации RFC 1035. Была реорганизована и исчезла ARPA. Но задуманный для адресного пространства ARPA домен IN-ADDR.ARPA остался.

На самом деле, в апреле 2000 года между DARPA (бывшей ARPA) и ICAAN было заключено соглашение о том, что домен верхнего уровня (TLD) ARPA будет использоваться для целей поддержки инфраструктуры Интернет.

Кроме того, само слово "ARPA" следует расшифровывать как "Address and Routing Parameter Area Domain (ARPA)", и не следует его ассоциировать с сетью ARPANET.

Основное назначение домена ARPA - обеспечивать отображение численных величин, определяемых протоколами межсетевого обмена, в пространство имен.

Делегирование поддоменов в домене ARPA возложено на IAB (Internet Architecture Board). В настоящее время в ARPA выделено три поддомена:

in-addr.arpa для отображения IP-адресов IPv4 в пространство доменных имен; ip6.arpa для отображения IP-адресов IPv6 в пространство доменных имен; е164.arpa для отображения телефонных номеров формата Е.164.

Сама зона ARPA поддерживается корневыми серверами и серверами TLD зон, хотя в соответствии с рекомендациями RFC 2870 для ARPA желательно выделение отдельных серверов.

Имена в домене IN-ADDR. ARPA образуют иерархию цифр, которые соответствуют IP-адресам. Правда, записываются эти имена в обратном порядке относительно написания IP-адреса.

Например, машина vega-gw.vega.ru, которая имеет адрес 194.226.43.1 должна быть описана в домене in-addr.arpa как 1.43.226.194.in-addr.arpa, т.е. адрес записывается в обратном порядке.

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

Рис.1. Пример структуры части домена in-addr.arpa

Как видно из рисунка, в данном случае не играет ни какой роли тип сети или разбиение на подсети. Согласно правилам описания доменов и зон в этих доменах, разделителем в имени, который определяет подчиненное значение зоны в домене, является только символ ".".

Когда мы написали, что разбиение на сети и подсети не имеет в данном случае никакого значения, мы имели в виду, только то, что для поиска доменного имени имеет значение только иерархия имен, доменов и хостов.

Однако на самом деле сама идея инверсной записи IP-адреса опирается на принципы построения этого адреса. Понятно, что первая группа цифр, ближайших к корню IN-ADDR.ARPA, задает номер сети, а остальные номер хоста. Принимая во внимание тот факт, что первоначально при создании доменной адресации в ARPA речь шла о сетях класса A (первый байт-октет определяет номер сети), то первая цифра в доменном имени в зоне IN-ADDR.ARPA - это номер сети, а все последующие - это номер хоста:

1.0.0.10.IN-ADDR.ARPA

Пример определяет первый хост в 10-ой сети.

Поиск этого адреса занял бы поиск сервера, ответственного за 10.IN-ADDR.ARPA, а тот бы ответил именем соответствующим адресу хоста.

В настоящее время, когда адреса раздаются, главным образом, из сетей класса C, и сама классификация сетей подменена спецификацией CIDR, цепочка обращений к серверам доменных имен значительно длиннее, но тем не менее, работает она также исправно, как и вся система DNS.

Теперь, прежде чем обсуждать проблемы поиска доменных имен в IN-ADDR.ARPA, необходимо вернуться к формату описания зон этого домена, которые принято называть "обратными".

Обратная зона состоит, главным образом из записей типа "Pointer" или PTR-записей. Формат записи имеет следующий вид:

[name][ttl] IN PTR [host]

Поле имя задает номер. Это, как уже обсуждалось, не реальный IP-адрес машыны, а имя в специальном домене in-addr.arpa или в одной из его зон.Приведем пример PTR записи:

$ORIGIN 43.226.194.in-addr.arpa. 1 IN PTR vega-gw.vega.ru.

По всей видимости провайдер выделили организации сетку класса С 194.226.43.0 (В нотации CIDR 194.226.43.0/24). При этом организации было также делегировано право ведения "обратной" зоны 43.226.194.in-addr.arpa. Вот в этой зоне администратор зоны и начал описывать "обратные" соответствия.

Следует признать, что соответствие обратных зон сетям - это общая практика описания "обратных" зон. Здесь точно также надо делегировать зоны из "обратного" домена. А делается это, как правило, на основе разбиения сети на подсети или сети.

В качестве примера для нашей учебной зоны в файле named.boot (BIND 4 или named.conf для BIND 8 - 9) определена "обратная" зона 43.226.194.in-addr.arpa. Ее описание будет выглядеть примерно так:

$TTL 3600 @ IN SOA vega-gw.vega.ru hostmaster.vega.ru ( 101 ; serial number 86400 ; refresh within a day 3600 ; retry every hour 3888000 ; expire after 45 days 3600 ) ; negative caching IN NS vega-gw.vega.ru. IN NS ns.relarn.ru. ; 1 IN PTR vega-gw.vega.ru. 4 IN PTR dos1.vega.ru. 5 IN PTR dos2.vega.ru 2 IN PTR zone1-gw.zone1.vega.ru. 3 IN PTR zone2-gw.zone2.vega.ru.

Из этого примера видно, что для обратной зоны указаны те же записи описания зоны, что и для "прямой". Кроме того, обратную зону вовсе не обязательно разбивать в соответствии с разделением прямой зоны на другие зоны. Речь в данном случае идет о зонах zone1 и zone2. С точки зрения домена in-addr.apra все машины принадлежат одной зоне - 43.226.194.in-addr.arpa.

Другое дело машина с IP-адресом 127.0.0.1 (localhost). С точки зрения домена in-addr. arpa она принадлежит другой ветке иерархии, отличной от той, которой принадлежат все остальные хосты. Поэтому для домена 127.in-addr.arpa на любой машине есть отдельный файл обратной зоны, хотя localhost, которому соответствует этот IP-адрес, обычно описывается в прямой зоне домена вместе с другими хостами. Вот пример описания этой зоны:

; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90 ; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 ; 15:31:40 peter Exp $ ; ; This file is automatically edited by the `make-localhost' script in ; the /etc/namedb directory. ; $TTL 3600 @ IN SOA generate.polyn.kiae.su. root.generate.polyn.kiae.su. ( 00000001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS generate.polyn.kiae.su. 1 IN PTR localhost.polyn.kiae.su. >

Как следует из комментария этого файла для его генерации можно использовать специальный sh-скрипт make-localhost, который входит в комплект поставки BIND. Он берет в качестве основы файл прототипа PROTO.localhost.rev подставляет в него имя хоста и имя домена.

Любопытно, что вместо пользователя hostmaster, что рекомендовано в RFC2142, в данном случае указывается пользователь root. Оно и понятно. Пользователя hostmaster может и не быть, ведь не все читают все подряд RFC, а пользователь root есть обязательно. Тем более, что это скорее всего и есть администратор локального сервера доменных имен.

Следует при этом помнить, что в файле конфигурации named.conf должен быть блок, который указывает на эту "обратную" зону:

zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; };

На самом деле мы опустили один интересный вопрос, а как прямой IP-адрес формата IPv4 преобразуется в доменное имя, которое имеет инверсную запись цифр.

Эти функции возложены на resolver. Resolver преобразует 32-битовый адрес в текстовую строку, размещая октеты в обратном порядке, разделяя их символами ".".

К полученному имени resolver через разделитель "." добавляет суфикс "in-addr.arpa". После этого формирует PTR запрос к системе доменных имен.

Вопросы делегирования зон в IN-ADDR.ARPA не столь просты, как может показаться на первый взгляд. Эта проблема тесно связана с получением пулов IP-адресов. Кроме получения адреса, нужно еще получить право на ведение обратного домена, соответствующего вашему адресному пулу.

На самом деле, никто кроме владельца адресного пула не знает, как распределено адресное пространство. Отдать кому-то ведение "обратной" зоны - это значит, во-первых, не обеспечить оперативность управления этой зоной, если только нет средств удаленного управления, как, например, в nic.ru, а, во-вторых, такая услуга стоит денег. По этим причинам обратную зону лучше вести самим.

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

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

Прежде всего, следует знать, что первоначально все адреса, которые мы используем в RuNet, получают RIPE Network Coordination Centre (RIPE - это Reseaux IP Europeens), который является одним из трех региональных интернет регистраторов поддерживающих глобальную инфраструктуру Интернет.

Из предыдущего абзаца важно только то, что все блоки адресов в нотации CIDR xxxx.xxxx.xxxx.xxxx/16 и xxxx.xxxx.xxxx.xxxx/24 выдаются этой организацией локальным интернет регистраторам (Local Internet Registres - LIR). А вот уж они и распределяют эти адреса между своими клиентами.

В обычной классификации сетей Интернет это означает, что RIPE NCC отвечает за делегирование в зоне IN-ADDR.ARPA не только сетей класса B, но и сетей класса C.

Сети класса B сейчас почти не выдают, поэтому смело можно остановиться на сетях класса C.

Если Вы не являетесь LIR, а Вам выделена сетка класса C, то направить заявку на делегирование обратной зоны в RIPE NCC Вы напрямую все равно не сможете. Сделать это сможет только провайдер, имеющий статус LIR, который, собственно, эту сетку в RIPE NCC получил. Следовательно, нужно связываться с ним и выяснять все вопросы делегирования обратной зоны. Если Вам выделен пул адресов из сетки класса B, то все вопросы по делегированию обратной зоны нужно также направлять своему провайдеру, т.к. именно ему делегировано право управления обратной зоны этой сети.

Если Вы сами имеете статус LIR, то лучше всего не читать это краткое описание, а обратиться к первоисточникам (http://www.ripe.net/ripencc/mem-services/rigistration/reverse/howtoreverse.html или http://www.ripe.net/.c/ripencc/mem-services/training/material/c.refbooknew.pdf.txt)J.

Тем не менее следует знать, что для делегирования зоны необходимо три вещи:

получить адресный блок; обеспечить поддержку зоны /16 или /24 в соответствии с требованиями RIPE NCC; направить заявку в RIPE NCC на делегирование домена.

Адресный блок получают в соответствии с документом RIPE "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region".

Требования по поддержке зоны заключаются в том, что параметры записи SOA зоны должны соответствовать RFC 1912. при этом серийный номер зоны следует записывать в виде YYYYMMDDnn.

Для зон /24 LIR должен организовать два сервера (один у себя, а другой желательно у другого провайдера, во всяком случае, должно быть обеспечено независимое подключение). Для зон /16 должно быть обеспечено 3 сервера, причем один из них дожен быть сервер RIPE NCC ns.ripe.net. Он должен выполнять функцию slave (secondary) для зоны.

Заявка на делегирование зоны, которая посылается в RIPE NCC роботу регистрации на адрес auto-inaddr@ripe.net, должна выглядеть примерно так:

domain: 65.35.80.in-addr.arpa descr: Reverse delegation for Bluelight 2nd /24 admin-c: JJ231-RIPE tech-c: JAJA1-RIPE zone-c: WF2121-RIPE nserver: ns.bluelight.nl nserver: ns2.bluelight.nl mnt-by: BLUELIGHT-MNT changed: jan@bluelight.nl 19991110 source: RIPE

О назначении полей и правилах их заполнения лучше всего справиться у вашего LIR, либо в nic.ru, либо в RIPE.

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

Отдельно обратим внимание на то, что для каждой "обратной" зоны, которая соответствует сети класса C (адреса в CIDR xxxx.xxxx.xxxx/24) нужно свое собственное описание зоны. Нельзя в один файл мешать несколько зон данного типа. Мешать их может только в файле, описывающем родительскую зону типа xxxx.xxxx/16, например, в зоне 206.144.in-addr.arpa могут быть записи типа PTR для зон 160.206.144.in-addr.arpa и 192.206.144.in-addr.arpa, и то, только при условии, что данные зоны не делегированы на другой сервер.

Действительно, NS запись для делегирования будет находиться в том же файле описания зоны, что записи типа PTR. BIND отловит эту коллизию и проигнорирует соответствующие PTR записи.

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

Но на самом деле для небольших компаний гораздо более серьезной проблемой становится делегирование обратных зон для пулов адресов, меньших, чем сеть класса С. Рассмотрим эту проблему более подробно. Все примеры будем брать из RFC 2317, т.к. именно оно рекомендовано RIPE NCC для решения нашей проблемы. Именно этот способ поддерживается в самом RIPE NCC.

Сначала о существе проблемы. Провайдер "нашинковал" в сети класса С (пул адресов в нотации CIDR /24) на несколько частей. Таким образом границы пулов адресов не приходятся на границы октетов.

Пусть мы имеем дело с сетью 192.0.2.0/24. Провайдер разделил адресное пространство следующим образом:

192.0.0/25 - организация А 192.0.128/26 - организация Б 192.0.192/26 - организация С

Классическое описание обратной зоны может выглядеть примерно так:

$ORIGIN 2.0.192.in-addr.arpa. ; 1 PTR host1.a.ru. 2 PTR host2.a.ru. 3 PTR host3.a.ru. ; 129 PTR host1.b.ru. 130 PTR host2.b.ru. 131 PTR host3.b.ru. ; 193 PTR host1.c.ru. 194 PTR host2.c.ru. 195 PTR host3.c.ru.

Делегировать поддержку такой зоны можно только кому-то одному. Все остальные будут зависимы от владельца зоны и все изменения должны будут вносить через него.

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

$ORIGIN 2.0.192.in-addr.arpa. @ IN SOA ns.provider.ru. hostmaster.provider.ru. (…) ; ; 0-127 /25 ; 0/25 IN NS ns.a.ru. 0/25 IN NS ns.slave.ru. ; 1 IN CNAME 1.0/25.2.0.192.in-addr.arpa. 2 IN CNAME 2.0/25.2.0.192.in-addr.arpa. 3 IN CNAME 3.0/25.2.0.192.in-addr.arpa. ; ; 129-191 /26 ; 128/26 IN NS ns.b.ru. 128/26 IN NS ns.slave.ru. ; 129 IN CNAME 129.128/26.2.0.192.in-addr.arpa. 130 IN CNAME 130.128/26.2.0.192.in-addr.arpa. 131 IN CNAME 131.128/26.2.0.192.in-addr.arpa. ; ; 193-255 /26 ; 192/26 IN NS ns.c.ru. 192/26 IN NS ns.slave.ru. ; 193 IN CNAME 193.192/26.2.0.192.in-addr.arpa. 194 IN CNAME 194.192/26.2.0.192.in-addr.arpa. 195 IN CNAME 195.192/26.2.0.192.in-addr.arpa.

Сами организации при это обязаны завести зоны следующего содержания:

$ORIGIN 0/25.2.0.192.in-addr.arpa. @ IN SOA ns.a.ru hostmaster.a.ru (…) IN NS ns.a.ru. IN NS ns.slave.ru. ; 1 IN PTR host1.a.ru. 2 IN PTR host2.a.ru. 3 IN PTR host3.a.ru.

Для блока 128/26 соответственно последовательность "0/25" следует заменить на "128/26", а сервер ns.a.ru на сервер ns.b.ru. Для блока 192/26 нужно также будет выполнить соответствующие замены.

Идея данного метода заключается в том, что, попадая в зону 2.0.192.in-addr.arpa, локальный сервер доменных имен или resolver на свой запрос доменного имени получают CNAME, т.е.

сервер зоны говорит, что имя, которое ему было сообщено не является каноническим именем хоста, указанным в адресной записи. Это лишь синонимом канонического имени. При этом каноническое имя сообщается в качестве ответа на запрос. Обращаясь по каноническому имени, локальный сервер доменных имен или resolver получают в ответ ссылку на другой сервер, т.к. в нашей зоне указан NS для поддержки зон с каноническими именами. Переходя на новый сервер, локальный сервер доменных имен или resolver получают уже обычную PTR запись ресурсов и могут сообщить доменное имя приложению, которое инициировало запрос к обратной зоне.

Может показаться накладным набивать большое количество CNAME в зонах типа 2.0.192.in-addr.arpa. Но здесь можно воспользоваться директивой управления $GENERATE, которая существенно сократит число набираемых вручную записей описания ресурсов.

Следует также обратить внимание на то, что имена зон в 2.0.192.in-addr.arpa могут быть любыми допустимыми именами, а не только "0/25" или "192/26", как это указано в примере. Более того, имена могут указывать на зоны из совершенно других доменов, не входящих в in-addr.arpa. Правда, зоны должны содержать соответствующие PTR записи описания ресурсов.

Мы в самом начале этого материала упоминали об инверсных запросах, которые не следует путать со стандартными запросами к серверам домена IN-ADDR.ARPA. Какова их судьба?

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

При этом реальная область применения такого сорта запросов ограничивается рамками одного сервера.

И в заключении о том, зачем вообще нужно искать доменные имена по IP_адресам. Этому есть несколько причин.

Во-первых, многие сетевые сервисы блокируют доступ, если не могут отобразить IP-адрес хоста, с которого к ним обращаются, в доменное имя.

Так поступают, например, ftp-серверы и серверы электронной почты.

Во-вторых, большое число запросов к "обратным" зонам возникает при работе систем электронной почты и веб-серверов. В электронной почте рассылка почты почтовыми транспортными агентами (ПТА) основана на процедуре канонизации адресов отправителя и получателя. А эта процедура подразумевает обращение к обратной зоне. Кроме того, ПТА блокируют пересылку почты, основываясь, в том числе, и на информации из "обратных" зон. При работе веб-серверов обращение к "обратной" зоне используется для сбора статистики.

В-третьих, при отсутствии "обратных" зон объем трафика, который генерируется прикладным программным обеспечением, гораздо больший, чем при наличии правильно сконфигурированных "обратных" зон.

Любопытно, что на 1999 год по данным RIPE NCC из 163124 зон, которые могли бы быть делегированы (зарегистрированые IP-адреса), реально было делегировано только 85352 или примерно 52%.

И еще одно замечание. Мы здесь вообще не рассматривали "обратное" отображение в рамках такой "экзотики", как адресное пространство IPv6. На самом деле современные версии BIND прекрасно справляются с этой задачей, но об этом как-нибудь в другой раз.

Zone

- имя зоны. Если речь идет о зоне, описанной в записи primary файла named.boot, то в качестве имени употребляется символ коммерческого эт - "@". В этом случае в качестве имени текущей зоны берется имя, указанное в качестве первого аргумента команды primary из файла named.boot, или имя зоны, указанное в директиве zone файла named.conf.

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

Можно, конечно, указывать и полное имя зоны, не забывая при этом ставить на конце имени ".":

kyky.ru. IN SOA ns.kyky.ru adm.kyky.ru ( 2 8h 30m 2w 2h )

Поле

"Невидимых" серверах (stealth, см. RFC-1996)

Официальный (Authoritative) сервер зоны

Описание "прямой" и "обратных" зон

Описание зоны. Формат записи описания ресурсов (RR).

Origin

Полезные ссылки:

Primary Master

"Прямая" и "обратная" зоны для

Программа интерактивного тестирования серверов DNS - nslookup

Программа тестирования системы доменных имен - dig

Программа тестирования системы доменных имен - host

Проверка работоспособности кэширующего named.

Refresh

Рекомендованная литература:

Resolver. Типовые настройки

Retry

Serial

Сервера, которые обслуживают корневую зону (Root servers)

Система доменных имен Internet. Немного истории и принципы построения иерархии имен.

Slave сервер для корпоративного домена. Настройки BIND.

Slave-сервер (secondary, вторичный, дублирующий)

Тестирование серверов и системы доменных имен

Типовые примеры описания зон и файлов конфигурации BIND

Типы серверов доменных имен. Master, Slave, Cache, Stealth, Root.

Ttl

Ttl (Time To Live)

Вспомогательный сервер (secondary, slave)

Запись Mail exchanger (MX). Электронная почта и DNS

Запись "Name Server"(NS), проблема

Запись назначения синонима каноническому

Запись "Start Of Authority"

Записи типа "Pointer". Домен IN-ADDR.ARPA. Делегирование "обратных" зон. Инверсные запросы.

Zone