Мій особистий сервер dns

В. Водолазки, к.т.н. ([email protected])

Мій особистий сервер DNS

Нарешті Internet набуває людські риси. Сьогодні кожен бажаючий отримує від мережі не тільки послуги електронної пошти, а й повний доступ практично до всіх ресурсів Мережі. На жаль, в більшості випадків використовується так зване "типове PPP-підключення", що реалізовується без додатка уявних зусиль з використанням Windows95 і броузера WWW Explorer або Netscape.

Основне призначення служби доменних імен (DNS - D omain N ame S ystem) складається у спрощенні навігації в Internet для людини, якій символьну послідовність запам'ятати набагато легше, ніж десяток цифр. Комп'ютера же навпаки - оперувати з числами набагато легше, та й швидше. Для вирішення цієї суперечності було створено ціле сімейство різних серверів DNS - програм, єдиною функцією яких є перетворення імен типу www.geocities.com в 123.22.22.11 і навпаки.

забезпечити максимальний рівень привілеїв в обслуговуванні запитів DNS - ви адже єдиний і улюблений користувач;

прискорити процедуру встановлення з'єднання з серверами Internet.

ps -ax | grep named

Швидше за все, named в системі не встановлений, але краще все ж перевірити. Пов'язано це з режимом подальшого запуску сервера: початковий запуск здійснюється за допомогою команди named, а перезапуск, при працюючому сервері - командою named.restart. У будь-якому випадку, якщо у вашій ізольованій системі вже запущений сервер DNS, його необхідно відключити, або, кажучи мовою UNIX - "вбити" відповідний процес.

По-перше, база даних хостів мережі / etc / hosts. Чи не відволікаючись на історичні подробиці, відзначимо, що localhost прописаний в ній зазвичай першої ж рядком. За подробицями за змістом цього файлу відсилаю вас до статті [1] і до керівництв користувача. Справедливості заради мушу зазначити, що ця проблема в будь-якому дистрибутиві Linux, як правило, вирішена. Друга проблема безпосередньо пов'язана з маршрутизацією в мережі. Перш за все, вам необхідно визначитися, які маршрути для вашої машини вже визначені. Для цього скористайтеся командою route:

Kernel routing table

Destination Gateway Genmask Flags MSS Window Use Iface

loopback * 255.0.0.0 U 3584 0 1 lo

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

route add 127.0.0.1

Взагалі кажучи, для багатозадачних і багатокористувацьких систем, до яких Linux можна віднести, з дещо більшою підставою, ніж гучну Windows95 застосовно одне важливе правило: потрібно вводити тільки ті установки середовища та конфігурації, які необхідні для вирішення конкретних, поточних завдань. Ну да ладно, після того, як ми включили в маршрут доступу (і в ініціалізації файл) наш localhost, можна приступати до налаштування власне DNS-сервера. Перевантажувати комп'ютер не потрібно! По-перше, ми ще не закінчили, а по-друге, всі зміни вступають в силу негайно після виконання відповідних утиліт, і ви повинні лише подбати про те, щоб необхідні настройки встановлювалися при подальших запусках системи.

Отже, приступимо до конфігурації named. При завантаженні сервер DNS здійснює зчитування власного ініціалізації файлу, який зазвичай має ім'я /etc/named.boot. Ви, безумовно, можете змінити і каталог, і ім'я ініціалізації файлу, але для цього вам доведеться самостійно перекомпілювати named з вихідних текстів, самостійно замінивши вказане ім'я файлу на альтернативне. Складного в цьому процесі нічого немає, але ми відволікатися на це не будемо.

; Завантажувальний файл кешуючого DNS

У цьому файлі ви вказуєте комп'ютера на дві обставини:

Всі інші конфігураційні файли сервера DNS розміщуються в каталозі / var / named. Це традиційний каталог для їх розміщення, але якщо вам більше подобається, ви можете створити для цих цілей підкаталог, наприклад, в / etc.

Сервер здійснює тільки кешування, при цьому кешування підлягають всі доменні імена (оскільки в полі домену вказана точка - корінь для будь-якого доменного імені), а в файлі /var/named/root.cache буде поміщений набір кореневих серверів мережі, звідки named буде отримувати всю необхідну інформацію.

Тепер саме час поглянути на вміст root.cache. У наведеному нижче прикладі поміщено вміст робочого конфігураційного файлу з мого комп'ютера. Не варто мудрувати, просто створіть такий же і користуйтеся. Єдине зауваження: всі рядки заповнюються з першого символу - ніяких прогалин "для краси"! І не забудьте про точки в кінці імен серверів.

; для кореня доменної системи імен (останні інстанції)

IN NS NS.INTERNIC.NET.

IN NS AOS.ARL.ARMY.MIL.

IN NS NS1.ISI.EDU.

IN NS TERP.UMD.EDU.

AOS.ARL.ARMY.MIL. 999999 IN A 192.5.25.82

NS1.ISI.EDU. 999999 IN A 128.9.0.107

C.PSI.NET. 999999 IN A 192.33.4.12

TERP.UMD.EDU. 999999 IN A 128.8.10.90

NS.NASA.GOV. 999999 IN A 128.102.16.10

NS.NASA.GOV. 999999 IN A 192.52.195.10

NIC.NORDU.NET. 999999 IN A 192.36.148.17

NS.ISC.ORG. 999999 IN A 192.5.5.241

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

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

search .rinet.ru .ru

Тепер можна приступати до перевірки нашого сервера. Підключіться до провайдера, і після встановлення з'єднання запустіть сервер DNS, ввівши команду named. Після запуску named самостійно перейде у фоновий режим і поверне управління в командну рядок оболонки. Перевірити, чи все в порядку, можна проаналізувавши файл / var / log / messages. в кінці якого ви повинні виявити що-небудь на зразок:

Sep 1 13:05:48 vvv named [197]: cache zone "" loaded (serial 0)

Sep 1 13:05:48 vvv named [198]: Ready to answer queries.

У разі появи будь-яких повідомлень про помилки (і природно, відсутності повідомлення про готовність обробляти запити) проаналізуйте файли named.boot і root.cache. Швидше за все, ви допустили помилку. Поправте "слова" в цих файлах, "убийте" процес named і перезапустіть його ще раз.

Оскільки ви в даний момент підключені до мережі, то доцільно відразу ж перевірити працездатність нашого сервера. Спробуйте скористатися вже розглядав раніше [1] командами ping і traceroute. А спробувавши, порівняйте з результатами, отриманими для найпростішого PPP-підключення з використанням DNS-сервера вашого провайдера.

Нам буде потрібно лише внести в файл named.boot деякі зміни, які наведені нижче:

; Завантажувальний файл кешуючого DNS

forwarders 195.23.1.65 195.23.1.89

Тепер залишилося лише перезавантажити сервер DNS, наприклад, за допомогою named.restart і можна проводити порівняльні випробування. На моєму комп'ютері середній час доступу до вузла мережі скоротилася приблизно на 10-15%, що якщо і не є радикальним засобом для порятунку сімейного бюджету, то, у всякому разі, скорочує час марного очікування біля екрану.

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

Для запуску цієї програми ви повинні перш за все виконати дві умови:

підключитися до мережі Internet,

запустити сервер named.

Після цього ми запускаємо nslookup з формуванням протоколу роботи програми:

nslookup | tee root.log

В результаті nslookup проаналізує нашу запис в root.cache і поверне нам повідомлення такого змісту: