Я не совсем уверен, как точно сформулировать то, что мне нужно, что затрудняет поиск. :) В основном у меня есть Bind DNS, работающий на экземплярах RackSpace, и я хочу настроить именованный так, чтобы любой из моих клиентов мог рекурсивно запрашивать, не рискуя открытым преобразователем.
Все клиенты основаны на Linux, хотя мобильные клиенты Android немного сложнее настроить. Я знаю, что могу настроить кэширующие экземпляры Bind на ноутбуках и шлюзах, что может позволить некоторую форму аутентификации рекурсивных запросов на основе ключей. Однако я не уверен, возможно ли это на клиентах Android.
Обратите внимание, что я знаю, что могу использовать широкий спектр общедоступных преобразователей, например, предоставляемых Google, но по причинам, не имеющим отношения к данному вопросу, мне нужно выполнять запросы клиентов через мой собственный сервер, если это вообще возможно. Я пробовал пролистывать справочные страницы и онлайн-документацию, но не совсем понимаю, что мне нужно искать.
----- Больше информации согласно комментариям. -----
Клиенты не подключаются через VPN, и я стараюсь этого избежать по определенным причинам. Одна из этих причин заключается в том, что дополнительный объем памяти и нагрузка на ЦП даже легких VPN с низким уровнем безопасности создают проблемы для самых доступных облачных инстансов. Во-вторых, виртуальные частные сети добавляют уровень сложности почти во все реализации Android, которые я видел, и это очень раздражает, если не совсем необходимо для безопасности.
Я не "замужем" за Bind в качестве сервера имен. Если есть другие серверы имен FOSS, которые могут быть более полезными в данном конкретном случае, я с радостью их опробую. Я просто потратил более 15 лет на Bind и перестал думать об альтернативах.
Я также не очень обеспокоен тем, что кто-то пытается взломать ответы DNS моим клиентам. Если бы мы жили в таком мире, для которого была разработана система DNS, я бы с радостью запустил открытый преобразователь. Увы, злоумышленники самых разных мастей используют мой открытый резолвер для атак на третьих лиц.
Я не использую здесь «критически важную» сеть. Он используется немногими людьми без каких-либо финансовых или личных соображений, а скорее для экспериментов, разработки и тестирования.
Для этого вы можете использовать управление доступом на основе TSIG на преобразователях BIND. Это работает с клиентами, которые действительно могут использовать TSIG, что, вероятно, ограничивает его использование только теми, у кого есть локальный экземпляр BIND.
Видеть http://www.cyberciti.biz/faq/unix-linux-bind- named-configuring-tsig/ и http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch04.html#id2570685.
Обратите внимание, что это позволяет очень легко организовать атаку отказа в обслуживании на ваши резолверы, заставив их проверять поток поддельных подписей.
В общем, я настоятельно не рекомендую запускать собственные распознаватели для ваших клиентов в Интернете. Он будет работать только в исключительных случаях, и рационального варианта использования просто нет. Ваши DNS-запросы не должны содержать конфиденциальных данных, иначе вы делаете это неправильно. Если резолверы ваших интернет-провайдеров слишком ненадежны или отсутствуют, используйте OpenDNS или Google Public DNS (я бы не стал их использовать, если в этом нет необходимости).
Во всяком случае, запустите локальные преобразователи BIND (или, скорее, несвязанные), где сможете, включите DNSSEC и подпишите свои зоны.
Следующее не будет работать для Android, но отлично работает с клиентами GNU / Linux. Технически это включает в себя настройку VPN, но фактическая настройка не требуется, и ваш фактический сетевой трафик не идет на удаленный сервер (за исключением ваших DNS-запросов, конечно, которые отправляются на удаленный сервер - в этом весь смысл! ), поэтому нагрузка на удаленный сервер минимальна. Если у вас есть ssh-доступ к удаленному серверу, вы можете это сделать.
В экземпляре Rackspace, который я назову remote-server.com: убедитесь, что sshd и named работают.
На клиентах Linux:
sudo apt install sshuttle ### or dnf install sshuttle, or whatever
sshuttle --dns -r username@remote-server.com 192.0.2.0/24
Это устанавливает VPN, которая направляет все DNS-запросы, а также весь сетевой трафик, отправленный на 192.0.2.0/24, на удаленный сервер. Но 192.0.2.0/24 - это черная дыра IP-адреса (RFC 5737), поэтому на практике сетевой трафик не отправляется на удаленный сервер. Однако DNS-запросы воля быть отправленным на удаленный сервер.
Я не верю, что вы можете фильтровать на основе ОС, на которой работает клиент. Но если вы знаете IP-адреса, с которых подключаются клиенты (или службы кеширования), вы можете использовать такой acl:
acl "trusted" {
192.168.0.0/16;
10.153.154.0/24;
localhost;
localnets;
};
options {
...
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
...
};