Нарешті-то 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. Може бути, виграш не надто значний? А тепер уявімо, що вам необхідно постійно звертатися до користувачів вузлів з двома і трьома крапками, наприклад: aivanov@informatik.dortmund.de. Оголосивши всю праву частину адреси в ключі search, ви можете відправляти пошту за адресою aivanov, як ніби-то ваш співрозмовник знаходиться не в Німеччині, а у вашій локальній мережі.
Тепер можна приступати до перевірки нашого сервера. Підключіться до провайдера, і після встановлення з'єднання запустіть DNS-сервер, ввівши команду named. Після запуску named самостійно перейде у фоновий режим і поверне управління в командний рядок оболонки. Перевірити, чи всі в порядку, можна проаналізувавши файл / var / log / messages, в кінці якого ви повинні знайти що-небудь на зразок: Sep одна 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 одна 13:05:48 vvv named [197]: cache zone "" loaded (serial 0) Sep один 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, janl@ifi.uio.no.
[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 за кореневої домен мережі.
Оскільки всі ці сервери розташовані досить далеко від Росії вибір конкретного сервера для знімання інформації носить довільний характер і на час отримання даних впливу, за великим рахунком, не робить.