Частная DNS-зона, которая разрешает частные субдомены и перенаправляет их на публичный сервер имен для существующих публичных субдоменов.

У меня есть TLD с рядом открытых поддоменов, скажем, *.example.com, У меня также есть частный сервер, который используется в качестве хранилища SVN, который я хотел бы иметь на svn.example.com, но только в частной сети. В настоящее время я достиг этого, создав файл зоны svn.example.com.zone и используя это объявление:

zone "svn.example.com" IN {
    type master;
    file "/etc/named/svn.example.com.zone";
};

И в файле зоны:

@                IN  NS  svn.example.com.
svn.example.com. IN  A   10.200.1.1

Все остальные домены пересылаются на публичный сервер имен. Это работает, но не идеально, так как требует создания новой зоны, если я хочу добавить новый частный поддомен. Если я сделаю эту зону основной записью для всего example.com TLD, тогда я принимаю запросы к в настоящее время общественности *.example.com больше не будет работать для клиентов, использующих частный DNS (если они не дублируются в файле зоны частного DNS).

Есть ли способ предоставить мне файл зоны, в котором указан один или несколько частных субдоменов, но все же переадресовывать запросы, которые он не может разрешить, на публичный сервер имен? Я пытался использовать forward тип зоны, но тогда я не могу указать свой собственный файл зоны, он только пересылается.

Обновить

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

Источник

4 ответа

Решение

В конечном итоге я остановился на решении, описанном здесь: http://www.zytrax.com/books/dns/ch6/. То есть:

  • Настройте DNS-сервер Stealth, который содержит записи как для публичных, так и для частных хостов.

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

  • Легко понять
  • Быстрая первоначальная настройка

Основными недостатками являются избыточность и необходимость вручную синхронизировать стелс-сервер с нашим общедоступным DNS.

Источник

Типичные способы достижения этого:

  • разделенный DNS - наличие разных DNS-записей на внутреннем DNS-сервере... но внутренний DNS-сервер должен иметь все записи и требует синхронизации между внутренним и внешним серверами
  • делегирование - создание зоны svn.example.com, а ваши DNS-серверы example.com обращаются к svn.example.com за информацией о *.svn.example.com (включая сам svn.example.com).

Одним из способов является делегирование субдомена типа "internal.example.com" DNS-серверам вашей локальной сети. На этих DNS-серверах вы можете настроить зону для internal.example.com (или i.example.com, если вы хотите, чтобы она была короче), и добавить любые записи, которые вы хотите.

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

Третий вариант - просто поместить внутренние IP-адреса в ваш публичный DNS. Это может иметь последствия для безопасности (кто-то может использовать его, чтобы обмануть вас, чтобы подключиться к своему серверу, если вы не в своей локальной сети), но он должен работать и очень прост в настройке.

Источник

Самый простой способ обойти это - иметь все внутренние адреса во внутреннем поддомене, например, *.internal.example.com, Это также устраняет любую неоднозначность того, что имя хоста, к которому вы обращаетесь, является внутренним и не разрешается извне.

Источник

Читайте о Bind Views. Например: http://oreilly.com/pub/a/oreilly/networking/news/views_0501.html. Вы можете ограничить, кто (исходный IP) имеет доступ к какой зоне, и вы можете иметь несколько версий данной зоны.

Источник
Другие вопросы по тегам