Наконец-то 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 " grepnamed Скорее всего, 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: #routeKernelroutingtableDestinationGatewayGenmaskFlagsMSSWindowUseIface 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/namedcache .
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]), мы по- местили в этот файл информацию следующего содержания: domainrinet.runameserver 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 1 13:05:47 vvvnamed[197]: starting. named 4.9.3-BETA26 SunNov 26 20:58:49 CST 1995 ^Iroot@fuzzy:/tmp/bind-4.9.3-BETA26/namedSep 1 13:05:48 vvvnamed[197]: cachezo
В случае появления каких-либо сообщений об ошибках (и естественно, отсутствии сообщения о готовности обрабатывать запросы) проанализируйте файлы named.boot и root.cache. Скорее всего, вы допустили опечатку. Поправьте "слова" в этих файлах, "убейте" процесс named и перезапустите его еще раз.
Поскольку вы в данный момент подключены к сети, то целесообразно сразу же про- верить работоспособность нашего сервера. Попробуйте воспользоваться уже рассматривав- шимися ранее [1] командами ping и traceroute. А попробовав, сравните с результатами, по- лученными для простейшего PPP-подключения с использованием DNS-сервера вашего про- вайдера.
В чем дело? Вы утверждаете, что стало только хуже, и что автор просто шарлатан, пытающийся заморочить голову всякой ерундой? Но ведь мы еще не закончили! Мы пока что просто проверили работоспособность вашего named! А вот теперь давайте займемся оп- тимизацией.
Давайте задумаемся, каким образом происходит запрос IP-адреса? Ваш DNS-сервер по цепочке пытается добраться до авторитетного сервера той или иной зоны, и при этом ис- пользует ограниченные ресурсы вашего коммутируемого канала. А сервер провайдера при тех же запросах может использовать совершенно другое (по пропускной способности) по- стоянное подключение к Internet. Конечно, после того, как сервер загрузит в свой кэш полу- ченные адреса, никакого паразитного трафика не будет, но ведь кэш еще надо загрузить! А почему бы не заставить DNS-сервера провайдера выполнять за нас всю грязную работу по первичному сбору информации? Named предоставляет и такую возможность! Нам потребуется лишь внести в файл named.boot некоторые изменения, которые приведены ниже: ; ; Загрузочный файл кэширующего сервера DNS ; directory /var/namedcache .
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 " teeroot.log В ответ nslookup сообщит нам, что работает с сервером DNS localhost (он же 127.0.0.1), и готова к обработке наших запросов. Если вы забыли подключиться к Internet, программа просто зависнет, а в /var/log/messages или /var/log/syslog вы найдете сообщение о том, что nslookup пытается достучаться до перечисленных вами в root.cache авторитетных серверов, но сеть, увы, недоступна (networkisunreachable).
Теперь проверим, насколько корректно nslookup понимает введенные нами сведения об авторитетных серверах сети. Для этого нам потребуется ввести всего две команды: > settype=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.NETDefaultServer: F.ROOT-SERVERS.NETAddress: 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.cacheechoawk ` BEGIN { print ";--------------------------------------" print "; root.cache : Список корневых серверов " print ";--------------------------------------" } /root/ { print ".
IN NS " $4"." } /internet/ { print $1"." " 999999 INA " $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> И в третьих, после того, как вы получите новую версию 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 за корневой домен сети.
Поскольку все эти серверы расположены довольно далеко от России выбор кон- кретного сервера для съема информации носит произвольный характер и на время получения данных влияния, по большому счету, не оказывает.