Банк рефератов содержит более 364 тысяч рефератов, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам: истории, психологии, экономике, менеджменту, философии, праву, экологии. А также изложения, сочинения по литературе, отчеты по практике, топики по английскому.
Полнотекстовый поиск
Всего работ:
364150
Теги названий
Разделы
Авиация и космонавтика (304)
Административное право (123)
Арбитражный процесс (23)
Архитектура (113)
Астрология (4)
Астрономия (4814)
Банковское дело (5227)
Безопасность жизнедеятельности (2616)
Биографии (3423)
Биология (4214)
Биология и химия (1518)
Биржевое дело (68)
Ботаника и сельское хоз-во (2836)
Бухгалтерский учет и аудит (8269)
Валютные отношения (50)
Ветеринария (50)
Военная кафедра (762)
ГДЗ (2)
География (5275)
Геодезия (30)
Геология (1222)
Геополитика (43)
Государство и право (20403)
Гражданское право и процесс (465)
Делопроизводство (19)
Деньги и кредит (108)
ЕГЭ (173)
Естествознание (96)
Журналистика (899)
ЗНО (54)
Зоология (34)
Издательское дело и полиграфия (476)
Инвестиции (106)
Иностранный язык (62792)
Информатика (3562)
Информатика, программирование (6444)
Исторические личности (2165)
История (21320)
История техники (766)
Кибернетика (64)
Коммуникации и связь (3145)
Компьютерные науки (60)
Косметология (17)
Краеведение и этнография (588)
Краткое содержание произведений (1000)
Криминалистика (106)
Криминология (48)
Криптология (3)
Кулинария (1167)
Культура и искусство (8485)
Культурология (537)
Литература : зарубежная (2044)
Литература и русский язык (11657)
Логика (532)
Логистика (21)
Маркетинг (7985)
Математика (3721)
Медицина, здоровье (10549)
Медицинские науки (88)
Международное публичное право (58)
Международное частное право (36)
Международные отношения (2257)
Менеджмент (12491)
Металлургия (91)
Москвоведение (797)
Музыка (1338)
Муниципальное право (24)
Налоги, налогообложение (214)
Наука и техника (1141)
Начертательная геометрия (3)
Оккультизм и уфология (8)
Остальные рефераты (21697)
Педагогика (7850)
Политология (3801)
Право (682)
Право, юриспруденция (2881)
Предпринимательство (475)
Прикладные науки (1)
Промышленность, производство (7100)
Психология (8694)
психология, педагогика (4121)
Радиоэлектроника (443)
Реклама (952)
Религия и мифология (2967)
Риторика (23)
Сексология (748)
Социология (4876)
Статистика (95)
Страхование (107)
Строительные науки (7)
Строительство (2004)
Схемотехника (15)
Таможенная система (663)
Теория государства и права (240)
Теория организации (39)
Теплотехника (25)
Технология (624)
Товароведение (16)
Транспорт (2652)
Трудовое право (136)
Туризм (90)
Уголовное право и процесс (406)
Управление (95)
Управленческие науки (24)
Физика (3463)
Физкультура и спорт (4482)
Философия (7216)
Финансовые науки (4592)
Финансы (5386)
Фотография (3)
Химия (2244)
Хозяйственное право (23)
Цифровые устройства (29)
Экологическое право (35)
Экология (4517)
Экономика (20645)
Экономико-математическое моделирование (666)
Экономическая география (119)
Экономическая теория (2573)
Этика (889)
Юриспруденция (288)
Языковедение (148)
Языкознание, филология (1140)

Реферат: Мой личный сервер DNS

Название: Мой личный сервер DNS
Раздел: Рефераты по информатике, программированию
Тип: реферат Добавлен 17:52:56 28 октября 2003 Похожие работы
Просмотров: 934 Комментариев: 2 Оценило: 1 человек Средний балл: 5 Оценка: неизвестно     Скачать

Наконец-то 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]: cachezone "" loaded (serial 0) Sep 1 13:05:48 vvvnamed[198]: Readytoanswerqueries.

В случае появления каких-либо сообщений об ошибках (и естественно, отсутствии сообщения о готовности обрабатывать запросы) проанализируйте файлы 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 за корневой домен сети.

Поскольку все эти серверы расположены довольно далеко от России выбор кон- кретного сервера для съема информации носит произвольный характер и на время получения данных влияния, по большому счету, не оказывает.

Оценить/Добавить комментарий
Имя
Оценка
Комментарии:
Где скачать еще рефератов? Здесь: letsdoit777.blogspot.com
Евгений21:51:20 18 марта 2016
Кто еще хочет зарабатывать от 9000 рублей в день "Чистых Денег"? Узнайте как: business1777.blogspot.com ! Cпециально для студентов!
09:48:04 24 ноября 2015

Работы, похожие на Реферат: Мой личный сервер DNS

Назад
Меню
Главная
Рефераты
Благодарности
Опрос
Станете ли вы заказывать работу за деньги, если не найдете ее в Интернете?

Да, в любом случае.
Да, но только в случае крайней необходимости.
Возможно, в зависимости от цены.
Нет, напишу его сам.
Нет, забью.



Результаты(151295)
Комментарии (1844)
Copyright © 2005-2016 BestReferat.ru bestreferat@mail.ru       реклама на сайте

Рейтинг@Mail.ru