Назад | Перейти на главную страницу

Частная зона 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 для ученых-ракетчиков Глава 6 дает пример конфигурации DNS для скрытый DNS-сервер во внутренней сети. Кажется, это соответствует тому, чего я хочу достаточно хорошо, и, в частности, предлагает дублировать общедоступные записи 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. Это может иметь последствия для безопасности (кто-то может использовать это, чтобы обмануть вас, чтобы подключиться к своему серверу, если вы не в своей локальной сети), но должно работать и очень просто в настройке.

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

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

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

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

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

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

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