Блог о системном администрировании. статьи о linux, windows, схд netapp и виртуализации
Содержание:
- Запросы DNS
- Configuring BIND to serve DNSSEC signed zones
- Зоны bind
- Вторичный (secondary, slave) авторитетный сервер зоны
- Немного теории
- Проверка работы DNS Server
- Онлайн курс «Сетевой инженер»
- Настройка netfilter (iptables) для DNS BIND
- COLOPHON top
- Частичное применение
- BOOLEANS
- DESCRIPTION top
- Интро
- Создание и настройка локальной зоны
- Настройка DNS сервера bind9. Ubuntu/Debian. Пошаговая инструкция
- Заключение
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
Обычно, провайдер выдает в локальной сети стоит DNS-сервер, обрабатывающий рекурсивные запросы, а так же, скорее всего, он настроен на кэширование запросов, что экономит трафик и снижает нагрузку на сеть. Схему взаимодействия клиента и DNS серверов можно представить следующей картинкой:
Давайте разберем, что тут нарисовано по шагам:
- Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
- Резолвер посылает запрос указанному серверу имен.
- Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
- Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
- Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
- пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
- и «вложенности» доменных имен.
- В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
- Сервер
провайдералокальной сети возвращает резолверу клиента запрошенные данные.
Обычно, количество шагов сокращено до минимума, т.к. на пути прохождения запросов встречается кэширующий сервер, который хранит необходимую информацию в кэше. В данной схеме может возникнуть вопрос: каким образом локальный DNS сервер, получивший рекурсивный запрос от резолвера, выбирает DNS-сервер из списка авторитативных? Существует множество корневых DNS-серверов в сети Интернет, какому из корневых серверов наш DNS-сервер отправит запрос?
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Configuring BIND to serve DNSSEC signed zones
To enable DNSSEC support you need to add «dnssec-enable yes;» to /etc/named.conf «options» block.
Do not forget to check that «edns» is not disabled.
On master DNS server:
generate KSK and ZSK keys:
$ dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com $ dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com
change zone configuration:
zone "example.com" {
type master;
allow-transfer { ... };
auto-dnssec maintain;
inline-signing yes;
key-directory "master/";
file "master/example.com.zone";
};
Now bind will sign zone automatically. (This example assumes that all required files are in /var/named/master/)
Then you should pass DS records (from dsset-example.com. file) to parent zone owner probably using your registrar website. It glues parent zone with your KSK.
KSK (and corresponding DS records) should be changed rarely because of it needs manual intervention, ZSK can be changed more often because of this key is usually shorter to be faster in signature checking.
You can schedule old ZSK key expiration and generate new one using:
$ dnssec-settime -I +172800 -D +345600 Kexample.com.+000+111111.key $ dnssec-keygen -S Kexample.com.+000+111111.key -i 152800
Bind should automatically use new ZSK key at appropriate time.
Зоны bind
Для возможности искать соответствия в собственной базе доменов, необходимо создать и настроить зоны. Существуют следующие типы зон:
- Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind.
- Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind.
- Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
- Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.
Вторичный (secondary, slave) авторитетный сервер зоны
Основная функция slave сервера — автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP, посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).
Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.
Прежде чем приступить к настройке slave DNS сервера, необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:
root@debian:~# dig @10.0.0.152 example.com. axfr ; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr ; (1 server found) ;; global options: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)
Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:
- Скопировать конфигурационный файл named.conf с master сервера;
- Заменить параметр type master на type slave в тех зонах, для которых он будет вторичным;
- Параметр allow-transfer { 10.0.0.191; }; заменить на masters { 10.0.0.152;}; в тех зонах, для которых он будет вторичным;
- Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
- Создать каталоги для логов, как в предыдущем примере.
Итого, мы получаем конфиг slave сервера:
root@debian:~# cat /etc/bind/named.conf
options {
directory "/var/cache/bind";
allow-query { any; }; // отвечать на запросы со всех интерфейсов
recursion no; // запретить рекурсивные запросы
auth-nxdomain no; // для совместимости RFC1035
listen-on-v6 { none; }; // IPv6 нам не нужен
version "unknown"; // не отображать версию DNS сервера при ответах
};
// нижеописанные зоны определяют сервер авторитетным для петлевых
// интерфейсов, а так же для броадкаст-зон (согласно RFC 1912)
zone "localhost" {
type master;
file "localhost";
};
zone "127.in-addr.arpa" {
type master;
file "127.in-addr.arpa";
};
zone "0.in-addr.arpa" {
type master;
file "0.in-addr.arpa";
};
zone "255.in-addr.arpa" {
type master;
file "255.in-addr.arpa";
};
// описание основной зоны
zone "example.com" {
type slave;
file "example.com";
masters { 10.0.0.152; };
};
//описание обратной зоны
zone "0.0.10.in-addr.arpa" {
type slave;
file "0.0.10.in-addr.arpa";
masters { 10.0.0.152; };
};
// настройки логирования
logging {
channel "misc" {
file "/var/log/bind/misc.log" versions 4 size 4m;
print-time YES;
print-severity YES;
print-category YES;
};
channel "query" {
file "/var/log/bind/query.log" versions 4 size 4m;
print-time YES;
print-severity NO;
print-category NO;
};
category default {
"misc";
};
category queries {
"query";
};
};
после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:
root@debian:~# ls -la /var/cache/bind/ итого 28 drwxrwxr-x 2 root bind 4096 Июл 8 18:47 . drwxr-xr-x 10 root root 4096 Июл 8 15:17 .. -rw-r--r-- 1 bind bind 416 Июл 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind bind 455 Июл 8 18:32 example.com ........
В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.
Немного теории
Основная цель DNS — это отображение доменных имен в IP-адреса и наоборот — IP в DNS. Решено было рассмотреть BIND (Berkeley Internet Name Domain, ранее Berkeley Internet Name Daemon), как самый распространенный софт для решения задачи DNS. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для части запросов TCP/53. Очень подробно о нем рассказано в статье на Хабре.
Если хочешь познакомиться с «новым» BIND, то рекомендую к чтению вот эту статью. В двух словах: версия 9 была последней, с 10-й версии права передают сообществу, и это ПО ныне известно как Bundy.
Проверка работы DNS Server
Первым делом пойдем в каталог с логами и проверим, что там у нас:
# cd /var/named/chroot/var/log/named # ls -l
Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:
26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)
Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:
Смотрим, что в логах:
26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)
Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, настроить запрет сайтов на микротике.
Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.
Онлайн курс «Сетевой инженер»
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные сети, рекомендую познакомиться с онлайн-курсом «Сетевой инженер» в OTUS. Это авторская программа в сочетании с удалённой практикой на реальном оборудовании и академическим сертификатом Cisco! Студенты получают практические навыки работы на оборудовании при помощи удалённой онлайн-лаборатории, работающей на базе партнёра по обучению — РТУ МИРЭА: маршрутизаторы Cisco 1921, Cisco 2801, Cisco 2811; коммутаторы Cisco 2950, Cisco 2960.
Особенности курса:
- Курс содержит две проектные работы.;
- Студенты зачисляются в официальную академию Cisco (OTUS, Cisco Academy, ID 400051208) и получают доступ ко всем частям курса «CCNA Routing and Switching»;
- Студенты могут сдать экзамен и получить вместе с сертификатом OTUS ещё сертификат курса «CCNA Routing and Switching: Scaling Networks»;
Проверьте себя на вступительном тесте и смотрите программу детальнее по .
Настройка netfilter (iptables) для DNS BIND
Собственно, настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 53/udp порту. Почитав статью о том, что такое netfilter и правила iptables и ознакомившись с практическими примерами iptables, можно создать правила фильтрации сетевого трафика:
dns ~ # iptables-save # типовые правила iptables для DNS *filter :INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # разрешить доступ локальной сети к DNS серверу: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # разрешить доступ DNS серверу совершать исходящие запросы -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT COMMIT
Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.
COLOPHON top
This page is part of release 5.08 of the Linux man-pages project. A
description of the project, information about reporting bugs, and the
latest version of this page, can be found at
https://www.kernel.org/doc/man-pages/.
Linux 2020-06-09 BIND(2)
Pages that refer to this page:
accept(2),
accept4(2),
connect(2),
getpeername(2),
getsockname(2),
listen(2),
pidfd_getfd(2),
socket(2),
socketcall(2),
syscalls(2),
bindresvport(3),
freeaddrinfo(3),
freeifaddrs(3),
gai_strerror(3),
getaddrinfo(3),
getifaddrs(3),
if_freenameindex(3),
if_nameindex(3),
sctp_bindx(3),
services(5),
systemd.socket(5),
ddp(7),
inotify(7),
ip(7),
ipv6(7),
netlink(7),
packet(7),
raw(7),
sctp(7),
signal-safety(7),
sock_diag(7),
socket(7),
tcp(7),
udp(7),
unix(7),
vsock(7)
Частичное применение
До сих пор мы говорили только о привязывании . Давайте шагнём дальше.
Мы можем привязать не только , но и аргументы. Это делается редко, но иногда может быть полезно.
Полный синтаксис :
Это позволяет привязать контекст и начальные аргументы функции.
Например, у нас есть функция умножения :
Давайте воспользуемся , чтобы создать функцию на её основе:
Вызов создаёт новую функцию , которая передаёт вызов , фиксируя как контекст, и – как первый аргумент. Следующие аргументы передаются как есть.
Это называется частичное применение – мы создаём новую функцию, фиксируя некоторые из существующих параметров.
Обратите внимание, что в данном случае мы на самом деле не используем. Но для это обязательный параметр, так что мы должны передать туда что-нибудь вроде
В следующем коде функция умножает значение на три:
Для чего мы обычно создаём частично применённую функцию?
Польза от этого в том, что возможно создать независимую функцию с понятным названием (, ). Мы можем использовать её и не передавать каждый раз первый аргумент, т.к. он зафиксирован с помощью .
В других случаях частичное применение полезно, когда у нас есть очень общая функция и для удобства мы хотим создать её более специализированный вариант.
Например, у нас есть функция . Потом внутри объекта мы можем захотеть использовать её частный вариант: , который отправляет текст от имени текущего пользователя.
BOOLEANS
If you want to determine whether Bind can bind tcp socket to http ports, you must turn on the named_tcp_bind_http_port boolean. Disabled by default.
setsebool -P named_tcp_bind_http_port 1
If you want to determine whether Bind can write to master zone files. Generally this is used for dynamic DNS or zone transfers, you must turn on the named_write_master_zones boolean. Disabled by default.
setsebool -P named_write_master_zones 1
If you want to allow users to resolve user passwd entries directly from ldap rather then using a sssd server, you must turn on the authlogin_nsswitch_use_ldap boolean. Disabled by default.
setsebool -P authlogin_nsswitch_use_ldap 1
If you want to allow all daemons to write corefiles to /, you must turn on the daemons_dump_core boolean. Disabled by default.
setsebool -P daemons_dump_core 1
If you want to enable cluster mode for daemons, you must turn on the daemons_enable_cluster_mode boolean. Enabled by default.
setsebool -P daemons_enable_cluster_mode 1
If you want to allow all daemons to use tcp wrappers, you must turn on the daemons_use_tcp_wrapper boolean. Disabled by default.
setsebool -P daemons_use_tcp_wrapper 1
If you want to allow all daemons the ability to read/write terminals, you must turn on the daemons_use_tty boolean. Disabled by default.
setsebool -P daemons_use_tty 1
If you want to deny any process from ptracing or debugging any other processes, you must turn on the deny_ptrace boolean. Enabled by default.
setsebool -P deny_ptrace 1
If you want to allow all domains to use other domains file descriptors, you must turn on the domain_fd_use boolean. Enabled by default.
setsebool -P domain_fd_use 1
If you want to allow all domains to have the kernel load modules, you must turn on the domain_kernel_load_modules boolean. Disabled by default.
setsebool -P domain_kernel_load_modules 1
If you want to allow all domains to execute in fips_mode, you must turn on the fips_mode boolean. Enabled by default.
setsebool -P fips_mode 1
If you want to enable reading of urandom for all domains, you must turn on the global_ssp boolean. Disabled by default.
setsebool -P global_ssp 1
If you want to allow confined applications to run with kerberos, you must turn on the kerberos_enabled boolean. Enabled by default.
setsebool -P kerberos_enabled 1
If you want to allow system to run with NIS, you must turn on the nis_enabled boolean. Disabled by default.
setsebool -P nis_enabled 1
If you want to allow confined applications to use nscd shared memory, you must turn on the nscd_use_shm boolean. Disabled by default.
setsebool -P nscd_use_shm 1
DESCRIPTION top
When a socket is created with socket(2), it exists in a name space
(address family) but has no address assigned to it. bind() assigns
the address specified by addr to the socket referred to by the file
descriptor sockfd. addrlen specifies the size, in bytes, of the
address structure pointed to by addr. Traditionally, this operation
is called “assigning a name to a socket”.
It is normally necessary to assign a local address using bind()
before a SOCK_STREAM socket may receive connections (see accept(2)).
The rules used in name binding vary between address families.
Consult the manual entries in Section 7 for detailed information.
For AF_INET, see ip(7); for AF_INET6, see ipv6(7); for AF_UNIX, see
unix(7); for AF_APPLETALK, see ddp(7); for AF_PACKET, see packet(7);
for AF_X25, see x25(7); and for AF_NETLINK, see netlink(7).
The actual structure passed for the addr argument will depend on the
address family. The sockaddr structure is defined as something like:
struct sockaddr {
sa_family_t sa_family;
char sa_data;
}
The only purpose of this structure is to cast the structure pointer
passed in addr in order to avoid compiler warnings. See EXAMPLE
below.
Интро
Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий DNS-сервер был один и выступал мастером для одной зоны (назовем ее xak.ru). Все остальные запросы он просто пересылал на DNS-сервер Google (8.8.8.8). А, чуть не забыл добавить: сервер этот был виртуальным. Потом в один прекрасный день сервер рухнул физически. После замены систему подняли, виртуализацию прикрутили. Поставили свежеустановленный Debian и к нему BIND 9. Присвоили тот же IP, что был у DNS-сервера до падения. Настройки восстановили из бэкапа. После успешного старта стали думать, как «закручивать болты».
Параллельно с этой работой был установлен хостинг, который держал на себе зону (например) xaker.ru. Само собой, центральный DNS должен о ней знать, а еще лучше быть slave DNS-сервером для этой зоны. Далее возникла необходимость перенаправлять DNS-запросы от центрального сервера к редиректору в зависимости от того, из какой сети пришел запрос. Делалось это ради подключения внешних DNS-фильтров, но не для всех. А только для тех, кому надо, а именно образовательных городских сетей — территории образовательных учреждений! Обо всем этом и пойдет речь ниже.
Создание и настройка локальной зоны
Открываем конфигурационный файл bind.
В CentOS / Red Hat:
vi /etc/named.conf
В Ubuntu / Debian:
vi /etc/bind/named.conf.local
И добавляем следующее:
zone «test.local» {
type master;
file «master/test.local»;
allow-transfer { 192.168.0.15; };
allow-update { none; };
};
* где test.local — имя зоны, которую будет обслуживать наш DNS-сервер. Это и есть домен, для которого bind будет хранить записи;
Описание опций настройки зоны:
| Опция | Описание |
|---|---|
| type | тип зоны (в нашем случае первичная — значит master). Другие варианты — slave, stub, forward. |
| file | Путь к файлу с записями зоны. В данном примере указан относительный путь — то есть файл находится по пути master/test.local, который начинается относительно рабочей директории (по умолчанию — /var/named/). Таким образом, полный путь до файла — /var/named/master/test.local. |
| allow-transfer | Список других DNS-серверов (вторичных) для передачи им зоны. В нашем случае, зонные передачи разрешены серверу 192.168.0.15. Можно указывать подсети. |
| allow-update | Список хостов, с которых разрешено обновление записей в зоне (для DDNS). Можно указать подсети. |
Чтобы настройки применились, необходимо перезапустить службу.
В CentOS / Red Hat:
systemctl reload named
В Ubuntu / Debian:
systemctl reload bind9
Настройка DNS сервера bind9. Ubuntu/Debian. Пошаговая инструкция
Сегодня мы поговорим о настройке, пожалуй, самого популярного DNS сервера bind9. Следуйте инструкции, и у Вас всё получится, в этом нет ничего сложного. В этом примере Вы увидите как формируются файлы зон и проследите процесс простой настройки, не вдаваясь при этом в подробности. Это лишь небольшое HowTo, призванное помочь Вам понять принцип работы DNS сервера. Если же Вы настраиваете DNS сервер на шлюзе в сегменте Вашей локальной сети, то в конце статьи Вы увидите как сделать Ваш DNS сервер кэширующим, что позволит существенно сократить время повторного запроса к NS серверам, ведь посещённые адреса будут браться из Вашего локального кэша. Ну что ж, приступим.
Если у Вас ещё не установлен bind9, проделаем это:
Отредактируем файл /etc/init.d/sysklogd, он должен выглядеть следующим образом:
#
# Full documentation of possible arguments are found in the manpage
# syslogd(8).
#
#
# For remote UDP logging use SYSLOGD=»-r»
#
SYSLOGD=»-u syslog»
Перезапустим демона sysklogd:
Приступим к настройке файла зоны для нашего домена. В качестве примера будет выступать домен zerolab.net. Создаём файл конфигурации для наших зон myzones.conf в папке /etc/bind, содержимое файла:
Теперь непосредственно создадим наш файл зоны zerolab.net в той же папке /etc/bind:
Где 192.168.0.1 — IP Вашего сервера, MX запись нам нужна если Вы поднимаете на своем сервере почтовый сервер. ns1.zerolab.net — наш DNS сервер. Так как для функционирования DNS сервера требуется помимо master ns сервер и slave, прописываем его — ns2.bla-bla-bla.com. Естественно у Вас он должен быть на стороннем сервере, либо если у Вас есть ещё выделенный IP для Вашего сервера, то задача упрощается. Для сервера, находящегося в локальной сети и выдающего имена только в локальную сеть (к примеру у Вас установлен web-сервер, обслуживающий Вашу сеть и настроены виртуальные хосты), достаточно лишь прописать ns1, т.е. адрес Вашего DNS сервера. 2008082859 — смените на текущую дату.
Выставим нужные права на файл зоны zerolab.net:
Отредактируем файл конфигурации bind /etc/bind/named.conf, включив в него конфигурацию для наших зон, добавим в конец файла:
include «/etc/bind/myzones.conf»;
Ну и обновим конфигурацию bind командой:
Если у Вас DNS сервер установлен на шлюзе в Вашей локальной сети, сделаем его кэширующим. Открываем файл /etc/bind/named.conf.options и раскомментируем следующую строку:
Добавим в неё IP адреса DNS серверов к которым будет обращаться наш сервер, с большой долей вероятности у Вашего провайдера есть свои DNS сервера, укажем их первыми, тем самым экономя трафик:
Перезапускаем наш DNS сервер:
Ну а далее не забудьте поменять DNS адрес в /etc/resolv.conf на свой.
Вернёмся к особенностям настройки DNS сервера на выделенном сервере, когда нам необходимо прописать два ns адреса. myzones.conf примет немного другой вид:
При настройке на slave сервере myzones.conf примет такой вид:
На этом всё, настройка закончена. 😉 Удачи!
Заключение
Теперь вы можете обращаться к интерфейсам серверов вашей частной сети по имени, а не по IP-адресу. Это упрощает настройку служб и приложений, поскольку вам больше не нужно запоминать частные IP-адреса, а файлы будет легче читать и понимать. Кроме того, теперь вы можете изменять свои конфигурации для работы с новыми серверами в одном месте, на вашем основном DNS-сервере, вместо того чтобы редактировать целых набор самых разных файлов.
Когда ваш внутренний DNS-сервер был настроен, а файлы конфигурации используют частные FQDN для указания сетевых подключений, *критически *важно, чтобы ваши DNS-сервера обслуживались надлежащим образом. Если оба сервера окажутся недоступны, ваши службы и приложения, которые опираются на них при работе, не смогут нормально функционировать
Именно поэтому рекомендуется настроить для вашей DNS минимум один дополнительный сервер и сохранять рабочиие резервные копии всех серверов.
