До еш DNS – це тимчасова база даних, в якій зберігається інформація про попередні пошуки DNS. Іншими словами, щоразу, коли ви відвідуєте веб-сайт, ваша ОС та веб-браузер будуть вести облік домену та відповідної IP-адреси. Це виключає необхідність повторюваних запитів до віддалених DNS-серверів і дозволяє вашій ОС або браузеру швидко вирішувати URL-адреси веб-сайту.

Однак у деяких ситуаціях, таких як усунення несправностей у мережі або після зміни перетворювачів DNS, необхідно очистити кеш DNS. Це очистить кешовані записи DNS і здійснить подальший пошук для дозволу домену на основі новоналаштованих параметрів DNS.

У цій статті наведено інструкції з очищення кешу DNS у різних операційних системах та веб-браузерах.

Очистити/видалити кеш DNS у Windows

Процес очищення DNS-кешу є однаковим для всіх версій Windows. Вам потрібно відкрити командний рядок із правами адміністратора та запустити ipconfig /flushdns.

Windows 10 та Windows 8

Щоб очистити кеш DNS у Windows 10 та 8, виконайте такі дії:

1. Введіть cmd у рядку пошуку Windows.

2. ipconfig /flushdns

   Windows 7

   Щоб очистити кеш DNS у Windows 7, виконайте такі дії:

   1. Натисніть кнопку Пуск.
   2. Введіть cmd у поле пошуку меню «Пуск».
   3. Клацніть правою кнопкою миші на командному рядку та виберіть пункт Запуск від імені адміністратора. Це відкриє вікно командного рядка.
   4. У командному рядку введіть наступний рядок та натисніть Enter:

      ipconfig /flushdns

      У разі успіху система поверне таке повідомлення:

      Windows IP Configuration Очевидно flushed the DNS Resolver Cache.

   Очистити/видалити кеш DNS у Linux

   У Linux немає кешування DNS на рівні ОС, якщо не встановлена ​​і не запущена служба кешування, така як Systemd-Resolved, DNSMasq або Nscd. Процес очищення DNS-кешу відрізняється залежно від дистрибутива та служби кешування, яку ви використовуєте.

   Systemd Resolved

   У більшості сучасних дистрибутивів Linux, як-от , використовується системний дозволений сервіс для кешування записів DNS.

   Щоб дізнатися, чи запущено службу, виконайте:

   sudo systemctl is-active systemd-resolved.service

   Якщо служба працює, команда надрукує active, інакше ви побачите inactive.

   Щоб очистити DNS-кеш Systemd Resolved, потрібно ввести наступну команду.

   sudo systemd-resolve --flush-caches

   У разі успіху команда не повертає жодного повідомлення.

   Dnsmasq

   Dnsmasq – це полегшений сервер кешування імен DHCP та DNS.

   Якщо ваша система використовує DNSMasq як сервер кешування, для очищення кеша DNS вам необхідно перезапустити службу Dnsmasq:

   sudo systemctl restart dnsmasq.service

   sudo service dnsmasq restart

   Nscd

   Nscd – це демон кешування, і він є найкращою системою кешування DNS для більшості дистрибутивів на основі RedHat.

   Якщо ваша система використовує Nscd, для очищення кешу DNS необхідно перезапустити службу Nscd:

   sudo systemctl restart nscd.service

   sudo service nscd restart

   Очистити/видалити кеш DNS на MacOS

   Команда очищення кешу в MacOS трохи відрізняється залежно від версії, що використовується. Команда має бути запущена як користувач із правами системного адміністратора (користувач sudo).

   Щоб очистити кеш DNS у MacOS, виконайте такі дії:

   1. Відкрийте Finder.
   2. Перейдіть до Програми > Утиліти > Термінал. Це відкриє вікно терміналу.
   3. У командному рядку введіть наступний рядок та натисніть Enter:

      sudo killall -HUP mDNSResponder

      Введіть пароль sudo і знову натисніть Enter. У разі успіху система не повертає жодних повідомлень.

   Для попередніх версій MacOS команда очищення кешу відрізняється.

   MacOS версії 10.11 та 10.9

   sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder

   MacOS версія 10.10

   sudo discoveryutil mdnsflushcache sudo discoveryutil udnsflushcaches

   MacOS версії 10.6 та 10.5

   sudo dscacheutil -flushcache

   Очистити / видалити кеш DNS браузера

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

   Google Chrome

   Щоб очистити DNS-кеш Google Chrome, виконайте такі дії:

   1. Відкрийте нову вкладку та введіть в адресний рядок Chrome: chrome://net-internals/#dns.
   2. Натисніть кнопку «Очистити кеш хоста».

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

   1. Натисніть CTRL+Shift+Del, щоб відкрити діалогове вікно «Очистити дані перегляду».
   2. Виберіть діапазон часу. Виберіть "Весь час", щоб видалити всі.
   3. Встановіть прапорці «Файли cookie та інші дані сайту» та «Кешовані зображення та файли».
   4. Натисніть кнопку «Очистити дані».

   Цей метод повинен працювати для всіх браузерів на основі Chrome, включаючи Chromium, Vivaldi та Opera.

   FireFox

   Щоб очистити DNS-кеш Firefox, виконайте такі дії:

   1. У верхньому правому куті клацніть значок гамбургера, щоб відкрити меню Firefox:
   2. Натисніть на ⚙ Options (Preferences) посилання.
   3. Натисніть на вкладку «Конфіденційність та безпека» або «Конфіденційність» ліворуч.
   4. Прокрутіть вниз до розділу History і натисніть кнопку Clear History.
   5. Виберіть часовий діапазон, щоб очистити. Виберіть "Всі", щоб видалити все.
   6. Виберіть усі поля та натисніть «Очистити зараз».

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

   1. Відкрийте нову вкладку та введіть about:config в адресний рядок Firefox.
   2. Знайдіть network.dnsCacheExpiration, тимчасово встановіть значення 0 і натисніть кнопку ОК. Після цього змініть значення за промовчанням та натисніть кнопку ОК.
   3. Знайдіть network.dnsCacheEntries, тимчасово встановіть значення 0 і натисніть кнопку ОК. Після цього змініть значення за промовчанням та натисніть кнопку ОК.

   Висновок

   Ви дізналися, як очистити або очистити кеш DNS в операційних системах Windows, Linux та MacOS.

   Linux та MacOS можуть використовувати команду dig для запиту DNS та усунення проблем із DNS.

   Якщо у вас є питання або відгуки, не соромтеся залишати коментарі.

З кожним роком швидкість інтернету - як останньої милі, так і магістральних каналів стає дедалі вищою. Лише одне незмінно - латентність вже вперлася у фізичні обмеження: швидкість світла в оптоволокні - близько 200тис кілометрів на секунду, і відповідно, швидше ніж за ~150ms відповідь від сервера через атлантичний океан не отримати в доступній для огляду перспективі (хоча звичайно є вишукування, на зразок оптоволокна з повітряним серцевиною або радіорелейного зв'язку, але це для простих смертних навряд чи доступно).

Коли ми намагаємося, наприклад, з Росії відкрити web-сайт, розташований у США (його NS сервера ймовірно там же), і домен не знайшовся в DNS-кеші вашого провайдера - то чекати доведеться довго навіть на гігабітному інтернеті, можливо навіть цілу секунду: поки ми через океан отримаємо імена NS серверів домену, поки розрізнемо їх IP, поки відправимо і отримаємо власне сам DNS запит…

Кілька років тому Google завела свої публічні DNS сервери, а для агітації переходу на них - вони розробили утилітку NameBench, яка проганяє тести DNS з вашої історії серфінгу і показує, наскільки Google DNS швидше за DNS сервера вашого провайдера.

Але мені вдалося зробити свій DNS сервер, який працює швидше за Google Public DNS, і в цій короткій замітці хочу поділитися результатами.

PDNSD

pdnsd- кешуючий DNS proxy. Крім банального кешування DNS запитів (з можливістю жорстко задавати мінімальний TTL - може бути потрібно на дуже поганому інтернеті), він вміє відсилати запит одночасно на кілька «батьківських» DNS серверів, і віддавати клієнту першу відповідь, що повернулася.

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

Ставиться в Ubuntu – банальним apt-get.

Пара моментів у конфізі

global (perm_cache=10240; //Максимальний розмір кешу в кілобайтах. //По дефолту було 1024, всі записи у мене не влазили. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // Мінімальний час збереження запису в кеші // Навіть якщо TTL прийде менше 60 хвилин - буде 60 хвилин max_ttl = 1w; // Максимальний час збереження запису в кеші neg_ttl = 5m; [..] par_queries=3; //Кількість одночасно опитуваних "батьківських" DNS серверів ) server ( label = "main"; ip = 85.21.192.5 //Тут 4 сервери, якщо перші 3 не дадуть відповідь, то буде відправлено запит на 4 -й, 213.234.192.7 //Перші 2 сервери - це сервер вашого провайдера, і якогось сусіднього, 8.8.4.4 //Це Google Public DNS - у них закешировано все рідкісне і резолюють вони швидко, 8.8.8.8; ] )

В принципі, кешування можна зробити менш агресивним (min_ttl = 1m наприклад), але за рік роботи особливих проблем не виникло. У разі проблем - при бажанні можна витерти один запис із кешу:
sudo pdnsd-ctl record 3.14.by delete або відразу все:
sudo pdnsd-ctl empty-cache

Результати тестування в NameBench

Бачимо, що для 50% запитів відповідь ми отримуємо менш ніж за 10мс, для 85% швидше за Google Public DNS, ну а далі результати природно збігаються з гуглом.

За результатами тестів NameBench нам радісно повідомляє:

8.8.8.8 Slower replica of SYS-192.167.0.98 8.8.4.4 Slower replica of SYS-192.167.0.98

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

Уявіть, що було б, якби ми мали пам'ятати IP-Адреси всіх веб-сайтів, які ми використовуємо щодня. Навіть якби у нас була приголомшлива пам'ять, процес переходу на сайт був би сміховинно повільним і трудомістким.

А як щодо того, якщо нам потрібно відвідувати кілька веб-сайтів або використовувати кілька програм, які знаходяться на одному комп'ютері чи віртуальному хості? Це буде один із найгірших головних болів, які тільки можна уявити — не кажучи вже про можливість зміни IP-адреси, пов'язані з веб-сайтом або програмою, без попередження.

Тільки сама думка про це була б достатньою причиною через деякий час відмовитися від використання Інтернету або внутрішніх мереж.

Саме так виглядатиме світ без системи доменних імен (також відомий як DNS). На щастя, ця служба вирішує всі проблеми, згадані вище, навіть якщо зв'язок між IP-Адресою і доменним ім'ям змінюється.

З цієї причини в цій статті ми дізнаємося, як налаштувати та використовувати простий DNS-сервер, службу, яка дозволить перекладати доменні імена в IP-Адреси і навпаки.

Дозволи імен DNS

Для невеликих мереж, які не піддаються частим змінам, файл /etc/hostsможна використовувати як рудиментарний метод визначення імені домену для дозволу IP-Адреси.

Цей файл, який використовує дуже простий синтаксис, дозволяє зв'язати ім'я (і/або псевдонім) з IP-Адресою. Це виконується так:

Наприклад,

192.168.0.1 gateway gateway.mydomain.com 192.168.0.2 web web.mydomain.com

Таким чином, ви можете зв'язатися з веб-машиною або на ім'я web.mydomain.com, або за її IP-Адресу.

Для великих мереж або тих, які піддаються частим змінам, використання файлу /etc/hostsдля дозволу імен доменів на IP-Адреси не буде прийнятним рішенням. Саме тут виникає потреба у спеціальному сервісі.

Заліземо за лаштунки роботи DNS. DNS-Сервер запитує велику базу даних у вигляді дерева, яке починається з кореневої ( «.» ) зони.

Наступний малюнок допоможе нам зрозуміти про що йдеться:

На зображенні вище коренева зона (.) містить com, eduі netдомени першого рівня. Кожен із цих доменів управляється (або може керуватися) різними організаціями, щоб уникнути залежності від однієї великої — центральної. Це дозволяє правильно розподіляти запити щодо ієрархії.

Давайте подивимося, що відбувається:

1. Коли клієнт робить запит на DNS-сервер для web1.sales.me.comсервер надсилає запит на верхній (кореневий) DNS-сервер, який надсилає запит на сервер імен до зони .com.

Це, своєю чергою, надсилає запит на сервер імен наступного рівня (до зони me.com), а потім на sales.me.com. Цей процес повторюється стільки разів, скільки необхідно, доки повне доменне ім'я (повне доменне ім'я, web1.sales.me.comу цьому прикладі) не буде повернуто сервером імен зони, в якій він знаходиться.

2. У цьому прикладі сервер імен sales.me.comвідповідає за адресу web1.sales.me.comі повертає бажану асоціацію для імені домену- IPта іншу інформацію (якщо він налаштований для цього).

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

Встановлення та налаштування DNS-сервера

У Linuxнайбільш використовуваним DNS-сервером є bind(скорочення від Berkeley Internet Name Daemon), яке може бути встановлене таким чином:

# yum install bind bind-utils # zypper install bind bind-utils # aptitude install bind9 bind9utils

Після того, як ми встановили bindта пов'язані з ним утиліти, зробимо копію файлу конфігурації перед внесенням будь-яких змін:

# cp /etc/named.conf /etc/named.conf.orig # cp /etc/bind/named.conf /etc/bind/named.conf.orig

Потім давайте відкриємо named.confі перейдемо до блоку параметрів, де нам потрібно вказати наступні налаштування для рекурсивного сервера, що кешує IP 192.168.0.18/24, до якого можуть звертатися тільки хости в тій самій мережі (як міра безпеки).

Параметри прямої зони використовуються для вказівки того, які сервери імен необхідно спочатку запитувати (у наступному прикладі ми використовуємо сервери імен Google) для хостів поза нашим доменом:

Options ( ... listen-on port 53 ( 127.0.0.1; 192.168.0.18); allow-query ( localhost; 192.168.0.0/24; ); recursion yes; forwarders ( 8.8.8.8; 8.8.4.4; ); )

Поза блоком опцій ми визначимо нашу зону sales.me.com(В Ubuntu це зазвичай робиться в окремому файлі з ім'ям named.conf.local), який відображає домен із заданим IP-адресою та зворотною зоною для зіставлення IP-Адреси до відповідної області.

Однак фактична конфігурація кожної зони проходитиме в окремих файлах, як зазначено в директиві файлу («master» означає, що ми будемо використовувати лише один DNS-сервер).

Додайте наступні рядки до файлу named.conf:

Zone "sales.me.com." IN ( type master; file "/var/named/sales.me.com.zone"; ); zone "0.168.192.in-addr.arpa" IN ( type master; file "/var/named/0.162.198.in-addr.arpa.zone"; );

Зверніть увагу, що inaddr.arpa(для адрес IPv4) та ip6.arpa(для IPv6) є угодами конфігурацій зворотної зони.

Після збереження вищезгаданих змін named.confми можемо перевірити наявність помилок таким чином:

# named-checkconf /etc/named.conf

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

Налаштування DNS-зон

У файлах /var/named/sales.me.com.zoneі /var/named/0.168.192.in-addr.arpa.zoneми налаштуємо пряму (домен → IP-адресу) та зворотну (IP-адресу → домен) зони.

Спочатку розглянемо пряму конфігурацію:

1. У верхній частині файлу ви знайдете рядок, що починається з TTL(скорочення від Time To Live), в якій зазначено, як довго кешована відповідь має «жити» перед його заміною на результати нового запиту.

У рядку, розташованому нижче, ми зв'яжемося з нашим доменом і вкажемо адресу електронної пошти, з якою мають бути надіслані повідомлення (зверніть увагу, що root.sales.me.comозначає ).

2. Запис SOA(Start of Authority) вказує, що ця система є авторитетним сервером імен для машин усередині домену sales.me.com.

За наявності двох серверів імен (одного ведучого та іншого підлеглого) для кожного домену потрібні наступні налаштування (хоча це не наш випадок, оскільки він не потрібен на іспиті, вони представлені тут для довідки):

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

У налаштуванні з провідним (вторинним) сервером імен Refreshвказує час, протягом якого вторинний сервер повинен перевіряти новий серійний номер із головного сервера.

Крім того, Retryповідомляє серверу, як часто вторинний об'єкт повинен намагатися зв'язатися з основним, якщо відповідь від первинної не отримана, тоді як Expireвказує, коли визначення зони у вторинному режимі більше не діє після того, як стає неможливо отримати відповідь від головного сервера, та негативний TTL- Це час, протягом якого не кешується неіснуючий домен ( NXdomain).

3. NS-Запис вказує, що є авторитетним DNS-Сервером для нашого домену (на який вказує знак @ на початку рядка).

4. Запис A(для адрес IPv4) або AAAA(для адрес IPv6) перетворює імена в IP-Адреси.

У наведеному нижче прикладі:

Dns: 192.168.0.18 (the DNS server itself) web1: 192.168.0.29 (a web server inside the sales.me.com zone) .0.30 (another mail server)

5. Запис MXвказує імена уповноважених агентів передачі пошти (MTA) для цього домену. Ім'я хоста має бути попередньо номером, що вказує пріоритет, який повинен мати поточний поштовий сервер за наявності двох або більше MTAдля домену (чим нижче значення, тим вищий пріоритет) у наступному прикладі, mail1є основним, тоді як mail2є вторинним MTA).

6. Запис CNAMEвстановлює псевдонім (www.web1) для хоста (web1).

ВАЖЛИВО: важлива наявність точки (.) наприкінці імен.

$TTL 604800 @ IN SOA sales.me.com. root.sales.me.com. (2016051101; Serial 10800; Refresh 3600; Retry 604800; Expire 604800); Negative TTL; @ IN NS dns.sales.me.com. dns IN A 192.168.0.18 web1 IN A 192.168.0.29 mail1 IN A 192.168.0.28 mail2 IN A 192.168.0.30 @ IN MX 10 mail1.sales.me.com. @ IN MX 20 mail2.sales.me.com. www.web1 IN CNAME web1

Погляньмо на конфігурацію зворотної зони (/var/named/0.168.192.in-addr.arpa.zone). Запис SOAтака сама, як і в попередньому файлі, тоді як останні три рядки із записом PTR(покажчик) вказують останній октет на адресу хостів IPv4 mail1, web1і mail2(192.168.0.28, 192.168.0.29, та 192.168.0.30, відповідно).

$TTL 604800 @ IN SOA sales.me.com. root.sales.me.com. (2016051101; Serial 10800; Refresh 3600; Retry 604800; Expire 604800); Minimum TTL @ IN NS dns.sales.me.com. 28 IN PTR mail1.sales.me.com. 29 IN PTR web1.sales.me.com. 30 IN PTR mail2.sales.me.com.

Ви можете перевірити файли зон на наявність помилок:

# named-checkzone sales.me.com /var/named/sales.me.com.zone # named-checkzone 0.168.192.in-addr.arpa /var/named/0.168.192.in-addr.arpa.zone

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

В іншому випадку ви отримаєте повідомлення про помилку та пораду щодо її усунення:

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

У CentOSі openSUSEвиконайте:

# systemctl restart named

І не забудьте також увімкнути його:

# systemctl enable named

У Ubuntu:

$ sudo service bind9 restart

Зрештою, вам потрібно буде відредагувати конфігурацію основних мережних інтерфейсів:

In /etc/sysconfig/network-scripts/ifcfg-enp0s3 for CentOS and openSUSE ---- DNS1=192.168.0.18 ---- In /etc/network/interfaces for Ubuntu ---- dns-nameservers 192.168.0.18

Тепер перезапустіть службу мережі, щоб застосувати зміни.

Тестування DNS-сервера

На цьому етапі ми готові запросити наш DNS-сервер для локальних та зовнішніх імен та адрес. Наступні команди повернуть IP-адреса, пов'язана з хостом web1:

# host web1.sales.me.com # host web1 # host www.web1

Як ми можемо дізнатися, хто обробляє електронні листи для sales.me.com? Дізнатися це легко – просто запитайте записи MXдля домену:

# host -t mx sales.me.com

Аналогічно, давайте проведемо зворотний запит. Це допоможе нам дізнатися ім'я IP-Адреси:

# host 192.168.0.28 # host 192.168.0.29

Ви можете спробувати ті самі операції для зовнішніх хостів:

Щоб переконатися, що запити справді проходять через наш DNS-Сервер, давайте включимо ведення журналу:

# rndc querylog

І перевірте файл /var/log/messages(CentOS і openSUSE):

# host -t mx linux.com # host 8.8.8.8

Щоб вимкнути ведення журналу DNS, введіть ще раз:

# rndc querylog

У Ubuntuдля включення ведення журналу потрібно додати наступний незалежний блок (той же рівень, що і блок опцій) /etc/bind/named.conf:

Logging ( channel query_log ( file "/var/log/bind9/query.log"; severity dynamic; print-category yes; print-severity yes; print-time yes; ); category queries ( query_log; ); );

Зверніть увагу, що файл журналу повинен існувати і бути доступним для запису на ім'я.

Підсумки

У цій статті ми пояснили, як налаштувати базовий рекурсивний, кешуючий DNS-сервер та як налаштувати зони для домену.

Щоб забезпечити правильну роботу вашого DNS-сервера, не забудьте дозволити цю службу у вашому брандмауері (порт TCP 53), як описано в («Налаштування брандмауера Iptables для увімкнення віддаленого доступу до послуг»).

.

Курси Cisco та Linux з працевлаштуванням!

Поспішайте подати заявку! Залишилося кілька місць. Групи стартують 22 липня, а наступна 19 серпня, 23 вересня, 21 жовтня, 25 листопада, 16 грудня, 20 січня, 24 лютого.

Що Ви отримаєте?

• Допоможемо стати експертом у мережевому адмініструванні та отримати міжнародні сертифікати Cisco CCNA Routing & Switching або Linux LPI.
• Пропонуємо перевірену програму та підручник експертів із Cisco Networking Academy та Linux Professional Institute, сертифікованих інструкторів та особистого куратора.
• Допоможемо з працевлаштуванням та зробити кар'єру. 100% наших випускників працевлаштовуються.

Як відбувається навчання?

• Проводимо вечірні онлайн-лекції на нашій платформі або навчайтеся на базі Київського офісу.
• Запитаємо у вас про зручний для практик і підлаштуємося: розуміємо, що часу вчитися мало.
• Якщо хочете індивідуальний графік – обговоримо та здійснимо.
• Виставимо чіткі дедлайн для самоорганізації. Особистий куратор буде на зв'язку, щоб відповісти на запитання, проконсультувати та мотивувати дотримуватись термінів складання іспитів.

А ще допоможемо Вам:

Призначення DNS це переклад доменних імен, що легко запам'ятовуються людиною в IP адреси, які розуміють комп'ютери, цей процес називається Дозвіл імен. Що нам дасть установка власного сервера, що кеширує DNS? Це трохи прискорить відгук сайтів + ​​Linux не дуже добре сприймає імена NetBios, адже іноді доводиться знаходити комп'ютери або принтери всередині локальної мережі, а хочеться це робити за іменами.

Запам'ятовувати IP адреси- не зручно, а постійно лазити до журналу роботи DHCP сервера- теж не наш метод. Ось для таких випадків і потрібний DNS у локальній мережі. Сама установка пакета bind9 не відрізняється складністю, затики зазвичай виникають на стадії його конфігурування, т.к. після конфігураційних файлів системи, що легко читаються, на людину звалюється незрозумілий синтаксис, до речі, дуже схожий на мову програмування С. Т.к. сервер буде працювати всередині локальної мережі, то немає сенсу переносити його в chroot оточення і все налаштування займає зовсім небагато часу. На цьому, ліричну частину, можна завершити, переходимо до встановлення та налаштування.

Встановимо DNS сервер Bind9:

# apt - get install bind9

Після завершення, завантаження та встановлення нам необхідно відредагувати його конфігураційний файл:

# vim / etc / bind / named . conf. options

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

options ( directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want// для того, щоб говорити про те, що потрібно fix firewall to allow multiple// Ports to talk. See http://www.kb.cert.org/vuls/id/800113// If your ISP надається один або більше IP-адреси для стабільного// Nameservers, ви хотіли б, щоб використовувати їх як forwarders.// Uncomment the following block, і insert the addresses replacing// the all-0"s placeholder. // forwarders ( // 0.0.0.0; // ); auth - nxdomain no ; # conform to RFC1035 listen - on - v6 ( any ; ); );

Секція forwarders відповідає за те, куди буде передаватися DNS запит на дозвіл імені, якщо його немає у власній базі. Останнім часом мене зовсім не тішить, робота цих серверів у провайдера з цього можна підключити сторонні наприклад гугловські, запам'ятати IP дуже легко 8.8.8.8, на його прикладі я і вестиму налаштування, але ніхто не заважає використовувати те, що вам подобаються більше.

Редагуємо секцію, для початку з неї потрібно зняти коментарі та додати сторонні DNS, якщо є необхідність додати кілька серверів, наприклад на той випадок, якщо сервер google не витримає ваших запитів і поламається:), то IP інших серверів можна написати в стовпчик, тоді можна домогтися більш значної стійкості до відмови.

forwarders (8.8.8.8; 193.58.251.251; //Російська служба DNS-SkyDNS};

У цю секцію краще вписати IP того сервера, який у вас вказаний у файлі /etc/resolv.confабо вписати туди до секції nameserverцей IP. Зберігаємо зміни та виходимо. Перезапускаємо сервер та перевіряємо. Набираємо у командному рядку nslookup mail.ru
Повинно видати:

Non-authoritative answer: Name: mail. ru Addresses : 94.100.191.202

Це говорить про те, що наш сервер не є головним в обслуговуванні цієї зони (mail.ru), але запити додав у кеш!
Тепер потрібно створити ДНС зону для нашої мережі, щоб машини могли знаходити різні мережеві сервіси - можуть бути, наприклад, мережеві принтери, вони можуть бути як самостійними так і розшарованими на інших робочих станціях.
Нашу зону можна назвати orgname -тобто. Назва організації.
Насамперед створюємо зону, для цього відредагуємо named.conf.local

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

і додамо до нього таке:

zone "orgname" (type master; file "/etc/bind/db.orgname";);

Зберігаємо та виходимо
Тепер нам необхідно створити файл налаштування зони

# vim / etc / bind / db. orgname

і вставляємо в нього таке:
(Прошу уважно поставитися до синтаксису конфігураційного файлу, навіть точки мають значення)

@IN SOA orgname. root. orgname. (20101015 4h; час оновлення - 4 години 1h; повтор кожну годину 1w; як довго зберігати інформацію - 1 тиждень 1d); TTL (час життя) запису - 1 день @ IN NS orgname. ; ім'я сервера імен @ IN A 192.168.10.1; A - запис - IP адреса нашого ДНС сервера, який обслуговує цю зону, @ означає що це коренева зона. * IN CNAME @ printer IN A 192.168.10.25 ; Можна створити ДНС запис мережного принтера, який знаходиться за адресою 192.168.10.25

Тепер, при додаванні нового мережевого пристрою, вам необхідно зробити 2 речі:
1) Зарезервувати IP адресу на DHCP сервері, про те, як це зробити, можна прочитати в статті-Настроювання DHCP сервера
2) Створити DNS зону для цього IP, вид devicename IN A XXX.XXX.XXX.XXX. Де: devicename-мережеве ім'я пристрою; XXX.XXX.XXX.XXX-його IP адреса яка зарезервована на DHCP сервері.

тепер нам потрібно відредагувати файл resolv.conf

# vim / etc / resolv. conf

і вписати туди:

nameserver 127.0.0.1

все, що там було можна закоментувати поставивши #
перезапуск сервер

# reboot

Зроблено це для того, щоб сервер шукав все у власній базі, а вже потім BIND перенаправлятиме запити до сервера 8.8.8.8 IP якого вписаний у директиві forwarders.
Тепер можна перевіряти працездатність:
Якщо тестування відбувається з під Windows:

ping devicename. orgname

Якщо тестуємо з-під Linux:

ping devicename. orgname - c 4

Повинні піти пінги на той IP, який ви вказали замість XXX.XXX.XXX.XXX

Можна також перевіряти швидкість обробки запитів командою dig

# dig @127.0.0.1 tut.by;<<>> DiG 9.9.5-9+deb8u6-Debian<<>> @127.0.0.1 tut.by; (1 server found);; Global options: +cmd;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310

DNS (Domain Name System) – важливий і досить складний у налаштуванні компонент, необхідний роботи веб-сайтів і серверів. Багато користувачів звертаються до DNS-серверів, які надає їхній хостинг-провайдер, проте власні DNS-сервери мають деякі переваги.

У цьому мануалі ви дізнаєтеся, як встановити Bind9 і налаштувати його як кешуючий або перенаправляючий DNS-сервер на сервері Ubuntu 14.04.

Вимоги

• Розуміння базових типів DNS-серверів. Ознайомитися з подробицями можна у .
• Дві машини, з яких хоч одна працює на Ubuntu 14.04. Перша машина буде налаштована як клієнт (IP-адреса 192.0.2.100), а друга – як DNS-сервер (192.0.2.1).

Ви навчитеся налаштовувати клієнтську машину для надсилання запитів через сервер DNS.

Кешируючий DNS-сервер

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

Коли кешуючий DNS-сервер відстежує відповідь на запит клієнта, він повертає відповідь клієнту, а також зберігає її в кеші протягом періоду часу, дозволеного значенням TTL відповідних DNS-записів. Потім кеш можна використовувати як джерело відповіді на наступні запити, щоб прискорити загальний час обробки запиту.

Майже всі DNS-сервери у вашій мережній конфігурації будуть кешуючими. Кешируючий DNS-сервер – гарний вибір для багатьох ситуацій. Якщо ви не бажаєте покладатися на DNS-сервери вашого хостинг-провайдера або інші загальнодоступні DNS-сервери, налаштуйте власний кешуючий DNS-сервер. Чим менша відстань від DNS-сервера до клієнтських машин, тим менший час обслуговування запитів DNS.

Перенаправляючий DNS-сервер

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

Перенаправляючий DNS-сервер має ті ж переваги, що і сервер, що кешує. Однак насправді він не виконує жодного рекурсивного запиту. Замість цього він перенаправляє всі запити на зовнішній сервер, а потім кешує результати для наступних запитів.

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

1: Встановлення Bind на DNS-сервер

Пакет Bind можна знайти в офіційній репозиторії Ubuntu. Оновіть індекс пакетів та встановіть Bind за допомогою менеджера apt. Також потрібно встановити пару залежностей.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

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

2: Налаштування кешируючого DNS-сервера

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

Конфігураційні файли Bind зберігаються у каталозі /etc/bind.

Більшість файлів редагувати не потрібно. Головний конфігураційний файл називається named.conf (named і bind – дві назви однієї програми). Цей файл посилається на файли named.conf.options, named.conf.local та named.conf.default-zones.

Для налаштування сервера кешування DNS-сервера потрібно відредагувати тільки named.conf.options.

sudo nano named.conf.options

Цей файл виглядає так (коментарі опущені для простоти):

options (
directory "/var/cache/bind";
dnssec-validation auto;

listen-on-v6 ( any; );
};

Щоб настроїти сервер, що кеширує, потрібно створити список контролю доступу, або ACL.

Потрібно захистити DNS-сервер, що обробляє рекурсивні запити від зловмисників. Атаки DNS-посилення особливо небезпечні, оскільки можуть залучити сервер до розподілених атак на відмову в обслуговуванні.

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

Для розміщення загальнодоступного рекурсивного DNS-сервера потрібне ретельне налаштування та адміністрування. Щоб запобігти зламу сервера, настройте список IP-адрес або діапазонів мережі, яким сервер зможе довіряти.

Перед блоком options додайте блок acl. Створіть мітку для групи ACL (у цьому мануалі група називається goodclients).

acl goodclients (
};
options (
. . .

У цьому блоці перерахуйте IP-адреси або мережі, які мають доступ до цього DNS-сервера. Оскільки сервер і клієнт працюють у підмережі /24, можна обмежити доступ до цієї підмережі. Також потрібно розблокувати localhost та localnets, які підключаються автоматично.

acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
. . .

Тепер у вас є ACL безпечних клієнтів. Можна регулювати дозвіл запитів у блоці options. Додайте до нього такі рядки:

options (
directory "/var/cache/bind";
recursion yes;

. . .

Блок options явно включає в себе рекурсію, а потім налаштовує параметр allow-query для використання списку ACL. Для посилання на групу ACL також можна використовувати інший параметр, наприклад allow-recursion. При включеній рекурсії allow-recursion визначить список клієнтів, які можуть використовувати рекурсивні послуги.

Однак якщо параметр allow-recursion не встановлений, Bind повертається до списку allow-query-cache, потім до списку allow-query і, нарешті, до стандартних списків localnets і localhost. Оскільки ми налаштовуємо лише сервер, що кешує (він не має власних зон і не пересилає запити), список allow-query завжди буде застосовуватися тільки до рекурсії. Це найзагальніший спосіб визначення ACL.

Збережіть та закрийте файл.

Це все налаштування, які потрібно додати до конфігураційного файлу кешируючого DNS-сервера.

Примітка: Якщо ви хочете використовувати тільки цей тип DNS, переходьте до перевірки конфігурацій, перезапустіть сервіс та налаштуйте клієнта.

3: Налаштування перенаправляючого DNS-сервера

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

На даний момент файл named.conf.options виглядає так:

acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 ( any; );
};

Можна використовувати той же список ACL, щоб обмежити сервер DNS конкретним списком клієнтів. Однак необхідно трохи змінити конфігурацію, щоб сервер більше не намагався виконувати рекурсивні запити.

Не змінюйте значення recursion на no. Перенаправляючий сервер таки підтримує рекурсивні послуги. Щоб настроїти сервер, що перенаправляє, потрібно створити список кешуючих серверів, на які він буде перенаправляти запити.

Це робиться в блоці options(). Спочатку потрібно створити в ньому новий блок forwarders, де зберігатимуться IP-адреси рекурсивних серверів імен, на які потрібно перенаправляти запити. У цьому випадку це будуть DNS-сервери Google (8.8.8.8 та 8.8.4.4):

. . .
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
forwarders (

8.8.8.8;

8.8.4.4;

};
. . .

В результаті конфігурація виглядає так:

acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
forwarders (
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 ( any; );
};

Остання зміна стосується параметра dnssec. При поточній конфігурації та залежно від налаштування DNS-серверів, на які перенаправляються запити, у логах можуть з'явитися такі помилки:

Jun 25 15:03:29 cache named: error (спостереження DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8#53
Jun 25 15:03:29 Опубліковано: error (no valid DS) "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53

Щоб уникнути їх, потрібно змінити значення параметра dnssec-validation на yes та явно дозволити dnssec.

. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .

Збережіть та закрийте файл. Налаштування перенаправляючого сервера DNS завершено.

4: Перевірка налаштувань та перезапуск Bind

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

Щоб перевірити синтаксис конфігураційних файлів, введіть:

sudo named-checkconf

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

Якщо ви отримали повідомлення про помилку, виправте її та повторіть перевірку.

Після цього можна перезапустити демон Bind, щоб оновити налаштування.

sudo service bind9 restart

Після цього потрібно перевірити логи сервера. Запустіть на сервер команду:

sudo tail -f /var/log/syslog

Тепер відкрийте новий термінал і починайте налаштування клієнтської машини.

5: Налаштування клієнта

Увійдіть на клієнтську машину. Переконайтеся, що клієнт був вказаний у групі ACL налаштованого сервера DNS. В іншому випадку DNS-сервер відмовиться обслуговувати запити клієнта.

Відредагуйте файл /etc/resolv.conf, щоб скерувати сервер на сервер імен.

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

Відкрийте файл за допомогою sudo у текстовому редакторі:

sudo nano /etc/resolv.conf

У файлі потрібно перерахувати DNS-сервери, які використовуватимуться для дозволу запитів. Для цього використовуйте директиву nameserver. Закоментуйте всі поточні записи та додайте рядок nameserver, який вказує на ваш DNS-сервер:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Збережіть та закрийте файл.

Тепер можна надіслати тестовий запит, щоб переконатися, що він дозволяється правильно.

Для цього можна використовувати ping:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- google.com ping statistics ---
1 пакетів transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms