☰

DNS-сервер для поддельного домена, только для внутреннего тестового использования (на Linux)

tag-icon • tag-icon domain-name-system bind nameserver internal-dns tinydns
DNS-сервер для поддельного домена, только для внутреннего тестового использования (на Linux)

Допустим, у меня есть несколько машин (или виртуальных машин) во внутренней локальной сети (класс 10.0 или 192.168), которым нужно взаимодействовать друг с другом, но вместо настройки довольно динамичного, утомительного для обновления файла /etc/hosts (поскольку время от времени добавляются новые виртуальные машины), я хотел бы настроить внутренний DNS-сервер. Все мои тестовые машины и виртуальные машины работают под управлением Linux. У меня есть несколько вопросов по этому поводу:

  1. Могу ли я настроить DNS-сервер так, чтобы я мог использовать поддельный домен (например, «example.com», поскольку он зарезервирован) в качестве своего домена, известного внутри частной сети?
  2. Могу ли я настроить DNS-сервер, чтобы /etc/resolv.conf указывал на этот сервер, чтобы разрешить все IP-адреса машин для хостов в этом частном / поддельном домене? Однако для реального / фактически существующего домена DNS-сервер должен указывать на или извлекать разрешенный IP-адрес из каскадного фактического DNS-сервера (так называемого публичного DNS-сервера)? Последний предназначен для доступа к общедоступному Интернету с тестовых машин через NAT-прокси.
  3. Могу ли я сделать что-то подобное, скажем, с TinyDNS? Я нахожу Bind немного пугающим и, возможно, излишним для моих нужд?

решение1

Короткий ответ — да, и неважно, настоящий у вас домен или поддельный. Просто обычно лучше использовать то, чем вы владеете (или поддомен того, чем вы владеете), чтобы избежать потенциальных проблем в будущем. Использование настоящего домена, которым вы владеете, также позволяет получать настоящие (публично доверенные) сертификаты для имен в этом домене без необходимости устанавливать внутреннюю PKI.

Почти любое программное обеспечение DNS может поддерживать то, что вы пытаетесь сделать. Оно будет действовать как «авторитетный» и «рекурсивный» DNS-сервер. Оно будет авторитетным для example.com(или чего-то еще) зоны, а рекурсия — это часть, которая позволяет запросам, для которых оно не является авторитетным, разрешаться из Интернета.

Таким образом, ваши клиенты указывают только на ваш DNS-сервер в своем resolv.conf. Запросы на что-либо в example.comбудут разрешены с использованием его записей. Запросы на что-либо еще заставят DNS-сервер обратиться к Интернету за ответами, (вероятно) кэшировать их и возвращать их как «неавторитетные» ответы клиенту.

решение2

я используюdnsmasqдля аналогичных целей. У меня он запущен на Raspberry Pi. Он служит локальным DNS-сервером для моей сети, поэтому все клиенты запрашивают его. Если домен отсутствует в его локальной базе данных или кэше, он делает запрос к DNS-серверу в Интернете (я провел несколько тестов, чтобы узнать, какой из них имеет самое быстрое время отклика, и выбрал их).

С этой настройкой вы можете иметь как реальные, так и «поддельные» домены. Например, при работе над веб-сайтом я могу изменить IP-адрес реального домена на локальный рабочий адрес на сервере dnsmasq. Когда я закончу и захочу получить доступ к реальному веб-сайту в Интернете, я просто удаляю настройку. (Помните, что это небольшая сеть, которую я полностью контролирую. В более сложном сценарии вы бы не хотели менять все туда-сюда таким образом).

В dnsmasq вы можете сделать:

address=/myfakedomain.com/10.16.1.20

для перенаправления запросов для myfakedomain.com на указанный IP-адрес. Вы даже можете делать такие вещи:

address=/plex/10.16.1.55

чтобы пользователи могли вводить ключевые слова и получать доступ к службам в сети.

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

решение3

Попробуйте использовать это решение:https://github.com/mocktools/ruby-dns-mock Легко имитировать любой тип записи DNS!

Связанный контент