none
Проконсультируйте пжл.Зоны DNS RRS feed

  • Вопрос

  • Приветствую!

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

    Единственный возможный плюс зон-заглушки это то, что они интегрированы в АД и реплицируются.

    20 июля 2016 г. 14:26

Ответы

  • Преимущество stub-зоны по сравнению с conditional forwarding - не только в том, что sub-зона может быть AD-integrated, но и в том, что в ней автоматически поддерживается актуальный список DNS-серверов, авторитативных для этой зоны. Однако если вы находитесь в условиях, что для разрешения имен сторонней зоны с вашего DNS открыт сетевой доступ лишь на строго определенные DNS-сервера, используйте conditional forwarding. Secondary zone имеет преимущество в том, что все ее записи доступны локально на вашем DNS-сервере. Однако это возможно, только если сторонний DNS-сервер разрешает передачу зоны на ваш DNS. Для stub-зоны такого требования нет. Иными словами, предпочтение того или иного метода лежит в области безопасности.

    Также посмотрите две статьи как раз по вашему вопросу:

    http://www.dell.com/support/article/us/en/19/SLN156306/EN

    http://blogs.msmvps.com/acefekay/2012/09/18/what-should-i-use-a-stub-conditional-forwader-forwarder-or-secondary-zone/


    20 июля 2016 г. 21:49
    Модератор
  • Согласен с тем, как вы описываете. Не нашел информации, документированы ли stub-зоны в RFC, отличие может быть в этом. Последние версии BIND поддерживают stub-зоны.
    26 июля 2016 г. 14:11
    Модератор

Все ответы

  • Общее представление о типах зон

    Дополнительная зона
    Если зона, хранящаяся на DNS-сервере, является дополнительной, DNS-сервер становится дополнительным источником сведений о зоне. Зона на этом сервере должна быть получена от другого удаленного компьютера DNS-сервера, который также хранит зону. Этот DNS-сервер должен иметь сетевой доступ к удаленному DNS-серверу, который будет обеспечивать этот сервер обновленными данными о зоне. Так как дополнительная зона является копией основной зоной, хранящейся на другом сервере, она не может быть размещена в доменных службах Active Directory.

    По-английски данная зона называется Secondary, что переводится как "вторичная". Это просто ещё одна копия с DNS сервера, на котором эта зона была создана в первый раз - Primary=Первичная=Основная.

    В некоторый случаях Primary может обозначаться как Master, Secondary и все остальные как Slave зоны\ДНС сервера.


    20 июля 2016 г. 14:44
    Модератор
  • Зона-заглушка получается урезанная Secondary, содержащая ток адреса днс-серверов.

    Например: имеется домен west.lan и домен work.local. В домене west.lan мы можем поднять дополнительную зону от work.local, где будут содержаться все записи или можем поднять зону-заглушку, где будут ток указаны записи днс серверов.Так же можно в данном случае настроить условную пересылку. Вот и возникает вопрос по какому сценарию действовать.

    20 июля 2016 г. 18:17
  • я бы сделал или Secondary или Условную пересылку.

    Вам вообще для чего это? какая задача поставлена?

    20 июля 2016 г. 18:26
    Модератор
  • Задач нет J

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

    Почему зону-заглушку в данном случае не стали бы делать?

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


    • Изменено WinsArt 20 июля 2016 г. 19:27 доп
    20 июля 2016 г. 19:15
  • Преимущество stub-зоны по сравнению с conditional forwarding - не только в том, что sub-зона может быть AD-integrated, но и в том, что в ней автоматически поддерживается актуальный список DNS-серверов, авторитативных для этой зоны. Однако если вы находитесь в условиях, что для разрешения имен сторонней зоны с вашего DNS открыт сетевой доступ лишь на строго определенные DNS-сервера, используйте conditional forwarding. Secondary zone имеет преимущество в том, что все ее записи доступны локально на вашем DNS-сервере. Однако это возможно, только если сторонний DNS-сервер разрешает передачу зоны на ваш DNS. Для stub-зоны такого требования нет. Иными словами, предпочтение того или иного метода лежит в области безопасности.

    Также посмотрите две статьи как раз по вашему вопросу:

    http://www.dell.com/support/article/us/en/19/SLN156306/EN

    http://blogs.msmvps.com/acefekay/2012/09/18/what-should-i-use-a-stub-conditional-forwader-forwarder-or-secondary-zone/


    20 июля 2016 г. 21:49
    Модератор
  • Если не трудно, что можете еще сказать про делегирование зоны. По функционалу очень схожа с stub-зоной, только stub-зона может делаться для любого домена, а делегирование из родительской и думаю, что это минус перед sub-зоной.
    Допустим на нашем сервере используется stub-зона и сетевой доступ открыт лишь на строго определенного DNS-сервера, по какому принципу клиент выбирает нужную для себя ns запись? Допустим клиенту выдается 5 адресов, из которых 3 закрыты фаерволом, он выберет для себя самый коротки путь к ns серверу или рандомно выбирает адрес и если попадает на закрытый, то получает инфу, что сервер недоступен и нужное вам имя разрешить не удалось.
    Если для stub-зоны есть какая-то логистика по выбору ns сервера, то зачем нужно делегирование, если есть sub-зона, зачем нужна stub-зона если есть условная пересылка, зачем столько зон схожих по функционалу. Возможно, такое мнение, потому что в голове рассматриваются примеры местечкового характера, а не глобальные схемы на 10ки тысяч клиентов.
    Stub-зона использует итерационный метод, зона пересылки рекурсию. Для обычной клиентской машины лучше чтобы запросы отправлялись с использованием рекурсии, итерации или без разницы?
    24 июля 2016 г. 20:32
  • Благодаря записям делегирования обеспечивается иерархическая структура доменных имен. Последовательно проходя по записям делегирования, ваш DNS-сервер успешно разрешит FQDN-имя, включающее множество поддоменов, даже если зоны поддоменов располагаются на разных  DNS-серверах. Записи делегирования - это ключевой элемент пространства имен DNS. Stub-зоны данной функциональностью не обладают, но это не их недостаток, у них просто другое назначение.

    25 июля 2016 г. 7:58
    Модератор
  • Благодаря записям делегирования обеспечивается иерархическая структура доменных имен. Последовательно проходя по записям делегирования, ваш DNS-сервер успешно разрешит FQDN-имя, включающее множество поддоменов, даже если зоны поддоменов располагаются на разных  DNS-серверах. Записи делегирования - это ключевой элемент пространства имен DNS. Stub-зоны данной функциональностью не обладают, но это не их недостаток, у них просто другое назначение.

    Извините, конечно за занудство и не понимание, но почему stub-зоны не обладают такой же функциональностью как делегирование?
    Вот пример использования зоны-заглушки с https://msdn.microsoft.com/ru-ru/library/cc779197%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
    Сценарий использования зоны-заглушки:
    Удостоверяющий DNS-сервер для родительской зоны example.com делегировал поддомен widgets.example.com другим DNS-серверам. Вначале при делегировании домена widgets.example.com родительская зона содержала только две записи ресурсов имен (NS) удостоверяющих DNS-серверов для зоны widgets.example.com. Позднее администраторы дочерней зоны осуществили настройку дополнительных DNS-серверов в качестве удостоверяющих серверов для зоны, но не уведомили об этом администраторов DNS-сервера, на котором размещается родительская зона example.com. В результате у DNS-сервера родительской зоны example.com нет сведений о новых удостоверяющих DNS-серверах для дочерней зоны widgets.example.com и он продолжает отправлять запросы только на два удостоверяющих DNS-сервера, сведения о которых у него имеются.
    Это можно исправить, настроив на удостоверяющем DNS-сервере для родительской зоны example.com зону-заглушку для делегированного домена widgets.example.com. Когда администратор удостоверяющего DNS-сервера example.com обновляет зону-заглушку, он отправляет на главные серверы зоны-заглушки запрос получения записей ресурсов удостоверяющих DNS-серверов для зоны widgets.example.com. В результате удостоверяющий DNS-сервер для родительской зоны получает данные о новых удостоверяющих DNS-серверах для дочерней зоны widgets.example.com и сможет выполнить рекурсию на все удостоверяющие DNS-серверы для дочерней зоны.

    Здесь так же получается  иерархическая структура, только в делегировании указаны те записи ns серверов, которые мы сами укажем, а в stub-зоне будут указаны все ns записи серверов.
    Прочитал в нескольких книгах главы про DNS, везде отдается плюс stub-зоне, и поэтому осталось недопонимание.

    26 июля 2016 г. 6:53
  • Согласен с тем, как вы описываете. Не нашел информации, документированы ли stub-зоны в RFC, отличие может быть в этом. Последние версии BIND поддерживают stub-зоны.
    26 июля 2016 г. 14:11
    Модератор