Загрузка...



  • 10.1. Настройка сервера DNS
  • 10.2. Кэширующий сервер DNS
  • 10.3. Настройка дополнительного сервера DNS
  • 10.4. Команды управления сервером DNS
  • 10.5. Использование nslookup
  • 10

    Служба имен — DNS

    Думаю, что не нужно в очередной раз рассказывать о преобразовании IP-адреса в имена компьютеров и о том, что выполняет служба DNS. Данному вопросу посвящены целые тома. Мы же давайте займемся непосредственно настройкой сервера DNS, который будет работать под управлением ОС Linux.

    Перед началом настройки сервера DNS разберемся, как он работает. Система имен DNS — это иерархическая древообразная система. В этом дереве существует корень — он обозначается «.» (root). Список корневых серверов должен быть у каждого сервера: он содержится в файле named.са, созданием которого мы займемся в п. 10.1. Этот файл может называться и по-другому — в зависимости от настроек сервера. Существует определенное количество доменов верхнего уровня. Наиболее известные вы знаете: com, gov, net, org и другие.

    Допустим, что пользователь вводит в окне браузера адрес http://www.yahoo.com. Однако адресация в сети Интернет построена на основе IP-протокола. Поэтому для того, чтобы установить соединение с компьютером www.yahoo.com компьютеру пользователя необходимо знать его IP-адрес, поэтому операционная система пользователя пытается разрешить (перевести) имя компьютера в IP-адрес. С этой целью она обращается к серверу DNS. Сервер DNS сначала пытается разрешить имя данного компьютера, используя свой собственный кэш имен. Если требуемое имя компьютера в нем отсутствует, то сервер DNS обращается к одному из корневых серверов DNS, о которых мы поговорим позже. Запрос обрабатывается рекурсивно: корневой сервер обращается к серверу, который отвечает за домен com, а тот, в свою очередь, к серверу DNS домена yahoo.com. Сервер DNS домена yahoo.com возвращает IP-адрес компьютера www — 64.58.76.222 или все адреса, которые сопоставлены этому имени (многие сетевые операционные системы, в том числе и Linux, позволяют одному имени сопоставлять несколько IP-адресов).

    Примечание.

    На самом деле, если выполнить разрешение имени www.yahoo.com, сервер DNS возвратит следующие адреса:

    64.58.76.222

    64.58.76.228

    64.58.76.223

    64.58.76.176

    64.58.76.224

    64.58.76.177

    64.58.76.227

    664.58.76.179

    А официальное имя компьютера www.yahoo.com (это его каноническое имя — о канонических именах и как их использовать будет сказано ниже) —www.yahoo.akadns.net

    10.1. Настройка сервера DNS

    Учитывая, что на обращение к серверу DNS провайдера требуется 10…15, а иногда и все 30 секунд (это зависит от загрузки сети и от скорости соединения), установка сервера DNS в локальной сети с выходом в Интернет является просто необходимой. Обычно сервер DNS устанавливается на шлюзе, который используется для выхода в Интернет. Прежде чем приступить к настройке сервера, нужно определить, запущен ли он:

    ps –ax | grep named

    Если сервер DNS запущен, то его нужно остановить (командой kill или ndc), а если он вообще не установлен, то вам придется установить пакет bind. Обратите внимание, что исполнимый файл называется named, а сам пакет — bind. BIND (Berkley Internet Nameserver Daemon) — это наиболее известный и используемый DNS-сервер, настраиваемый в Linux. Для работы сервера должен быть активизирован сервис network. Я надеюсь, вы не забыли, как это сделать?

    Теперь приступим к непосредственной настройке сервера и рассмотрим ее на примере. Для этого обратимся к файлу /etc/named.conf, в котором содержится основная информация о параметрах сервера (см. листинг 10.1).

    Листинг 10.1. Файл named.conf

    logging {

     category cname {null; };

    };

    options {

     directory "/var/named";

    };

    zone "." {

     type hint;

     file "named.ca";

    };

    zone "dhsilabs.com" {

     type master;

     file "dhsilabs.com";

     notify no;

    };

    zone "0.0.127.in-addr.arpa" {

     type master;

     file "named.local";

    };

    zone "1.168.192.in-addr.arpa" {

     type master;

     file "192.168.1";

     notify yes;

    };

    Основной рабочий каталог сервера — /var/named. Указанные без начального обратного слэша имена файлов будут искаться относительно этого каталога. То есть именно в нем сервер будет искать файлы dhsilabs.com, named.local, 192.168.1, named.ca (см. листинги 10.1, 10.3, 10.4). Обслуживаемая сервером зона (домен) — dhsilabs.com.

    Давайте рассмотрим поподробнее листинг 10.1. Сначала в нем были определены опции протоколирования — блок logging. Затем идет задание параметров самого сервера — блок options. Параметр directory определяет корневой каталог сервера – /var/named. Помимо параметра directory в блоке options могут задаваться и другие параметры (такие, как forwarders, forward и др.), о которых сказано будет несколько позже (см. п. 10.2). Для функционирования сервера достаточно и одного параметра directory.

    После блока параметров должны быть перечислены зоны, обслуживаемые сервером. Мы будем обслуживать зону (домен) dhsilabs.com. Информация об этой зоне хранится в файле /var/named/dhsilabs.com. Позже мы займемся созданием этого файла. С помощью него наш сервер будет преобразовывать имена компьютеров в IP-адреса. Для обратного преобразования служит файл /var/named/192.168.1.

    Зоны "." и "0.0.127.in-addr.arpa" — особые. Я не буду их подробно описывать: их назначение вы поймете из дальнейшего текста книги. Файл named.local — это файл обратного соответствия, предназначенный для преобразования IP-адресов в имена, то есть, в частности, он используется для преобразования адреса 127.0.0.1 в имя localhost.

    Файл named.ca — это файл, в котором перечислен начальный набор корневых DNS-серверов. Он содержит информацию о корневых серверах DNS. При разрешении имени в IP-адрес или наоборот, полученная информация кэшируется и остается в памяти сервера определенное время. В свой работе, если нужно разрешить имя в IP-адрес (или наоборот), ваш DNS-сервер сначала будет искать необходимую ему информацию в кэше. Если ее там не окажется, то сервер обратится к одному из корневых серверов DNS, IP-адреса которых находятся в файле named.ca. Файл named.ca необходимо регулярно обновлять, чтобы он всегда содержал свежие данные (первый раз его нужно обновить сразу же после установки сервера, несмотря на то, что этот файл будет только что создан). Немного позже я отдельно опишу его обновление.

    Файл dhsilabs.com непосредственно служит для преобразования имен в IP-адреса (см. листинг 10.2).

    Листинг 10.2. Файл dhsilabs.com

    @    IN SOA den.dhsilabs.com. hostmaster.dhsilabs.com. (

            93011120 ; серийный номер

            10800 ; обновление каждые 3 часа

            3600 ; повтор каждый час

            3600000 ; хранить информацию 1000 часов

            86400) ; TTL записи — 2 4 часа

         IN NS den.dhsilabs.com.

         IN A 192.168.1.1

         IN MX 150 den.dhsilabs.com.

    den  IN A 192.168.1.1

         IN HINFO INTEL CELERON (LINUX)

         IN MX 100 den

         IN MX 150 evg.dhsilabs.com.

    ns   IN CNAME den.dhsilabs.com.

    www  IN CNAME den.dhsilabs.com.

    ftp  IN CNAME den.dhsilabs.com.

    mail IN CNAME den.dhsilabs.com.

    evg  IN A 192.168.1.2

         IN MX 100 den.dhsilabs.com.

    localhost IN A 127.0.0.1

    Попробую объяснить все как можно быстрее и проще. Свое объяснение оформлю в виде табл. 10.1.

    Записи DNS Таблица 10.1

    Запись Описание
    NS Обозначает сервер имен (name server)
    А Задает IP-адрес, соответствующий имени компьютера
    PTR Задает имя компьютера, соответствующее IP-адресу
    MX число Определяет почтовик, который будет обслуживать наш домен. Числовой параметр возле записи MX является приоритетом данного почтового сервера. Чем меньше число, тем выше приоритет
    CNAME Определяет каноническое имя узла, то есть, если вы в окне браузера введете http://www.dhsilabs.com, то обращение будет произведено к den.dhsilabs.com
    HINFO Сведения об аппаратном обеспечении. Рекомендую не заполнять эту запись или использовать заведомо неправильные данные. Чем меньше информации имеет о вашей сети злоумышленник, тем сложнее ему будет атаковать ее
    TXT Прочие сведения. Содержит произвольный текст

    Обратите внимание на точку в конце

    @ IN SOA den.dhsilabs.com. hostmaster.dhsilabs.com. (

    Если точка не указана, то к имени будет добавлено имя домена (то есть dhsilabs.com).

    Листинг 10.3. Файл named.local

    @ IN SOA dhsilabs.com. root.dhsilabs.com. (

         199609203 ;серийный номер

         28800 ;обновление каждые 8 часов

         7200 ;повтор каждые 2 часа

         604800 ;хранить информацию 168 часов (1 неделю)

         86400) ;TTL записи – 24 часа

      NS  dhsilabs.com.

    1 PTR localhost.

    Файл 192.168.1 или файл обратного соответствия представлен в листинге 10.4.

    Листинг 10.4. Файл обратного соответствия

    @ IN SOA den.dhsilabs.com. hostmaster.dhsilabs.com. (

         93011120 ; серийный номер

         10800 ; обновление каждые 3 часа

         3600 ; повтор каждый час

         3600000 ; хранить информацию 1000 часов

         86400 ) ; TTL записи – 24 часа

    @ IN NS den.dhsilabs.com

    1 IN PTR den.dhsilabs.com

    2.1.168.192 IN PTR evg.dhsilabs.com

    Запись PTR используется для преобразования IP-адреса в имя. Если указан не весь IP, например:

    1 IN PTR den.dhsilabs.com

    то к нему будет добавлен адрес подсети 1.168.192. IP-адреса указываются в обратном порядке!

    Для установки файла корневого кэша следует установить пакет caching-nameserver, но я рекомендую получить и установить самую новую версию. Для этого подключитесь к Интернет, запустите сервер DNS, а затем выполните команду:

    # nslookup | tee ns

    В ответ на приглашение программы nslookup введите две команды

    > set q=ns (или set type=ns)

    > .

    На экране вы увидите список корневых серверов DNS, который будет помешен в файл ns. Для преобразования файла ns в формат named.ca воспользуйтесь следующей программкой на awk (см. листинг 10.5).

    Листинт 10.5. Сценарий reformat

    #!/bin/awk

    awk ` BEGIN {

    /root/ { print ". INNS " $4"." }

    /internet/ { print $1"." " 999999 IN a " $5 }

    END `

    Использовать ее нужно как reformat <source file> <output file>, то есть:

    reformat ns named.ca

    Теперь осталось скопировать named.ca в каталог /var/named и на этом — все.

    А теперь покажу, как то же самое можно было сделать проще. Для этого следует воспользоваться программой dig, выполнив команду:

    dig @e.root-servers.net.ns > root.hints.new

    После этого остается просто заменить старый файл named.ca новым

    файлом named.ca.new. Как видите, второй способ намного проще, но и

    первый знать не помешает.

    Обычно файл named.ca содержит примерно такую информацию:

    . 6D IN NS G.ROOT-SERVERS.NET.

    . 6D IN NS J.ROOT-SERVERS.NET.

    . 6D IN NS K.ROOT-SERVERS.NET.

    . 6D IN NS L.ROOT-SERVERS.NET.

    . 6D IN NS M.ROOT-SERVERS.NET.

    . 6D IN NS A.ROOT-SERVERS.NET.

    . 6D IN NS H.ROOT-SERVERS.NET.

    . 6D IN NS B.ROOT-SERVERS.NET.

    . 6D IN NS C.ROOT-SERVERS.NET.

    . 6D IN NS D.ROOT-SERVERS.NET.

    . 6D IN NS E.ROOT-SERVERS.NET.

    . 6D IN NS I.ROOT-SERVERS.NET.

    . 6D IN NS F.ROOT-SERVERS.NET.

    ;; ADDITIONAL SECTION:

    G.ROOT-SERVERS.NET. 5w6dl6h IN A 192.112.36.4

    J.ROOT-SERVERS.NET. 5w6dl6h IN A 198.41.0.10

    K.ROOT-SERVERS.NET. 5w6dl6h IN A 193.0.14.129

    L.ROOT-SERVERS.NET. 5w6dl6h IN A 198.32.64.12

    M.ROOT-SERVERS.NET. 5w6dl6h IN A 202.12.27.33

    A.ROOT-SERVERS.NET. 5w6dl6h IN A 198.41.0.4

    H.ROOT-SERVERS.NET. 5w6dl6h IN A 128.63.2.53

    B.ROOT-SERVERS.NET. 5w6dl6h IN A 128.9.0.107

    C.ROOT-SERVERS.NET. 5w6dl6h IN A 192.33.4.12

    D.ROOT-SERVERS.NET. 5w6dl6h IN A 128.8.10.90

    E.ROOT-SERVERS.NET. 5w6dl6h IN A 192.203.230.10

    I.ROOT-SERVERS.NET. 5w6dl6h IN A 192.36.148.17

    F.ROOT-SERVERS.NET. 5w6dl6h IN A 192.5.5.241

    Если вы настраиваете сервер DNS только для своей внутренней сети (intranet), которая не имеет выхода в Интернет, не спешите обновлять файл кэша! Он вам вообще не нужен. Вы также должны удалить зону, описывающую корневой кэш в файле named.conf.

    Теперь остается сделать пару завершающих штрихов. Отредактируйте файл /etc/resolv.conf таким образом: с помощью директивы search укажите домены для поиска, а в качестве сервера по умолчанию — 127.0.0.1. Можно также указать и адрес реального интерфейса:

    search subdomain.domain.com domain.com

    nameserver 127.0.0.1

    Как вы уже догадались, сервером DNS по умолчанию является первый сервер из списка nameserver. Напомню, что в списке может быть не более четырех серверов. Список доменов используется для поиска компьютера в

    том случае, если указано только имя узла без домена. Например, если вы введете в окне браузера http://host, сначала будет выполнена попытка обращения к узлу host.subdomain.domain.com, а потом, если узел не будет найден, к узлу host.domain.com. Если и этот узел не будет найден, вы получите соответствующее сообщение. И еще: проверьте порядок разрешения имен в файле /etc/hosts.conf. Порядок должен быть задан так: order hosts,bind. Несмотря на то, что сейчас мы используем DNS, лучше сначала все же искать в файле hosts.

    10.2. Кэширующий сервер DNS

    Кэширующий сервер, как правило, не обслуживает домен, а используется для повышения скорости работы соединения. Для настройки кэширующего сервера используется параметр forwarders, задаваемый в файле named.conf (в блоке options). Рассмотрим пример: допустим, ваш сервер для разрешения какого-нибудь имени пытается добраться до одного из корневых серверов. А если у вас коммутируемое соединение да и модем на 14400? Сейчас выглядит смешно, но иногда бывают и такие ситуации, например, в моей системе спокойно уживаются два модема — один 56К V.90, а второй именно на 14К. В любом случае, если у вас нет собственного домена, а сервер DNS запущен на вашей машине, которую вы используете в гордом одиночестве, то с помощью вышеупомянутой директивы можно существенно повысить скорость соединения. Способ очень прост: можно заставить провайдера проделать за вас всю «грязную» работу. В обычной ситуации в процессе разрешения какого-нибудь имени ваш сервер будет последовательно запрашивать несколько удаленных корневых DNS-серве-ров, с каждым из которых надо установить соединение, отправить запрос и получить ответ. Создание у себя кэширующего DNS-сервера позволит возложить всю эту работу на DNS-сервер провайдера. При этом ваш DNS-сервер будет отсылать в сеть только. один запрос на разрешение имени (DNS-серверу провайдера) и получать только один окончательный ответ. Это особенно полезно, если у вас плохое соединение с Интернет.

    Для того, чтобы насладиться такой возможностью, следует в файл named.conf добавить следующие параметры (в блоке options):

    forward first;

    forwarders {

     192.168.99.1;

     192.168.99.2;

    };

    Здесь я рассматриваю конкретный пример, вы же у себя замените адреса 192.168.99.1 и 192.168.99.2 на адреса DNS-серверов вашего провайдера. Параметр forwarders задает заключенный в фигурные скобки список IP-адресов, соответствующих DNS-серверам, которым ваш DNS-сервер будет переадресовывать запросы вместо того, чтобы отвечать на них самому. IP-адреса перечисляются через точку с запятой.

    Параметр forward может принимать одно из двух следующих значений:

    only — ваш DNS-сервер никогда не должен предпринимать попыток обработать запрос самостоятельно;

    first — ваш DNS-сервер должен пытаться сам обработать запрос, если указанные далее параметром forwarders сервера DNS не были найдены. Использование параметра forward бессмысленно без использования параметра forwarders.

    Таким образом, вернемся к настройке сервера, весь файл named.conf примет следующий вид, приведенный в листинге 10.6:

    Листинг 10.6. Файл named.conf кэширующего сервера DNS

    options {

     directory "/var/named";

     forward first;

     forwarders {

      192.168.99.1;

      192.168.99.2;

     };

     // Раскомментируйте следующую строку, если вы

     // работаете через firewall и система не работает

     // query-source port 53;

    };

    zone "." {

     type hint;

     file "named.ca";

    };

    zone "0.0.127.in-addr.arpa" {

     type slave;

     file " named.local ";

    };

    Обратите внимание, что в примере уже не поддерживается зона dhsilabs.com.

    Как правило, кэширующий сервер используется на отдельной машине, которая подключается к Интернет по коммутируемому соединению. Нужно учитывать, что сервер DNS сразу требует обращения к какому-нибудь сетевому ресурсу. В нашем же случае, если соединение не установлено, то устройство ррр0 существовать не будет, a named будет страшно ругаться на то, что сеть недоступна. При этом недоступным окажется даже интерфейс lо, а программа nslookup, если она нам понадобится без существования сети, просто «подвиснет», ожидая ответа от сервера DNS.

    Есть два способа решить данную проблему. Какой использовать — это решать вам. Первый заключается в том, что при установлении соединения сценарий ррр-on, который обсуждался в гл. 7, будет запускать программу ndc с параметром start (см. ниже), а сценарий ppp-off будет останавливать сервер DNS командой ndc stop.

    Второй способ основывается тоже на использовании сценариев ррр-on и ppp-off, но в этом случае сервер dns всегда будет запущен. Принцип работы заключается в подмене файла корневого кэша named.ca. Сервер dns содержит пустой файл корневого кэша, и при установке соединения сценарий ррр-on скопирует вместо пустого файла нормальный файл кэша. Сценарий ppp-off при разрыве соединения перезапишет нормальный файл named.ca пустым файлом с таким же именем. При использований этого способа в ваших протоколах (журналах) будут регулярно появляться сообщения примерно такого содержания:

    Jan 5 16:10:11 den named[10147] : No root nameserver for class IN

    Для полноты картины хочу отметить, что если вы используете NFS, и у вас возникают проблемы с монтированием удаленных файловых систем, запускайте сервер named после запуска nfsd и mountd.

    10.3. Настройка дополнительного сервера DNS

    Вы когда-нибудь обращали внимание, что у любого уважающего себя провайдера есть два сервера DNS — первичный (primary или master) и вторичный (secondary или slave)? Так вот сейчас и мы займемся настройкой вторичного сервера DNS.

    Примечание. Практически у каждого провайдера работают два сервера DNS. Наличие двух серверов обеспечивает, если можно так выразиться, избыточность разрешения имени. Например, с первичным сервером что-нибудь случилось, произошел сбой, что бывает очень редко, или же просто первичный сервер не в состоянии обработать большое количество запросов клиентов. Тогда система разрешения имен операционной системы, получив отказ от первичного сервера DNS, обращается к вторичному.

    Например, вам нужно создать вторичный сервер, который будет обслуживать домен domain.com. С этой целью внесите следующие изменения в файл named.conf дополнительного сервера:

    zone "domain.com" {

     type slave;

     file "domain.com";

     masters {

      192.168.1.1;

      192.168.1.2;

     };

    };

    IP-адреса основных серверов DNS вашей сети указываются внутри подсекции master через точку с запятой. Вторичный сервер, в отличие от кэширующего, всегда должен иметь тип slave.

    10.4. Команды управления сервером DNS

    Для управления сервером DNS используется программа ndc. Ее можно использовать с параметрами start, stop, reload, restart.

    Параметр start запускает сервер, a stop — останавливает. Параметр reload перезагружает файлы зоны, если в них произошли изменения, а параметр restart перезапускает сервер DNS.

    10.5. Использование nslookup

    Программа nslookup используется для просмотра зоны DNS и входит в состав Linux (и всех вариантов UNIX), а также Windows NT.

    Примечание. В данном случае зону следует понимать как домен и читать «для просмотра домена». В зоне содержится различная информация о компьютерах в домене. Зоны бывают разные: одни содержат информацию о компьютерах в домене и служат для преобразования имени компьютера в IP-адрес и наоборот (см. листинг 10.1), другие содержат информацию о корневых серверах — зона «.». Последняя зона относится к типу hint — подсказка, зоны для разрешения имен обычно имеют тип master (главный), а зоны вторичных серверов относятся к типу slave (подчиненный).

    Просмотр зоны — это просмотр информации, которую содержит зона. Обычно просмотр зоны разрешается только определенным, доверенным хостам. Итак, запустите nslookup:

    # nslookup

    Default Server: myserver.domain.com

    Address: 127.0.0.1

    >

    Для того, чтобы получить информацию от сервера, нужно установить тип запроса set q=<type> (или set type=<type>). Перечень типов запросов представлен в табл. 10.2.

    Tunы запросов Таблица 10.2 

    Тип Описание
    soa Начало полномочий
    а Преобразование имени в IP-адрес узла
    аааа Отображение IРv6-адреса узла
    ns Отображение информации о сервере DNS
    ptr Преобразование IP-адреса в имя узла
    wks Распространенные службы
    hinfo Информация о «железе» узла
    mx Информация о почтовых серверах домена
    txt Отображение записи общего назначения
    cname Отображение канонического имени
    any Отображение всех ресурсных записей

    Теперь рассмотрим несколько практических примеров. Например, вы знаете имя узла — www.server.com. Давайте посмотрим, какая информация будет выведена при указании типа any:

    >set q=any

    >server.com

    Server: myserver.domain.com

    Address: 127.0.0.1

    Non-authoritative answer:

    server.com nameserver = comp1.server.com

    server.com nameserver = comp2.server.com

    server.com nameserver = comp3.server.com

    Authoritative answers can be found from:

    server.com nameserver = comp1.server.com

    server.com nameserver = comp2.server.com

    server.com nameserver = comp3.server.com

    comp1.server.com internet address = 323.111.200.1

    comp2.server.com internet address = 323.111.200.2

    comp3.server.com internet address = 323.555.200.3

    Теперь получим сведения о зоне и почтовиках.

    >server comp1.server.com

    Default Server: comp1.server.com

    Address: 323.111.200.1

    >server.com.

    Server: comp1.server.com

    Address: 323.111.200.1

    server.com internet address = 123.111.200.2

    server.com nameserver = comp1.server.com

    server.com nameserver = comp2.server.com

    server.com nameserver = comp3.server.com

    server.com

    origin = comp2.server.com

    mail addr = root.server.com

    serial = 19

    refresh = 10800 (3 hours)

    retry = 7200 (2 hours)

    expire = 86400 (1 day)

    minimum ttl = 3600 (1 hour)

    server.com preference = 10, mail exchanger = mail.server.com

    comp1.server.com internet address = 323.111.200.1

    comp2.server.com internet address = 323.111.200.1

    comp3.server.com internet address = 323.111.200.3

    mail.server.com internet address = 323.111.200.17

    А сейчас посмотрим информацию о других узлах в этой сети:

    ls server.com.

    [comp2.server.com]

    server.com. 323.111.200.2

    server.com. server = comp1.server.com

    server.com. server = comp2.server.com

    server.com. server = comp3.server.com

    mail 323.111.200.17

    gold 323.111.200.22

    www.ie 323.111.200.11

    jersild 323.111.200.25

    comp1 323.111.200.1

    comp3 323.111.200.3

    parasit3 323.111.200.20

    www.press 323.111.200.30

    comp1 323.111.200.1

    www 323.111.200.2

    Теперь вам понятно, почему не нужно вообще использовать запись HINFO? Если при реальной атаке злоумышленник выяснит, какая операционная система используется на компьютерах в вашей сети, ему будет проще нанести удар. Я не отрицаю, существует много способов выяснить тип ОС, но зачем же сообщать это самому?

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

    Несколько замечаний:

    1. IP-адреса использовались учебные.

    2. Не всегда все так просто: иногда настройки сервера DNS и firewall не разрешат вам просмотреть некоторую информацию о зоне, например ту, которую мы получали с помощью команды Is server.com.

    Разрешить передачу зоны (трансфер зоны) определенным узлам, а значит, запретить всем остальным, вы можете с помощью директивы allow-transfer. В следующем примере трансфер зоны разрешен узлам 10.1.1.1 и 10.1.2.1. Другими словами, на узлах 10.1.1.1 и 10.1.2.1 можно будет использовать команду nslookup ls для просмотра зоны.

    allow-transfer

    {

     10.1.1.1;

     10.1.2.1;

    };








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх