DNS За 15 хвилин

Сервер:
OS debian 5
ip 192.168.1.1
zone org.ua (для прикладу :) )

Насам перед потрібно встановити сам DNS сервер. В якості сервера я обрав bind, отже приступимо.

#aptitude install bind9

Дочекавшись закінчення процедури інсталяції робимо наступне.

#/etc/init.d/bind9 stop

Тепер можемо приступидо до зміни конфігураційних файлів.

#nano /etc/bind/named.conf.local

zone "org.ua" {
type master;
file "/etc/bind/db.org.ua";
};

zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.org.ua.rev";
};

Зараз нам потрібно створити файли зон які ми вказали в named.conf.local, а саме db.org.ua та db.org.ua.rev

db.org.ua:

;
; BIND data file for broadcast zone org.ua
;
$TTL 604800
@ IN SOA org.ua. root.org.ua. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.org.ua.

ns A 127.0.0.1
ns A 192.168.1.1
gw A 192.168.1.1
web A 192.168.1.2

db.org.ua.rev

;
; BIND reverse data file for broadcast zone
;
$TTL 604800
@ IN SOA org.ua. root.org.ua. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.

1 PTR ns.org.ua.
2 PTR web.org.ua.

після чого потібно внести запис про DNS сервер в /etc/resolv.conf

#nano /etc/resolv.conf

search org.ua
nameserver 127.0.0.1
nameserver 192.168.1.1

Запускаємо сервер
#/etc/init.d/bind9 start
Перевіряємо

~# dig ns.org.ua

; <<>> DiG 9.3.4-P1.1 <<>> ns.org.ua
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26392
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.org.ua. IN A

;; ANSWER SECTION:
ns.org.ua. 604800 IN A 192.168.1.1
ns.org.ua. 604800 IN A 127.0.0.1

;; AUTHORITY SECTION:
org.ua. 604800 IN NS ns.org.ua.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 4 15:47:32 2009
;; MSG SIZE rcvd: 73

DNS Amplification (DNS усиление)

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



Начало


Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:

10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)

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

DNS Amplification (DNS усиление). Теория

Сам тип атаки не нов — о нем было известно еще в 2006 году, подробности на английском языке можно посмотреть здесь , однако активно использовать его начали относительно недавно. В январе-феврале 2009 года несколько интернет-изданий опубликовало информацию о крупномасштабном использовании киберпреступниками этого вида DDOS, о чем можно узнать здесь и на английском языке здесь
Объясняя простым языком, суть усиления заключается в том, что злоумышленник посылает (обычно короткий) запрос уязвимому DNS-серверу, который отвечает на запрос уже значительно большим по размеру пакетом. Если использовать в качестве исходного IP-адреса при отправке запроса адрес компьютера жертвы (ip spoofing), то уязвимый DNS-сервер будет посылать в большом количестве ненужные пакеты компьютеру-жертве, пока полностью не парализует его работу.

Практика

Наиболее эффективен этот тип атаки на старом (непропатченном) или неправильно сконфигурированном DNS-сервере, который, как уже было сказано, отвечает на короткие запросы злоумышленников большими по размеру пакетами.
Вот пример такого взаимодействия (кстати именно такие запросы чаще всего используют атакующие):
Отправляем серверу NS запрос командой
#dig @SERVER_IP NS
где SERVER_IP — IP-адрес сервера. В результате в логе по 53 порту сервера получаем:
11:08:47.994604 IP MY_IP.47816 > SERVER_IP.53: 5655+ NS?. (17)
т.е. как раз те 17 байт запроса, что мы хотели послать.
В ответ в то же самом логе видим:
11:08:47.995853 IP 192.168.100.254.53 > 192.168.100.100.47816: 5655 13/0/6 NS C.ROOT-SERVERS.NET.,[|domain]
т.е. сервер ответил нам подсказкой в виде адресов корневых DNS-серверов, что составляет уже 360 байт. Это длины DNS запроса и ответа, общая же длина пакетов 60 и 402 байта соответственно. Усиление налицо.

Что делать?

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

Что еще можно сделать?

В моем случае делать было уже особенно нечего. Если посмотреть самый первый лог, который я привел, то видно, что атакующий отправляет запрос длиной 17 байт и получает REJECT той же самой длины (17 байт), т.е. никакого усиления не происходит. Но, видимо, «ddos-еры» особенно не торопятся убирать из своих списков адреса DNS-серверов, не подверженных этой уязвимости, и продолжают беспокоить их своей долбежкой… Эта ситуация меня не устраивала. Неприятно что от моего адреса кто-то получает на свой сервер ненужный трафик (даже пусть я в этом и не виноват).
Поначалу я начал ставить в black-лист адреса отправителей, но не тут-то было, со старых адресов атака прекращалась, но появлялись все новые и новые. Было решено использовать более изощренные методы фильтрации и задействовать на моем Linux-сервере модули iptables, до которых раньше у меня никак руки не доходили. Убить, так сказать, сразу двух зайцев — и атакующим сделать -1 и разобраться с парой модулей iptables.

Модуль String

Закрыть 53 порт (DNS) полностью я конечно же не мог — у меня много клиентов которым он нужен. Я решил фильтровать пакеты по содержимому DNS-запросов и убирать те из них, которые содержат запросы атакующих, а они все как один содержали в себе «NS». Для этой задачи подходит модуль iptables string, который как раз позволяет заглянуть в содержимое пакетов.
Для того, чтобы понять что фильтровать, посмотрим на пакет атакующего через wireshark.



Здесь и здесь можно почитать о структуре UDP пакетов и формате кадра DNS соответственно. Для краткости скажу, что первые 14 байт пакета занимают данные протокола Ethernet (на рис. красным), затем идут 20 байт заголовка протокола IP (на рис. синим), затем 8 байт — заголовок UDP (на рис. зеленым), после которого начинаются данные протокола DNS (на рис. желтым). Первые 12 байт кадра DNS занимает заголовок, после которого, наконец, начинается поле DNS Query (т.е. непосредственно сам запрос, на рис. оранжевым). В пакетах, присылаемых атакующим начиная с 54-ого (14+20+8+12) байта идут следующие данные: 00 00 02 00 01 (в шестнадцатеричном коде), что соответствует запросу «NS», о котором я говорил раньше. Таким образом нужно выделить пакеты, которые начиная с 54 байта содержат эти байты. Это будет выглядеть так:

iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --jump DROP

Немного поясню.
--in-interface — указывает на каком интерфейсе отлавливать пакеты. Нужно поставить только внешний интерфейс, на который идет атака (незачем ущемлять пользователей во внутри сети).
--match state --state NEW — отлавливаем пакеты только со состоянием NEW, чтобы не проверять все транзакции подряд, а только инициирующие пакеты (мало ли что может передаваться по 53 порту).
Дальше идет самое интересное — задействуем модуль sting. Мы используем следующие параметры:
--algo — указывает алгоритм поиска, по сути не важен я указал kmp, но можно указать и bm;
--hex-string — записывается та самая строка в шестнадцатеричном виде, которую мы ищем;
--from 40 — ищем начиная с 40 байта (заметьте, не с 54 потому что string начинает поиск, а соответственно и отсчет от первого байта протокола IP, т.е. выбрасывается протокол Ethernet, длина которого 14 байт(на рис. сверху красным). Итого 54 — 14 = 40);
--to 45 — соответственно искать до 45 байта пакета.

Модуль Recent


На этом уже можно было бы остановиться. Пакеты уже не будут доходить до bind, но меня еще не утешала мысль, что я закрыл для ВСЕХ возможность обращаться с запросами NS к моему DNS-серверу, поэтому я решил задействовать еще один модуль iptables — recent.
Этот модуль позволяет создавать динамические таблицы IP-адресов в зависимости от определенных условий, а затем устанавливать разрешающие и запрещающие правила для этих таблиц.
Рассмотрим простой пример использования recent, состоящий из двух строк:

iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --update --seconds 30 --name SSHT --jump DROP
iptables -A INPUT --protocol tcp --match state --state NEW --dport 22 --match recent --set --name SSHT --jump ACCEPT
Начнем разбираться со второго правила. Каждый кто пытается зайти (именно зайти, т.к. мы используем --state NEW) на порт 22 (SSH) пропускается (--jump ACCEPT), но его IP-адрес попадает в таблицу с именем SSHT. Когда с этого адреса пытаются соединиться еще раз, начинает работать первое правило, смысл которого состоит в том, чтобы обновить (--update) запись в таблице и заодно проверить когда эта запись была установлена/обновлена в последний раз. Если запись была установлена/обновлена меньше 30 секунд назад (--seconds 30), то срабатывает --jump DROP и пакет отбрасывается. Таким образом брутфорсеры, пытающиеся долбиться на порт SSH будут отбрасывается, если частота отправки их пакетов будет превышать 1 пакет в 30 секунд.
Попробуем использовать recent для наших нужд:
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --update --seconds 600 --jump DROP
iptables -A INPUT --in-interface eth1 --protocol udp --dport 53 --match state --state NEW --match string --algo kmp --hex-string "|00 00 02 00 01|" --from 40 --to 45 --match recent --name DNST --set --jump ACCEPT

Таким образом я разрешаю делать запросы NS на внешний интерфейс не чаще, чем 1 раз в 10 минут.

После добавления этих правил в /proc/net/xt_recent моего сервера появился файл DNST, в котором начали записываться IP-адреса атакующих. А DNS-сервер перестал поддаваться на провокации:
14:10:19.011818 IP 89.149.221.182.40320 > MY_IP.53: 23508+ NS?. (17)
14:10:25.243499 IP 89.149.221.182.64984 > MY_IP.53: 25306+ NS?. (17)
14:11:08.832827 IP 89.149.221.182.15864 > MY_IP.53: 48029+ NS?. (17)
14:11:15.063058 IP 89.149.221.182.30959 > MY_IP.53: 64444+ NS?. (17)

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

Джерело http://habrahabr.ru/blogs/infosecurity/51574/

bind 9

Этот документ описывает установку и начальную конфигурацию пакета BIND 9 для работы в качестве кэширующего DNS сервера для локальной сети.


Было решено использовать 9-ю версию пакета BIND, так как она наименее уязвима для внешних атак. BIND 9 поддерживает списки управления доступом для запросов, передачи зоны, а также динамических обновлений. Кроме того, этой версией поддерживается стандарт динамических обновлений и уведомления об изменениях зоны, она может использовать механизм инкрементальной передачи зоны, позволяющий вторичным DNS серверам запрашивать у первичных серверов только изменения зональных данных. Это позволяет ускорить передачу зон.
В качестве ОС на сервере установлена FreeBSD 4.10.

Получение, сборка и установка пакета BIND из исходных кодов

На момент написания статьи последней стабильной версией BIND 9 являлась 9.2.3.
Исходные коды BIND 9.2.3 доступны для загрузки с публичного FTP сервера: ftp://ftp.isc.org/isc/BIND9/9.2.3/bind-9.2.3.tar.gz.
Итак.

Создаем директорию, где будет проходить весь процесс:

# mkdir /usr/local/src
# cd /usr/local/src
Скачиваем дистрибутив с FTP сервера ftp.isc.org:

# fetch ftp://ftp.isc.org/isc/BIND9/9.2.3/bind-9.2.3.tar.gz
Распаковываем, и заходим в полученную папку:

# tar -xzf bind-9.2.3.tar.gz
# cd bind-9.2.3
Мы хотим что бы наш BIND 9 стал вместо штатного BIND 8.

# ./configure --prefix=/usr --sysconfdir=/etc/namedb
Далее, если конфигурация прошла успешно, приступаем к сборке пакета:

# make
# make install
На моей системе (FreeBSD 4.10) все собралось и установилось без каких-либо проблем.

Проверяем версию named которая у нас теперь стоит:

# named -v
BIND 9.2.3
Пусть вас не пугает, что мы устанавливаем BIND, а для проверки запускаем named. Так называется исполняемый файл, который, собственно говоря, и выполняет роль DNS сервера.

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

Установка BIND 9 из портов FreeBSD

Если порты у вас обновляются регулярно, то переходим в соответствующую директорию:
# cd /usr/ports/dns/bind9
Если не регулярно, то, вероятно, ваш BIND 9 нужно искать здесь:

# cd /usr/ports/net/bind9
Если портов у вас совсем нет, то устанавливайте BIND 9 из исходных кодов (см. выше).

Итак делаем следующие шаги.
Переходим в каталог BIND9 в ваших портах и компиллируем BIND 9:

# cd /usr/ports/dns/bind9
# make PORT_REPLACES_BASE_BIND9=yes install
Данная операция необходима для того, чтобы BIND 9 был установлен вместо штатного BIND 8.
Система сама скачает дистрибутив, распакует, сконфигурирует и установит.
После того, как закончится установка, предлагаю убедиться, что теперь у вас установлен именно BIND 9:

# named -v
BIND 9.2.3
На этом установка BIND 9 закончена, теперь можно переходить к конфигурированию и запуску. :)

Маленькая ремарка: я предпочитаю установку из портов, потому что в дальнейшем очень удобно обновлять пакет при помощи portupgrade, например, и потому, что устанавливать из портов просто удобнее.

Начальное конфигурирование и запуск BIND 9

Если у вас был установлен BIND 8, который идет в поставке с системой, то, вероятно, в папке /etc/namedb вы найдете файл конфигурации bind и некоторые дополнительные файлы, которые могут понадобиться для работы BIND. Если таких файлов у вас нет, никогда не было, и вы не знаете, где их взять, придется писать их с нуля. Я, например, нашел эти файлы в исходных кодах системы /usr/src/etc/namedb/.
Если вы обнаружили у себя соответствующие файлы, внимательно делайте необходимые правки в них. Будьте особенно осторожны, если вы решились писать конфигурационные файлы с нуля.
Итак, сначала создадим самый главный файл - файл конфигурации. Возьмите свой любимый текстовый редактор и создайте новый файл с именем named.conf. Содержание у него будет примерно такое:

# cat named.conf

// Первой строкой задаем сети, которым будет разрешено
//посылать запросы через наш DNS-сервер:
acl "corpnets" { 192.168.1.0/24; 192.168.2.0/24; 127.0.0.1; };
options {
// Рабочая директория:
directory "/etc/namedb";
// Pid файл создавать тоже в рабочей директории, хотя можно
// написать любую другую, например /var/run/named/named.pid:
pid-file "named.pid";
// Разрешаем посылать запросы только от тех сетей, которые мы
// указали выше:
allow-query { "corpnets"; };
};
// Указатели корневых серверов:
zone "." {
type hint;
file "named.root"; };
// Настраиваем обратное отображение
// для адреса 127.0.0.1:
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
notify no; };
С файлом named.conf пока все. Теперь нужно создать файлы, на которые мы ссылаемся в named.conf, а именно: named.root и localhost.rev.
Файл named.root скачиваем c FTP-сервера ftp.internic.net:

# fetch ftp://ftp.internic.net/domain/named.root
Желательно периодически повторять эту процедуру или настроить на автоматическое обновление через cron.

Файл localhost.rev можно написать вручную, а можно воспользоваться специальной утилитой make-localhost, которая находится в исходных кодах системы: /usr/src/etc/namedb/make-localhost.

Выглядит он примерно так:

# cat localhost.rev

; 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 zm.domain.com. root.zm.domain.com. (
20040603 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS zm.domain.com.
1 IN PTR localhost.domain.com.

С файлом localhost.rev тоже закончили.

Теперь можно попробовать запустить и проверить наш bind:

# named
# ps -ax|grep named
Если процес запущен и работает, пробуем послать запрос через наш DNS-сервер:

# dig @127.0.0.1 ya.ru
В ответ на этот запрос мы должны получить некий положительный ответ, например:

# dig @127.0.0.1 ya.ru

; <<>> DiG 9.2.1 <<>> @127.0.0.1 ya.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36843
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru. IN A

;; ANSWER SECTION:
ya.ru. 36000 IN A 213.180.193.123

;; AUTHORITY SECTION:
ya.ru. 36000 IN NS ns1.yandex.ru.
ya.ru. 36000 IN NS ns2.yandex.ru.
ya.ru. 36000 IN NS ns3.yandex.ru.
ya.ru. 36000 IN NS ns.ispm.ru.

;; Query time: 2639 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jun 13 22:28:50 2004
;; MSG SIZE rcvd: 122
Если ответа нет, идем смотреть логи системы в /var/log/messages, читаем, что нам пишет наш bind, и пытаемся понять, с чем это может быть связано.
Надеюсь, вы догадаетесь при необходимости настроить соответствующим образом ваш фаервол для работы DNS-сервера.

Если положительный ответ получен, значит ваш DNS-сервер работает и теоретически может обслуживать вашу сеть :)

Теперь давайте настроим ваш компьютер на работу с установленным DNS-сервером. Для этого необходимо внести изменения в файл /etc/resolv.conf. Выглядеть он будет примерно следующим образом:

# cat /etc/resolv.conf
# Ваш домен
domain domain.com
# IP адрес либо 127.0.0.1 либо адрес вашей машины
nameserver 127.0.0.1
Проверяем, обращается ли ваша машина к установленному DNS-серверу:

# nslookup yandex.ru
Server: localhost.domain.com
Address: 127.0.0.1
Non-authoritative answer:
Name: yandex.ru
Address: 213.180.216.200
Если получен ответ, аналогичный тому, что вы видите выше, значит, обращение происходит успешно.

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

Для этого необходимо добавить в наш файл конфигурации (named.conf) опцию forwarders.
В секции options добавляем следующую строку:

forwarders { 195.5.45.17; };
Не забудьте изменить IP адрес на адрес DNS сервера вашего провайдера.

Секция options в файле конфигурации должна выглядеть вот так:

options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working dir
allow-query { "corpnets"; };
forwarders { 195.5.45.17; };
};
После изменения файла конфигурации необходимо перестартовать named, для чего можно воспользоваться командой:

# killall -HUP named


Настройка DNS-сервера для работы с утилитой удаленного администрирования rdnc

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

Чтобы решить эту задачу, нам необходимо создать файл конфигурации для утилиты rndc.conf и добавить несколько строк в конфигурационный файл нашего сервера.
Копируем содержимое файла /usr/sbin/rndc-confgen в файл /etc/namedb/rndc.conf, который будет служить конфигурационным файлом для утилиты rndc:

# /usr/sbin/rndc-confgen > /etc/namedb/rndc.conf
В результате выполнения этой команды мы получим файл rndc.conf примерно следующего содержания:

# Начало файла rndc.conf
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# Конец файла rndc.conf
# Начало секции для named.conf
# Для использования ключа авторизации необходимо добавить следующие строки в файл
# named.conf, при необходимости исправив список разрешенных для авторизации хостов:
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
#Конец секции для named.conf
Теперь нужно добавить в самое начало файла конфигурации DNS сервера (named.conf) следующую секцию файла rndc.conf:
key "rndc-key" {
algorithm hmac-md5;
secret "SW8ldl5IOMfhvlqxyRuRVw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
После этого можно перезапустить named:
# killall -HUP named
Давайте проверим, работает ли наша утилита для удаленного администрирования DNS сервера:

# rndc status
number of zones: 3
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
Если выполнение данной команды прошло успешно, и вы получили примерно то, что получилось выше, значит утилита смогла подключиться к вашему named, успешно авторизовалась при помощи ключа, который мы создали, и попросила показать статус DNS сервера.

При помощи утилиты rndc можно делать очень много различных операций с вашим DNS сервером. Запустите ее без аргументов и увидите список доступных команд. :)



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



В следующей части статьи мы рассмотрим такие темы, как:

1. Настройка DNS сервера для поддержки домена.
2. Повышение безопасности DNS сервера.
3. Параметры в файле доменной зоны.

Автор: Дмитрий Донченко.
Огромное спасибо всем кто помогал написать эту статью. Отдельное спасибо bm-у, моему лучшему другу и коллеге, который высматривал очепятки и неправильности в том, что я тут насочинял.

Оригінал : http://www.ru-board.com/new/article.php?sid=161