Dns master что это
Услуга DNS-master от RU-CENTER
RU-CENTER, хостинг-провайдер и крупнейший российский регистратор доменных имен, запустил новую услугу DNS-master, с которой редактирование и размещение зон доменов станет проще.
Услуга DNS-master предполагает:
Кроме того, с 31 января изменились условия предоставления услуг Primary-Standard и Secondary. Так, Primary-Standard будет заменена услугой DNS-master по тарифу Primary-Standard, в рамках которого для поддержки доменов предоставляется один первичный и два вторичных DNS-сервера. Услуга DNS-master по тарифу Primary-Standard будет доступна только для продления.
Услугу Secondary можно будет заказать для большого количества доменов, выбрав один из пяти тарифов (S, M, L, XL, XXL). Услуга Secondary, подключенная до 31 января, будет предоставляться по тарифу S (по желанию его можно будет изменить).
Для корректного функционирования услуг DNS-master и Secondary необходимо переделегировать домены на новые DNS-серверы. Домены, зарегистрированные в RU-CENTER и делегированные с использованием услуг Primary-Standard и Secondary, будут перенесены на новые серверы автоматически.
Другие статьи из раздела
Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.
NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …
компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …
МФУ Panasonic DP-MB545RU с возможностью печати в формате А3
Хотите повысить эффективность работы в офисе? Вам поможет новое МФУ #Panasonic DP-MB545RU. Устройство осуществляет
Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …
Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …
DNS-хостинг
Удобный сервис для редактирования содержания зоны, настройки DNS и управления доменами.
Рекомендуем
Рекомендуем
Качество DNS-серверов не менее важно, чем качество хостинга
Производительность и скорость сайта зависят не только от хостинга и скорости соединения. DNS-сервер должен отвечать в момент, когда браузер пользователя отправляет к нему запрос для определения IP-адреса сайта. В противном случае ресурс будет недоступен, несмотря на стабильную работу хостинга.
Скорость
Технология Anycast
Один и тот же IP-адрес назначается нескольким серверам, уменьшая время ответа.
Развитая инфраструктура серверов
Узлы расположены в 12 городах по всему миру.
Балансировка трафика
На DNS-запросы отвечают одновременно десятки серверов, в случае выхода из строя одного из них, остальные продолжат работу.
Отказоустойчивость
Защита от DDoS
Бесперебойная работа за счет большого количества серверов даже при пиковых нагрузках, в частности, при DDoS-атаках.
Надёжное оборудование
Регулярно обновляемое оборудование от проверенных производителей.
Особенности сервиса
БЫСТРЫЙ СТАРТ
Автоматическая загрузка существующего файла зоны при добавлении домена на DNS-хостинг.
ОНЛАЙН-РЕДАКТОР DNS-ЗОНЫ
Управление ресурсными записями в современном и удобном редакторе.
ИМЕНОВАННЫЕ DNS-СЕРВЕРЫ
Возможность указать DNS-серверы, одноименные вашему домену, для поддержки бренда.
ДИНАМИЧЕСКИЙ DNS
Настройка обращения по доменному имени к сетевому устройству с внешним динамически меняющимся IP-адресом.
ПРЯМЫЕ И ОБРАТНЫЕ ЗОНЫ
Поддержка прямых и обратных доменов в любых доменах верхнего уровня.
Возможность создания собственных приложений.
Настройки
Для работы DNS-хостинга необходимо делегировать домен — указать DNS-серверы RU-CENTER в настройках домена.
Часто задаваемые вопросы
Что такое DNS?
Компьютеры в интернете не имеют имен, данные передаются с использованием сложных для запоминания IP-адресов (числовые адреса вида 123.123.123.123). Упростить работу с сайтами призвана система DNS (Domain Name System). Она преобразует доменное имя, которое вводит пользователь в браузере, в IP-адрес для доступа к серверу.
Что такое DNS-сервер?
DNS-сервер — это сервер, на котором запущенно специальное программное обеспечение. Изначально назначение этого программно-аппаратного комплекса было хранение таблицы DNS-записей вида: «имя домена» — «IP-адрес», так называемых записей типа «А», например:
Домен IP-адрес сервера
nic.ru 115.115.115.115
Сейчас В системе DNS содержатся и другие ресурсные DNS-записи: «MX», «TXT», «CNAME» и др. Они необходимы для работы домена как адреса сайта, почты и многих других сервисов.
Что такое «Ресурсные записи DNS»?
Ресурсные записи (DNS-записи домена) — это записи в системе доменных имен о соответствии имени и служебной информации о сервере, на которое это имя должно указывать. Каждая ресурсная запись необходима для работы определённой службы. Например, в ресурсную запись типа MX вносятся данные для корректной работы электронной почты на домене.
Зачем прописывать DNS-серверы для домена?
Без размещения информации о домене на DNS-серверах работа сайта или почты на нем невозможна. Для гарантии отказоустойчивости DNS-серверы прописываются парами — выход из строя одного сервера не скажется на доступности сайта.
Для чего нужен динамический DNS?
Динамический DNS — технология, которая позволяет назначать постоянное имя устройству с изменяющимся IP-адресом, обеспечивая доступ по доменному имени к сетевым устройствам — компьютерам, роутерам, веб-камерам и т.д.
Динамический DNS поддерживается на всех тарифах услуги DNS-хостинг.
Как настроить динамический DNS?
Для работы динамичеcкого DNS необходимо настроить сетевое оборудование через панель администратора. Для настройки потребуются:
Подробные инструкции по работе с панелью администратора можно найти на сайте производителя оборудования.
Динамический DNS
Если у вас еще нет домена
Для того чтобы зарегистрировать домен, вам сначала необходимо создать аккаунт на сайте RU-CENTER. Для этого нажмите ссылку «Стать клиентом» в правом верхнем углу сайта. 
Далее необходимо выбрать тип анкеты (для физического или юридического лица), а также согласиться с условиями предоставления услуг. 
Затем нажать кнопку «Заполнить анкету». В открывшейся анкете необходимо заполнить все поля, отмеченные *. Вводимые данные должны соответствовать действительности. После ввода требуемой информации нажмите кнопку «Отправить анкету». 
После того как вы зарегистрировались на сайте RU-CENTER, вы можете начать регистрацию домена. Для этого на сайте RU-CENTER введите имя домена, который вы хотели бы зарегистрировать, и нажмите кнопку «Проверить». 
Система даст вам информацию о том, свободен ли данный домен.
Если домен свободен, вы можете начать процедуру регистрации, нажав кнопку «Зарегистрировать». 
В процессе регистрации домена вам необходимо сразу добавить услугу «DNS-master», которая позволяет использовать динамический DNS. 
Вам необходимо придумать уникальный идентификатор (имя) для этой услуги, которое будет отображаться в вашем личном кабинете, и нажать кнопку «Продолжить». 
На следующей странице вам необходимо проверить правильность заказа.
Если все данные верны, нажмите кнопку «Отправить заказ». 
После этого ваш заказ будет принят в обработку. Если на вашем счете достаточно денег для оплаты заказа, то он начнет выполняться сразу после отправки заявки. Если на вашем счете недостаточно средств для оплаты заказа, то вам необходимо пополнить счет, после чего ваш заказ будет исполнен.
Получение данных для динамического DNS
Для работы динамического DNS необходимо получить специальные логин и пароль.
Для этого вам нужно перейти в раздел «Для клиентов» → «DNS-хостинг» → «Динамический DNS» на сайте www.nic.ru и нажать кнопку «Получить». 
После этого для вас будут сгенерированы логин и пароль, которые необходимы для настройки динамического DNS. Эти данные будут продублированы письмом на электронный адрес вашего аккаунта. 
Внимание! При повторном запросе ранее выданные логин и пароль становятся недействительными. Необходимо перенастроить динамический DNS на сетевом устройстве с новыми полученными данными.
Добавление ресурсной записи
Вам нужно добавить зарегистрированный домен в список управляемых доменов услуги DNS-master.
Для этого в интерфейсе выберите идентификатор, который вы ввели при заказе услуги DNS-master. 
Затем нажмите кнопку «Добавить домен». 
В появившемся окне введите имя вашего домена и нажмите кнопку «Добавить». 
При успешном добавлении домена появится следующее сообщение: 
После того как вы добавили домен, выберите его в списке.
Далее нажмите кнопку «Добавить новую запись». 
После этого заполните поля формы: 
Затем нужно нажать кнопку «Добавить», далее — «Выгрузить зону»: 
Внимание! Если при выборе домена вы видите такое сообщение: 
это означает, что делегирование домена на серверы RU-CENTER еще не завершилось. Обычно делегирование происходит в течение суток.
Вам необходимо настроить ваше оборудование через имеющуюся панель администратора с использованием полученных данных:
Подробную инструкцию по работе с панелью администратора вы можете найти на сайте производителя вашего оборудования.
Если у вас уже есть домен
Если у вас уже имеется ранее зарегистрированный домен, вы можете использовать его для настройки динамического DNS.
Заказ услуги DNS-master
Для работы динамического DNS необходимо подключить услугу DNS-master. Для этого перейдите по ссылке, выберите понравившийся вам тариф и придумайте уникальный идентификатор (имя) для заказываемой услуги, которое будет отображаться в вашем личном кабинете.
Работа динамического DNS поддерживается каждым из доступных тарифов. Различия заключаются в доступном количестве добавляемых доменов и ресурсных записей.
Если вы будете использовать динамический DNS в рамках 1 домена, а количество ресурсных записей не будет превышать 75, вам подойдет тариф S.
Получение данных для динамического DNS
Для работы динамического DNS вам необходимо получить специальные логин и пароль. Для этого вам нужно перейти в раздел «Для клиентов» → «DNS-хостинг» → «Динамический DNS» на сайте www.nic.ru и нажать кнопку «Получить».
После этого для вас будут сгенерированы логин и пароль, которые необходимы для настройки динамического DNS. Эти данные будут продублированы письмом на электронный адрес вашего аккаунта. 
Внимание! При повторном запросе ранее выданные логин и пароль становятся недействительными. Необходимо перенастроить динамический DNS на сетевом устройстве с новыми полученными данными.
Делегирование домена на серверы RU-CENTER
Если ваш домен не используется для доступа к сайтам и другим ресурсам
Если ваш домен до этого не использовался для доступа к сайтам и другим ресурсам, вам необходимо делегировать его на серверы RU-CENTER.
Чтобы делегировать домен, вам необходимо зайти в панель вашего регистратора, найти раздел, в котором можно управлять DNS-серверами домена, и указать там следующие DNS-серверы.
Для того чтобы узнать, кто является регистратором вашего домена, воспользуйтесь сервисом WHOIS: 
В данном случае регистратором является RU-CENTER. Инструкция по делегированию доменов, зарегистрированных в RU-CENTER.
Внимание! При делегировании домена происходит процесс перезаписи старых данных в реестре доменной зоны, в которой зарегистрирован домен. Этот процесс может занимать до суток.
Если ваш домен используется для доступа к сайтам и другим ресурсам
Внимание! В этом случае вы должны быть точно уверены в том, что вы делаете. В случае ваших неверных действий все ресурсы и сайты, каким-либо образом использующие этот домен, могут оказаться неработоспособными!
В панели вашего хостинг-провайдера создайте поддомен вашего домена. Далее вам нужно делегировать созданный поддомен на серверы RU-CENTER. Для этого в панели вашего хостинг-провайдера найдите раздел, в котором происходит управление DNS-записями, и добавьте NS-записи для созданного поддомена, указав в них следующиеDNS-серверы.
Добавление ресурсной записи
Вам нужно добавить зарегистрированный домен в список управляемых доменов услуги DNS-master.
Для этого в интерфейсе выберите идентификатор, который вы ввели при заказе услуги DNS-master. 
Затем нажмите кнопку «Добавить домен». 
В появившемся окне введите полный адрес поддомена, который вы создали в панели вашего регистратора, и нажмите кнопку «Добавить». 
При успешном добавлении домена появится следующее сообщение: 
После того как вы добавили доменeн, выберите его в списке.
Далее нажмите кнопку «Добавить новую запись».
После этого заполните поля формы: 
Затем нужно нажать кнопку «Добавить», после чего кнопку «Выгрузить зону».
Внимание! Если при выборе домена вы видите такое сообщение:
это означает, что делегирование домена на серверы RU-CENTER еще не завершилось. Вам нужно подождать завершения делегирования, которое может длиться до суток, либо проверить правильность указанных вами DNS-серверов при делегировании.
Вам необходимо настроить ваше оборудование через имеющуюся панель администратора с использованием полученных данных:
Подробную инструкцию по работе с панелью администратора вы можете найти на сайте производителя вашего оборудования.
Dns master что это
В данном материале разбирается типизация 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-сервер.
Существует оговоренная практика резервирования серверов, которая описана в рекомендациях по ведению зон. Она заключается в том, что для домена второго уровня необходимо иметь как минимум два сервера, ответственных за зону, т.е. дающих авторитативные отклики на запросы. Один 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
>
> 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 следующий:
На рисунке пояснется работы приведенной выше схемы:
Рис.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-сервером состоянии.
При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т.к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.
При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.
Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.
В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о «невидимых» серверах (stealth, см. RFC-1996). Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т.к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.
Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.
Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall. В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с «невидимого» Primary master:
Рис.4. Схема организации DNS-серверов с невидимым primary master сервером
Серверы данного вида используют для организации централизованного кеширования соответствий доменных имен и 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» в отклике мы бы не увидели.
Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:
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 серверов, содержатся общие слова о том, как не допустить такого развития событий, но там нет конкретного плана действий.
Средние цифры таковы:
Исходящий трафик: 600 Kbps
Входящий трафик: 2.2 Kbps
Число пакетов за сутки: 26M
Распределение запросов по типам:
Поиск IP-адреса(A) 77%
Поиск сервера доменных имен (NS) 15%
Поиск почтового шлюза(MX) 5%
Статистика обслуживания запросов, которая названа ужасающей(Scary statistics):
— Только 26% правильных(valid) запросов к корневой зоне.
— 66% запросов к несуществующим доменам верхнего уровня (non existent TLDs)
По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствие негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду.
Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности приреализации протоколов.
К слову сказать, в 2002 году на встрече IEGP также обсуждались проблемы DNS, а точнее масштаб ошибок при делегировании и описании зон.