Сколько dns серверов одновременно могут быть в одном сегменте сети
Корневые DNS-серверы переводят URL-адреса в IP-адреса. Эти корневые серверы представляют собой сеть из сотен серверов в разных странах мира. Однако вместе они определены как 13 именованных серверов в корневой зоне DNS.
Сколько существует DNS-серверов?
Есть несколько причин, по которым система доменных имен в Интернете использует ровно 13 DNS-серверов в корне своей иерархии: число 13 было выбрано в качестве компромисса между надежностью и производительностью сети, а 13 основано на ограничении интернет-протокола (IP). версия 4 (IPv4).
Хотя для IPv4 существует только 13 назначенных имен корневых серверов DNS, на самом деле каждое из этих имен представляет собой не один компьютер, а скорее кластер серверов, состоящий из множества компьютеров. Такое использование кластеризации повышает надежность DNS без какого-либо негативного влияния на его производительность.
Поскольку новый стандарт IP версии 6 не имеет таких низких ограничений на размер отдельных дейтаграмм, мы можем ожидать, что в будущем DNS будет содержать больше корневых серверов для поддержки IPv6.
DNS IP пакеты
В широко распространенном сегодня использовании IPv4 данные DNS, которые могут поместиться в одном пакете, составляют всего 512 байт после вычитания всего другого протокола, поддерживающего информацию, содержащуюся в пакетах. Каждый IPv4-адрес требует 32 байта. Соответственно, разработчики DNS выбрали 13 в качестве числа корневых серверов для IPv4, взяв 416 байтов пакета и оставив до 96 байтов для других вспомогательных данных, а также возможность добавления еще нескольких корневых серверов DNS в будущем при необходимости.
Практическое использование DNS
Корневые DNS-серверы не так важны для обычного пользователя компьютера. Число 13 также не ограничивает DNS-серверы, которые вы можете использовать для своих устройств. На самом деле, существует множество общедоступных DNS-серверов, которые каждый может использовать для изменения DNS-серверов, используемых любым из их устройств.
Например, вы можете заставить свой планшет использовать DNS-сервер Cloudflare, чтобы ваши интернет-запросы проходили через этот DNS-сервер, а не другой, как у Google. Это может быть полезно, если сервер Google не работает или вы обнаружите, что вы можете просматривать веб-страницы быстрее, используя DNS-сервер Cloudflare.
Как видим, причин иметь свои NS-сервера достаточно. Обычно для решения этих задач хостеры настраивают пару серверов имен в режиме master-slave. При этом на обоих серверах создаются доменые зоны, но управление ресурсными записями доменных зон происходит только на мастере. А вторичный (slave) сервер имен загружает изменения автоматически с мастера. Таким образом, у вас всегда активны два сервера имен с идентичным набором доменных зон и с идентичным набором ресурсных записей.
Единственная неприятная мелочь — создавать/удалять зону нужно на обоих серверах. Автоматически этого не происходит. Поэтому создаем доменную зону на мастере. Затем создаем доменную зону на slave, указав адрес master-сервера. Все, теперь, добавляя доменные ресурсные записи на мастере, мы можем быть уверенными, что slave автоматически заберет их оттуда.
Как мы это реализовали?
Интеграция Parallels Plesk Panel и slave DNS много лет была не очень тривиальной задачей. Подразумевается, что Plesk-сервер выполняет роль мастера. В Plesk реализованы режимы slave/master для доменной зоны, существует глобальный список IP-адресов, которым можно делать запрос на получение доменных зон. Но механизма создания новых доменных зон на slave-сервере нет. И не будет. Потому, что концепция Plesk — это панель автоматизации хостинговых операций в рамках одного сервера. Если вам нужна интеграция нескольких серверов, разделение по типам сервисов – то у Parallels есть другие продукты: Parallels Plesk Automation, Parallels Operation Automation, и, в конце концов, большое комплексное решение Parallels Automation.
«Ну и в чем проблема?» — спросите вы. А дело в том, что существует ряд пользователей Plesk, которым перечисленные выше продукты не требуются, они overqualified для решения их конкретных задач. А нужна им только интеграция с slave-сервером имен.
Чтобы решить эту проблему, в свое время каждый администратор Plesk писал свои собственные программные решения. Или покупал коммерческие. Или вручную выполнял операцию создания/удаления доменных зон на slave-сервере.
Казалось бы, что сложного? У Plesk есть локальный NS-сервер, пусть будет мастером, есть система событий, давайте повесим выполнение нашего скрипта на события «создание DNS-зоны» и «удаление DNS зоны». Все будут счастливы. К сожалению, именно таких событий в Plesk нет.
Как это работает?
У Plesk в качестве локального NS-сервера используется BIND. У него есть возможность удаленного управления с помощью штатной утилиты rndc. Никто нам не мешает на удаленном сервере поставить BIND и управлять им через rndc. В Plesk 11.5 появился механизм «Custom DNS backend». Через него можно подключить сторонний DNS-сервис, например AWS Route53. Почитать об этом подробнее можно в документации.
В двух словах смысл этой функциональности можно описать как возможность зарегистрировать в Plesk скрипт, который будет получать JSON описание DNS-зоны, что нужно сделать с зоной, при каждом создании/обновлении/удалении любой активной зоны в Plesk. Это все, что нам нужно. При реализации этой функциональности подразумевалось, что вы не будете ставить локальный BIND с Plesk, а будете использовать внешний сервис. Но! Удалять локальный BIND совсем не обязательно. Скрипт может работать параллельно с локальным DNS-сервисом. Вот эту идею наше расширение и использует.
Здравствуйте, возникла проблема. решения которой пока не знаю.Есть 2 сети, с собственными DNS серверами, с собственными прокси-серверами, через которые поступает интернет трафик.
Как мне разграничить использование DNS серверов?
Одна сеть производственная, DNS сервер требуется для работы с 1С, Гарант и удаленным офисом через шлюз, и через производственный прокси сервер - доступ в интернет.
Вторая сеть дружественного подразделения никоем образом не влияет на управленческие задачи. Она нужна для обеспечения дополнительного канала доступа в интернет, через собственный прокси-сервер и собственный DNS сервер.
Как увязать работу двух сетей на одном компьютере? ОС Windows XP. Чтобы DNS запрос на расшифровку сервера с 1С шел через первый DNS. А интернет адреса, через второй? Также желательно наличие 2 браузеров с различными настройками. Последнее вроде не проблема, хотя. я использовал IE и Opera. (Вопрос в том, насколько сильно IE "прикручен" к ОС)
-------
- Я не разрешаю тебе быть плохой! Потому что плохие люди совершают плохие поступки. А это нехорошо!
(Из наставлений 5 летней девочки своей младшей сестре)
| Конфигурация компьютера | |
| Процессор: I7 10700 | |
| Материнская плата: Asus h470-plus | |
| Память: Hyper 32 GB | |
| HDD: Crucial ct1000 | |
| Видеокарта: Gigabyte GeForce rtx 260 | |
| Блок питания: Thermaltake smart 650 w | |
| Монитор: Samsung U32J592UQU | |
| Ноутбук/нетбук: Lenovo T420s | |
| ОС: W10 x64 |
| Чтобы DNS запрос на расшифровку сервера с 1С шел через первый DNS. » |
но я не уверен, что так можно.
-------
Вежливый клиент всегда прав!
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
| Конфигурация компьютера | |
| Процессор: Intel Core i5 (660) | |
| Материнская плата: Gigabyte GA-P55-UD3L | |
| Память: 4 GBt | |
| HDD: WD3000HLHX + WD7500AARS | |
| Видеокарта: GT-220 | |
| Звук: Realtek | |
| CD/DVD: Pioneer DVD-RW DVR-219L | |
| Монитор: VieSonic VA2014w | |
| ОС: Win 7 Pro | |
| Индекс производительности Windows: 5.1 |
| Также желательно наличие 2 браузеров с различными настройками. » |
При настройке прокси-серверов надо указывать тот ДНС, который должен резолвить адреса для него.
Если указать браузеру, что он ходит через прокси, то настройка ДНС в свойствах сети для web-серфинга не работает, прокси использует свой, тот, который прописан в его конфиге.
ps. Если ДНС видят друг друга, можно организовать трансфер зон.
-------
Когда у тебя есть только молоток, все похоже на гвоздь
| можно настроить резолв первого ДНС только локальной сети » |
Может есть какой либо Firewall позволяющий перенаправлять запросы на различные DNS? Т.к. список имен персоналок и сервер более-менее стандартизован. Если правила будут записываться в простенький текстовый файл, то с обновлением правил проблем не в встанет.
| При настройке прокси-серверов надо указывать тот ДНС, который должен резолвить адреса для него. Если указать браузеру, что он ходит через прокси, то настройка ДНС в свойствах сети для web-серфинга не работает, прокси использует свой, тот, который прописан в его конфиге. » |
Если это так, то это просто здорово!
| ps. Если ДНС видят друг друга, можно организовать трансфер зон. » |
Это скажем такой BlackDoor для себя.
-------
- Я не разрешаю тебе быть плохой! Потому что плохие люди совершают плохие поступки. А это нехорошо!
(Из наставлений 5 летней девочки своей младшей сестре)
Последний раз редактировалось lxa85, 25-05-2009 в 17:52 . Причина: добавил ответ для gf100
Я в принципе понимаю, как работает DNS. Вот пример, который помогает проиллюстрировать то, что мне трудно понять.
Прямо сейчас я запускаю небольшой веб-сервер. Я использую диспетчер DNS своего провайдера, поэтому у меня нет DNS-сервера, размещенного на машине.
Скажем на секунду, что я не использую DNS своего хоста, и я решил настроить DNS-сервер на моем сервере. Гипотетический сценарий: мой сервер (весь) сервер отключается - DNS включен. Зачем мне нужен резервный DNS? Если сервер не работает, кому нужно, если DNS-сервер тоже не работает, учитывая, что даже если бы у меня был DNS (он не был на сбойном сервере), он все равно не смог бы пересылать запросы, так как сервер будет вниз?
Надеюсь, кто-нибудь увидит, на чем я помешан, и даст некоторые рекомендации.
Основной момент наличия вторичного DNS-сервера - это резервное копирование на случай, если основной DNS-сервер, обрабатывающий ваш домен, выходит из строя. В этом случае ваш сервер все еще будет в рабочем состоянии, и поэтому без резервной копии никто не сможет добраться до вашего сервера, что может стоить вам много потерянных клиентов (то есть РЕАЛЬНЫЕ ДЕНЬГИ).
Вторичный DNS-сервер всегда включен и готов к работе. Это может помочь сбалансировать нагрузку на сеть, так как теперь есть несколько официальных мест для получения вашей информации. Обновления обычно выполняются автоматически с главного DNS. Таким образом, это точный клон мастера.
Как правило, DNS-сервер содержит больше информации, чем просто один сервер, он может содержать информацию о маршрутизации почты, информацию о многих хостах, ключи почтового спама и т. Д. Таким образом, устойчивость и избыточность имеют определенную выгоду для владельцев доменов.
Я надеюсь, что это поможет вашему пониманию.
Есть ли смысл иметь вторичный DNS
Только очень маленькие организации могут делать все на одном сервере. У меня много серверов, и я хочу, чтобы моя электронная почта продолжала работать, даже если веб-сервер не работает. У меня есть сервисы, размещенные во внешних сетях, которые я хочу поддерживать, даже если моя интернет-связь не работает.
Работает ли резервная система DNS в основном все время?
Это зависит от программного обеспечения DNS-сервера, но обычно от «резервного сервера» вы настраиваете его как вторичный. Затем вы указываете IP-адрес главного сервера и зоны, которые хотите реплицировать.
Чтобы процитировать важные вещи со страницы 4:
DNS требует, чтобы все зоны были избыточно поддержаны более чем одним сервером имен. Назначенные вторичные серверы могут получать зоны и проверять наличие обновлений с первичного сервера, используя протокол передачи зон DNS.
Резервные DNS-серверы (один или несколько) будут рабами вашего основного DNS-сервера. Изменения первичного DNS-сервера будут приниматься ведомыми. Это может быть сделано на периодической основе или в ответ на уведомление от основного сервера. Это одна из причин задержки распознавания изменений в DNS через Интернет. Ваш основной и резервный серверы имен будут перечислены в качестве серверов имен для вашего домена.
До уведомления DNS подчиненные серверы имен будут иметь предыдущую версию данных DNS в течение некоторого периода времени. (Это одно из назначений серийного номера.) Как только все серверы имен обновятся до одной и той же версии (с одинаковым серийным номером), все они должны иметь одинаковые данные. Редактирование файла зоны без увеличения серийного номера может привести к несогласованности данных.
Нет переключения на резервный DNS-сервер (ы). DNS-запросы распределяются по всем вашим серверам имен относительно равномерно. (Это делается с помощью запросов к серверам по циклическому графику.) Если один или несколько серверов имен не работают, запросы будут повторены на другом сервере имен после истечения времени ожидания. Пока работает один из ваших серверов имен, ваш домен будет разрешаться (время от времени). Вы хотите, чтобы все ваши серверы имен были всегда активны.
В вашем случае вы можете обнаружить, что проще использовать своего интернет-провайдера или регистратора домена для размещения своего домена. У них будет один или несколько резервных серверов имен, а также ресурсы, выделенные для их работы.
Если все, что вы запускаете - это веб-сервер, вторичный DNS может показаться не столь важным. Тем не менее, когда ваш сервер не работает, существует несколько причин, по которым вам может потребоваться резервный DNS-сервер, в том числе:
- чтобы позволить вам пинговать или трассировать маршрут до вашего хоста, чтобы убедиться, что он не работает.
- чтобы пользователи и сканеры не могли решить, что ваш домен больше не используется.
Вам не нужно переключаться на резервную копию, она автоматическая. Если запрос DNS на имя в вашем домене идет до того, как запрашивать (помните, что DNS сильно кэшируется) ваших серверов, то, если ваш основной сервер NS не отвечает, будет запрашиваться дополнительный сервер NS.
Если вы размещаете свой DNS вдали от сервера, на котором размещены предоставляемые вами услуги, разумно иметь 2. Если один из них выйдет из строя, другой начнет работать, и ваш домен все еще будет доступен.
Я прочитал довольно много комментариев, которые указывают, что многие реальные службы кэширования DNS (например, используемые провайдером) не пытаются повторно использовать второй сервер имен, они просто терпят неудачу, если первый сервер не отвечает. Например, этот ответ на serverfault . В этом случае, если у вас есть два отдельных сервера имен, вы должны убедиться, что оба работают, потому что любой из них может быть недоступен для размещенных доменов. Это идет вразрез с обычной практикой и RFC, но, похоже, касается.В дополнение к вышесказанному:
Помимо того, что RFC требует второго DNS-сервера, также полезно избегать негативного кэширования обратными преобразователями. Обычно кешируется тот факт, что запрос не соответствует ни одной записи (NXDOMAIN) / DNS-сервер не найден.
Поскольку некоторые интернет-провайдеры имеют необычные политики кэширования, лучше иметь второй DNS-сервер, который отвечает на эти запросы, даже если веб-сервер не работает. Таким образом, вы можете избежать последствий отрицательного кеширования, когда сервер снова запустится.
Примечание. В общем случае интервал отрицательного кэша составляет макс. Рекомендуется 5 минут (тем не менее, некоторые провайдеры получили действительно безумные значения)
Вы правы - вам не нужен сторонний вторичный сервер в вашей ситуации, и он предложит вам несколько улучшений при условии, что все ваши другие службы (включая почту) по-прежнему размещены в одном ящике в одном сеть.
Да, и основной, и дополнительный работают рядом друг с другом; оба должны иметь одинаковую информацию (но согласованность информации не гарантируется на практике); с точки зрения постороннего, нет никакой разницы между первичным и вторичным сервером, оба рассматриваются одинаково, как правило, только один используется для данного разрешения. Если один не работает, другой судят. Будет плохой идеей иметь один из серверов в Токио, если все ваши клиенты находятся в Нью-Йорке, потому что это увеличит задержку среднего разрешения (например, плохо), так как серверы довольно много случайно выбранных.
Спецификация DNS, по-видимому, требует, чтобы по крайней мере две записи NS были предоставлены для домена, поэтому вы можете столкнуться с некоторыми распознавателями, которые не могут разрешить имя, если вам каким-то образом удается настроить только одну запись NS для вашего домена.
Хороший обзор неправильных представлений о вторичной сторонней службе DNS предоставлен DJB, автором djbdns:
Давайте краткую цитату со страницы:
на самом деле, в большей части мира резервный DNS-сервер никогда не запрашивается, если основной не работает. потому что это дополнительный шаг для резольвера. он не хочет делать эту работу, и не будет.
поэтому резервное копирование нам бесполезно. если основной сервер не работает, запрос DNS пользователя не будет ничего возвращать (даже если имеется полностью исправный DNS-сервер, доступный и указанный в записи имени, и резервные серверы в ожидании). пользователь, чтобы получить сервер не найден.
Единственное неудобство в том, что вам приходится создавать и удалять каждую зону на обоих серверах, так как это автоматически не происходит. Вот почему вы создаёте доменную зону на master сервере и потом создаёте эту же доменную зону на slave сервере и указываете адрес master сервера. После того, как вы добавили ресурсные записи домена на master сервер, можете быть уверены, что slave сервер будет автоматически получать их от master сервера.
На протяжении многих лет интеграция Plesk и slave DNS сервера была непростой задачей. Подразумевается, что сервер Plesk должен быть master сервером. В Plesk есть режимы slave и master для доменной зоны и есть список ip адресов , которые отдаются доменной зоной . Но в плеск нет механизма создания новой доменной зоны на slave сервере. И этого механизма никогда не будет, потому что концепция плеск — это автоматизация хостинговых процедур на одном сервере. Для интеграции нескольких серверов разделённых для работы по видам сервисов, компания Parallels предлагает использовать продукты PPA (Parallels Plesk Automation) и PA (Parallels Automation).
На данный момент существует множество пользователей Plesk для которых решения PPA или РА превосходят их необходимые потребности для работы, так как им необходима только интеграция slave сервера. Ранее для решения этой проблемы каждый администратор Plesk должен был писать скрипты или приобретать коммерческие версии или вручную создавать и удалять доменные зоны на slave сервере.
Казалось бы, какие могут быть трудности. В Plesk есть собственный локальный сервер имён, который, предположим, будет master сервер. И есть система событий — давайте назначим исполнение нашего скрипта на события «создание DNS зоны» и «удаление DNS зоны» и проблема будет решена. Но, к сожалению, Plesk не поддерживает такие события.
КАК ЭТО РАБОТАЕТ
Plesk использует BIND как локальный сервер имён. Им можно управлять удалённо с помощью штатной утилиты rndc . Нет причин, по которым мы не можем установить BIND на удалённом сервере и управлять им с помощью rndc. В Plesk 12.5 реализован механизм “Custom DNS backend”, который может быть использован для подключения внешнего DNS сервиса, например AWS Route53.
Если вкратце, то этот способ позволяет зарегистрировать в Plesk скрипт, который будет получать описание DNS зоны в JSON формате с инструкциями для исполнения, такими как создание, изменение, удаление любой DNS зоны в Plesk. Это то, что нам нужно. Реализовывая этот функционал, Plesk подразумевали, что будет использоваться внешний DNS сервис вместо того, чтобы устанавливать BIND сервер в Plesk.
Также нет нужды удалять локальный сервер BIND . Этот скрипт может одновременно работать с локальной DNS службой. Такова идея использования данного расширения.
Это расширение работает по следующему алгоритму:
- Регистрируется slave сервер в своих настройках скрипта
- IP адрес slave сервер автоматически добавляется в список адресов разрешённых для трансфера доменных зон из сервера Plesk
- Когда вы создаёте, меняете или удаляете активную зону домена в Plesk , то эти действия происходят на локальном DNS сервере
- После этого скрипт запускается , получает доменное имя и выполняет соответствующую операцию
- Скрипт инициирует команду rndc для каждого подключённого slave сервера
- Slave серверы синхроинизируют доменные зоны с сервером Plesk.
Все настройки, такие как формат зоновых файлов, подключение и перезапуск служб управляются службой DNS. Администратор должен настроить slave сервер для работы с внешним сервером Plesk только один раз. После этого вы можете сообщить регистратору, что теперь Plesk сервер и slave сервер являются серверами имён для ваших доменов. Таким образом мы решили все вопросы обозначенные в начале статьи.
А ТЕПЕРЬ О ТЕХНИЧЕСКОЙ СТОРОНЕ - КАК РЕШИТЬ ЗАДАЧУ
Для установки slave сервера возьмём, к примеру, сервер с Centos 7
Установка BIND
В начале проверим что система имеет все последние обновления.
Если не указать "-y" ключ, то придется отвечать на все вопросы установщика, а с ним все ответы ставятся автоматически по умолчанию.
Установить bind и bind-utils
yum install bind bind-utils -y
Разрешим создание новых зон с помощью rndc. В файле /etc/named.conf, в фигурных скобках <>, напишите директиву:
Укажите ip адрес от которого должны быть приняты инструкции управления и установите BIND для прослушивания на всех доступных сетевых интерфейсах. Определите ключ rndc , который будет использоваться Plesk . В файле /etc/named.conf напишите:
Вот и всё, slave сервер установлен.
После этого установите расширение на сервере Plesk . В настройках расширения добавьте slave сервер, установите его ip адрес и ключ . Расширение создаст конфигурационный файл с настройками slave севрера для утилиты rndc.
Теперь Plesk будет автоматически передавать все созданные изменённые и удалённые зоны на slave сервер при выполнении следующей команды для каждого slave сервера:
Сейчас , когда вы добавили домен в Plesk, его ДНС зона автоматически создалась на slave сервер аналогично как на master сервере. Расширение (Slave DNS manager) доступно для загрузки здесь
Обращаем внимание, что Plesk не пр оводит техподдержку для для данного расширения . Это расширение лишь пример как можно решить техническую задачу.
Читайте также: