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

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

Что такое DNS?

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

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

При этом в любом адресе главенствующее место занимает именно индивидуальное доменное имя сервера.

Зачем нужны DNS-серверы?

Таким образом, можно определить основное предназначение, которое имеет настройка DNS-сервера и его дальнейшее использование:

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

Почему важна правильная настройка?

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

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

Windows 8

1. Чтобы настроить сервер в этой операционной системе, вам первоначально нужно будет навести мышку на нижний левый угол экрана, нажать ЛКМ на кнопку «Пуск», после чего открыть через
2. Теперь переходите в раздел "Сеть и Интернет", далее "Центр управления сетями" и теперь заходим в "Изменение параметров адаптера".
3. В появившемся меню вам нужно будет из списка выбрать соответствующее сетевое подключение. После того как вы его найдете, нажмите на него ПКМ и выберите пункт "Свойства".
4. Теперь откроется новое окно, и в частности вкладка "Общие", на которой вам нужно будет выбрать пункт "Использовать адреса DNS".
5. После того как вы поставите соответствующую галочку, у вас разблокируется возможность вводить различные данные в строчки ниже и теперь вы сможете ввести в поля параметры сервера DNS, настройки которого вас интересуют.

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

Windows 7

1. Опять же, как и в случае с предыдущей операционной системой,
2. В разделе "Сеть и Интернет" выбираем пункт "Просмотр состояния сети и задач".
3. В строке "Просмотр активных сетей" необходимо будет выбрать пункт, который находится справа от кнопки "Подключения".
4. В появившемся окне вам нужно будет нажать кнопку "Свойства", "Состояние подключения".
5. В появившемся списке "Отмеченные компоненты используются данным подключением" вам следует выбрать параметр "Протокол Интернета версии 4 (TCP/IP)" и также нажать кнопку "Свойства".
6. Теперь откроется новое окно, и в частности вкладка "Сеть", на которой вам нужно будет выбрать пункт "Использовать адреса DNS".
7. После того как вы поставите соответствующую галочку, у вас разблокируется возможность вводить различные данные в строчки ниже и теперь вы сможете ввести в поля параметры сервера DNS, настройка которого вас интересует.

Нажимаем «Ок», и настройки сохраняются.

Windows XP

1. Через меню "Пуск" заходим в "Панель управления".
2. Теперь выбираем и ищем то, которое нам нужно.
3. Зайдя на вкладку "Общие", в строке с названием "Состояние подключения" необходимо будет выбрать вариант "Свойства".
4. Теперь нужно снова перейти в раздел "Общие", прокрутить вниз, после чего выбрать раздел "Протокол Интернета (TCP/IP)" и снова выбрать "Свойства".
5. В разделе "Общие" в нижней части установите галочку возле "Использовать адреса DNS", после чего у вас будет возможность ввести нужные данные.

Нажимайте клавишу «Ок» и закрывайте все окна. Настройки будут сохранены.

Windows Vista

Теперь рассмотрим, как проверить настройки DNS и внести в них изменения в операционной системе Windows Vista:

1. "Пуск">"Панель управления".
2. "Центр управления сетями"
3. В разделе "Сеть" необходимо будет выбрать вариант "Просмотр состояния каждого соединения".
4. В появившемся перед вами окне нужно нажать на "Свойства".
5. Как и в предыдущем случае, прокрутите список вниз до того момента, пока у вас не появится возможность выбрать "Протокол Интернета версии 4 (TCP/IP)", после чего нажимайте на "Свойства".
6. Установите галочку напротив "Использовать адреса DNS", после чего вы сможете вводить различную информацию.

Нажимайте «Ок» и закрывайте все окна, любые настройки будут сохранены.

Linux (Ubuntu)

В Linux настройка DNS осуществляется с помощью сервиса resolvconf, при помощи которого корректировка параметров осуществляется на базе данных, полученных от различных подсистем. Одним из полезных свойств такого нововведения является то, что теперь файл этой системы генерируется полностью автоматически, причем не индивидуально каждой отдельной программой, которой нужно внести различные изменения, а при помощи общего программного интерфейса. Таким образом, любые изменения в данный файл, которые вы будете пытаться вносить собственноручно, в конечном итоге просто будут утеряны.

В связи с этим информация о DNS, предназначенных для статических интерфейсов, должна быть внесена в специализированный файл etc/network/interfaces в раздел параметров search, nameservers, а также domain. При этом данные параметры должны соответствовать тем характеристикам, которые указаны в файле resolv.conf.

Debian

Если вам требуется в Debian настройка DNS, то эта процедура практически не отличается от той, которая предоставляется вам другими дистрибутивами. Вам необходимо будет добавить индивидуальное имя хоста, а также его IP-адрес в отдельный файл etc/hosts для осуществления различных статических запросов. Чтобы ваш компьютер впоследствии постоянно отправлял всевозможные запросы соответствующему серверу, вам достаточно добавить адрес этого ресурса в отдельный файл etc/resolv.cong.

К примеру, если у вас используется компьютер с адресом 192.168.1.1, который должен будет непрерывно отправлять всевозможные запросы на определенный DNS-сервер, то в таком случае в файле resolv.conf должна присутствовать следующая строка: nameserver 192.168.3.2.

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

В данной статье я опишу, как поднять свой DNS сервер на арендованном VDS/VPS с помощью пакета BIND.

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

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

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

Сервер для DNS → 91.197.130.49 (ns1.mydomain.com)
→ 91.197.130.63 (ns2.mydomain.com)
Зона --> mydomain.com
На виртуальном сервере установлена ОС - CentOS5.5

Установка BIND

Прежде всего, нам необходимо установить на сервер сам пакет BIND, а для этого нужно подсоединится к нашему VDS.

Тут есть два варианта в зависимости от того, какой ОС вы пользуетесь на своем персональном компьютере.

В linux системах все довольно просто. Нужно перейти в основной панели на вкладку Places - Connect to Server.., в Service type выбрать SSH соединение, ввести адрес вашего сервера, ваш логин, нажать кнопку «connect». В появившемся окошке ввести свой пароль и… вы уже в терминале операционной системы своего VDS.

Если вы пользуетесь Windows, то могу посоветовать вам скачать программу PuTTY. Программа распространяется бесплатно и без ограничений. Скачать и узнать, как ей пользоваться, можно .

Итак, мы попали в терминал VDS. Чтобы установить последнюю версию пакета BIND, нужно ввести команду:

Yum install bind

Жмем «Enter» и ждем успешного завершения установки.

Создание данных зоны

Следующим шагом на нашем пути будет создание данных для зоны.

Для корректной настройки DNS под BIND данные разбиваются на несколько файлов. Один из них содержит отображения имен узлов в адреса, остальные - отображения адресов обратно в имена. Поиск адреса для имени принято называть прямым отображением, а поиск имени по адресу - обратным отображением.

Мы будем использовать следующие файлы:
1.Файл, содержащий данные преобразования имен хостов в адреса. Его имя для нашей зоны будет иметь вид db.mydomain.com.
2.Файл, содержащий данные преобразования адресов в имена хостов. Его название имеет вид db.addr, где addr - это внешний IP адрес нашего будущего DNS сервера, без последних цифр или маски сети. Для данного примера файл будет назваться
db.91.197.130.
3.Файлы зоны db.cache и db 127.0.0. Эти файлы необходимы для корректной работы DNS.
4.Файл настройки (конфигурационный файл), необходимый для связи всех файлов данных зоны. В версиях BIND 8 и 9 файл обычно называется /etc/named.conf.

Приступим непосредственно к созданию файлов.

Начнем с конфигурационного файла. Чтобы создать его, вводим в терминале VDS команду

Vi /etc/named.conf

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

Options {
directory "/var/named/";

};

Далее идет описание каждого файла данных зоны, которые необходимо использовать. Строка начинается со слова zone, за ним следует доменное имя и имя класса (in - класс интернета.) В BIND 8 и 9 класс интернета устанавливается по умолчанию, и поэтому нет необходимости указывать класс для него. Тип master указывает на то, что наш DNS сервер будет первичным. В последнем поле содержится имя файла данных зоны.

Zone "mydomain.com" IN {
type master;
file "db.mydomain.com";
};

Данная строка файла настройки предписывает чтение файла корневых указателей:

Zone "." {
type hint;
file "db.cache";
};

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

В целом конфигурационный файл будет иметь следующий вид:

Options {
directory "/var/named/";
dump-file "/var/run/named_dump.bd";
statistics-file "/var/run/named.stats";
};

Zone "mydomain.com" IN {
type master;
file "db.mydomain.com";
};

Zone "130.197.91.IN-ADDR.ARPA." IN {
type master;
file "db.91.197.130.";
};

Zone "0.0.127.IN-ADDR.ARPA." IN {
type master;
file "db.127.0.0";
};

Zone "." {
type hint;
file "db.cache";
};

Теперь рассмотрим, как создать файлы данных для mydomain.com., 91.197.130.0, 127.0.0 и cache. Вообще файлы db.127.0.0 и db.cache создаются автоматически, так что описывать их нет необходимости.

Вводим в терминале

Vi /var/named/db.mydomain.com.

Теперь приступим к редактированию файла.

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

Для того, чтобы указать стандартное значение, нужно воспользоваться директивой $TTL. Для данного примера возьмем за стандартное значение 3 часа (3h). Первая строчка будет выглядеть так:

Теперь необходимо указать SOA- запись. Она должна находиться в каждом из файлов данных зоны. Она показывает, что наш DNS-сервер является самым надежным источником информации в пределах этой зоны.
Важно знать! В файле данных зоны может быть записана одна и только одна SOA-запись.

SOA-запись для данного примера будет иметь вид:

Mydomain.com. IN SOA ns1.mydomain.com. admin.mydomain.com. (
1 ; Порядковый номер
3h ; Обновление через 3 часа
1h ; Повторение попытки через 1 час
1w ; Устаревание через 1 неделю
1h) ; Отрицательное TTL в 1 час

На первом месте указываем доменную зону нашего будущего NS, обязательно в конце домена ставим точку. Зачем это делается, я расскажу чуть позже. Далее следует класс сети, об этом уже было написано выше, его указывать не обязательно. SOA указывает на тип записи. ns1.mydomain.com. - это адрес первичного сервера DNS зоны mydomain.com. А admin.mydomain.com. - почтовый адрес владельца доменной зоны. Скобки позволяют указать несколько строк, относящихся к записи. Следующие в них значения по сути не нужны в данном примере, они используются в основном вторичными серверами, но все же я вкратце опишу, что они значат.

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

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

Обновление (refresh)
Интервал обновления инструктирует вторичный DNS-сервер, с какой частотой следует проверять актуальность информации для зоны. Установленные в данном примере 3 часа будут создавать весьма большую нагрузку на первичный сервер, так что при редком обновлении файлов зоны вторичного сервера стоит установить интервал хотя бы в 24 часа.

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

Устаревание (expire)
Если вторичный DNS сервер не может соединиться с первичным в течении указанного периода, данные на нем устаревают. Устаревшие данные зоны говорят о том, что информация уже не актуальна и не стоит ее больше использовать. Имеет смысл устанавливать значения устаревания намного большие, чем интервал обновления (от недели до месяца), иначе они будут устаревать еще до того, как успеют обновиться.
Отрицательное TTL

TTL - это время жизни (time to live). Это значение относится ко всем отрицательным ответам DNS-серверов, авторитативных для данной зоны.

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

Mydomain.com. IN NS ns1.mydomain.com.
mydomain.com. IN NS ns2.mydomain.com.

Теперь наши записи указывают на то, что для нашей DNS зоны существует якобы два различных DNS сервера. Для правильной работы NS записей необходимо указать IP адреса, на которых установлены сервера. Делается это с помощью A записей:

Ns1.mydomain.com. IN A 91.197.130.49
ns2.mydomain.com. IN A 91.197.130.63

Файл db.mydomain.com. готов, перейдем к создания следующего файла. Вводим в терминале:

Vi /var/named/chroot/var/named/db.91.197.130.

И редактируем данные как в предыдущем файле.
Сначала прописываем TTL и SOA запись.

$TTL 3H
130.197.91 IN SOA ns1.mydomain.com admin.mydomain.com (
1
3H
1H
1W
1H)

Пробел IN NS ns1.mydomain.com.
пробел IN NS ns2.mydomain.com.

А теперь указываем PTR записи - они служат для отображения имен, соответствующих IP адресам. Для данного примера записи будут выглядеть следующим образом:

49.130.197.91 PTR ns1.mydomain.com.
63.130.197.91 PTR ns2.mydomain.com.

Вот наш файл и готов.

Упрощаем код

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

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

Исходя из данного принципа сокращений, можно упростить код следующим образом:

Вместо строки: «ns1.mydomain.com. IN A 91.197.130.49» можно указать вот такую строку:

Ns1 IN A 91.197.130.49

Запись «49.130.197.91 PTR ns1.mydomain.com.» можно записать так:

49 PTR ns1.mydomain.com.

Если доменное имя совпадает с суффиксом по умолчанию, его можно указывать в виде «@». Обычно такая запись используется в SOA-записях. Например:

@ IN SOA ns1.mydomain.com. admin.mydomain.com. (
1
3h
1h
1w
1h)

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

130.197.91 IN NS ns1.mydomain.com.

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

Итог

Посмотрим теперь, как будут выглядеть наши файлы данных зоны с применением вышеописанных правил сокращения.
Файл db.mydomain.com.

$TTL 3H
@ IN SOA ns1.mydomain.com. admin.mydomain.com. (
1
3h
1h
1w
1h)

«пробел» IN NS ns2.mydomain.com.

Ns1 IN A 91.197.130.49
ns2 IN A 91.197.130.63

Файл db.91.197.130.

$TTL 3H
@ IN SOA ns1.mydomain.com admin.mydomain.com (
1
3H
1H
1W
1H)

«пробел» IN NS ns1.mydomain.com.
«пробел» IN NS ns2.mydomain.com.

49 PTR ns1.mydomain.com.
63 PTR ns2.mydomain.com.

Поздравляю! Мы закончили настройку нашего DNS сервера с двумя записями NS.

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

/etc/init.d/nammed start
/etc/init.d/nammed stop
/etc/init.d/nammed restart

Для тестирования серверов существует очень полезная программка - nslookup.

Теги: DNS, BIND, NS записи, файлы данных зоны.

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

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

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

Система DNS является глобальной и имеет строгую иерархию. Рассмотрим следующую схему:

Верхним уровнем иерархии является корневой домен, обозначаемый точкой, который содержит информацию о доменах первого уровня, например, ru , сom , org и т.п. Работу корневой зоны обеспечивают 13 корневых серверов, расположенных по всему миру и постоянно реплицирующих свои данные между собой. На самом деле корневых серверов больше, но особенности протокола позволяют указать только 13 узлов верхнего уровня, поэтом масштабируемость и отказоустойчивость системы обеспечивается зеркалами каждого корневого сервера.

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

В свою очередь домены второго уровня тоже являются доменными зонами и позволяют размещать в себе домены третьего уровня, в которые, как в матрешку, помещать домены четвертого, пятого и т.д. уровней. Для того, чтобы можно было однозначно определять узлы, находящиеся в разных зонах, введено понятие полностью определенное имя домена (FQDN, Fully Qualified Domain Name ), которое включает в себя все имена родительских доменов в иерархии DNS. Например, для нашего сайта FQDN будет: сайт. Именно так, с окончанием на точку, обозначающее корневую зону.

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

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

MailIN CNAMEdomain.mail.yandex.net.

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

Mail IN CNAME domain.mail.yandex.net

Неподготовленным взглядом разницу заметить сложно, но вместо веб-интерфейса почты Яндекса такая конструкция отправит нас на несуществующий адрес: domain.mail.yandex.net.сайт.

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

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

Итак, вы купили домен, скажем, example.org , после чего вы должны его делегировать, т.е. указать сервера имен (DNS-сервера), которые будут содержать записи данной файловой зоны. Это могут быть как ваши собственные сервера, так и публичные сервисы, например, DNS Яндекса.

В этом случае в доменной зоне org будет добавлена запись:

Example IN NS dns1.yandex.net.

Которая будет указывать, что все записи этой зоны расположены на сервере dns1.yandex.net . По правилам, каждая доменная зона должна иметь не менее двух NS-серверов, расположенных в разных подсетях. На практике часто обходятся одним сервером, приобретая для него два IP-адреса из разных диапазонов.

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

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

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

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

Итак, клиент отправляет DNS-запрос серверу провайдера с целью узнать адрес домена market.yandex.ru , сервер провайдера не располагает подобной информации, поэтому обращается к одному из корневых серверов, передавая ему запрос. Корневой сервер также не имеет нужных записей, но отвечает, что знает сервер, отвечающий за зону ru - a.dns.ripn.net . Вместе с данным именем корневой сервер может сразу сообщить его IP-адрес (и в большинстве случаев сообщит), но может и не сделать этого, если не располагает такой информацией, в таком случае, перед тем как обратиться к данному серверу, нужно будет выполнить еще один рекурсивный запрос, только уже для определения его имени.

Выяснив адрес сервера, отвечающего за зону ru, сервер провайдера передаст запрос ему, но данный сервер также не имеет нужных записей, но сообщит, что за зону yandex отвечает сервер ns1.yandex.ru и обязательно сообщит его адрес. Иначе рекурсию завершить не удастся, так как за зону yandex отвечает сервер, находящийся в зоне yandex . Для этого в вышестоящей зоне, кроме NS-записи об обслуживающих зону серверах имен, создается "связанная" А-запись , которая позволяет узнать адрес такого сервера.

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

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

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

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

Например, если пользователь после посещения Яндекс Маркета решит воспользоваться почтовым сервисом, то сервер сразу направит запрос к ns1.yandex.ru , так как уже знает, какой сервер содержит записи для зоны yandex .

От теории к практике

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

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

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

1.2.3.4 example.com

Где 1.2.3.4 и example.com соответственно новый IP-адрес и имя вашего домена.

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

В этом случае вам нужно создать, как минимум, две А-записи, которые будут указывать на веб-сервер обслуживающий сайт в данном домене:

@ IN A 1.2.3.4
www IN A 1.2.3.4

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

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

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

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

Nslookup -typr=soa сайт

В нашем случае это 4 часа:

Поэтому заранее, не менее 4 часов (старое значение TTL) до планируемого переноса, измените значение TTL на более низкое, например, 900 (15 минут). Затем переведите свой сайт в режим "только чтение" и перенесите его на новый сервер. Выключать или переводить на техобслуживание сайт не следует, он может и должен оставаться доступным. Но вы должны исключить изменение и добавление информации пользователями, т.е. запретить регистрацию, комментирование, размещение заказов и т.п. Также не забудьте разместить на видном месте сообщение о технических работах и примерный срок их завершения.

Для того, чтобы работать с новым сервером, не изменяя DNS-записи, добавьте нужную строку в файл hosts. Разместив сайт на новой площадке и убедившись в его нормальной работе измените DNS-записи, теперь уже через 15 минут первые пользователи начнут посещать ваш сайт на новом сервере. Работоспособность старого сервера требуется поддерживать еще некоторое время, в идеале до недели, так как не все провайдеры используют значение TTL из SOA-записи для обновления кэша, для уменьшения нагрузки на оборудование могут быть использованы собственные настройки.

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

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

У нас имеются публичные сервера для сайта и электронной почты и офисная сеть, для которой мы выделили поддомен office . Если с почтой и веб-сервером особых вопросов нет, то с офисной зоной есть варианты. Обычно локальная зона обслуживается собственным DNS и никак не связана с материнской зоной. Для глобальной системы DNS зона office.example.com не существует, но существует одноименный хост. Это оправдано, если сеть предприятия находится за NAT и ее узлы имеют только серые адреса, а доступ извне осуществляется только к шлюзу, на который проброшены соответствующие порты от внутренних узлов.

В этом случае DNS записи зоны example.com могут выглядеть следующим образом:

@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8

Но возникает некоторая сложность, внутри сети клиенты обращаются к сетевым сервисам по внутренним именам: corp.office.example.com или rdp.office.example.com , которые указывают на внутренние "серые" адреса". Однако за пределами локальной сети разрешить IP-адрес для таких имен не представляется возможным, так как содержащей их зоны для глобальной системы DNS не существует. Выйти из положения позволяет механизм, называемый Split-DNS, который позволяет отдавать различные результаты в зависимости от положения клиента.

В локальной сети DNS-запросы клиентов обслуживает локальный сервер, которые имеет соответствующие записи, за ее пределами запросы будут направлены серверу, обслуживающему зону example.com . При этом все корпоративные ресурсы, которые в локальной сети представлены различными серверами, извне доступны по единственному адресу: office.example.com . Поэтому самое время вспомнить о записи псевдонима или CNAME. Данная запись позволяет связывать с реальным именем хоста дополнительные мнемонические имена или псевдонимы. При этом учтите, что использовать в других записях псевдонимов недопустимо. В нашем случае следует добавить записи:

Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.

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

Также записи типа CNAME можно использовать для перенаправления за пределы обслуживаемой доменной зоны. Главное условие - CNAME запись должна указывать на реальное имя в формате FQDN.

Еще одно применение псевдонимов - это сокращение адреса. Допустим, в качестве почтового сервера для всего домена example.com мы хотим использовать сервер, который расположен в московском офисе и имеет адрес mail.office.msk.example.com , согласитесь, выглядит не слишком привлекательно. Гораздо удобнее был бы адрес вида mail.example.com , нет ничего проще, добавим следующую запись:

Mail IN CNAME mail.office.msk.example.com.

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

Example.com. IN MX 10 mail

Правильно будет так:

Example.com. IN MX 10 mail.office.msk

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

Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.

ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Теперь при обращении по адресу, скажем mail.office.msk.example.com сервера имен зоны example.com будут выдавать имя и адрес сервера, обслуживающего зону msk.example.com . Это позволяет администраторам зоны самостоятельно вносить необходимые изменения, не затрагивая при этом функционирования вышестоящей зоны и не обращаясь к ее администраторам по любому вопросу, требующему изменения записей.

• Теги:

Откройте диспетчер сервера . Чтобы открыть диспетчер сервера, щелкните Пуск , затем выберите Диспетчер сервера .

В области результатов, в разделе Сводка по ролям щелкните элемент Добавить роли.


В мастере добавления ролей при появлении страницы Прежде чем приступить к работе нажмите кнопку Далее.
В списке Роли щелкните DNS-сервер, а затем нажмите кнопку Далее.


Прочитайте сведения на странице DNS-сервер, затем нажмите кнопку Далее.
На странице Подтверждение параметров установки убедитесь, что будет установлена роль DNS-сервера, затем нажмите кнопку Установить.

Настройка

Чтобы настроить параметры DNS-сервера, щелкните правой кнопкой мыши имя нужного сервера и в контекстном меню выберите Свойства.

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

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

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

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

На вкладке Дополнительно вы можете настроить дополнительные параметры DNS-сервера. Они загружаются при запуске службы DNS-сервера из информационного загрузочного файла, системного реестра или Active Directory. В большинстве случаев значения параметров, установленные по умолчанию, не требуют модификации.

В поле Номер версии сервера вы можете узнать номер версии службы DNS-сервера. Это бывает необходимо для выяснения совместимости службы DNS-сервера Windows с другими DNS-серверами.

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

Строгое следование (Strict) RFC (ANSI) - все вводимые имена должны полностью соответствовать требованиям стандарта RFC 1123 ;

• Не (Non) RFC (ANSI) - допускается ввод нестандартных имен, недопустимых стандартом RFC 1123 ;
• Многобайтовый (UTF8) - допускается ввод имен, содержащих не ASCII-символы, включая символы в кодировке Unicode, которые обычно требуют для своего хранения более одного байта. Этот режим проверки выбран по умолчанию.

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

Из реестра - параметры службы DNS-сервера загружаются из системного реестра. Для хранения параметров службы используется ветвь реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\ Parameters. Из файла - параметры службы загружаются из специального файла по аналогии с серверами BIND (Berkeley Internet Name Domain). Для использования этого режима необходим загрузочный файл (обычно с именем Named.boot) с другого DNS-сервера, использующего BIND. В Windows Server 2003 этот файл должен иметь имя boot и располагаться в папке %systemroot%\system32\dns. Файл должен иметь более ранний формат BIND 4, а не BIND 8. Для всех параметров, не настраиваемых через загрузочный файл, будут использоваться значения из системного реестра. Из Active Directory и реестра - параметры службы DNS-сервера загружаются из Active Directory и системного реестра. Этот режим загрузки используется по умолчанию.

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

Щелкнув кнопку Восстановить умолчания, вы восстановите значения параметров по умолчанию.

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

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

Сведения о корневых серверах хранятся в файле %systemroot%\system32\DNS\ Cache.dns. Вы можете редактировать его вручную в текстовом редакторе, либо воспользоваться вкладкой Корневые ссылки окна свойств DNS-сервера. Файл корневых ссылок Cache.dns автоматически создается и заполняется при первом запуске службы DNS-сервера Windows Server 2003.

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

Если ваша сеть подключена к Интернету, при необходимости можно обновить файл cache.dns, загрузив новую версию файла корневых ссылок Named.root по адресу ftp://rs.internic.net/domain/named.root . Переименуйте полученный файл в cache.dns. Если ваша сеть не подключена к Интернету, можно сохранить файл cache.dns в надежном месте, очистить его и добавить адреса серверов, ответственных за обслуживание корневого домена. На серверах, обслуживающих корневой домен, этот файл может быть вообще удален, т. к. для нормальной работы корневых серверов он не нужен.

Чтобы добавить новый корневой сервер, щелкните кнопку Добавить. В появившемся окне введите DNS-имя сервера (или, если оно определено в одной из зон, обслуживаемых локальным сервером, найдите его, щелкнув кнопку Обзор). Если соответствующий хост уже имеет доменное имя DNS, щелкните кнопку Сопоставить, чтобы получить IP-адрес хоста. Если же у него еще нет доменного имени DNS, самостоятельно укажите один или более IP-адресов сервера, последовательно вводя их в поле IP-адрес и щелкая кнопку Добавить. Для добавления DNS-сервера должно быть указано и его имя, и как минимум один его IP-адрес. Заполнив все необходимые поля, щелкните кнопку ОК.

Чтобы изменить информацию о корневом сервере, щелкните кнопку Изменить.

При добавлении корневого сервера в файл cache.dns заносятся две записи: запись NS сервера и запись A соответствующего хоста. Запись A добавляется независимо от того, определена она в какой-либо зоне или нет. Такая запись называется glue record и предназначена для того, чтобы соответствующее имя хоста можно было использовать даже в случае неработоспособности зоны, в которой он определен. DNS-сервер Windows Server 2003 добавляет glue-записи для всех серверов, указываемых в записях NS.

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

Cache.dns -- DNS CACHE FILE Initial cache data for root domain servers. YOU SHOULD CHANGE -> Nothing if connected to the Internet. Edit this file only when updated root name server list is released. OR -> If NOT connected to the Internet, remove these records and replace with NS and A records for the DNS server authoritative for the root domain at your site. Note, if you are a root domain server, for your own private intranet, no cache is required, and you may edit your boot file to remove it. This file holds the information on root name servers needed to initialize cache of Internet domain name servers (e.g. reference this file in the "cache . " configuration file of BIND domain name servers). This file is made available by InterNIC under anonymous FTP as file /domain/named.root on server FTP.INTERNIC.NET last update Nov 5, 2002 related version of root zone 2002110501 formerly NS.INTERNIC.NET

3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

Formerly NS1.ISI.EDU

3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107

Formerly C.PSI.NET

3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12

Formerly TERP.UMD.EDU

3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90

Formerly NS.NASA.GOV

3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10

Formerly NS.ISC.ORG

3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241

Formerly NS.NIC.DDN.MIL

3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4

Formerly AOS.ARL.ARMY.MIL

3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53

Formerly NIC.NORDU.NET

3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17

Operated by VeriSign, Inc.

3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30

Housed in LINX, operated by RIPE NCC

3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129

Operated by IANA

3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12

Housed in Japan, operated by WIDE

3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33

End of File

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

На вкладке Ведение журнала отладки вы можете настроить список параметров, фиксируемых в журнале DNS-сервера. Журнал располагается в файле %systemroot%\ system32\dns\dns.log. Чтобы начать ведение журнала, включите как минимум один параметр журнала и щелкните кнопку ОК.

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

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

Запросы и передачи - фиксируются все запросы клиентов на разрешение имен; Уведомление - фиксируются уведомления, посылаемые серверу другими DNS-серверами; Обновление - фиксируются все динамические обновления; Запрос - фиксируются основные параметры запроса на разрешение имени; Отклик - фиксируются основные параметры ответа на запрос на разрешение имени; Исходящие - фиксируется количество запросов, отправленных DNS-сервером; Входящие - фиксируется количество запросов, полученных DNS-сервером; UDP - фиксируется количество запросов, полученных DNS-сервером через UDP-порт; TCP - фиксируется количество запросов, полученных DNS-сервером через TCP-порт;

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

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

Вы можете использовать два вида тестов.

Простой запрос к этому DNS-серверу - для теста используется локальный DNS-клиент, при помощи которого DNS-серверу отправляется итеративный запрос (с запретом использования рекурсии); Рекурсивный запрос к другим DNS-серверам - для теста используется локальный DNS-клиент, при помощи которого DNS-серверу отправляется рекурсивный запрос.

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

Результаты тестов выводятся в таблице в нижней части окна. В ней отображается дата и время исполнения каждого теста, а также результат (ПРОШЕЛ или ОШИБКА) простого и рекурсивного запросов.

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