DNS-сервер для поддельного домена, только для внутреннего тестирования (в Linux)
Допустим, у меня есть несколько машины (или виртуальные машины) во внутренней (10.0 или 192.168 класс) LAN, которые должны взаимодействовать друг с другом, но вместо настройки несколько динамического, утомительного для обновления файла / etc / hosts (поскольку новые виртуальные машины добавляются каждый раз и затем), я бы хотел настроить внутренний DNS-сервер. Все мои тестовые машины и виртуальные машины работают под управлением Linux. У меня есть несколько вопросов по этому поводу:
- Могу ли я настроить DNS-сервер s.t. Я могу использовать поддельный домен (скажем, "пример.com ", так как он зарезервирован), поскольку мой домен известен внутри частной сети?
- Могу ли я настроить DNS-сервер, если /etc/resolv.conf указывает на этот сервер, чтобы разрешить все IP-адреса машин для хостов в этот частный / поддельный домен? Однако для реального / фактического существующего домена DNS-сервер должен указывать или получать разрешенный IP-адрес с каскадного фактического DNS-сервера (например, общедоступный DNS-сервер)? Последний предназначен для доступа к общему общедоступный Интернет с тестовых машин через NAT-прокси.
- Могу ли я сделать что-нибудь в этом роде, скажем, с TinyDNS? Я считаю Bind слишком пугающим и, возможно, излишним для моих нужд?
Короткий ответ - да, и не имеет значения, настоящий у вас домен или поддельный. Как правило, лучше использовать то, что у вас есть (или субдомен того, что у вас есть).чтобы избежать потенциальных проблем в будущем. Использование реального домена, которым вы владеете, также позволяет получить настоящие (пользующиеся всеобщим доверием) сертификаты для имен в этом домене без необходимости поддерживать внутреннюю PKI.
Практически любое программное обеспечение DNS может поддерживать то, что вы пытаетесь сделать. Он будет действовать как «авторитетный» и «рекурсивный» DNS-сервер. Он будет авторитетным для зоны example.com (или любой другой), а рекурсия - это часть, которая позволяет запросам, для которых она не является авторитетной, разрешаться из Интернета.
Таким образом, ваши клиенты указывают только на ваши DNS-сервер в их resolv.conf. Запросы чего-либо в example.com решаются с использованием его записей. Запросы для чего-либо еще заставят DNS-сервер обращаться к Интернету за ответами, (вероятно) кэшировать их и возвращать их как «неавторизованные» ответы клиенту.
Я использую 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 сервер для сети.
Попробуйте использовать это решение: https://github.com/mocktools/ruby-dns-макет Легко имитировать любой тип записи DNS!