Налаштування dns сервера centos. Перевірте роботу DNS Server. Встановлення та запуск BIND

Представляємо вашій увазі новий курсвід команди The Codeby- "Тестування Веб-Додатків на проникнення з нуля". Загальна теорія, підготовка робочого оточення, пасивний фазинг та фінгерпринт, Активний фазинг, Вразливості, Пост-експлуатація, Інструментальні засоби, Social Engeneering та багато іншого.


Домени мають як мінімум два DNS сервера один називається первинним сервером імен (ns1), а інший - вторинним сервером імен (ns2). Вторинні сервери зазвичай задіяні при проблемах з первинним сервером DNS: якщо один сервер недоступний, другий стає активним. Можливі і більше складні схемиз використанням балансування навантаження, фаєрволів та кластерів.

Усе DNS записупевного домену додаються в первинний серверімен. Вторинний серверпросто синхронізує всю інформацію, отримуючи її від первинного, виходячи з параметрів, заданих на первинному сервері.

Ця інструкція опише, як створити первинний DNS сервер, який працює на CentOS. Будь ласка, зверніть увагу, що сервер DNS, представлений в цій інструкції, буде публічним DNS, це означає, що сервер буде відповідати на запити від будь-якої IP адреси. Як обмежити доступ до сервера, описано в цій інструкції.

Перед тим, як ми почнемо, хотілося б згадати, що DNS може бути встановлений з або без chroot jail оточенням. Оточення chroot jail обмежує DNS сервер певною директорією у системі, на відміну повного системного доступу на сервері. Таким чином, будь-яка вразливість сервера DNS не скомпромітує всю систему. Обмеження DNS сервера в певній директорії (процес називається chrooting) також корисне у тестових умовах.

Ціль

Ми налаштуємо сервер DNS в тестових умовах для домену example.tst, який є гіпотетичним (не існуючим) доменом. Таким чином, ми не втрутимося випадково в роботу будь-яких реальних доменів.

У цьому домені є три наступні сервери.

Сервер IP адреса служби, Що Хостяться FQDN
Сервер A 172.16.1.1 Mail mail.example.tst
Сервер B 172.16.1.2 Web, FTP www.example.tst
ftp.example.tst
Сервер C 172.16.1.3 Primary DNS server ns1.example.tst

Ми налаштуємо первинний DNS сервер і додамо необхідний домен та DNS записи як показано в таблиці.

Налаштовуємо імена хостів

Усі хости мають бути коректно визначені з погляду FQDN. Це може бути зроблено з використанням наступного методу.

Ті, хто любить графічний інтерфейс, можуть скористатися інструментами NetworkManaget. Для цього наберіть команду nmtui. Відкриється такий псевдографічний інтерфейс:

Вибираєте "Змінити ім'я вузла" та вводите ns1.example.tst

Коли готово, натискаєте та ОК.

Ще один спосіб, лише в одну команду:

Hostnamectl set-hostname ns1.example.tst

Після встановлення ім'я хоста може бути перевірено наступною командою.

# hostname ns1.example.tst

Hostnamectl status

Перед тим, як перейти до наступного кроку, переконайтеся, що ім'я хоста для всіх серверів встановлено належним чином.

Встановлення пакетів

Ми будемо використовувати bind для DNS, який легко може бути встановлений командою yum.

Встановлення DNS без chroot:

# yum install bind

Установка DNS з chroot:

# yum install bind bind-chroot

Підготовка конфігураційних файлів

Як згадувалося раніше, bind може бути налаштований з або без chroot. Шляхи трохи різняться, залежно від того, чи було встановлено chroot.

Шлях до конфігураційного файлу Шлях до файлів зони
Без chroot /etc/ /var/named/
З chroot /var/named/chroot/etc/ /var/named/chroot/var/named/

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

Робимо резервну копію файлу /etc/named.conf

Cp /etc/named.conf /etc/named.conf.bak

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf

Тепер, коли є резервна копіяконфігураційного файлу, а сам оригінальний файл змінено, рухаємося далі.

# vim /etc/named.conf

# vim /var/named/chroot/etc/named.conf

Наступні рядки були додані/змінені.

Options ( ## шлях до файлів зон ## directory "/var/named"; ## пенера надсилаємо запити на публічний DNS сервер Googleдля нелокальних доменів ## forwarders ( 8.8.8.8; ); ); ## оголошення прямої зони для example.tst ## zone "example.tst" IN ( type master; file "example-fz"; ## файл для прямої зони розміщений в /var/named ## allow-update ( none; ) ;); ## оголошення зворотної зони для мережі 172.16.1.0 ## zone "1.16.172.in-addr.arpa" IN ( type master; file "rz-172-16-1"; ## файл для зворотної зони розміщений в /var /named ## allow-update (none; ););

Підготовка файлів зон

Дефолтні файли зон автоматично створені в /var/named або /var/named/chroot/var/named (для chroot).

Маючи на увазі, що дефолтні файли зон не представлені, ми можемо скопіювати файли зразків із /usr.

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named

Чудово. Тепер дефолтні файли зони готові, ми створюємо наші власні файлизони для example.tst та мережі 172.16.1.0. Поки ми створюємо файли зони, слід пам'ятати таке.

  • Символ '@' означає NULL у файлах зони.
  • Кожен запис повного доменне ім'я (FQDN) закінчується точкою '.' наприклад. mail.example.tst. Без крапки, будуть проблеми.

1. Пряма зона

Пряма зона містить карту перетворень з імен IP адреси. Для публічних доменів, DNS доменів, розміщених на хостингах, міститься у файлі прямої зони.

# vim /var/named/example-fz

# vim /var/named/chroot/var/named/example-fz $TTL 1D @ IN SOA ns1.example.tst. mial.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. IN A 172.16.1.3 mail IN A 172.16.1.1 IN MX 10 mail.example.tst. www IN A 172.16.1.2 ns1 IN A 172.16.1.3 ftp IN CNAME www.example.tst.

Пояснення: Всередині файлу зони SOA означає початок авторизації. Це повне доменне ім'яавторитетний сервер імен. Після повного доменного імені йде контактний email адреса. Оскільки ми не можемо використовувати '@' в [email protected], ми перезаписуємо email адресу як mial.example.tst.

  • NS: Ім'я сервера
  • A: A запис або запис адреси – це IP адреса
  • MX: Mail Exchangerзапис. Тут ми використовуємо лише один MX з пріоритетом 10. У разі множини MX, ми можемо використовувати різні цифрові пріоритети. Нижній номервиграє. Наприклад, MX 0 краще ніж MX 1.
  • CNAME: ім'я в канонічному вигляді. Якщо на сервері розміщено безліч служб, ймовірно, що безліч імен будуть перетворюватися до одного серверу. CNAME сигналізує, що інші імена сервер може мати та відсилає до імені, яке міститься в A запису.

2. Зворотна зона

Зворотна зона містить карту перетворень з IP-адрес в імена. Тут ми створюємо зворотну зону мережі 172.16.1.0. У реальному домені DNS сервер власника публічного IP блоку міститься у файлі зворотної зони.

# vim /var/named/rz-172-16-1

# vim /var/named/chroot/var/named/rz-172-16-1 $TTL 1D @ IN SOA ns1.example.tst. sarmed.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. 1 IN PTR mail.example.tst. 2 IN PTR www.example.tst. 3 IN PTR ns1.example.tst.

Пояснення: Більшість використовуваних параметрів зворотній зоніідентичний прямій зоні, крім одного.

  • PTR: PTR або запис покажчика, вона вказує на повне доменне ім'я

Завершення

Тепер, коли файли зон готові, ми налаштуємо роздільну здатність файлів зони.

# chgrp named /var/named/*

# chgrp named /var/named/chroot/var/named/*

Зараз ми поставимо IP адреса DNSсервера.

# vim /etc/resolv.conf nameserver 172.16.1.3

Зрештою, ми можемо запустити службу DNSта переконайтеся, що вона додана в автозапуск.

# service named restart # chkconfig named on

Тестування DNS

Ми можемо використовувати dig або nslookup для тестування DNS. Спочатку ми встановимо необхідні пакети.

# yum install bind-utils

1. Тестування прямої зони з використанням dig

# dig example.tst;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 172.16.1.3 ;; AUTHORITY SECTION: example.com. 86400 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 86400 IN A 172.16.1.3

2. Перевірка PTR за допомогою dig

Коли ви використовуєте для тестування dig вам завжди слід шукати статус "NOERROR". Будь-який інший стан означає, що щось не так.

# dig-x 172.16.1.1;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415 ;; QUESTION SECTION: ;1.1.17.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst. ;; AUTHORITY SECTION: 1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst. ;; ADDITIONAL SECTION: ns1.example.tst. 86400 IN A 172.16.1.3

3. Перевірка MX за допомогою dig

# dig example.tst mx;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405 ;; QUESTION SECTION: ;example.tst. IN MX ;; ANSWER SECTION: example.tst. 14366 IN MX 10 mail.example.tst.

Підказки під час вирішення проблем

  1. У мене вимкнено SELinux.
  2. Переконайтеся, що ваш фаєрвол не блокує UDP порт 53
  3. /var/log/messages повинен містити корисну інформацію у випадку, якщо щось не так
  4. Переконайтеся, що власники файлів зон є користувачем 'named'
  5. Переконайтеся, що IP-адреса DNS сервера стоїть на першому місці в /etc/resolv.conf
  6. Якщо ви використовуєте example.tst у лабораторних умовах, переконайтеся, що сервер від'єднано від Інтернету, оскільки example.tst — це неіснуючий домен.

Підсумуємо, цей урок фокусується на хостингу домену example.tst у лабораторних умовах для демонстраційних цілей. Будь ласка, пам'ятайте, що це не інструкція щодо створення публічного DNS сервера, наприклад, DNS сервера, який відповідає на запити від будь-яких IP адрес. Якщо ви налаштовуєте робочий DNS сервер, переконайтеся, що перевірили, які політики стосуються публічних DNS. Інший урок висвітлює створення вторинного DNS, обмеження доступу до DNS серверу та реалізацію DNSSEC.

Гарант є довіреним посередником між Учасниками під час угоди.


Одним із важливих сервісів, що забезпечують функціонування сучасного інтернету, є сервіс з перетворення імені сайту на ip адресу. Налаштуванням реалізації сервісу DNS ми займемося в цій статті на прикладі налаштування Bind 9 (named) на сервері під керуванням CentOS 7. Ми підготуємо мінімально необхідний базовий функціонал і заглянемо трохи глибше у налаштування логування.

Bind- Найпоширеніша на поточний день реалізація ДНС сервера, що забезпечує перетворення IP адрес в dns-імена і навпаки. Його також називають named, наприклад Freebsd. Судячи з інформації з Вікіпедії, зараз 10 із 13 кореневих ДНС серверів інтернету працюють на bind. Він встановлений з коробки практично в усіх дистрибутивах linux. Я розгляну його інсталяцію на сервер CentOS 7.

Встановлюємо Bind 9 (named) у CentOS 7

Насамперед перевіримо, чи встановлений у нас сервер в системі:

# rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch

У мене не встановлено, тому що під час вибрав мінімальний пакет програм. Сервер імен у нас буде працювати в оточенні chroot, так що встановлюємо відповідні пакети:

# yum - y install bind bind - utils bind - chroot

Ще раз звертаю увагу, що ми будемо використовувати bind у chrootсередовище для підвищення безпеки. Це накладає певні особливості в налаштуванні та керуванні сервером. Потрібно бути уважним у цих дрібницях. Отже, запускаємо bind :

# systemctl start named-chroot# systemctl enable named-chroot ln -s "/usr/lib/systemd/system/named-chroot.service" "/etc/systemd/system/multi-user.target.wants/named-chroot.service"

Перевіряємо вміст chroot каталогу:

# ls -l /var/named/chroot/etc

Все в порядку, сервер запустився, необхідні файли створені, все готове для налаштування. Займемося їй.

Налаштовуємо DNS сервер у CentOS 7

Файл конфігурації нашого сервера знаходиться за адресою /var/named/chroot/etc/named.conf. Відкриваємо його і наводимо до такого вигляду:

# mcedit /var/named/chroot/etc/named.conf options ( listen-on port 53 ( any; ); listen-on-v6 port 53 ( none; ); directory "/var/named"; dump-file " /var/named/data/cache_dump.db"; allow-query ( 127.0.0.1; 192.168.7.0/24; ); recursion yes; allow-recursion ( 127.0.0.1; 192.168.7.0/24; ); .8.8; );version "DNS Server"; managed-keys-directory "/var/named/dynamic"; key"; dnssec-enable no; dnssec-validation no; ); zone "." IN (type hint; file "named.ca"; ); include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging ( channel default_file ( file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; ); category default ( default_file; ); );

Ця конфігурація забезпечить роботу звичайного сервера кеші в локальній мережі. Коментарі до деяких параметрів:

Не забудьте відредагувати правила фаєрволу для коректної роботи сервера DNS — відкрити 53 порт UDP для роботи кешируючого сервера, який ми зараз налаштували, і 53 порт TCP для пересилання зон, про які йтиметься далі

Тепер створимо папку для ліг. Не забуваймо, що ми працюємо в chroot оточенні:

# cd /var/named/chroot/var/log && mkdir named && chown named. named

Підтримка власної зони

Допустимо, нам необхідно в нашому named розмістити власну зону site1.ru. Насамперед створюємо файл зони, яку обслуговуватиме dns сервер:

# mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. (2015092502 43200 3600 3600000 2592000) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231

Опис синтаксису файлів зон досить добре освітлений в інтернеті, не хочеться докладно на цьому зупинятися. За бажання кожен сам зможе подивитися, якщо у нього виникне необхідність налаштувати підтримку власної зони.

Виставляємо необхідні права:

# chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone

Zone "site1.ru" (type master; file "site1.ru.zone"; );

Перечитуємо конфігурацію named за допомогою rndc:

# rndc reconfig

Додавання до bind slave zone

Якщо ви хочете на своєму сервері тримати копію якоїсь зони, взятої з іншого dns сервера, додайте наступні налаштування в конфіг.

Zone "site.ru" IN (type slave; masters (10.1.3.4; ); file "site.ru.zone"; );

10.1.3.4 - IP адреса dns сервера, з якого ми беремо зону. Не забудьте на ньому дозволити передачу зони на ваш сервер DNS.

Потрібно додати групі named дозвіл на запис, щоб стало так:

Після цього можна перезапустити bind і перевірити, чи створився файл слейв зони. З вказаними вище налаштуваннями, він розташовуватиметься за адресою /var/named/chroot/var/named/site.ru.zone. Якщо bind не матиме рації для створення файлу, у лозі ви отримаєте помилку:

Dumping master file: tmp-7Swr6EZpcd: open: permission denied

Набагато цікавіше та корисніше розібратися з докладним логуванням роботи сервера. Я довгий час поверхово хапався за всякі рекомендації та шматки зразкових конфігів в інтернеті, поки не вирішив розібратися сам з цією темою і не поліз в оригінальний мануал.

Bind дає широкі змогу ведення логів. Можна фіксувати практично все, що пов'язане із роботою сервера. Я зараз на простих прикладах покажу як це працює.

Насамперед у конфігурації ми задаємо канал, куди складатимуться логи з тих чи інших подій. Ось приклад такого каналу:

Channel general ( file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes;

Тут вказано назву каналу, які ми вигадуємо самі - general, вказаний шлях до файлу, сказано, що будемо зберігати 3 версії лога розміром не більше 5 мегабайт. Параметр severityможе приймати такі значення:

Параметр print-timeвказує на те, що в балку необхідно записувати час події. Крім вказаних мною налаштувань, конфігурації каналу можуть бути додані такі параметри:

  • print-severity yes | no — вказує, писати чи ні параметр severity у лог
  • print-category yes | no — вказує писати чи ні назву категорії логів

Я ці параметри не вказав, оскільки за замовчуванням встановлюється значення no, що особисто мене влаштовує.

Category general (general;);

Опис категорій логів у bind (named)
defaultСюди потраплятимуть події всіх категорій цієї таблиці, якщо вони не визначені окремо, за винятком категорії queries, яку потрібно включати спеціально. Тобто якщо позначити лише категорію default, то до неї сипатимуться події всіх категорій.
generalЦя категорія для всіх логів, які не включені до жодної з перерахованих категорій.
databaseПовідомлення, що стосуються зберігання зон та кешування.
securityПідтвердження та відмова у виконанні запитів.
configВсе, що відноситься до читання та виконання файлу конфігурація.
resolverДозвіл імен, включаючи інформацію про рекурсивні запити, що виконуються від імені клієнта сервером, що кешує.
xfer-inІнформація щодо отримання зон.
xfer-outІнформація про передачу зон.
notifyЛогування операцій протоколу NOTIFY.
clientВиконання клієнтських запитів.
unmatchedПовідомлення, які named не зміг віднести до жодного класу або для яких не визначено відображення.
networkЛогування мережевих операцій.
updateДинамічні апдейти.
update-securityПідтвердження чи відхилення запитів на апдейт.
queriesЛогування запитів до ДНЗ серверу. Щоб увімкнути цю категорію, необхідно окремо встановити параметр у конфігурації сервера. Це з тим, що ця категорія генерує дуже багато записів у лог файл, що може зашкодити продуктивності сервера.
query-errorsПомилки запитів до сервера.
dispatchПеренаправлення вхідних пакетів до модулів сервера на обробку.
dnssecРобота протоколів DNSSEC та TSIG.
lame-serversФіксуються помилки, які отримує bind при зверненні до віддалених серверів у спробі виконати запит на дозвіл імені.
delegation-onlyЛогування запитів, які повернули NXDOMAIN.
edns-disabledЗапити, які змушені використовувати plain DNS через перевищення timeouts.
RPZВсі операції, пов'язані з виконанням Response Policy Zone (RPZ).
rate-limitОперації пов'язані з одним або декількома rate-limit statements в options або view.

Таким чином, щоб вивести всі категорії логів в окремі файли, необхідно до конфіг named додати наступну конструкцію:

Logging ( channel default ( file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel general ( file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; );channel database (file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; /var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; ); print-time yes; );channel resolver ( file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; ); named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel xfer-out ( file "/var/log/named/xfer-out.log" ; print-time yes; );channel notify ( file "/var/log/named/notify.log" /client.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel unmatched ( file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel network ( file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel update ( file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel update-security ( file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel queries ( file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel query-errors ( file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel dispatch ( file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel dnssec ( file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel lame-servers ( file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel delegation-only ( file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel edns-disabled ( file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel rpz ( file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel rate-limit ( file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; ); category default ( default; ); категорії general ( general; ); категорії database ( database; ); category security (security;); category config (config;); категорії resolver (resolver;); категорії xfer-in ( xfer-in; ); категорії xfer-out ( xfer-out; ); категорії notify ( notify; ); category client ( client; ); категорії unmatched (unmatched;); category network ( network; ); category update ( update; ); category update-security ( update-security; ); category queries (queries;); категорії query-errors (query-errors; ); категорії dispatch (dispatch;); category dnssec ( dnssec; ); категорії lame-servers (lame-servers;); категорії delegation-only (delegation-only; ); категорії edns-disabled ( edns-disabled; ); категорії rpz (rpz;); категорії rate-limit ( rate-limit; ); );

Якщо ми хочемо збирати всі запити з категорії queries, то розділ options файлу конфігурації необхідно додати параметр, який це дозволяє:

Querylog yes;

Перезапускаємо bind :

# systemctl restart named-chroot.service

Перевірка роботи 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 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:8 56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Тепер виконаємо ping site1.ru, щоб перевірити, як сервер підтримує нашу зону:

Дивимося, що у логах:

26-Sep-2015 19:28:01.660 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

Таким чином, дуже зручно відстежити, куди лізе комп'ютер. Наприклад, можна підняти тимчасово сервер dns, включити лог запитів. У клієнті вказати єдиний сервер, який ми налаштували. Далі можна відстежувати, наприклад, куди лізе вінда після завантаження без нашого відома. Або звідки вантажиться реклама у скайпі. Усі запити будуть акуратно складатися у файл, який можна спокійно аналізувати, та був, наприклад, .

Це все, що я хотів розповісти в цьому матеріалі. Тема налаштування bind (named) досить велика. Можливо, я ще повернуся до неї.

Онлайн курс "Адміністратор Linux"

Якщо у вас є бажання навчитися будувати та підтримувати високодоступні та надійні системи, рекомендую познайомитись з онлайн-курсом «Адміністратор Linux»в OTUS. Курс не для новачків, для вступу потрібні базові знання з мереж та встановлення Linux на віртуалку. Навчання триває 5 місяців, після чого успішні випускники курсу зможуть пройти співбесіду у партнерів. Перевірте себе на вступному тесті і дивіться програму детальніше.

DNS- система доменних імен - розподілена система, яка здатна на запит містить ім'я хоста повідомити його IP адресу. Структура DNS схожа на файлову систему Linux, вся база має деревоподібну структуру, вгорі якої розташований корінь . ). Саме з точки починається вся система доменних імен. За точкою може слідувати ru, com, net, info та ін. Домени, що беруть свій початок від кореня, тобто ru., Com., Net.називаються доменами першого рівня, домени виду сайт. називаються доменами другого рівня, а виду file.сайт. - домени третього рівняі так далі. Зверніть увагу на точку наприкінці прикладів. Імена, що записуються таким прикладом, називаються абсолютним (FQDN). Якщо точка не вказана, це ім'я розглядається як відносне. Т. е.. сайт.

Навіщо використовувати DNS?

1) Уявіть, що вам необхідно звернутися до мережного ресурсу під назвою host(це файл сервер, в якому зберігаються всі файли співробітників) ім'я hostмає IPадреса 192.168.200.20 і якщо у вас немає служби перетворюючої IP адреси на імена, то ви повинні набирати саме IP адресу 192.168.200.20, щоб потрапити на файл сервер. Що ж легко запам'ятати ім'я host або набір цифр 192.168.200.20?

2) Другий варіант відноситься до виходу в інтернет, вам наприклад необхідно потрапити на FTP сервер в інтернеті з ім'ям ftp.сайт, а IP адреса допустимо 89.111.176.87.

Так от, якщо в першому варіанті зовсім не потрібно встановлювати і налаштовувати DNS сервер, а можна просто швидко налаштувати, наприклад службу WINS, то для виходу в інтернет він вам просто необхідний (не будемо ми постійно запам'ятовувати цифри коли намагаємося звернутися до якогось ресурсу в інтернеті). Інше питання чи потрібно його налаштовувати, якщо провайдер надав вам свої DNS сервери?

DNS сервер може використовуватися як: первинний та вторинний, рекурсивний та перенаправник запитів.

Первинний(master) здійснює завантаження даних для зони з файлу на машині сервера, а вторинний (slave) отримує дані від первинного DNS. DNS сервер може бути первинним для однієї зони та вторинним для іншої.

Рекурсивний серверстворюється у великих організаціях зі швидкісним підключенням до мережі. Він не прив'язаний до серверів провайдера, є гнучким і безпечним.

Перенаправник запитівнадсилає запит від клієнта до сервера провайдера. Сервер провайдера обробляє безліч запитів клієнтів, має великий кеш та швидкісне підключення.

Основні записи DNS.

А - відповідність між ім'ям та IP адресою
АААА - відповідність між ім'ям та IPv6 адресою
CNAME – канонічне ім'я (синонім)
MX - вказує на поштовий сервер для цього домену
NS - DNS сервер для домену
PTR – канонічне ім'я
SOA - початковий запис, що вказує, де зберігається інформація про сервер.
SRV – сервери для сервісів.

Встановлення BIND.
Установку BIND будемо проводити на centOs5.
Має сервер під ім'ям ns1..168.200.1

yum install bind

Налаштування BIND
Створюємо та наповнюємо конфігураційний файл

vi /var/named/chroot/etc/named.conf

options (
directory "/var/named/";
dump-file "/var/run/named_dump.bd";
statistics-file "/var/run/named.stats";
};
zone "сайт" in (
type master;
file "сайт.db";
};
zone "200.168.192.IN-ADDR.ARPA." IN (
type master;
file "192.168.200.db";
};

zone "0.0.127.IN-ADDR.ARPA." IN (
type master;
файл "127.0.0.db";
};

zone "." (
type hint;
файл "named.ca";
};

Створюємо файли зон для сайту.db, 192.168.0.db, 127.0.0.db, named.ca.

vi /var/named/chroot/var/named/сайт.db# Пряма зона для відображення імен в адреси.

$ TTL 1H; 1 hour
сайт IN SOA ns1.сайт. root.сайт (22
3H
1H
1W
1H)

; Сервери імен
NS ns1.сайт

;Для каконічних імен
ns1.сайт. IN 1H A 192.168.200.1
host1.сайт. IN 1H A 192.168.200.154
;Псевдоніми
gw1.сайт. IN 1H CNAME host1.сайт.
www.сайт. IN 1H CNAME host1.сайт.

vi /var/named/chroot/var/named/192.168.200.db# Зворотна зона для відображення адрес в імена.

$ TTL 3600; 1 hour
200.168.192.in-addr.arpa IN SOA ns1.сайт. root.сайт (21
3H
1H
1W
1H)
; Сервери імен
200.168.192.in-addr.arpa IN NS ns1.сайт

; канонич імена
1.200.168.192.in-addr.arpa PTR ns1.сайт.
154.200.168.192.in-addr.arpa PTR host1.сайт.

vi /var/named/chroot/var/name/127.0.0.db# loopback адреса для направлення пакетів собі.

$ TTL 3600; 1 hour
0.0.127.in-addr.arpa IN SOA ns1.сайт. root.сайт (21
3H
1H
1W
1H)

0.0.127.in-addr.arpa IN NS ns1.сайт
0.0.127.in-addr.arpa. IN PTR localhost.

vi /var/named/chroot/var/named/named.ca#кореневі сервери

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 192.228.79.201
;
; 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
;
. 3600 000 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
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

Запуск та зупинення сервера/etc/init.d/named (start stop restart)
Утиліти для тестування DNS: host, nslookup, dig.
Докладніші налаштування DNS читайте man bind, книга DNS та BIND та ін.

У статті розглянемо розгортку Master і Slave DNS-серверів BIND (Berkeley Internet Name Domain) на ОС CentOS 6.4 minimal. Перед тим, як виконати всі дії, описані в цій статті, необхідно, щоб була налаштована мережа, встановлені system-config-firewall-tui та Midnight Commander. Всю первинну настройку CentOS можна прочитати.

На обох машинах:

встановлюємо Midnight Commander:

встановлюємо system-config-firewall-tui:

yum install system-config-firewall-tui -y

вводимо в командному рядку

iptables -A INPUT -p udp -m state -state NEW -m udp -dport 53 -j ACCEPT

встановлюємо BIND:

yum install bind-chroot bind-utils –y

Запустимо утиліту конфігурування файрволу та налаштуємо:

system-config-firewall-tui

Відзначимо зірочкою DNS

Тиснемо "Вперед". Відзначимо інтерфейс eth0 і тиснемо "Вперед"

Тиснемо "Вперед". Відзначимо інтерфейс для маскараду eth0 і тиснемо "Вперед"

Тиснемо "Вперед".

Тиснемо "Вперед".

Тиснемо "Вперед".

Тиснемо "Вперед".

Тиснемо «Закрити».

Тиснемо "OK".

Тиснемо «Так». Готово.

Вимикаємо SELINUX:

у /etc/selinux/config виправимо на SELINUX=disabled

Тепер згенеруємо ключ:

dnssec-keygen -a HMAC-MD5 -b 128 -n USER rndckey

Ця команда створить два файли у поточному каталозі. У файлі *.private у третьому рядку буде розташований ключ виду: wGmtcnMtn9od+ndTc20tGg==

Після цього відкриваємо файл /etc/resolv.confі на самому початку в нього пропишемо:

nameserver 192.168.0.191

nameserver 192.168.0.192

Master DNS сервер (IP: 192.168.0.191 ім'я хоста: ns1.localserver12.ru):

створимо каталог /etc/named/master

mkdir /etc/named/master

передамо в господарство бінду

chown -R named:named /etc/named/master

Відкриваємо /etc/named.conf. У ньому перевіряємо наявність наведених нижче опцій. Якщо їх немає – додаємо, якщо вони відрізняються – виправляємо:

listen-on port 53 (127.0.0.1; 192.168.0.191; );

allow-transfer ( 192.168.0.192; );

notify yes;

zone «localserver12.ru» IN (

type master;

файл "/etc/named/master/localserver12.ru";

/* Path to ISC DLV key */)

dnssec-enable yes;

dnssec-validation yes;

dnssec-lookaside auto;

Створимо файл localserver12.ruу каталозі /etc/named/master

touch /etc/named/master/localserver12.ru

Передамо його в господарство бінду:

chown -R named:named /etc/named/master/localserver12.ru

Пропишемо в нього наступне (приблизно як на картинці):

Стартуємо бинд

Заганяємо BIND в автозавантаження, щоб стартував під час завантаження системи

Master DNS-сервер готовий.

Slave DNS сервер (IP: 192.168.0.192 ім'я хоста: ns2.localserver12.ru):

створимо каталог /etc/named/slave

Передамо його у господарство бінду

chown -R named:named /etc/named/slave

Відкриваємо /etc/named.conf. У ньому перевіряємо наявність наведених нижче опцій. Якщо їх немає – додаємо, якщо вони відрізняються – виправляємо:

listen-on port 53 (127.0.0.1; 192.168.0.192; );

allow-recursion ( 192.168.0.0/24; );

recursion yes;

allow-transfer ( none; );

notify no;

zone «localserver12.ru» (

type slave;

файл "/etc/named/slave/localserver12.ru";

masters (192.168.0.191; );

Також перевіряємо наявність таких рядків (якщо ні – додати перед рядком /* Path to ISC DLV key */)

Dnssec-enable yes;

Dnssec-validation yes;

Dnssec-lookaside auto;

Стартуємо бинд

Заганяємо його в автозавантаження, щоб стартував під час завантаження системи

Slave сервер DNS готовий. Також після перезапуску до каталогу /etc/named/slave автоматично підтягнеться файл localserver12.ru

Тепер перевіримо:

на слейві вводимо команду

dig @ns1.localserver12.ru localserver12.ru axfr

і на майстрі таку

dig @ns2.localserver12.ru localserver12.ru axfr

в обох випадках виводяться дані та DNS записи з файлу localserver12.ru

Всі. DNS сервер готовий.


Якщо Вам допомогла стаття, ви можете віддячити автору:
перерахувати на WMR гаманець (WebMoney): R301575071888
перерахувати на Яндекс.Гаманець: 410011003938168
або на PayPal:

Пропонуємо до вашої уваги новий курс від команди The Codeby- "Тестування Веб-Додатків на проникнення з нуля". Загальна теорія, підготовка робочого оточення, пасивний фазинг та фінгерпринт, Активний фазинг, Вразливості, Пост-експлуатація, Інструментальні засоби, Social Engeneering та багато іншого.


Домени мають як мінімум два DNS сервери, один називається первинним сервером імен (ns1), а інший – вторинним сервером імен (ns2). Вторинні сервери зазвичай задіяні при проблемах з первинним сервером DNS: якщо один сервер недоступний, другий стає активним. Можливі і складніші схеми з використанням балансування навантаження, фаєрволів та кластерів.

Всі DNS записи певного домену додаються до первинного сервера імен. Вторинний сервер просто синхронізує всю інформацію, отримуючи її від первинного, виходячи з параметрів, заданих первинному сервері.

Ця інструкція опише, як створити первинний DNS сервер, який працює на CentOS. Будь ласка, зверніть увагу, що сервер DNS, представлений в цій інструкції, буде публічним DNS, це означає, що сервер буде відповідати на запити від будь-якої IP адреси. Як обмежити доступ до сервера, описано в цій інструкції.

Перед тим, як ми почнемо, хотілося б згадати, що DNS може бути встановлений з або без chroot jail оточенням. Оточення chroot jail обмежує сервер DNS певною директорією в системі, на відміну від повного системного доступу на сервері. Таким чином, будь-яка вразливість сервера DNS не скомпромітує всю систему. Обмеження DNS сервера в певній директорії (процес називається chrooting) також корисне у тестових умовах.

Ціль

Ми налаштуємо сервер DNS в тестових умовах для домену example.tst, який є гіпотетичним (не існуючим) доменом. Таким чином, ми не втрутимося випадково в роботу будь-яких реальних доменів.

У цьому домені є три наступні сервери.

Сервер IP адреса служби, Що Хостяться FQDN
Сервер A 172.16.1.1 Mail mail.example.tst
Сервер B 172.16.1.2 Web, FTP www.example.tst
ftp.example.tst
Сервер C 172.16.1.3 Primary DNS server ns1.example.tst

Ми налаштуємо первинний DNS сервер і додамо необхідний домен та DNS записи як показано в таблиці.

Налаштовуємо імена хостів

Усі хости мають бути коректно визначені з погляду FQDN. Це може бути зроблено з використанням наступного методу.

Ті, хто любить графічний інтерфейс, можуть користуватися інструментами NetworkManaget. Для цього наберіть команду nmtui. Відкриється такий псевдографічний інтерфейс:

Вибираєте "Змінити ім'я вузла" та вводите ns1.example.tst

Коли готово, натискаєте та ОК.

Ще один спосіб, лише в одну команду:

Hostnamectl set-hostname ns1.example.tst

Після встановлення ім'я хоста може бути перевірено наступною командою.

# hostname ns1.example.tst

Hostnamectl status

Перед тим, як перейти до наступного кроку, переконайтеся, що ім'я хоста для всіх серверів встановлено належним чином.

Встановлення пакетів

Ми будемо використовувати bind для DNS, який легко може бути встановлений командою yum.

Встановлення DNS без chroot:

# yum install bind

Установка DNS з chroot:

# yum install bind bind-chroot

Підготовка конфігураційних файлів

Як згадувалося раніше, bind може бути налаштований з або без chroot. Шляхи трохи різняться, залежно від того, чи було встановлено chroot.

Шлях до конфігураційного файлу Шлях до файлів зони
Без chroot /etc/ /var/named/
З chroot /var/named/chroot/etc/ /var/named/chroot/var/named/

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

Робимо резервну копію файлу /etc/named.conf

Cp /etc/named.conf /etc/named.conf.bak

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf

Тепер, коли є резервна копія конфігураційного файлу, а сам оригінальний файл змінено, рухаємося далі.

# vim /etc/named.conf

# vim /var/named/chroot/etc/named.conf

Наступні рядки були додані/змінені.

Options ( ## шлях до файлів зон ## directory "/var/named"; ## пенера надсилаємо запити на публічний DNS сервер Google для нелокальних доменів ## forwarders ( 8.8.8.8; ); ); ## оголошення прямої зони для example.tst ## zone "example.tst" IN ( type master; file "example-fz"; ## файл для прямої зони розміщений в /var/named ## allow-update ( none; ) ;); ## оголошення зворотної зони для мережі 172.16.1.0 ## zone "1.16.172.in-addr.arpa" IN ( type master; file "rz-172-16-1"; ## файл для зворотної зони розміщений в /var /named ## allow-update (none; ););

Підготовка файлів зон

Дефолтні файли зон автоматично створені в /var/named або /var/named/chroot/var/named (для chroot).

Маючи на увазі, що дефолтні файли зон не представлені, ми можемо скопіювати файли зразків із /usr.

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named

Чудово. Тепер дефолтні файли зони готові, ми створюємо власні файли зони для example.tst і мережі 172.16.1.0. Поки ми створюємо файли зони, слід пам'ятати таке.

  • Символ '@' означає NULL у файлах зони.
  • Кожен запис повного доменне ім'я (FQDN) закінчується точкою '.' наприклад. mail.example.tst. Без крапки, будуть проблеми.

1. Пряма зона

Пряма зона містить карту перетворень з імен IP адреси. Для публічних доменів, DNS доменів, розміщених на хостингах, міститься у файлі прямої зони.

# vim /var/named/example-fz

# vim /var/named/chroot/var/named/example-fz $TTL 1D @ IN SOA ns1.example.tst. mial.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. IN A 172.16.1.3 mail IN A 172.16.1.1 IN MX 10 mail.example.tst. www IN A 172.16.1.2 ns1 IN A 172.16.1.3 ftp IN CNAME www.example.tst.

Пояснення: Всередині файлу зони SOA означає початок авторизації. Це повне доменне ім'я авторитетного сервера імен. Після повного доменне ім'я, йде контактний email адресу. Оскільки ми не можемо використовувати '@' в [email protected], ми перезаписуємо email адресу як mial.example.tst.

  • NS: Ім'я сервера
  • A: A запис або запис адреси – це IP адреса
  • MX: Mail Exchanger запис. Тут ми використовуємо лише один MX з пріоритетом 10. У разі множини MX, ми можемо використовувати різні цифрові пріоритети. Нижній номер виграє. Наприклад, MX 0 краще ніж MX 1.
  • CNAME: ім'я у канонічному вигляді. Якщо на сервері розміщено безліч служб, ймовірно, що безліч імен будуть перетворюватися до одного серверу. CNAME сигналізує, що інші імена сервер може мати та відсилає до імені, яке міститься в A запису.

2. Зворотна зона

Зворотна зона містить карту перетворень з IP-адрес в імена. Тут ми створюємо зворотну зону мережі 172.16.1.0. У реальному домені DNS сервер власника публічного IP блоку міститься у файлі зворотної зони.

# vim /var/named/rz-172-16-1

# vim /var/named/chroot/var/named/rz-172-16-1 $TTL 1D @ IN SOA ns1.example.tst. sarmed.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. 1 IN PTR mail.example.tst. 2 IN PTR www.example.tst. 3 IN PTR ns1.example.tst.

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

  • PTR: PTR або запис покажчика, вона вказує на повне доменне ім'я

Завершення

Тепер, коли файли зон готові, ми налаштуємо роздільну здатність файлів зони.

# chgrp named /var/named/*

# chgrp named /var/named/chroot/var/named/*

Зараз ми задамо IP-адресу DNS сервера.

# vim /etc/resolv.conf nameserver 172.16.1.3

Нарешті, ми можемо запустити службу DNS і переконатися, що її додано до автозапуску.

# service named restart # chkconfig named on

Тестування DNS

Ми можемо використовувати dig або nslookup для тестування DNS. Спочатку ми встановимо необхідні пакети.

# yum install bind-utils

1. Тестування прямої зони з використанням dig

# dig example.tst;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 172.16.1.3 ;; AUTHORITY SECTION: example.com. 86400 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 86400 IN A 172.16.1.3

2. Перевірка PTR за допомогою dig

Коли ви використовуєте для тестування dig вам завжди слід шукати статус "NOERROR". Будь-який інший стан означає, що щось не так.

# dig-x 172.16.1.1;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415 ;; QUESTION SECTION: ;1.1.17.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst. ;; AUTHORITY SECTION: 1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst. ;; ADDITIONAL SECTION: ns1.example.tst. 86400 IN A 172.16.1.3

3. Перевірка MX за допомогою dig

# dig example.tst mx;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405 ;; QUESTION SECTION: ;example.tst. IN MX ;; ANSWER SECTION: example.tst. 14366 IN MX 10 mail.example.tst.

Підказки під час вирішення проблем

  1. У мене вимкнено SELinux.
  2. Переконайтеся, що ваш фаєрвол не блокує UDP порт 53
  3. /var/log/messages повинен містити корисну інформацію у випадку, якщо щось не так
  4. Переконайтеся, що власники файлів зон є користувачем 'named'
  5. Переконайтеся, що IP-адреса DNS сервера стоїть на першому місці в /etc/resolv.conf
  6. Якщо ви використовуєте example.tst у лабораторних умовах, переконайтеся, що сервер від'єднано від Інтернету, оскільки example.tst — це неіснуючий домен.

Підсумуємо, цей урок фокусується на хостингу домену example.tst у лабораторних умовах для демонстраційних цілей. Будь ласка, пам'ятайте, що це не інструкція щодо створення публічного DNS сервера, наприклад, DNS сервера, який відповідає на запити від будь-яких IP адрес. Якщо ви налаштовуєте робочий DNS сервер, переконайтеся, що перевірили, які політики стосуються публічних DNS. Інший урок висвітлює створення вторинного DNS, обмеження доступу до DNS серверу та реалізацію DNSSEC.

Гарант є довіреним посередником між Учасниками під час угоди.




ПОХОДЖЕННЯ СТАТТІ