15751-1 (662976)
Текст из файла
Мой личный сервер 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. Может быть, выигрыш не слишком значителен? А теперь представим, что вам необходимо постоянно обращаться к пользователям узлов с двумя и тремя точками, например: aivanov@informatik.dortmund.de. Объявив всю правую часть адреса в ключе 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 серверам (учебные адреса приведены по той простой причине, что исполь- зовать чужой сервер без разрешения администратора – плохой тон!).
Характеристики
Тип файла документ
Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.
Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.
Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
