? Сервер осуществляет только кэширование, при этом кэшированию подлежат все доменные имена (поскольку в поле домена указана точка – корень для любого доменного имени), а в файле /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 в строки вида: .