|
|
|
В. Водолазкий, к.т.н. ([email protected]) Мой личный сервер 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. А при установке собственного сервера вы сможете:
Поскольку авторитетом для вашего 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-адрес, к которому вы сможете обращаться без оглядки на особенности localhost). Обратите внимание, что мы не видим указания на наш любимый адрес 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 В этом файле вы указываете компьютеру на два обстоятельства:
Теперь самое время взглянуть на содержимое 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-сервера. Для запуска этой программы вы должны прежде всего выполнить два условия:
После этого мы запускаем 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.NET internet address = 192.112.36.4 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOT-SERVERS.NET internet address = 202.12.27.33 A.ROOT-SERVERS.NET internet address = 198.41.0.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOT-SERVERS.NET internet 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.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOT-SERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOT-SERVERS.NET internet address = 202.12.27.33 A.ROOT-SERVERS.NET internet 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> И в третьих, после того, как вы получите новую версию 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 |
||||||||||||||||
|
With any suggestions or questions please feel free to contact us | ||||||||||||||||||