Руководство администратора сети в ОС Linux - Конфигурирование сервера поиска --- resolv.conf

7.1.3 Конфигурирование сервера поиска --- resolv.conf

При конфигурировании библиотеки решающего устройства,
для того чтобы использовать BIND обслуживание для поиска
хостов, вы обязательно должны сообщить, какое имя сервера вы
используете. Существует отдельный файл, предназначенный специально для
этого, называемый resolv.conf. Если этот файл не существует или пуст,
то решающее устройство примет имя сервера, определенного для вашего
локального хоста.Если Вы запускаете сервер на Вашем локальном хосте, то Вы
должны установить это имя отдельно, как это сделать, будет объяснено
позже в следующем разделе. Если в локальпой уети есть возможность
использовать существующее имя сервера, то этому должно отдаваться
предпочтение.
Самая важная опция в resolv.conf - nameserver, которая
дает IP адрес используемого сервера. Если Вы определите несколько
имен серверов используя nameserver опцию несколько раз, то они будут
проверяться в данном порядке. Поэтому Вы должны поместить наиболее
надежный сервер первым. Постоянно, могут поддерживаться не более трех
серверов.
Если опция nameserver не дана, то решающее устройство попытается
соединиться с сервером на локальном хосте.
Две других опции, domain и search имеют дело с заданными по
умолчанию областями, которые беруться из имени хоста, если BIND не может
решить это с первого запроса. Опция search определяет список названий
областей, которые необходимо проверить. Пункты списка отделены пробелом или
табуляцией.
Если опция search не дана, то заданный по умолчанию список
поиска создается из локального имени области, используя само название
области непосредственно, плюс все родительские области вплоть до root.
Локальное название области может быть дано при использовании оператора
области; если ни один из них не дан, то решающее устройство получит его
через getdomainname(2) системный вызов.

Если это уж слишком для вас, рассмотрите пример resolv.conf
файла для Virtual Brewery:

# /etc/resolv.conf
# Our domain
domain vbrew.com
#
# We use vlager as central nameserver:
nameserver 191.72.1.1

При определении имени vale, решающее устройство искало бы его и
в случае неудачи, vale.vbrew.com, и vale.com.

7.1.4 Ошибкоустойчивость решающего устройства.

Если Вы запускаете LAN внутри большей сети, Вы непременно должны
использовать центральные сервера, если они доступны. Преимущество этого
состоит в том, что они разработают богатые кэши, так как все запросы
направлены к ним. Эта схема имеет недостаток: когда сгорел базовый кабель в
нашем университете при пожаре, невозможно было дальше работать на LAN
нашего отдела, потому что решающее устройство не могло достичь какого-либо
из серверов. Не было login на X-terminals, не было печати на принтерах, и
т.д.
Хотя это не гоже для университетского городка, опускаться до пожаров,
каждый обязан соблюдать технику безопаности, чтобы избежать случаев
подобных этим.
One - устанавливает локальный сервер, который определяет hostnames из
вашей локальной области, и делает вперед все запросы для других
hostnames к главным серверам. Конечно, это применимо только тогда, когда
Вы используете вашу собственную область.
В качестве альтернативы, Вы можете сохранить таблицу
сохраненных хостов Вашей области или LAN в /etc/hosts. В /etc/host.conf Вы
можете включить "order bind hosts" для того, чтобы решающее устройство
вернулась бы к хост файлу, если центральный сервер ослабел или вышел из
строя.

7.2 Запуск named.

Программа, которая обеспечивает обслуживание имени области на
большинстве Unix машин обычно называется named. Эта программа
первоначально разработанна для BSD обеспечения клиентуры, и ,возможно,
для других серверов. Эта версия в настоящее время используется на
большинстве Linux инсталяционных пакетов, как мне кажеться это BIND-
4.8.3. Новая версия, BIND-4.9.3, тестируется бетой в этот момент, и должна
быть скоро доступна на Linux.
Этот раздел требует некоторого понимания как работает Domain
Name System. Если следующее изложение будет не совсем Вам понятно, то
Вам следует перечитать главу 3., которая имеет более подробную информацию
по основам DNS.

Named обычно запускается при начальной загрузке сичтемы, и работает
пока машина вновь не перезагрузится. Она черпает информацию из
конфигурационного файла называемого /etc/named.boot, и из различных файлов,
которые содержат набор данных имен областей адресов. Далее они будут
называться zone files. Форматы и семантика этих файлов будут объяснены в
следующем разделе.
Для запуска named, просто введите в командной строке:

# /usr/sbin/named

Появится named, читает named.boot файл и zone file,
установленные там. Он записывает идентичность процесса id к
/var/run/named.pid в ASCII, выгружая любые zone files из основных
серверов, в случае необходимости запускает listening на порт 53 для
запросов DNS. (1)

7.2.1 Файл named.boot.

Файл named.boot в основном очень мал и содержит еще немного
информации, но содержит указатели на главные файлы, содержащие zone
информацию, и указатели к другим серверам. Комментарии в файле начальной
загрузки начинаются с точки с запятой и простираются вплоть до
следующей линии. Прежде, чем мы обсудим формат named.boot файла более
подробно, мы рассмотрим типовой файл для vlager представленный на рисунке
7.2.1. (2)

Кэш и основные команды, показанные в этом примере загружают
информацию в named. Эта информация берется из главного файла,
определенного во втором аргументе. Он содержат текстовые представления
DNS источника записи, которые мы рассмотрим ниже.

1. Имеются различные named binaries касающиеся Linux FTP sites,
каждые из которых не намного, но отличаются друг от друга. Некоторые
имеют свой собственный pid файл, некоторые хранят его в /tmp или /var/tmp.
2. Заметьте, что имена областей в этом примере даны без конечной
точки. Более ранние версии named принимают конечные точки в named.boot за
ошибку, и их отбрасывают. BIND-4.9.3, как уже упоминалось, устраняет это.

;
; /etc/named.boot file for vlager.vbrew.com
;
directory /var/named
;
; domain file
;---------------------------------------------------
cache . named.ca
primary vbrew.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 72.191.in-addr.arpa named.rev

Рисунок 9. Named.boot файл для vlager.

В этом примере, мы сконфигурировали named как основной сервер для
трех областей, как обозначено основными операторами в конце файла.
Первая из этих строк, например, инструктирует named действовать как
основной сервер для vbrew.com, принимая zone данные из файла named.hosts.
Ключевое слово каталога сообщает ему, что все zone files размещаются в
/var/named.

Кеш запись очень особа и должна присутствовать фактически на всех
машинах, запускающих сервер. Его функция - двукратная: она инструктирует
named для отмены кэша, и загружает основной сервер hints из кэш файла
(named.ca в нашем примере). Мы вернемся к серверам hints ниже.

Также имеется список наиболее важных опций, которые Вы
можете
использовать named.boot:

directory - определяет директорию, в которой zone files постоянно
находятся. Имена файлов могут быть даны относительно этой
директории.Несколько директорий могут быть определены неоднократно
используя directory. Согласно стандарту Linux filesystem, эта директория
должна быть /var/named.

primary - берет имя области и имя файла как аргумент,
объявленный локальным сервером авторитарно для named области. Как
основной сервер, named загружает zone информацию из данного главного файла.

В основном будет всегда, по крайней мере хотя бы одна основная
запичь в каждом boot-файле, а именно для обратного отбора сети
127.0.0.0, которая является локальной замкнутой сетью.

secondary - берет имя области, список адресов, и имя файла как
аргумент. Он объявляет локальный сервер вторичным главным сервером для
установленной области.Вторичный сервер задерживает авторитарные данные
поступающие на область, но он не собирает их из файла, и пробует
загрузить их из основного сервера. IP адрес, по крайней мере одного
основного сервера, должен быть дан named(у) в списке адресов. Локальный
сервер войдет в контакт с каждым из них, пока он успешно не перенесет всю
зональную базу данных, которая затем будет сохранена в файле с резервной
копией, данной как третий аргумент. Если ни один из основных
серверов не отвечает,то зональные данные восстановятся из файла с
резервной копией взамен.named затем пытается обновить зональные данные в
постоянные интервалы. Это объясняется ниже с SOA типом записи.

cache -Эта опция берет область и имя файла как аргументы. Этот файл
содержит подсказки сервера hints, который является списком записей,
указывающих на серверы. Но только NS и А записи будут признаны. Аргумент
области, в основном ,- источник имени области.Эта очень важно: если кэш
оператор не пояляется в boot-файле, named не начинает разрабатывать
локальный кэш вообще. Это строго ухудшит характеристику и увеличит
сетевую загрузку, если следующий сервер делает запрос не на локальную
сеть. Кроме того, named не будет способен достичь всех серверов, и
таким образом это не решит проблему адресов за исключением тех, которые
авторитарны. Исключение из этого правила - это когда используются
серверы пересылки (опция механизмов продвижения дана ниже).

forwarders -Этот оператор берет список адреса как аргумент. IP
адреса в этом списке точно определяют список серверов, на которые named
может сделать запрос, решается ли запрос из его локального кэша. Они
тестируются по порядку, пока один из них не отвечает на запрос.

slave - это оператор делает главный сервер подчиненным сервером. То
есть он никогда не будет выполнять рекурсивные запросы самостоятельно, и
будет только направлять их к серверам определенных с forwarders
оператором.

Имеются две опции, которые мы не будем описывать здесь, это sortlist
и domain. Дополнительно, имеются две директивы, которые могут
использоваться внутри zone файлов базы данных. Это - $INCLUDE и $ORIGIN.
Так как они редко когда понадобятся, то мы не будем описывать их здесь.

7.2.2 DNS файл базы данных.

Основной файл включаемый named, подобно named.hosts, всегда имеет
область соединенную с ним, которая называется origin. Это - область
название которой определено с кэшем и с основными командами. Внутри
основного файла Вам дозволено определить область и имена хостов
относительно этой области. Имя, данное в файле конфигурации, считается
абсолютным, если оно заканчивается в единственной точке, иначе она
будет рассматривается относительно origin. Весь оrigin может быть
упомянут, если Вы используете "@".

Все данные, содержащиеся в основном файле определены в источнике
записей, или Rrs(resource records) для краткости. Они составляют самую
малую единицу информации доступную через DNS. Каждый способ записи имеет
тип. Запись, например отображение имени хоста к IP адресу, и CNAME запись
ассоциируется с псевдонимом для хоста с его официальным именем. Например,
посмотрите на рисунок 7.2.3 на странице 116, которая показывает named.hosts
основной файл для virtual brewery.

Способ записи в основых файлах является общим форматом:

[domain] [ttl] [class] type rdata

Поля отделены пробелами или табуляцией. Запись может быть продолжена
через
несколько строк, если открываящая"фигурная скобка появляется перед
первой строкой, и последнее поле оканчивается закрывающей фигурной скобкой.
Что-либо между точкой с запятой и новой строкой игнорируется.

domain Это имя области в которой появляется запись. Если имя
области не дано, RR попытается обратиться к области из предыдущего RR.

ttl Необходим для того чтобы заставить решающие устройства
отбрасывать информацию после определенного промежутка времени, каждый RR
ассоциируется с "time to live'', или ttl для краткости. Поле ttl
определяет время в секундах.

information имеет силу после того, как она была найдено на сервере.
Это - десятичное число с восемью разрядами.

Если ttl значение не дано, то будет использоваться значение по
умолчанию к значению минимального поля предшествующей SOA записи.

class Это - класс адреса, подобно IN для IP адресов, или HS для
объекта в Hesoid классе. Для TCP/IP сетей, Вам необходимо сделать это IN.
Если никакой класс поля не дан,то будет принят класс предшествующего RR.

type Это описывает тип RR. Наиболее общие типы: A, SOA, PTR,
и NS. Следующие разделы описывают различные типы RR.

rdata Это задерживает данные связанные с RR. Формат этого поля
зависит от типа RR. Ниже, это будет описано для каждого RR поотдельности.

following - незавершенный список RR, который нужно использовать в
DNS основном файле. Имеется несколько пар из них, которые мы не
будем объяснять. Они являются экспериментальными, и вообще, небольшого
использования.

SOA

Это описывает зону власти (SOA означает " Start of
Authority''). Он сообщает что запись следующая за SOA RR содержите
авторитарную информацию для области. Каждый основной файл, включенный
основным оператором должен содержать SOA запись для этой зоны. Источники
данных содержат следующиз поля:

origin Это - каноническое имя хоста основного сервера для этой
области. Обычно дается как абсолютное имя.

contact Это - email адрес человека ответственного за поддержания
области, со знаком "@" в качестве точки. Например, если ответственный в
Virtual Brewery - janet, то тогда это поле содержало бы janet.vbrew.com.

serial Это - номер версии зонального файла, выраженный как
единственное десятичное число. Всякий раз, когда данные меняются в
зональном файле, то это число должно быть увеличено.

Серийный номер используется вторичными серверами, чтобы распознать,
когда зональная информация была изменена. Чтобы оставаться на уровне
современных требований, вторичные серверы запрашивают SOA запись
примарного сервера в определенные промежутки времени, и сравнивают
порядковый номер с кэшируемой SOA записью. Если номер изменился, то
вторичные серверы переносут целую зону баз данных из основного сервера.

refresh Определяет интервал, в секундах, который вторичные
серверы должны использовать между проверками SOA записей основного сервера.
Это - десятичный номер более чем с восемью разрядами.

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

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

expire - определяет время в секундах после которого сервер
должен наконец-то отбросить все зональные данные, если невозможно было
войти в контакт с основным сервером. Этот промежуток времени в основном
должен быть очень большим. Craig Hunt (GETS "hunt - tcpip"]) рекомендует 42
дня.

minimum - задает по умолчанию ttl значение для исходных
записей, которые точно не определяют его. Требует другого сервера,
чтобы отбросить RR при проверки после определенного кол-ва времени.

Ничего нельзя сделать с временем после которого вторичный сервер
попробует модифицировать зональную информацию.

minimum должен быть большим значением, особенно для LANs, где
сетевая топология почти никогда не меняется. Значение в неделю или в месяц.
В случае, когда единственные Rrs могут часто изменяться, то Вы все еще
можете приписывать им различные ttl.

Ассоциирует IP адрес с hostname. Источник полей данных содержит адрес
в dotted quad notation.

Для каждого хоста должна быть только одна запись. Hostname
используемый в этой А записи рассматривается служебным или каноническим
hostname. Все другие hostnames - псевдонимы и должны быть отображены на
каноническом hostname используя CNAME запись.

Указывает на главный сервер подчиненной зоны. Для объяснения,
почему, каждый должен иметь NS запись, просмотрите раздел 3.6.
Источник полей данных содержит hostname сервера. Можно разрешить
дополнительный hostname к A записи, так называемый glue, которая дает IP
адрес сервера.

CNAME

Ассоциирует псевдоним хоста с его каноническим hostname.
Каноническиий hostname - главный файл, который обеспечивает А запись;
псевдонимы просто связаны с этим именем CNAME записью, но не имеют
собственные записи.

PTR

Этот тип записи используется, для того, чтобы соединить имя в
Addr.arpa области с hostnaoes. Это используется для обратного отображения
IP адресов к hostnames. Данный hostname должен быть каноническим hostname.

Эта RR объявляет преобразователь почты для области. Для чего надо
иметь преобразователи почты, обсуждено в разделе 14.4.1 в главе 14..
Синтаксис MX записи следующий:

[domain] [ttl] [class] MX preference host

host объявляет преобразователь почты для области. Каждый
преобразователь почты предпочитает целое число, связанное с этим хостом.
Агент переноса почты, то кто желает доставить почту к области, будет
перебирать все хосты, не имеющие MX записей в этой области, пока
все не пойдет успешно. Сначала будет пробоваться тот хост, у которого
самое низкое число, а дальше все хосты с числом по возрастанию (это
число называется-preference value).

HINFO Эта запись предоставляет информацию относительно аппаратных
средств системы и программного обеспечения. Синтаксис этой записи:

[domain] [ttl] [class] HINFO hardware software

Аппаратная область идентифицирует аппаратные средства, используемые
этим хостом. Имеются специальные соглашения, чтобы точно определить ее.
Список подходящих имен дан в "Assigned Numbers'' (RFС 1340). Если область
содержит пробелы, то это надо заключить в двойные кавычки. Имена
областей программного обеспечения используються операционной системой.
И снова, подходящее имя может быть выбрано из "Assigned Numbers'' RFC.

7.2.3 Запись главных файлов.

Рисунки 7.2.3, 7.2.3, 7.2.3, и 7.2.3 дают примерные файлы для
названия сервера в brewery, размещенном на vlager. Вследствие характера
обсуждаемой сети (единственная локальная вычислительная сеть), пример
- довольно простой. Если ваши требования чересчур сложны, и Вы не
можете запустить named, то вам поможет "DNS and BIND'' by Cricket Liu and
Paul Albitz ([GETST "liu-dns"]).

& "

Кэш файл named.ca, который вы увидите на рисунке 7.2.3, показывает
пример hint записи для root name сервера. Типичный кеш файл обычно
описывает около дюжины серверов, или около того. Вы можете получить текущий
список серверов для root области, используя nslookup, описанный ближе к
концу этой главы.(3)

;
; /var/named/named.ca Cache file for the brewery.
; We're not on the Internet, so we don't need
; any root servers. To activate these
; records, remove the semicolons.
;
; . 99999999 IN NS NS.NIC.DDN.MIL
; NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103
; . 99999999 IN NS NS.NASA.GOV
; NS.NASA.GOV 99999999 IN A 128.102.16.10

Рисунок 10. Файл named.ca.

7.2.4 Проверка установки сервера(Name Server Setup).

3. Заметьте, что Вы не сможете сделать запрос для Вашего сервера
на root серверы, если Вы не имеете какие-нибудь root server hints:
Захватите 22! Чтобы выйти из этой дилеммы, Вы можете также попробовать
заставите nslookup использовать другой сервер, или Вы можете использовать
примерный файл на рисунке 7.2.3, и затем получить полный список
подходящих серверов.

;
; /var/named/named.hosts Local hosts at the brewery
; Origin is vbrew.com
;
@ IN SOA vlager.vbrew.com. (
janet.vbrew.com.
16 ; serial
86400 ; refresh: once per
day
3600 ; retry: ong howr
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
;
; local mail is distributed on vlager
IN MX 10 vlager
;
; loopback address
localhost. IN A 127.0.0.1
; brewery Ethernet
vlager IN A 191.72.1.1
vlager-if1 IN CNAME vlager
; vlager is also news server
news IN CNAME vlager
vstout IN A 191.72.1.2
vale IN A 191.72.1.3
; winery Ethernet
vlager-if2 IN A 191.72.2.1
vbardolino IN A 191.72.2.2
vchianti IN A 191.72.2.3
vbeaujolais IN A 191.72.2.4

Рисунок 11. Файл named.hosts.

Существует прекрасное средство для проверки действия установки
Вашего сервера(server setup). Оно называется nslookup, и может быть
использовано и в интерактивном режиме и из командной строки. В последнем
случае, Вы просто вызываете ее как

nslookup hostname

и она сделает запрос на сервер, определенный в resolv.conf, для
hostname. (Если эти имена файла больше чем один сервер, nslookup выберет
какой-нибудь один)

;
; /var/named/named.local Reverse mapping of 127.0.0
; Origin is 0.0.127.in-
addr.arpa.
;
@ IN SOA vlager.vbrew.com. (
joe.vbrew.com.
1 ; serial
" " 360000 ; refresh: 100 hrs
3600 ; retry: one hour
3600000 ; expire: 42 days
; minimum: 100 hrs
)
IN NS vlager.vbrew.com.
1 IN PTR localhost.

Рисунок 12. Файл named.local.

Интерактивный режим, является намного более захватывающим. Кроме
того при просмотре индивидуальных хостов, Вы можете сделать запрос для
любого типа DNS записи, и перенести зональную информацию для области.

Когда он вызывается без аргумента, nslookup отобразит название
используемого сервера, и вступить в интерактивный режим. В " > "
приглашении(prompt), Вы можете ввести любое имя для которого должен быть
сделан запрос. По умолчанию, он опросит класс A записи, содержащий IP
адреса в отношении названия области.

Вы можете изменить этот тип, используя "set type=type", где
type(тип) является одним из исходных названий записи, описанных выше в
разделе 7.2, или ANY.

Например, у Вас мог бы получиться следующий диалог:

;
; /var/named/named.rev Reverse mapping of our IP
addresses
; Origin is 72.191.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. (
joe.vbrew.com.
16 ; serial
86400 ; refresh: once per
day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum; 1 week
)
IN NS vlager.vbrew.com.
; brewery
1.1 IN PTR vlager.vbrew.com.
2.1 IN PTR vstout.vbrew.com.
3.1 IN PTR vale.vbrew.com.
; winery
1.2 IN PTR vlager-if1.vbrew.com.
2.2 IN PTR vbardolino.vbrew.com.
3.2 IN PTR vchianti.vbrew.com.
4.2 IN PTR vbeaujolais.vbrew.com.

Рисунок 13. Файл named.rev.

$ nslookup
Default Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

> sunsite.unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

Non-authoritative answer:
Name: sunsite.unc.edu
Address: 152.2.22.81

Если Вы попробуете сделать запрос на имя, которое не имеет
никакого связанного IP адреса, но другие записи были найдены в DNS базе
данных, то nslookup сообщит об ошибке: "No type A records found''. Однако,
Вы можете заставить сделать запрос для записей других типов (не А), введя
"set type" команду. Например, чтобы получить SOA запись unc.edu, Вы бы
ввели:

> unc.edu
*** No address (A) records available for unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

> set type=SOA
> unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

Non-authoritative answer:
unc.edu
origin = ns.unc.edu
& mcil addr = shava.ns.unc.edu
serial = 930408
refresh = 28800 (8 hours)
retry = 3600 (1 hour)
expire = 1209600 (14 days)
minimum ttl = 86400 (1 day)

Authoritative answers can be found from:
UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU internet address = 128.109.157.30

Таким образом Вы можете сделать запрос для MX записей, и т.д.
Использование типа ANY вернет все исходные записи, связанные с данным
именем.

> set type=MX
> unc.edu
Non-authoritative answer:
unc.edu preference = 10, mail exchanger =
lambada.oit.unc.edu
lambada.oit.unc.edu internet address = 152.2.22.80

Authoritative answers can be found from:
UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU internet address = 128.109.157.30

Практическое применение nslookup, помимо отладки, - получить текущий
список root серверов для файла named.ca. Вы можете сделать это,
запрашивая все типы NS записей, связанные с root областью:

> set typ=NS
> .
Name Server: fb0430.mathematik.th-darmstadt.de
Address: 130.83.2.30

Non-authoritative answer:
(root) nameserver = NS.INTERNIC.NET
(root) nameserver = AOS.ARL.ARMY.MIL
(root) nameserver = C.NYSER.NET
(root) nameserver = TERP.UMD.EDU
(root) nameserver = NS.NASA.GOV
(root) nameserver = NIC.NORDU.NET
(root) nameserver = NS.NIC.DDN.MIL

Authoritative answers can be found from:
(root) nameserver = NS.INTERNIC.NET
(root) nameserver = AOS.ARL.ARMY.MIL
(root) nameserver = C.NYSER.NET
(root) nameserver = TERP.UMD.EDU
(root) nameserver = NS.NASA.GOV
(root) nameserver = NIC.NORDU.NET
(root) nameserver = NS.NIC.DDN.MIL
NS.INTERNIC.NET internet address = 198.41.0.4
AOS.ARL.ARMY.MIL internet address = 128.63.4.82
AOS.ARL.ARMY.MIL internet address = 192.5.25.82
AOS.ARL.ARMY.MIL internet address = 26.3.0.29
C.NYSER.NET internet address = 192.33.4.12
TERP.UMD.EDU internet address = 128.8.10.90
NS.NASA.GOV internet address = 128.102.16.10
NS.NASA.GOV internet address = 192.52.195.10
NS.NASA.GOV internet address = 45.13.10.121
NIC.NORDU.NET internet address = 192.36.148.17
NS.NIC.DDN.MIL internet address = 192.112.36.4

Полная система команд, доступных с nslookup может быть получена при
использовании команды help изнутри nslookup.

7.2.5 Другие полезные инструментальные средства

Имеется несколько инструментальных средств, которые помогут Вам с
Вашими задачами как BIND администратор. Я кратко опишу два из них.
Пожалуйста обратитесь к документации, которая прилагается с этими
инструментальными средствами для выяснения того, как их использовать.

hostcvt - средство, которое помогает Вам с Вашей начальной
BIND конфигурации, преобразовывая ваш /etc/hosts файл в главный файл для
named. Оно генерирует оба и прямое (A) и обратное отбражение (PTR), и
заботится о псевдонимах и т.п. Конечно, оно не будет делать всю
работу за Вас, поскольку Вы можете все еще захотеть настроить значения
блокировки по втемепи в SOA записи сами, например, или прибавить MX запись
и т.п. Но оно может помочь сохранить Вам несколько таблеток аспирина.
Hostcvt - часть BIND источника, но может также быть использован как
автономный пакет на несколько Linux FTP серверах.

После установки вашего сервера, Вы можт быть захотите
проверить Вашу конфигурацию. Идеальным (и, по моему мнению тоже)
средством для этого является dnswalk, perl-based пакет который
прогуливается по вашей DNS базе данных, выискивая общие ошибки и
проверяет совместимость информации. Dnswalk был выпущен на
comp.sources.misc недавно, и должен быть доступен на всех FTP, которые
архивируют эту группу.

8. Последовательная линия IP

Порядковые протоколы линии связи, SLIP и PPP, обеспечивают
Internet connectivity для плохой связи. Кроме модема и
последовательной оборудованной панели с FIFO буфером, никакие аппаратные
средства не нужны. Использование его - не намного усложняется чем
использование mailbox, и поэтому увеличивается число частных организаций,
которые предлагают телефонный вызов по номеру IP за доступную
стоимость каждому.

Имеются оба драйвера доступные для Linux- SLIP и PPP. SLIP был
там в течение долгого времени, и работает достаточно неплохо. А PPP
драйвер был разработан совсем недавно MIchael Callahan и Al Longyear.
Этот драйвер будет описан в следующей главе.

8.1 Общие требования.

Для того, чтобы использовать SLIP или PPP, Вы должны
сконфигурировать некоторую базисную работу с сетями, как описано в
предыдущих главах. Наконец Вы должны установить looback interface, и
обеспечить для name resolution. При соединении с Internet, Вы несомненно
пожелаете использовать DNS. Самая простая опция - поместит адрес
сервера в Ваш resolv.conf файл; этот сервер сделает запрос как только
SLIP связь будет активизированна.

Однако, это решение не оптимально, потому что все поиски имен будут
все еще проходить через вашу SLIP/PPP связь. Если Вы волнуетесь
относительно ширины зоны, которую она требует, то Вы может также установить
cache-only сервер. Он действительно не обслуживающий, он только действует
как переключатель для всех DNS запросов, произведенных на Вашем хосте.
Преимущество этой схемы - то, что она создает кэш, так, чтобы
большинство запросов должны быть посланы через последовательные линии
только один раз. Named.boot файл для cache-only серверов, выглядит так:

; named.boot file for caching-only server
directory /var/named

primary 0.0.127.in-addr.arpa db.127.0.0 ; loopback
net
cache . db.cache ; root
servers

В дополнение к этому файлу, Вы также должны установить

db.cache файл с подходящим списком root серверов. Это описывается
ближе к концу главы "Конфигурация решающего устройства".

8.2 SLIP Операция.

Телефонный вызов IP серверов часто предлагает SLIP обслуживание
через специальные пользовательские account(ы). После login в такой account,
Вы не входите в общую оболочку; взамен программа или script оболочки -
отключат SLIP драйвер серверов последовательной линии и
сконфигурируют соответствующий сетевой interface. Затем Вы должны сделать
тоже самое в конце связи.

На некоторых операционных системах, SLIP драйвер -- user-space
программа; под Linux, это - часть ядра, которая делает его намного
быстрее. Требуется, однако, чтобы порядковая линия явно была бы
преобразована в SLIP режим. Это выполнено посредством tty line
discipline, SLIPDISC. Пока tty находится в обычной line discipline
(DISC0), изменятся данные только с процессвми пользователя, используя
normal read (2) и write(2) вызовы, SLIP драйвер - отключен для записи
или чтения из tty, пока все данные, поступающие на серейный порт,
будут пропущены SLIP драйвером.

SLIP драйвер непосредственно понимает число разновидностей на
SLIP протоколе. Кроме обычного SLIP, он также понимает CSLIP,
который выполняется так называемым Van Jacobson header compression на
выходящих IP блоков.(1) Дополнительно, имеются шести-битовые версии для
каждого из этих протоколов.

Простой способ преобразовать последовательную линию в SLIP режим
- использовать slattach. Допустим, что у Вас есть модем на /dev/cua3, и
Вы удачно подсоеденились на SLIP сервер. Вы затем бы выполнили:

#slattach /dev/cua3 &

Это включит line discipline cua3 к SLIPDISC, и подсоединит ее к
одному из interface SLIP сети. Если это ваша первая активная SLIP связь,
то линия будет подсоединена к sl0; вторая была бы подсоединенп к sl1, и
так далее. Текущие ядра поддерживают до восьми одновременных SLIP связей.

1. Van Jacobson header compression описан в RFC 1441.

Заданное по умолчанию оформление пакета, выбранное slattach -
CSLIP. Вы можете выбрать любой другой режим, используя -p переключатель.
Для того, чтобы использовать normal SLIP (no compression), Вы должны
использовать

# slattach -p slip /dev/cua3 &

Другие режимы - cslip, slip6, cslip6 (для шести-битовой версии
Slip(а)), и adaptive для адаптивного SLIP. Последние оставляют это для
ядра, чтобы выяснить, который тип оформления пакета SLIP использует remote
end.

Заметьте, что Вы обязаны использовать такое же оформление, какое
имеет Ваш peer. Например, если cowslip использует CSLIP,то Вы должны
использовать его же. Симптомы рассогласования будут такие, что ping
незначительному хосту не вернет блоки огратно. Если другой хост pings
Вас, то Вы можете увидеть сообщение типа "Can't build ICMP header'' на
вашем мониторе. Один способ избежать эту неприятность - надо
использовать adaptive SLIP.

Фактически, slattach не только не позволяет Вам отключить SLIP, но
и не позволяет отключает другие протоколы, которые используют
последовательную линию также, как и PPP или KISS (другой протокол,
используемый людьми в ham radio). Для деталей, обратитесь пожалуйста к
slattach инструкции стр. 8.

После передачи линии SLIP драйверу, Вы должны сконфигурировать
сетевой interface. И снова, мы используем стандарт ifconfig и route
команды. Предположим, что из vlager мы соединилисьс сервером crowslip.
Тогда Вы должны выполнить:

# ifconfig sl0 vlager pointopoint cowslip
# route add cowslip
# route add default gw cowslip

Первая команда конфигурирует interface как point-to-point связь к
cowslip, в то время как вторая и третья команды прибавляет route к
cowslip и задает по умолчанию маршрут, используемый cowslip как ворота.

При демонтаже SLIP связи, Вы сначала должны удалить все маршруты
cowslip, используя route c del опцией, уберите interface, и передаете
slatch сигнал hangup(повесить трубку). Впоследствии Вы должны hangup
модем, использующий Вашу терминал программу:

# route del default
# route del cowslip
# ifconfig sl0 down
# kill -HUP 516

                       Назад | Содержание | Вперед