Автор: Paul Cobbaut
Дата публікації: 24 травня 2015 р.
Переклад: A.Панін
Дата перекладу: 11 липня 2015 р.

Розділ 4. Вступна інформація про сервери DNS

4.3. Кешируючі сервери DNS

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

Існує два види серверів кешуючих DNS. Це сервери DNS, що використовують перенаправляючі сервери DNS, а також сервери DNS, які використовують кореневі сервери DNS.

4.3.1. Кешируючий сервер DNS, що не використовує сервер, що перенаправляє

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

На ілюстрації нижче показано процес надсилання клієнтом запиту інформації про IP-адресу для доменного імені linux-training.be. Наш сервер, що кеширує, з'єднається з кореневим сервером і буде перенаправлений на сервер, що обслуговує домен верхнього рівня.be. Після цього він з'єднається з сервером, який обслуговує домен верхнього рівня.be, і буде перенаправлений на один із серверів імен організації Openminds. Один із цих серверів імен (в даному випадку nsq.openminds.be) відповість на запит, передавши IP-адресу сервера з доменним ім'ям linux-training.be. Після того, як наш кешуючий сервер передасть цю інформацію клієнту, клієнт зможе з'єднатися з веб-сайтом, що розглядається.

При використанні ніфера tcpdump у процесі дозволу даного імені можна отримати наступний висновок (перші 20 символів кожного рядка були видалені).

192.168.1.103.41251 > M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr aining.be. (46) M.ROOT-SERVERS.NET.domain > 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268 > d.ns.dns.be.domain: 3855 linux-training. be. (46) d.ns.dns.be.domain > 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514 > ns2.openminds.be.domain: 60888% A? linux-train ing.be. (46) ns2.openminds.be.domain > 192.168.1.103.7514: 60888*- 1/0/1 A 188.93.155.\ 87 (62)

4.3.2. Кешируючий сервер DNS, який використовує перенаправляючий сервер

Кешируючий сервер DNS , що використовує сервер, що перенаправляє, є сервером DNS, який отримує всю необхідну інформацію від сервера, що перенаправляє (forwarder). Як перенаправляючий сервер DNS може виступати, наприклад, сервер DNS інтернет-провайдера.

На ілюстрації вище показаний сервер DNS в локальній мережі компанії, який використовує сервер DNS, що надається інтернет-провайдером, як перенаправляючий сервер DNS . У тому випадку, якщо IP-адресою сервера DNS, що надається інтернет провайдером, є адреса 212.71.8.10, у файлі конфігурації named.conf сервера DNS компанії повинні бути наступні рядки:

Forwarders (212.71.8.10; );

Крім того, ви також можете налаштувати ваш DNS-сервер для роботи з умовно-перенаправляючими серверами DNS (conditional forwarders). Опис умовно-перенаправляючого сервера DNS у файлі конфігурації виглядає так:

Zone "someotherdomain.local" ( type forward; forward only; forwarders ( 10.104.42.1; ); );

4.3.3. Ітеративний чи рекурсивний запит

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

Сервер DNS, який керує зоною DNS, називається авторитативним сервером DNS (authoritative DNS server) для даної зони. Пам'ятайте про те, що зона DNS є лише набором ресурсних записів.

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

Вторинний сервер отримує копію бази даних зони DNS від первинного сервера у процесі передачі даних зони DNS (zone transfer). Запити здійснення передач даних зон DNS надсилаються вторинними серверами через певні часові інтервали. Тривалість цих часових інтервалів встановлюються в рамках ресурсного запису SOA.

Ви можете ініціювати примусове оновлення даних DNS за допомогою утиліти rndc . У прикладі нижче ініціюється передача даних зони DNS fred.local , і навіть виводиться відповідний фрагмент файлу системного журналу /var/log/syslog .

[email protected]:/etc/bind# rndc refresh fred.local [email protected]:/etc/bind# grep fred /var/log/syslog | tail -7 | cut -c38- zone fred.local/IN: повідомлення повідомлень (серіал 1) отриманий контрольний канал "Refresh fred.local" zone fred.local/IN: Transfer started. transfer of "fred.local/IN" від 10.104.109.1#53: connected using 10.104.33.30#57367 zone fred.local/IN: transfered serial 2 transfer of "fred.local/IN" від 10.104.109.1#53 completed: 1 messages, 10 records, 264 bytes, 0.001 secs (264000 bytes/sec) zone fred.local/IN: sending notifies (serial 2) [email protected]:/etc/bind#

При додаванні вторинного сервера DNS в зону DNS ви можете налаштувати цей сервер таким чином, що він виявиться провідним сервером DNS (slave DNS server) по відношенню до первинного сервера. Первинний сервер DNS виявиться провідним сервером DNS (master DNS server) стосовно вторинному серверу.

Найчастіше первинний сервер DNS є провідним сервером, що працює з усіма керованими серверами. Іноді ведений сервер може бути одночасно провідним сервером для ведених серверів наступного рівня. На ілюстрації нижче сервер з ім'ям ns1 є первинним сервером, а сервери з іменами ns2, ns3 та ns4 – вторинними серверами. Хоча провідним сервером для серверів з іменами ns2 і ns3 є сервер з ім'ям ns1, провідним сервером для сервера з ім'ям ns4 є сервер з ім'ям ns2.

Ресурсний запис SOA містить значення частоти оновлення даних зони DNS з ім'ям refresh. У разі, якщо це значення встановлюється рівним 30 хвилин, ведений сервер надсилатиме запити на передачу копії даних зони DNS через кожні 30 хвилин. Також цей запис містить значення тривалості періоду очікування з ім'ям retry. Це значення використовується, якщо провідний сервер не відповідає на останній запит передачі даних зони DNS. Значення з ім'ям expiry time встановлює період, протягом якого ведений сервер може відповідати запити від клієнтів без оновлення даних зони DNS.

Нижче наведено приклад використання утиліти nslookup для читання даних ресурсного запису SOA зони DNS (linux-training.be).

[email protected]:~# nslookup > set type=SOA > server ns1.openminds.be > linux-training.be Server: ns1.openminds.be Address: 195.47.215.14#53 linux-training.be origin = ns1.openminds.be mail addr = hostmaster.openminds.be serial = 2321001133 refresh = 14400 re0 = 04

Передачі даних зон DNS здійснюються лише у випадках зміни даних у базах даних зон DNS (тобто тоді, коли відбувається додавання, видалення або зміна однієї або більшої кількості ресурсних записів на стороні провідного сервера). Ведомий сервер здійснює порівняння номера версії (serial number) власної копії ресурсного запису SOA з номером версії ресурсного запису SOA відповідного провідного сервера. Якщо номери версій збігаються, оновлення даних не потрібне (оскільки інші ресурсні записи не були додані, видалені або змінені). У тому ж випадку, якщо номер версії ресурсного запису SOA на стороні веденого сервера менший за номер версії того самого запису на стороні відповідного провідного сервера, буде здійснено запит передачі даних зони DNS.

Нижче наведено знімок вікна сніфера Wireshark з даними, перехопленими під час передачі даних зони DNS.

4.9. Повні або часткові передачі даних зон DNS

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

Випуск WordPress 5.3 покращує та розширює представлений у WordPress 5.0 редактор блоків новим блоком, більш інтуїтивною взаємодією та покращеною доступністю. Нові функції у редакторі […]

Після дев'яти місяців розробки доступний мультимедіа-пакет FFmpeg 4.2, що включає набір додатків та колекцію бібліотек для операцій над різними мультимедіа-форматами (запис, перетворення та […]

Нові функції в Linux Mint 19.2 Cinnamon

Linux Mint 19.2 є випуском із довгостроковою підтримкою, який підтримуватиметься до 2023 року. Він поставляється з оновленим програмним забезпеченням та містить доопрацювання та безліч нових […]

Вийшов дистрибутив Linux Mint 19.2

Представлено реліз дистрибутива Linux Mint 19.2, другого оновлення гілки Linux Mint 19.x, що формується на пакетній базі Ubuntu 18.04 LTS та підтримується до 2023 року. Дистрибутив повністю сумісний […]

Доступні нові сервісні релізи BIND, які містять виправлення помилок та покращення функцій. Нові випуски можуть бути завантажені зі сторінки завантажень на сайті розробника: […]

Exim – агент передачі повідомлень (MTA), розроблений у Кембриджському університеті для використання у системах Unix, підключених до Інтернету. Він знаходиться у вільному доступі відповідно до […]

Після двох років розробки представлений реліз ZFS on Linux 0.8.0, реалізації файлової системи ZFS, оформленої як модуля для ядра Linux. Робота модуля перевірена з ядрами Linux з 2.6.32 по […]

У WordPress 5.1.1 усунуто вразливість, що дозволяє отримати контроль над сайтом

Комітет IETF (Internet Engineering Task Force), що займається розвитком протоколів та архітектури інтернету, завершив формування RFC для протоколу ACME (Automatic Certificate Management Environment) […]

Некомерційний посвідчувальний центр Let's Encrypt, який контролює співтовариство і надає сертифікати безоплатно всім охочим, підбив підсумки минулого року і розповів про плани на 2019 рік. […]

Вийшла нова версія Libreoffice - Libreoffice 6.2

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) resolving "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

З кожним роком швидкість інтернету - як останньої милі, так і магістральних каналів стає дедалі вищою. Лише одне незмінно - латентність вже вперлася у фізичні обмеження: швидкість світла в оптоволокні - близько 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-мегабітний інтернет. А вже для повільних (радіо)лінків з великою латентністю та втратою пакетів - і зовсім різниця може бути як між небом та землею.