Мой личный
сервер 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. Может быть, выигрыш не слишком
значителен? А теперь представим, что вам необходимо постоянно обращаться к
пользователям узлов с двумя и тремя точками, например:
' );
document.write( addy68280 );
document.write( '' );
//-->\n
' );
//-->
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
' );
//-->
. Объявив всю правую часть адреса в ключе 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,
' );
document.write( addy87144 );
document.write( '' );
//-->\n
' );
//-->
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
' );
//-->
.
[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