Мастер слейв

В этой статье я хочу рассказать вам о том, как настроить BIND9 Named сервер на Linux машинах и сделать из них связку основного и резервного ДНС сервера.

Если у вас возникли вопросы по установке пакета BIND из репозиториев или из исходников. Отпишите об этом в комментариях и я постараюсь помочь вам в решении вашего вопроса.

Итак, допустим, BIND установлен и что же дальше?

Давайте проверим работает ли он в данный момент времени или нет?

Примечание: такую проверку сделать нужно, потому что при установке пакета BIND, в некоторых дистрибутивах Linux, установщик сразу же его может запустить. Этого нам пока не нужно.

Итак, если BIND запущен — остановите его.

давайте заглянем в основной конфигурационный файл BIND (обычно он располагается по пути /etc/named.conf или /etc/bind/named):

### КОД по-умолчанию ###

options {
     directory «/var/named»;
};

zone «.» IN {
     type hint;
     file «caching-example/named.root»;
};

zone «localhost» IN {
     type master;
     file «caching-example/localhost.zone»;
     allow-update { none; };
};

zone «0.0.127.in-addr.arpa» IN {
     type master;
     file «caching-example/named.local»;
     allow-update { none; };
};

теперь давайте из этого конфига сделаем конфиг для MASTER зон:

### КОД для MASTER ###

options {
     directory «/var/named»;
     allow-query { any; }; //указываем кто может обращаться за ДНС запросами к этому серверу — ставим «any», т.е. любой.
     version «No info»; // Прячем реальную версию ДНС сервера за надписью «No info». Тут можно всякое написать, в т.ч. и «заборное».
     listen-on { 192.168.1.100; 127.0.0.1; }; // Тут мы указываем на каких интерфейсах нам нужно ловить ДНС запросы, на 53 порту.
     allow-recursion { none; }; // отключаем рекурсию
     allow-transfer { 192.168.2.100; }; // Говорим MASTER серверу куда можно передавать зоны (обычно тут указывается адрес IP Slave сервера).
};

zone «.» IN {
     type hint;
     file «caching-example/named.root»;
};

zone «localhost» IN {
     type master;
     file «caching-example/localhost.zone»;
     allow-update { none; };
};

zone «0.0.127.in-addr.arpa» IN {
     type master;
     file «caching-example/named.local»;
     allow-update { none; };
};

zone «domain1.ru» IN { // Вот собственно и первая наша внешняя зона, которую будет обслуживать наш сервер
     type master; // поскольку мы хотим чтобы для этой зоны наш сервер был первичным (MASTER), то и пишем тут «type master»
     file «caching-example/domain1.conf»; // А это место расположения файла с описанием зоны. Название файла «domain1.conf» может быть произвольным.
     notify yes; // Говорим зоне MASTER сервера предупреждать SLAVE сервер о том что зона обновилась (если в нее вносили какие-то изменения).
};

zone «domain2.ru» IN { // А это вторая зона. Таких зон может быть ооочень много.
     type master; // По аналогии.
     file «caching-example/domain2.conf»; // По аналогии.
     notify yes; // По аналогии.
};

Вот и все.

А теперь давайте посмотрим на другую машину. Также поставим там Bind как и для MASTER. Смотрим конфиг:

### КОД для SLAVE ###

options {
     directory «/var/named»;
     allow-query { any; }; //указываем кто может обращаться за ДНС запросами к этому серверу — ставим «any», т.е. любой.
     version «No info»; // Прячем реальную версию ДНС сервера за надписью «No info». Тут можно всякое написать, в т.ч. и «заборное».
     listen-on { 192.168.2.100; 127.0.0.1; }; // Тут мы указываем на каких интерфейсах нам нужно ловить ДНС запросы, на 53 порту.
     allow-recursion { none; }; // отключаем рекурсию
};

zone «.» IN {
     type hint;
     file «caching-example/named.root»;
};

zone «localhost» IN {
     type master;
     file «caching-example/localhost.zone»;
     allow-update { none; };
};

zone «0.0.127.in-addr.arpa» IN {
     type master;
     file «caching-example/named.local»;
     allow-update { none; };
};

zone «domain1.ru» IN { // Вот собственно и первая наша внешняя Slave зона, которую будет обслуживать наш сервер
     type slave; // поскольку мы хотим чтобы для этой зоны наш сервер был вторичным (SLAVE), то и пишем тут «type slave»
     file «caching-example/domain1-slave.conf»; // А это место расположения файла с описанием зоны. Название файла «domain1-slave.conf» может быть произвольным. Но лучше, для удобства помечать файлик маркером, так как сделал это я «-slave».
     masters { 192.168.1.100; }; // А вот Этой переменной мы указываем SLAVE серверу адрес MASTER сервера, откуда, собственно, мы и будем забирать описание и детали зоны «domain1.ru»
};

zone «domain2.ru» IN { // А это вторая Slave зона. Таких зон может быть ооочень много.
     type slave; // По аналогии
     file «caching-example/domain2-slave.conf»; // По аналогии.
     masters { 192.168.1.100; }; // По аналогии.
};

Обратите внимание, что в listen-on { 192.168.2.100; 127.0.0.1; }; стоит IP адрес отличный от адреса сервера MASTER, более того он находится в другой подсети. Это сделано для того чтобы, если вдруг подсеть #1 192.168.1.xxx «упадет» и перестанет отвечать на запросы… то резервный сервер в подсети #2 192.168.2.xxx — наш SLAVE останется доступным для общекорпоративной сети 192.168.xxx.xxx и он сможет продолжать обрабатывать ДНС запросы пользователей так, что они ничего не почувствуют. Как только MASTER сервер встанет в строй, работа продолжится в штатном режиме.
Примечание: Если MASTER сервер выходит из строя очень важно понимать, что добавление новых записей на SLAVE сервер лучше не производить.. иначе база данных зон на MASTER сервере потеряет свою актуальность и хоть перебросить новые зоны на мастер сервер не составит труда, надо понимать, что в масштабах обновления записей к примеру 1000 и более, это будет очень тяжело.
Потому, если аварийное состояние MASTER сервера затянется надолго.. то лучше объявить клиентам о технических работах и приостановить также работу и SLAVE сервера до момента полного восстановление работоспособности MASTER узла.
Так же обратите внимание, что мы убрали allow-transfer { 192.168.2.100; }; — Для SLAVE сервера нет нужны передавать зону куда либо еще (за редким исключением), потому мы убрали эту опцию.

Вот и все со SLAVE.

Теперь можно добавлять на сервере MASTER файлы описания/содержания зоны и выкладывать их в соответствующие (указанные в файле конфигурации) директории. На сервер SLAVE эти файлы добавлять не нужно, SLAVE сервер сам их заберет с базы MASTER сервера.

Пример такого файла:

$ORIGIN .
$TTL 1800      ; 30 minutes
domain1.ru     IN SOA ns1.domain1.ru. info.domain1.ru. (
       201108083 ; serial
       1800   ; refresh (30 minutes)
       900   ; retry (15 minutes)
       604800   ; expire (1 week)
       86400   ; minimum (1 day)
       )
       NS ns1.domain1.ru.
       NS ns2.domain1.ru.
       A 192.168.1.100
       MX 10 mail.domain1.ru.
$ORIGIN domain1.ru.
*     A 192.168.1.100
mail      A 192.168.1.100
ns1     A 192.168.1.100
ns2     A 192.168.2.100
www     A 192.168.1.100

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

Теперь запустим поочередно Bind (named) демоны на MASTER и на SLAVE серверах и посмотрим как оно все работает.

На сим все..
Надеюсь у вас все получится.

С Уважением,
Savaog

dedicatesupport.com

Это режимы работы IDE-устройств.

На одном IDE-кабеле могут работать до двух устройств:

Master (MA) — основной, или первый, и
Slave (SL) — дополнительный, или второй.

На некоторых IDE шлейфах есть пометки: Master/Slave.
Мастер — дальний конец шлейфа, слейв — тот, что посередине.
Если устройство на кабеле одно, оно обычно может работать в режиме Master, однако у некоторых для этого есть отдельный режим Single.

Как правило, не допускается работа устройства в режиме Slave при отсутствии Master-устройства, однако многие новые устройства могут работать в этом режиме.
При этом требуется поддержка со стороны BIOS или драйвера: многие драйверы, обнаружив отсутствие Master-устройства, прекращают дальнейший опрос данного контроллера.

Conner Present (CP) — имеющийся на некоторых моделях режим поддержки винчестеров Conner в режиме Slave; введен из-за несовместимостей в диаграммах обмена по интерфейсу.

Cable Select (CS, CSel) — выбор по разъему кабеля — режим, в котором устройство само устанавливается в режим Master/Slave в зависимости от типа разъема на интерфейсном кабеле.
Для этого должен быть выполнен ряд условий:

— оба устройства должны быть установлены в режим Cable Select;
— контакт 28 со стороны контроллера должен быть либо заземлен, либо на нем должен поддерживаться низкий уровень;
— на одном из разъемов кабеля контакт 28 должен быть удален, либо отключен подходящий к нему провод кабеля.

Таким образом, на одном из устройств контакт 28 оказывается заземленным (этот винчестер настраивается на режим Master), а на другом — свободным (Slave).

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

На обоих IDE устройствах перемычки переключаются в режим Cable Select.
Тогда контроллер сам выбирает, кто ведущий, а кто ведомый в этой паре.
Этот режим корректно работает только при наличии двух устройств на кабеле и не получил широкого распространения.
На обычном кабеле этот режим не работает.

В комплекте с мат. платами идут кабели Master-Slave, и лучше перемычками выставить зависимости устройств.

Все перечисленные режимы устанавливаются перемычками (джамперами) на плате устройства.
Положения перемычек обычно описаны на корпусе или в инструкции.

faqhard.ru

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

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

Сразу оговоримся, что в данном материале речь не идет о серверах, как о программах, которые реализуют функцию сервера доменных имен, например named или сервер доменных имен Windows Server 2000. Мы будем рассматривать серверы, как процессы, которые должны выполнять определенные функции по обслуживанию DNS запросов.

В документах RFC-1034 и RFC-1035 выделяют несколько типов DNS-серверов. В соответствии с типами откликов на запрос к системе доменных имен серверы можно разделить на авторитативные (authoritative) и неавторитативные (non authoritative).

Авторитативный отклик (authoritative response) возвращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая resolver-у (клиент DNS).

Неавторитативный отклик (non authoritative response) возвращают серверы, которые не отвечают за зону, содержащую необходимую resolver информацию.

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

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

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

Master-сервер (primary, первичный) доменных имен является ответственным (authoritative) за информацию о зоне в том смысле, что читает описание зоны с локального диска компьютера, на котором он функционирует и отвечает в соответствии с этим описанием на запросы resolver-ов. Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера. Вообще говоря, такое определение несколько устарело, и позже будет ясно почему. Но при настройках реальных серверов мы будем использовать именно это определение.

Для зоны можно определить только один master-сервер, т.к. первоисточник может и должен быть только один.

Slave-сервер (secondary, вторичный, дублирующий) также является ответственным (authoritative) за зону. Его основное назначение заключается в том, чтобы подстраховать работу основного сервера доменных имен (master server), ответственного за зону, на случай его выхода из строя, а также для того, чтобы разгрузить основной сервер, приняв часть запросов на себя. Так, например, из 13 серверов, которые обслуживают корневую зону, 12 являются slave-серверами.

Администратор slave-сервера не прописывает данные описания зоны. Он только обеспечивает настройку своего сервера таким образом, чтобы его сервер копировал описание зоны с master-сервера, поддерживая его (описание зоны) в актуальном согласованном с master-сервером состоянии.

Обычно, время согласования описания зоны между slave-сервером и master-сервером задается администратором master-сервера в описании зоны. Slave-сервер в момент своего запуска копирует это описание и затем руководствуется им при обновлении информации о зоне. Slave-сервера периодически через заданный интервал времени опрашивают master-сервер на предмет изменения описания зоны. Если изменения имеют место быть, то описание зоны копируется на slave-сервер.

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

Существует оговоренная практика резервирования серверов, которая описана в рекомендациях по ведению зон. Она заключается в том, что для домена второго уровня необходимо иметь как минимум два сервера, ответственных за зону, т.е. дающих авторитативные отклики на запросы. Один master-сервер и один slave-сервер. При этом эти серверы должны иметь независимые подключения к Интернет, чтобы обеспечить бесперебойное обслуживание запросов к зоне в случае потери связи с одним из сегментов сети, в котором находится один из серверов.

Мастер слейв

Рис.1. Схема подключения master и slave серверов зоны

Из рисунка 1 видно, что корпоративная локальная сеть и сеть регистратора имеют независимые подключения к Интернет, через разных канальных провайдеров. В частности резервирование серверов в ru-center (www.nic.ru) обеспечивает такую схему подключения, т.е. master-сервер может быть размещен на площадке корпоративной локальной сети, а slave на площадке ru-center.

Размещение обоих серверов на площадке регистратора, например, ru-center, также обеспечивает независимое подключение серверов, т.к. обычно регистратор имеет несколько точек подключения к Интернет.

Как уже было сказано, slave-сервер копирует описание зоны c master-сервера. В настоящее время существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

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

Так slave-сервером называют сервер, который использует механизм передачи зоны для получения копии зоны, а master-сервером называют сервер, с которого осуществляется копирование зоны. При этом зону можно скопировать с любого сервера, который является авторитативным. Т.е. зону можно скопировать и со slave-сервера, который относительно самой процедуры копирования зоны будет считаться master-сервером. Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master. Этот сервер для зоны только один, и он находится в корне процедуры копирования описания зоны.

Типизация серверов относительно процедуры обмена описаниями зон связана с возможностями, которые не описаны в RFC-1034 и RFC-1035, и, соответственно, не поддерживались в ранних версиях программ-серверов доменных имен. Это механизм объявлений об изменениях в описании зоны (RFC-1996), динамическое обновление описания зоны (RFC-2136) и инкрементальное обновление описания зоны (RFC-1995).

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

Сначала о том, что такое уведомления об изменениях описания зоны (DNS NOTIFY). Идея достаточно проста и проистекает из проблемы распространения изменений, внесенных в описание зоны при ее редактировании. Дело в том, что slave-серверы при традиционной работе опрашивают master-сервер (в данном контексте primary master) на предмет изменения в описании зоны через определенные промежутки времени, которые задаются в описании зоны. Возможна ситуация, когда изменения были внесены в зону сразу после ее копирования slave-сервером. В этом случае новая информация появится на всех slave-серверах только при следующем обновлении зоны.

Ситуация усугубляется еще и тем, что остальные не авторитативные серверы держат записи соответствия между именем домена и IP_адресом в своем кэше в течение времени TTL (Time To Live), которое также определяется в описании зоны. Обычно задержка между внесением изменений и стабильной работой с новым описанием зоны в российском сегменте Интернет составляет примерно 2 часа. Вот пример отчета программы nslookup для rambler.ru:

>set type=soa
>rambler.ru
Server: ns.rambler.ru
Address: 217.73.192.49

rambler.ru
origin = ns.rambler.ru
mail addr = bindmaster.rambler-co.ru
serial = 2002090601
refresh = 10800 (3H)
retry = 1800 (30M)
expire = 10800 (3H)
minimum ttl = 3600 (1H)
rambler.ru nameserver = ns.rambler.ru
rambler.ru nameserver = ns.park.rambler.ru
ns.rambler.ru internet address = 217.73.192.49
ns.park.rambler.ru internet address = 217.73.193.23
>

Позиция refresh говорит о том, что время опроса в стандартном режиме составляет 3 часа. А вот из другого отчета для зоны relarn.ru это время и того больше — сутки:

> relarn.ru
Server: ns.relarn.ru
Address: 194.226.65.3

relarn.ru
origin = ns.relarn.ru
mail addr = noc-dns.relarn.ru
serial = 650127367
refresh = 86400 (1D)
retry = 3600 (1H)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
relarn.ru nameserver = ns.relarn.ru
relarn.ru nameserver = ns.ussr.EU.net
relarn.ru nameserver = ns.spb.su
relarn.ru nameserver = ns2.ripn.net
ns.relarn.ru internet address = 194.226.65.3
ns.ussr.EU.net internet address = 193.124.22.65
ns.spb.su internet address = 193.124.83.69
ns2.ripn.net internet address = 194.226.96.30
>

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

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

Принцип работы DNS NOTIFY следующий:

  1. В базу данных primary master вносятся изменения (руками с последующей перезагрузкой сервера или динамически по протоколу динамического обновления зоны).
  2. Primary master оповещает свои slave о том, что произошли изменения, сообщая им номер версии описания зоны.
  3. Slave запрашивает с primary master описание зоны и, если номера версии описаний зоны не совпадают (на primary master номер больше), то инициирует процесс обновления описания зоны.
  4. Завершив обновление описания зоны, slave посылает оповещения на известные ему авторитативные сервера зоны.

На рисунке пояснется работы приведенной выше схемы:

Мастер слейв

Рис.2. Схема работы DNS NOTIFY

На рисунке 2 primary master является для обоих slave-серверов master-сервером c точки зрения процедуры передачи зоны. Но в принципе, для одного из серверов он может быть и не определен в качестве master-сервера. В этом случае появляется дополнительное звено в дереве зависимости обмена данными зоны. В этом случае изменения будут передаваться от сервера к серверу так, как это показано на рисунке 3:

Мастер слейв

Рис.3. Схема работы DNS NOTIFY при двухзвенном оповещении об изменении описания зоны.

Теперь поясним механизм динамического обновления описания зоны (Dynamic Updates или DNS UPDATE). Изначально описание зоны было, да и до сих пор в большинстве случаев остается, статическим. Это значит, что есть на Primary master файл описания зоны, в который администратор вручную или при помощи скриптов изменения содержания файла вносит изменения. Для того чтобы они стали актуальными, т.е. их увидели resolver-ы, необходима перезагрузка сервера. Идея динамического обновления описания зоны состоит в том, чтобы, во-первых, вносить изменения в описание зоны без перезагрузки сервера, а, во-вторых, делать это удаленно, т.е. администратору не нужно получать доступ к файлам описания зон ни для ручного редактирования, ни для скриптов. Тем самым класс клиентов в модели «клиент-сервер» в рамках DNS обмена расширяется на группу клиентов администрирования.

Когда актуально динамическое обновление зоны? Чаще всего необходимость динамического обновления связывают с работой по протоколу DHCP (Dynamic Host Configuration Protocol, RFC-1541). DHCP Позволяет динамически назначать компьютерам IP-адреса, маски, IP-адреса шлюзов, доменные имена и т.п., т.е. передавать хостам данные без которых невозможна работа в сетях TCP/IP.

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

Динамическое обновление позволяет авторизованным клиентам посылать запросы на динамическое обновление описания зоны серверам, которые являются авторитативными для соответствующей зоны. Обратите внимание, что запросы могут направляться как master-серверам, т.к. slave-серверам.

Если сервер не является Primary master-сервером зоны, то он отправляет (ретранслирует) запрос на обновление своему master-серверу. Таким образом запрос на обнавление достигает Primary master-сервера зоны.

Как только Primary master-сервер совершит обновление описания зоны, он может по механизму DNS NOTIFY оповестить об этом slave-серверы, которые, в свою очередь, обновят свои описания зоны.

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

Для того, чтобы успешно выполнялись обмены со slave-серверами, при каждом изменении зоны изменяется и номер ее версии. Это позволяет slave-серверам поддерживать свои описания зоны в актуальном, согласованном с Primary master-сервером состоянии.

Динамическое обновление описания зоны порождает другую проблему — многократную передачу по сети описания зоны между master-серверами и slave-серверами. Если описание зоны большое, то и объем трафика, который передается по сети, будет немаленький.

При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т.к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.

При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.

Для того, чтобы не передавать всю зону, а передавать только изменения предназначен механизм инкрементальной передачи описания зоны (IXFR, RFC-1995). В рамках обмена передаются номера версий описаний зон и записи, которые нужно добавить или удалить. Принцип простой — сначала идут номер старой версии и список записей, которые нужно удалить, а потом номер более свежей версии и записи, которые нужно добавить.

Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.

В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о «невидимых» серверах (stealth, см. RFC-1996). Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т.к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.

Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.

Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall. В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с «невидимого» Primary master:

Мастер слейв

Рис.4. Схема организации DNS-серверов с невидимым primary master сервером

Другая причина создания «невидимых» серверов — разгрузка официально зарегистрированных серверов. В этом случае для обслуживания определенного класса клиентов, которые можно настроить на работу с «невидимым» сервером, создается один или несколько slave-серверов зоны. Они являются авторитативными, но неизвестными широкой интернет-общественности.

Рассмотрим еще один тип серверов, которые выделяют при описании системы доменных имен — кэширующие (cache) серверы. Этот тип серверов отличается от тех, что мы обсудили раньше, тем, что сервер данного типа не является авторитативным для какой-либо зоны.

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

Кэш-сервер не поддерживает описаний зон и, соответственно, не посылает resolver-ам авторитативных откликов:

> www.w3.org
Server: [144.206.192.60]
Address: 144.206.192.60

Non-authoritative answer:
Name: www.w3.org
Addresses: 18.29.1.35, 18.7.14.127, 18.29.1.34

>

Выше приведен типичный отклик кэширующего сервера на запрос nslookup об адресе www.w3.org. Если бы сервер был авторитативным, то строчки «Non-authoritative answer» в отклике мы бы не увидели.

Мы не обсудили еще один тип серверов — это сервера, которые обслуживают корневую зону (Root servers). Их место в получении отклика на запрос к системе доменных имен ключевое. Именно к одному из корневых серверов обращается локальный сервер доменных имен, если не находит в зоне своей ответственности или в своем кэше соответствия между доменным именем и IP-адресом.

Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:

> .
Server: [144.206.192.60]
Address: 144.206.192.60

Non-authoritative answer:
(root)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM
serial = 2002091100
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)

Authoritative answers can be found from:
(root) nameserver = A.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 = F.ROOT-SERVERS.NET
(root) nameserver = G.ROOT-SERVERS.NET
(root) nameserver = H.ROOT-SERVERS.NET
(root) nameserver = I.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
A.ROOT-SERVERS.NET internet address = 198.41.0.4
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
I.ROOT-SERVERS.NET internet address = 192.36.148.17
J.ROOT-SERVERS.NET internet address = 198.41.0.10
K.ROOT-SERVERS.NET internet address = 193.0.14.129
L.ROOT-SERVERS.NET internet address = 198.32.64.12
M.ROOT-SERVERS.NET internet address = 202.12.27.33
>

Согласно этому отчету Primary master сервером для корневой зоны является сервер A.ROOT-SERVERS.NET. Именно он отвечает за все изменения в описании зоны. Остальные серверы относительно корневой зоны являются slave-серверами. Slave-серверы обновляют свои описания зоны каждые 30 минут. Если в течении недели Primary master будет неработоспособен, то по идее вся система доменных имен потеряет связность. В RFC-2870, где описаны требования к работе root серверов, содержатся общие слова о том, как не допустить такого развития событий, но там нет конкретного плана действий.

На самом деле каждый из 13 серверов — это не одна машина. Так, например, k.root-servers.net (европейский) состоит из k1, k2 и k3, m.root-servers.net (японский) состоит из двух основных серверов и двух серверов горячего резерва, которые подключены к трем независимым точкаv обмена трафиком, f.root-servers.net состоит из двух двухпроцессорных Alpha, по 4GB оперативной памяти в каждой, с балансировкой нагрузки через маршрутизатор Cisco.

И еще несколько слов о root серверах в заключении этого раздела. Существует такая организация — IEPG (Internet Operational Group), задача которой помогать Интернет Сервис Провайдерам взаимодействовать в Сети Интернет. В 1999 году на очередной встрече этой группы обсуждались проблемы DNS И приводилась некоторая статистика по запросам к root серверам:

Средние цифры таковы:

   Исходящий трафик:   600 Kbps
  Входящий трафик:   2.2 Kbps
  Число пакетов за сутки:   26M

Распределение запросов по типам:

   Поиск IP-адреса(A)   77%
   Поиск сервера доменных имен (NS)   15%
   Поиск почтового шлюза(MX)   5%

Статистика обслуживания запросов, которая названа ужасающей(Scary statistics):

— Только 26% правильных(valid) запросов к корневой зоне.

— В 6% случаев на правильный запрос нельзя получить авторитативного отклика (.com, .net etc.)

— 66% запросов к несуществующим доменам верхнего уровня (non existent TLDs)

По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствие негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду.
Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности приреализации протоколов.

К слову сказать, в 2002 году на встрече IEGP также обсуждались проблемы DNS, а точнее масштаб ошибок при делегировании и описании зон.

Рекомендованная литература:

  1. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
  2. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
  3. P. Vixie & others. RFC-2136. Dynamic Updates in the Domain Name System (DNS UPDATE). 1997. (http://www.ietf.org/rfc/rfc2136.txt?number=2136)
  4. P. Vixie. RFC-1996. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). 1996. (http://www.faqs.org/rfcs/rfc1996.html)
  5. P. Vixie. RFC-1995. Incremental Zone Transfer in DNS. 1996. (http://www.faqs.org/rfcs/rfc1995.html)
  6. R. Bush. RFC-2870. Root Name Server Operational Requirements. 2000. (http://www.ietf.org/rfc/rfc2870.txt)
  7. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.


Полезные ссылки:

  1. R. Droms. Dynamic Host Configuration Protocol. ISI, 1997. (ftp://ftp.isi.edu/in-notes/rfc2131.txt)
  2. http://www.wia.org/pub/rootserv.html — схема расположения root servers системы доменных имен.
  3. http://m.root-servers.org/ — статистика и краткое описание root серверов m.root-servers.org
  4. http://k.root-servers.org/ — статистика и краткое описание root серверов k.root-servers.org
  5. http://www.isc.org/iepg/notes-mar99.html — протокол встречи IEPG Оклахоме в марте 1999 года. Довольно любопытная статистика обращений к корневой зоне.

info.nic.ru

Ведущее устройство (англ. Master — букв. «господин») — главное устройство в сети, которое может самостоятельно запрашивать данные у ведомых устройств, или рассылать широковещательные сообщения.

В сетях, работающих по принципу ведущий—ведомые (Master—Slave), только ведущее устройство может инициировать передачу данных и определяет порядок доступа к сети.

В профессиональной литературе встречаются ещё термины «мастер-устройство», «устройство-мастер», «Master».

В одной сети может быть несколько ведущих устройств, тогда сеть называется многомастерной. Многомастерную технологию используют сети Profibus. Многомастерная система требует определения порядка доступа мастеров к сети. Например, в сетях Profibus используется метод передачи маркера (англ. token), по идее аналогичный применяемому в сетях Token ring, но зависящий не от топологического расположения мастеров в сети, а от сетевого адреса мастера. Одно ведомое устройство в сети с несколькими мастерами должно иметь только одного конкретного мастера.Ведущее устройство вместе с назначенными ему ведомыми составляют Мастер-систему. Конфигурация Мастер-системы обычно известна на стадии проектирования.

Технологию обмена Master-Slave поддерживают многие сетевые протоколы, в частности:

  • Profibus DP
  • Profibus PA
  • Modbus
  • INTERBUS
  • PROFINET IO
  • SERCOS III

Технология Master-Slave может быть сопоставлена с технологией клиент-сервер, причём Master эквивалентен клиенту (активный партнёр), а Slave — серверу (пассивный партнёр), однако обратными являются количественные отношения в системе Master-Slave один активный партнёр и несколько пассивных. В системе «Клиент-сервер» обычно несколько активных партнёров приходится на один пассивный сервер.

ru.wikipedia.org

Master&Slave устройства в датчиках присутствия

В датчиках присутствия понятия «master» и «slave» относятся к подключению датчиков.
Как и принято, master здесь ведущее устройство, а slave – ведомое.

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

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

2

Комбинация master и slave-устройств расширяет зону действия ведущего датчика. Это удобно, например, для управления длинной группой светильников.

Кроме экономии важная особенность системы с ведущими и ведомыми элементами – согласованность. Использование двух и более master-устройств в датчиках присутствия может привести к рассогласованности или неправильной работе системы.

В схеме Master&Slave ведущее устройство – «капитан на корабле». Конечные действия принимает только он, ведомые лишь посылают импульс главному датчику по специальному каналу.

Схема подключения Master&Slave датчиков присутствия

В датчиках компании B.E.G. для подключения Slave устройств к датчику Master используется разъем R. Ниже представлена схема подключения ведущего и ведомого устройства.

master&slave

Нужно иметь в виду, что схемы подключения бывают разные в зависимости от модели. К одному master-устройству можно подключить до десяти slave-датчиков, длина линии не должна при этом превышать ста метров.

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

Например, master управляет группой светильников и измеряет освещенность, ведомое же устройство регистрирует движение и присутствие в своей зоне не доступном датчику мастер. Slave-датчики не имеют реле, сенсоров освещенности и программируемых функций, они могут только подавать импульс раз в две или раз в девять секунд.

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

Так как реле и сенсором освещенности оснащен только датчик master, важно правильное его расположение в связке master&slave – master устанавливается подальше от окон, где меньше всего естественного освещения, а ближе к окнам ставится датчик slave.

4

beg-russia.ru

dev.1c-bitrix.ru

You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.