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

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

Чому до жаль? Справа в тому, що використання "простих" засобів, як правило, призводить до отримання найпростіших же результатів. Я вже писав про те, що викорис-тання більш перспективної операційної системи Linux [1] дозволяє підвищити реальну пропускну здатність орендованого комутованого каналу (телефонної лінії) майже вдвічі! Але і це не межа. У згаданій мною публікації виграш досягався виключи-кові за рахунок ефективної роботи ядра операційної системи Linux, яка спочатку орієнтувалася на роботу в мережах TCP/IP. Але цим можливості організації ефективної роботи в мережі жодним чином не вичерпуються! Візьмемо хоча б службу DNS ...

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

Завдання, здавалося б, тривіальна: таблиця з двох полів і великої кількості рядків -- знайшов значення в одному полі, взяв з другого, і все в порядку ... Але на практиці і розробники, і користувачі зіткнулися з кількома перешкодами. По-перше, не-безперервно зростаюча мережа постійно збільшує кількість використаних IP-адрес, що призводить до розбухання нашої таблиці відповідностей до, прямо-таки скажімо, просто непри-особистих розмірів. По-друге, інформація в цій таблиці схильна до непередбачуваних змін: вузли з'являються і зникають, змінюють свої адреси та імена і так далі. І, нако-нец, найбільш неприємний момент - Internet не є однорідною системою, керованої будь-чиєї "залізною рукою" і роздача адрес IP (і присвоєння їм доменних імен) проис-ходить якщо й не зовсім хаотично, то, у всякому разі, децентралізоване.

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

Кінцеві користувачі, як правило, підключаються до DNS-серверів своїх провал-деров, які працюють в режимі авторитетного сервера для своїх користувачів і осущ-ствляют кешування всіх інших запитів. З точки зору користувача Windows ця проблема по-іншому і не вирішується, але як тільки ви переходите в UNIX і починаєте гово-вірить з Internet спільною мовою, у вас з'являються вельми цікаві можливості.

Однією з них є створення власного локального кешуючого DNS-сервера.

Справді, при кожному зверненні до віддаленого вузла вам доводиться запитувати у провайдера IP-адреса. Клієнтів, подібних вам, у провайдера кілька десятків, і на обслуговування вашого запиту йде дорогоцінний час, який, як ви можете помітити, якщо будете уважно розглядати рядок стану в Netscape Navigator чи Explorer може становити 30-40 секунд на кожному зверненні до DNS . А при установці власного сервера ви зможете:? забезпечити максимальний рівень привілеїв в обслуговуванні запитів DNS - ви адже єдиний і улюблений користувач;? створити базу даних DNS вузлів, до яких постійно звертаєтеся, і дізнатися з отриманої інформації чимало цікавого (докладніше про це написано в [2]);? прискорити процедуру встановлення з'єднання із серверами Internet.

Оскільки авторитетом для вашої IP-адреси (байдуже, статичного чи дина - мічного) є ваш провайдер, вам досить встановити простий кешуючий сер-вер. На щастя, програма DNS-сервера - bind, єдина для всіх типів серверів (включаючи но-мер версії - 4.9.3), а конкретний режим роботи визначається тільки параметрами настрій-ки. Сам же сервер входить в обов'язковому порядку у всі дистрибутиви Linux, і нерідко зустрічається в вихідних текстах. Є тільки один неув'язочка, про яку варто попередити заздалегідь. Пакет c DNS-сервером і в RedHat і в Slackware називається bind (який-небудь вер-ті), але виконується програма сервера має зовсім інша назва - named! По-цьому, перевіряючи, чи встановлений сервер DNS? вашій системі, вам доведеться скориста-тися наступними командами: ps-ax "grep named Швидше за все, named в системі не встановлений, але краще все-таки перевірити. Пов'язано це з режимом подальшого запуску сервера: початковий запуск здійснюється за допомогою команди named, а перезапуск, при працюючому сервері - командою named.restart. У будь-якому випадку, якщо у вашій ізольованій системі вже запущений DNS-сервер, його необ-обхідно відключити, або, кажучи мовою UNIX - "убити" відповідний процес.

Тепер необхідно перевірити налаштування мережного інтерфейсу TCP/IP. Для того щоб локальні сервери вашої системи могли обслуговувати запити локальних ж клієнтських програм, в TCP/IP передбачено спеціальну адресу IP, званий localhost, який має значення 127.0.0.1.

Поширена думка говорить, що його адресу в будь-якому комп'ютері є синонімом адреси поточного комп'ютера і може використовуватися поряд із звичайним адресою при обра-щении до локальних ресурсів. Дійсність ж виявляється більш суворою. Адреса localhost не може використовуватися зовнішніми користувачами для звернення до ваших ресурсів, оскільки при такому зверненні будь-який комп'ютер починає опитувати тільки свої власні ресурси. В іншому адреса localhost підпорядковується всім правилами, вста-новлення для адрес IP. А це означає, що ви повинні не забути прописати його у файлі/etc/hosts, а також підключити маршрут доступу до цього файлу. Як не дивно, але досить часто саме відсутність цих двох простих налаштувань унеможливлює роботу з серве-рами і клієнтами TCP/IP. Але давайте по порядку.

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

Справедливості ради повинен відзначити, що ця проблема в будь-якому дистрибутиві Linux, як правило, вирішена. Друга проблема безпосередньо пов'язана з маршрутизацією в мережі. Перш за все - го, вам необхідно визначитися, які маршрути для вашої машини вже визначені. Для цього скористайтеся командою route: # route Kernel routing table Destination Gateway Genmask Flags MSS Window Use Iface loopback * 255.0.0.0 U 3584 0 1 lo Ось що повинна повідомляти ваша система при правильній конфігурації мережевого ін-терфейса (при цьому ми вважаємо, що Ethernet-інтерфейсу у вашій системі немає - в іншому випадку процес конфігурування стане навіть простіше, адже у вас з'явиться власний "апаратний" IP-адресу, до якого ви зможете звертатися без оглядки на особливості lo-calhost). Зверніть увагу, що ми не бачимо вказівки на наш улюблений адреса localhost. Справа в тому, що в даному випадку команді route передувало включення до таблиці маршрутів-тізаціі цілої підмережі 127.0.0.0, що, звичайно ж, вирішує наші проблеми, але за великим рахунком, є зайвим.

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

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

Оскільки ми припускаємо реалізувати тільки найпростіший, кешуючий DNS-сервер, то й особливих проблем з налаштуванням сервера поки не передбачається. Ось типове содер-жаніе файлу named.boot:;; Завантажувальний файл кешуючого DNS-сервера; directory/var/named cache.

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

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

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

;; Список серверів DNS, які є кінцевими авторитетами; для кореня доменної системи імен (останні інстанції);.

IN NS NS.INTERNIC.NET.

.

IN NS AOS.ARL.ARMY.MIL.

.

IN NS NS1.ISI.EDU.

.

IN NS C.PSI.NET.

.

IN NS TERP.UMD.EDU.

.

IN NS NS.NASA.GOV.

.

IN NS NIC.NORDU.NET.

.

IN NS NS.ISC.ORG.

;; --- Відповідність імен DNS-серверів; --- і їх IP-адрес; NS.INTERNIC.NET.

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

999999 IN A 128.63.4.82 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 В основному ці дані залишаються незмінними - можна сказати, що на перерахований-них вище серверах тримається вся доменна система імен. Тим не менше, періодично в мережі відбуваються зміни, і нижче ми розглянемо, як можна отримати більш свіжу ін - формацію.

Зараз же ми припустимо, що хоч одна з введених нами в конфігураційний файл серверів виявиться "на ходу" і завершимо процес конфігурування. Нам буде потрібно скорегувати значення файлу/etc/resolv.conf. Як ви, мабуть, пам'ятаєте, в цьому файлі міститься посилання на DNS-сервер, який обслуговує ваші запити. Раніше (див. [1]), ми по-місць у цей файл інформацію наступного змісту: domain rinet.ru nameserver 194.87.171.65 Тепер давайте внесемо деякі коректування. По-перше, замість domain ми, як і ставимо сучасну конструкцію search, а по-друге, зазначимо системі на необхід-тість використовувати наш власний сервер DNS. Ось що ми отримаємо в результаті: search. Rinet.ru. Ru nameserver 127.0.0.1 Що означає директива search? Вона вказує DNS-сервера, які домени необ-обхідно "трусити" при спробах з'єднання з будь-якими, що належать їм хостами. Але це в теорії, а на практиці він використовується для завдання скорочених доменних імен. Справді, припустимо, ви постійно працюєте в домені ru, і звертаєтеся до пошукової системі www.rambler.ru. При наведеній вище настроювання DNS ви можете просто використовувати запити типу www.rambler. Може бути, виграш не дуже значний? А тепер уявімо, що вам необхідно постійно звертатися до користувачам вузлів з двома і трьома крапками, наприклад: [email protected]. Оголосивши всю праву частину адреси в ключі search, ви можете відправляти пошту за адресою aivanov, як ніби-то ваш співрозмовник знаходиться не в Німеччині, а у вашій локальній мережі.

Тепер можна приступати до перевірки нашого сервера. Підключіться до провайдера, і після встановлення з'єднання запустіть DNS-сервер, ввівши команду named. Після запуску named самостійно перейде у фоновий режим і поверне управління в командну рядок оболонки. Перевірити, чи все в порядку, можна проаналізувавши файл / var/log/messages, в кінці якого ви повинні знайти що-небудь на кшталт: Sep 1 13:05:47 vvv named [197]: starting. named 4.9.3-BETA26 Sun Nov 26 20:58:49 CST 1995 ^ Iroot @ fuzzy:/tmp/bind-4.9.3-BETA26/named 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! А ось тепер давайте займемося оп-тімізаціей.

Давайте задумаємося, яким чином відбувається запит IP-адреси? Ваш DNS-сервер з ланцюжку намагається дістатися до авторитетного сервера тієї чи іншої зони, і при це що використовують обмежені ресурси вашого комутованого каналу. А сервер провайдера при тих же запитах може використовувати зовсім інше (за пропускної спроможності) по-стояла підключення до Internet. Звичайно, після того, як сервер завантажить в свій кеш напів-ченние адреси, ніякого паразитного трафіку не буде, але ж кеш ще треба завантажити! А чому б не примусити DNS-сервера провайдера виконувати за нас всю брудну роботу з первинного збору інформації? Named надає і таку можливість! Нам потрібно лише внести в файл named.boot деякі зміни, які наведені нижче:;; Завантажувальний файл кешуючого DNS-сервера; directory/var/named cache.

root.cache; Увага - адреси умовні, замініть їх на DNS-сервер; вашого провайдера forwarders 195.23.1.65 195.23.1.89 slave У результаті ваш DNS-сервер буде адресувати всі свої запити тільки зазначеним у рядку forwarders серверів (навчальні адреси наведені з тієї простої причини, що викорис-зова чужий сервер без дозволу адміністратора - поганий тон !).

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

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

Тепер має варто поговорити докладніше про авторитетних серверах. Само-самостійності наш DNS-сервер оновлювати інформацію про кореневих серверах мережі не стане.

Значить, ми повинні йому допомогти. Робиться це за допомогою команди nslookup, яка перед - призначена для інтерактивного тестування DNS-сервера.

Для запуску цієї програми ви повинні перш за все виконати дві умови:? підключитися до мережі Internet,? запустити сервер named.

Після цього ми запускаємо nslookup з формуванням протоколу роботи програми: nslookup "tee root.log У відповідь nslookup повідомить нам, що працює з DNS-сервером localhost (він же 127.0.0.1), і готова до обробки наших запитів. Якщо ви забули підключитися до Internet, програма просто зависне, а в / var/log/messages або/var/log/syslog ви знайдете повідомлення про те, що nslookup намагається достукатися до перерахованих вами в root.cache авторитетних серверів, але мережа, на жаль, недоступна (network is unreachable).

Тепер перевіримо, наскільки коректно nslookup розуміє збудовані нами відомості про авторитетних серверах мережі. Для цього нам буде потрібно ввести лише дві команди:> set type = ns>.

У результаті nslookup проаналізує нашу запис у root.cache і поверне нам пові-нення такого змісту: Server: localhost.rinet.ru Address: 127.0.0.1 Non-authoritative answer: (root) nameserver = G.ROOT-SERVERS.NET (root) nameserver = J.ROOT-SERVERS.NET (root) nameserver = K.ROOT-SERVERS.NET (root) nameserver = L.ROOT-SERVERS.NET (root) nameserver = M.ROOT-SERVERS.NET (root) nameserver = A.ROOT-SERVERS.NET (root) nameserver = H.ROOT-SERVERS.NET (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = I.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET Authoritative answers can be found from: G.ROOT-SERVERS.NETinternet address = 192.112.36.4 J.ROOT-SERVERS.NETinternet address = 198.41.0.10 K.ROOT-SERVERS.NETinternet address = 193.0.14.129 L.ROOT-SERVERS.NETinternet address = 198.32.64.12 M.ROOT-SERVERS.NETinternet address = 202.12.27.33 A.ROOT-SERVERS.NETinternet address = 198.41.0.4 H.ROOT-SERVERS.NETinternet address = 128.63.2.53 B.ROOT-SERVERS.NETinternet address = 128.9.0.107 C.ROOT-SERVERS.NETinternet address = 192.33.4.12 D.ROOT-SERVERS.NETinternet address = 128.8.10.90 E.ROOT-SERVERS.NETinternet address = 192.203.230.10 I.ROOT-SERVERS.NETinternet address = 192.36.148.17 F.ROOT-SERVERS.NETinternet address = 192.5.5.241 Ось тобі раз! Куди ж поділися всі так ретельно виписані нами імена кореневих серверів! Що за формалізм замість живого дихання Мережі? А це, шановні читачі, і є одна з тих ситуацій, при яких може знадобитися перевантаження списку кореневих серверів - відносно недавно всім цих серверів були присвоєні нові доменні імена, щоб користувачам було легше їх запам'ятати і при необхідності знайти. Адреса IP залишилися колишніми (а інакше наш DNS-сервер і не заробив би), але при перевірці вияс-з'ясувалося, що їм відповідають вже зовсім інші імена! Зверніть увагу, що наші власноручно введені дані розглядаються як неавторитетного, які вимагають підтвердження від одного з кореневих серверів. Не будемо розчаровувати очікувань nslookup і звернемося до одного з них:> Server: F.ROOT-SERVERS.NET Default Server: F.ROOT-SERVERS.NET Address: 192.5.5.241>.

Server: F.ROOT-SERVERS.NET Address: 192.5.5.241 (root) nameserver = H.ROOT-SERVERS.NET (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = I.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET (root) nameserver = G.ROOT-SERVERS.NET (root) nameserver = J.ROOT-SERVERS.NET (root) nameserver = K.ROOT-SERVERS.NET (root) nameserver = L.ROOT-SERVERS.NET (root) nameserver = M.ROOT-SERVERS.NET (root) nameserver = A.ROOT-SERVERS.NET H.ROOT-SERVERS.NETinternet address = 128.63.2.53 B.ROOT-SERVERS.NETinternet address = 128.9.0.107 C.ROOT-SERVERS.NETinternet address = 192.33.4.12 D.ROOT-SERVERS.NETinternet address = 128.8.10.90 E.ROOT-SERVERS.NETinternet address = 192.203.230.10 I.ROOT-SERVERS.NETinternet address = 192.36.148.17 F.ROOT-SERVERS.NETinternet address = 192.5.5.241 G.ROOT-SERVERS.NETinternet address = 192.112.36.4 J.ROOT-SERVERS.NETinternet address = 198.41.0.10 K.ROOT-SERVERS.NETinternet address = 193.0.14.129 L.ROOT-SERVERS.NETinternet address = 198.32.64.12 M.ROOT-SERVERS.NETinternet address = 202.12.27.33 A.ROOT-SERVERS.NETinternet address = 198.41.0.4 Після цього можна завершити роботу з nslookup, ввівши команду:> exit У результаті в створеному нами протокольному фото root.log буде створено копію наведеного вище сеансу роботи з nslookup. Тепер нам залишається тільки перетворити його в формат, прийнятний для використання root.cache. Завдання зовсім не складна. Нам необ-обхідно перетворити рядки з файлу реєстрації типу: (root) nameserver = D.ROOT-SERVERS.NET в такі рядки:.

IN NS D.ROOT-SERVERS.NET.

а також рядки: D.ROOT-SERVERS.NET internet address = 128.8.10.90 в: D.ROOT-SERVERS.NET.

999999 IN A 128.8.10.90 Вирішити цю проблему можна різними шляхами, наприклад, скориставшись ска-зочной міццю будь-якого текстового редактора, наприклад, jed або ted. Але з точки зору UNIX-культури набагато розумніше використовувати одне з коштів, призначених для ре-ня подібних завдань. У даному випадку найбільш зручним є використання програмки на мові awk. Якщо ви не дуже впевнено почуваєте себе в awk-програмуванні, я хочу порекомендувати вам невелику книжку українською мовою - [6], яку ви можете вивантажити з моєї домашньої сторінки. Нижче наведено сценарій на мові оболонки, в яку інтегрована awk-програма.

#!/bin/sh echo echo Переформатування даних від nslookup у формат echo / var/named/root.cache echo awk `BEGIN (print ";--------------------------------------" Print "; root.cache: Список кореневих серверів "print ";--------------------------------------")/root/(print ".

IN NS "$ 4". ")/internet/(print $ 1". "" 999999 IN A "$ 5) END (Print "; Згенерований програмою rfm ")` $ 1> $ 2 В результаті ви повинні отримати наступне: ;--------------------------------------; Root.cache: Список кореневих серверів ;--------------------------------------.

IN NS H.ROOT-SERVERS.NET.

.

IN NS B.ROOT-SERVERS.NET.

.

IN NS C.ROOT-SERVERS.NET.

.

IN NS D.ROOT-SERVERS.NET.

.

IN NS E.ROOT-SERVERS.NET.

.

IN NS I.ROOT-SERVERS.NET.

.

IN NS F.ROOT-SERVERS.NET.

.

IN NS G.ROOT-SERVERS.NET.

.

IN NS J.ROOT-SERVERS.NET.

.

IN NS K.ROOT-SERVERS.NET.

.

IN NS L.ROOT-SERVERS.NET.

.

IN NS M.ROOT-SERVERS.NET.

.

IN NS A.ROOT-SERVERS.NET.

H.ROOT-SERVERS.NET.

999999 IN A 128.63.2.53 B.ROOT-SERVERS.NET.

999999 IN A 128.9.0.107 C.ROOT-SERVERS.NET.

999999 IN A 192.33.4.12 D.ROOT-SERVERS.NET.

999999 IN A 128.8.10.90 E.ROOT-SERVERS.NET.

999999 IN A 192.203.230.10 I.ROOT-SERVERS.NET.

999999 IN A 192.36.148.17 F.ROOT-SERVERS.NET.

999999 IN A 192.5.5.241 G.ROOT-SERVERS.NET.

999999 IN A 192.112.36.4 J.ROOT-SERVERS.NET.

999999 IN A 198.41.0.10 K.ROOT-SERVERS.NET.

999999 IN A 193.0.14.129 L.ROOT-SERVERS.NET.

999999 IN A 198.32.64.12 M.ROOT-SERVERS.NET.

999999 IN A 202.12.27.33 A.ROOT-SERVERS.NET.

999999 IN A 198.41.0.4; згенерований програмою rfm Програма проста і зрозуміла. Варто звернути увагу лише на наступне. По-перше, ви повинні подбати про те, щоб увесь файл програми не містив неав-торітетной інформації від вашого домашнього сервера. Rfm перетворює формат записів, але не може перевірити, чи потрібні вони вам чи ні. Вирішити цю проблему дуже просто - відріжте редактором відповідний блок з файлу протоколу і "згодувати" його rfm.

По-друге, майте на увазі, що синтаксис виклику наведеної вище програми rfm наступний: rfm І по-третє, після того, як ви отримаєте нову версію root.cache, її потрібно помістити в каталог / var/named, а сам сервер DNS - перезапустити.

Отже, чого ж нам вдалося домогтися? Ми зуміли встановити власний кешує-щий DNS-сервер, який дозволяє зберегти працездатність нашого вузла Internet навіть у разі відмови DNS-сервера провайдера. Наступний крок очевидний - витяг корисної інформації про доменні імена з Мережі, і її подальший аналіз. Але про це - в на-дме раз.

Список літератури

[1] В. Водолазки, PPP-підключення в Linux, Планета Internet, № 5, 1997, повний текст статті -- http://www.geocities.com/SiliconValley/Pines/7895

[2] П. Храмцов, Лабіринт Internet, М., Електроінформ, 1996, 256 стор

[3] Справочное керівництво системного адміністратора UNIX, Київ. Bhv, 1997, 600 стор

[4] Річард Петерсен, Linux: керівництво по операційній системі., Київ, Bhv, 1997, 685 стор

[5] Nicolai Langfeldt, Caching named mini howto, Version 1, 1995, [email protected].

[6] В. водолазка. GAWK: Довідник. 120 стор, Повний текст у форматі Postscript - http://www.geocities.com/SiliconValley/Pines/7895 Більшість читачів, мабуть не підозрює про те, що ще в 1992-1994 роках тільки обрані громадяни мали можливість використовувати програмку uupc (версія uucp для MS-DOS). Про протоколах PPP і SLIP, так само як і про FTP знали зовсім небагато. A тер-мін WWW ставився до наукової фантастиці.

Найбільш акуратне і грамотне опис процесу встановлення авторитетного сер-віра ви знайдете в [2], а більш зрозуміле виклад процесу - в [3].

Природно, маються на увазі поточні з'єднання, а не загальна кількість абонентів.

Якщо ви користуєтеся стеком TCP/IP Trumpet Winsock, ви можете включити режим контролю проходження запитів і відповідей DNS. Дуже повчальне видовище ...

За подробицями з використання команди kill відправляю читача до літератури [3], [4] За допомогою route add-net 127.0.0.0 У нашому випадку, це програма route.

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

Для знаючих читачів повідомляю, що мені відомо про механізм синонімів, по-зволяющіх спростити введення адрес в повідомленнях електронної пошти. Але зараз ми говоримо про механізми скорочення адреси, які використовуються сервером DNS.

Останні кілька рядків можна побачити, додавши tail/var/log/messages.

Згадайте, що в named.boot записано про відповідальність root.cache за кореневий домен мережі.

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

Для підготовки даної роботи були використані матеріали з сайту http://lib.rin.ru/cgi-bin/index.pl