Как поднять свой dns сервер
Делаем свой локальный DNS (PDNSD), с блэкджеком и быстрее Google Public DNS
150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).
Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…
Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.
Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.
PDNSD
pdnsd — кэширующий DNS proxy. Помимо банального кэширования DNS запросов (с возможностью жестко задавать минимальный TTL — может быть нужно на очень плохом интернете), он умеет отсылать запрос одновременно на несколько «родительских» DNS серверов, и отдавать клиенту первый вернувшийся ответ.
Именно включение параллельного опроса и дает нам основное преимущество в скорости, т.к. при нахождении результата в кеше любого из провайдеров мы получаем результат очень быстро, и не ждем полного и медленного разресолвивания если у первого провайдера нет ответа в кэше.
Ставится в Ubuntu — банальным apt-get.
Пара моментов в конфиге
В принципе, кэширование можно сделать менее агрессивным (min_ttl=1m например), но за год работы проблем особых не возникло. В случае проблем — при желании можно вытереть одну запись из кэша:
или сразу все:
Результаты тестирования в NameBench
Видим, что для 50% запросов ответ мы получаем менее чем за 10мс, для 85% быстрее Google Public DNS, ну а дальше результаты естественно совпадают с гуглом.
По результатам тестов NameBench нам радостно сообщает:
Поднимаем свой DNS сервер на VDS
В данной статье я опишу, как поднять свой DNS сервер на арендованном VDS/VPS с помощью пакета BIND.
Причины, по которым нам нужен свой DNS сервер, могут быть самые разнообразные, но в большинстве случаев, это просто облегчает работу со множеством доменов. И согласитесь, приятно видеть в сервисе Whois свои нейм сервера.
Хочу обратить ваше внимание на то, что в данном примере рассматривается как поднять оба NS на одном виртуальном сервере. Два NS необходимы в большинстве случаев, чтобы зарегистрировать домен, так как не все регистраторы позволяют проводить регистрацию с указанием одной записи или вообще без нее.
Так же скажу, что для обеспечения надежной работы, стоит задуматься о том, чтобы расположить ваши DNS сервера на разных виртуальных серверах и желательно в разных дата центрах. Это позволит продолжить работу вашего сайта без каких-либо задержек в случае падения одного из серверов.
Для того чтобы было понятно, как происходит установка, возьмем вымышленные исходные данные:
Установка BIND
Прежде всего, нам необходимо установить на сервер сам пакет BIND, а для этого нужно подсоединится к нашему VDS.
Тут есть два варианта в зависимости от того, какой ОС вы пользуетесь на своем персональном компьютере.
В linux системах все довольно просто. Нужно перейти в основной панели на вкладку Places — Connect to Server. в Service type выбрать SSH соединение, ввести адрес вашего сервера, ваш логин, нажать кнопку «connect». В появившемся окошке ввести свой пароль и… вы уже в терминале операционной системы своего VDS.
Если вы пользуетесь Windows, то могу посоветовать вам скачать программу PuTTY. Программа распространяется бесплатно и без ограничений. Скачать и узнать, как ей пользоваться, можно здесь.
Итак, мы попали в терминал VDS. Чтобы установить последнюю версию пакета 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 команду
Файл настройки содержит строки, которые определяют каталог с файлами данных зоны.
Обычно файлы настройки содержат строку, определяющую каталог, в котором расположены файлы данных зоны. Эти строки будут иметь вид:
options <
directory «/var/named/»;
dump-file «/var/run/named_dump.bd»;
statistics-file «/var/run/named.stats»;
>;
Далее идет описание каждого файла данных зоны, которые необходимо использовать. Строка начинается со слова 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 создаются автоматически, так что описывать их нет необходимости.
Вводим в терминале
Теперь приступим к редактированию файла.
В самом начале следует установить стандартное значение времени жизни TTL. DNS сервер передает указанное значение TTL в ответах на запросы, что позволяет другим серверам имен кешировать полученные данные на указанный период. Если данные изменяются редко, то будет разумно выставить интервал обновления в несколько дней, но не больше недели. Если же данные изменяются часто, то можно выставить интервал в один час, но желательно не меньше, так как из-за более коротких интервалов будет создаваться большой объем DNS трафика.
Теперь необходимо указать 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-серверов, авторитативных для данной зоны.
Документом RFC 1537 рекомендуются следующие значения для DNS серверов высшего уровня:
Обновление 24 hours
Повторение попытки 2 hours
Устаревание 30 days
Стандартное TTL 4 days
Следующие записи называются 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. готов, перейдем к создания следующего файла. Вводим в терминале:
И редактируем данные как в предыдущем файле.
Сначала прописываем 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.
«пробел» IN NS ns2.mydomain.com.
Таким сокращением можно пользоваться даже при создании различных типов записей для одного имени.
Посмотрим теперь, как будут выглядеть наши файлы данных зоны с применением вышеописанных правил сокращения.
Файл db.mydomain.com.
$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.
ns1 IN A 91.197.130.49
ns2 IN A 91.197.130.63
$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 сервер на VDS
В данной статье я опишу, как поднять свой DNS сервер на арендованном VDS/VPS с помощью пакета BIND.
Причины, по которым нам нужен свой DNS сервер, могут быть самые разнообразные, но в большинстве случаев, это просто облегчает работу со множеством доменов. И согласитесь, приятно видеть в сервисе Whois свои нейм сервера.
Хочу обратить ваше внимание на то, что в данном примере рассматривается как поднять оба NS на одном виртуальном сервере. Два NS необходимы в большинстве случаев, чтобы зарегистрировать домен, так как не все регистраторы позволяют проводить регистрацию с указанием одной записи или вообще без нее.
Так же скажу, что для обеспечения надежной работы, стоит задуматься о том, чтобы расположить ваши DNS сервера на разных виртуальных серверах и желательно в разных дата центрах. Это позволит продолжить работу вашего сайта без каких-либо задержек в случае падения одного из серверов.
Для того чтобы было понятно, как происходит установка, возьмем вымышленные исходные данные:
Установка BIND
Прежде всего, нам необходимо установить на сервер сам пакет BIND, а для этого нужно подсоединится к нашему VDS.
Тут есть два варианта в зависимости от того, какой ОС вы пользуетесь на своем персональном компьютере.
В linux системах все довольно просто. Нужно перейти в основной панели на вкладку Places — Connect to Server. в Service type выбрать SSH соединение, ввести адрес вашего сервера, ваш логин, нажать кнопку «connect». В появившемся окошке ввести свой пароль и… вы уже в терминале операционной системы своего VDS.
Если вы пользуетесь Windows, то могу посоветовать вам скачать программу PuTTY. Программа распространяется бесплатно и без ограничений. Скачать и узнать, как ей пользоваться, можно здесь.
Итак, мы попали в терминал VDS. Чтобы установить последнюю версию пакета 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 команду
Файл настройки содержит строки, которые определяют каталог с файлами данных зоны.
Обычно файлы настройки содержат строку, определяющую каталог, в котором расположены файлы данных зоны. Эти строки будут иметь вид:
options <
directory «/var/named/»;
dump-file «/var/run/named_dump.bd»;
statistics-file «/var/run/named.stats»;
>;
Далее идет описание каждого файла данных зоны, которые необходимо использовать. Строка начинается со слова 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 создаются автоматически, так что описывать их нет необходимости.
Вводим в терминале
Теперь приступим к редактированию файла.
В самом начале следует установить стандартное значение времени жизни TTL. DNS сервер передает указанное значение TTL в ответах на запросы, что позволяет другим серверам имен кешировать полученные данные на указанный период. Если данные изменяются редко, то будет разумно выставить интервал обновления в несколько дней, но не больше недели. Если же данные изменяются часто, то можно выставить интервал в один час, но желательно не меньше, так как из-за более коротких интервалов будет создаваться большой объем DNS трафика.
Теперь необходимо указать 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-серверов, авторитативных для данной зоны.
Документом RFC 1537 рекомендуются следующие значения для DNS серверов высшего уровня:
Обновление 24 hours
Повторение попытки 2 hours
Устаревание 30 days
Стандартное TTL 4 days
Следующие записи называются 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. готов, перейдем к создания следующего файла. Вводим в терминале:
И редактируем данные как в предыдущем файле.
Сначала прописываем 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.
«пробел» IN NS ns2.mydomain.com.
Таким сокращением можно пользоваться даже при создании различных типов записей для одного имени.
Посмотрим теперь, как будут выглядеть наши файлы данных зоны с применением вышеописанных правил сокращения.
Файл db.mydomain.com.
$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.
ns1 IN A 91.197.130.49
ns2 IN A 91.197.130.63
$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.