15751-1 (662976), страница 2
Текст из файла (страница 2)
Теперь осталось лишь перезагрузить сервер 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, 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 за корневой домен сети.
Поскольку все эти серверы расположены довольно далеко от России выбор кон- кретного сервера для съема информации носит произвольный характер и на время получения данных влияния, по большому счету, не оказывает.
Для подготовки данной работы были использованы материалы с сайта http://lib.rin.ru/cgi-bin/index.pl