Выполнять команды от имени другого пользователя

Это называется службой DNS с разделенным горизонтом , и есть четыре способа сделать это. В качестве примера предположим, что вы хотите настроить разделение горизонта для unix.stackexchange.com. (и, конечно же, для всех частей дерева доменных имен ниже). Как вы это сделаете, зависит от того, что вы решите запустить локально.

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

   Вы говорите это для unix.stackexchange.com. он пересылает на другой сервер. Вам необходимо настроить второй (удаленный) прокси-сервер DNS, который знает, как разрешать запросы для unix.stackexchange.com. и его подобласти. Вам также необходимо настроить частный DNS-сервер контента, который будет обслуживать фактические альтернативные данные для unix.stackexchange.com. и его поддомены, о которых второй прокси-сервер DNS знает и настроен для использования.

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

   Локальный прокси-сервер DNS настроен:

   • Для таких серверов, как dnscache Бернштейна (в режиме ТОЛЬКО ВПЕРЕД ), вы настраиваете серверы / unix.stackexchange.com файл (в корневом / рабочем каталоге сервера) с IP-адресами прокси-серверов DNS для пересылки запросов и перезапуска сервера.
   • Для зонированных DNS-серверов, таких как DNS-сервер Microsoft и BIND ISC, вы настраиваете зону пересылки для unix.stackexchange.com. и перезагрузите / перезапустите сервер.
   Второй (удаленный) DNS-сервер прокси настроен, как в варианте №2, приведенном ниже. Вариант №2 также применяется к ситуации, когда клиентские библиотеки DNS машины указываются (например, /etc/resolv.conf ) напрямую на (локальном / удаленном) разрешающем прокси-сервере DNS. сервер, вместо того, чтобы использовать DNS-сервер пересылки в качестве посредника.

2. Вы запускаете локальный разрешающий прокси-DNS-сервер . С момента появления системы доменных имен в 1980-х годах многозадачные операционные системы, такие как Unices и Linux, не уклонялись от запуска разрешающих прокси-серверов DNS на каждой машине, как это обычно бывает. Но, как указано в выборе №1, «локальный» может быть таким же локальным, как в локальной сети, а не на отдельных машинах.

   Вы это скажете, что для unix.stackexchange.com. он должен запускать разрешение запросов на сервере DNS контента, отличном от того, что публикуется в общедоступной базе данных DNS. Вам необходимо настроить частный DNS-сервер контента, который будет обслуживать фактические альтернативные данные для unix.stackexchange.com. и его подобласти.

   Локальный разрешающий прокси-сервер DNS настроен:

   • Для таких серверов, как dnscache Бернштейна (в режиме, отличном от ТОЛЬКО ВПЕРЕД ), вы настраиваете серверы / unix.stackexchange .com файл (в корневом / рабочем каталоге сервера) с IP-адресами DNS-серверов содержимого, с которых нужно начать разрешение запросов, и перезапустить сервер.
   • Для зонированных DNS-серверов, таких как DNS-сервер Microsoft и BIND ISC, вы настраиваете зону-заглушку для unix.stackexchange.com. и перезагрузите / перезапустите сервер.

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

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

   • Для серверов, таких как tinydns Бернштейна, вы используете его код местоположения и настраиваете все (внутренние IP-адреса клиентов) «ваших» прокси DNS-серверов как один код местоположения. а остальной интернет как другой. Вы помечаете все данные в базе данных, которые должны быть видны вашим прокси-DNS-серверам, с первым кодом местоположения,и все данные, которые должны быть видны остальной части Интернета как другие (или просто без кода местоположения).

     % si: 10 
     % si: 192.168 
     % lo: 127 
     … 
      = unix.stackexchange.com:127.0.0.1:::lo 
      = unix.stackexchange.com:192.168.72.3:::si
     =unix.stackexchange.com:151.101.1.69:::

   • Для DNS-сервера Microsoft вы используете немного больше громоздкая система зональных зондов . Это работает путем маркировки IP-адресов собственных принимающих интерфейсов сервера, а не путем маркировки исходных IP-адресов DNS-клиентов. Адаптация примеров Microsoft PowerShell:

      Add-DnsServerQueryResolutionPolicy -Name "SplitHorizonZonePolicy" -Action ALLOW -ServerInterface "eq, 10.0.0.56" -ZoneScope "internal, 1" -ZoneName "stackexchange.com" 
     Add- -ZoneName "stackexchange.com" -A -Name "unix" -IPv4Address "151.101.1.69" 
     Add-DnsServerResourceRecord -ZoneName "stackexchange.com" -A -Name "unix" -IPv4Address "10.0.0.69" -ZoneScope "internal" 

   • Для ISC BIND вы используете определенно более громоздкую систему просмотров .
   Если вы полагаетесь на внешнюю компанию для обслуживания вашего общедоступного контента DNS, вы вероятно не повезло, даже в наши дни, спустя годы после того, как эти идеи вошли в мейнстрим. Немногие такие компании все же предоставляют такую ​​возможность клиентам, даже если они могут использовать одно из этих программных средств DNS-серверов.

   Но если вы (скажем) публикация ваших собственных данных с помощью tinydns на вашей собственной общедоступной машине OpenBSD, служба DNS с разделением горизонта th это путь довольно простой. ☺

4. Вы используете сложное клиентское программное обеспечение DNS. Обычно вашим DNS-клиентом является код из библиотеки / библиотек C, связанных с программным обеспечением приложений в вашей системе. Но иногда это не так.

   Прикладное программное обеспечение может использовать такие вещи, как система Desktop Bus, которая обращается к systemd systemd-resolved . Они не передают протокол DNS прокси-серверу DNS. (Специалисты по systemd призывают разработчиков прикладного программного обеспечения прекратить это делать.) Вместо этого они используют идиосинкразический и нестандартный протокол шины рабочего стола для systemd-resolved . systemd-resolved , в свою очередь, имеет сложную систему для определения, на основе текущей конфигурации сети, на какой DNS-сервер (-ы) фактически отправить запрос протокола DNS.

   Обратите внимание, что эта локальная служба DNS не так полнофункциональна, как API-интерфейсы шины [desktop] libc NSS или systemd-resolved . […] Таким образом, всем приложениям настоятельно рекомендуется использовать вместо этого libc NSS API или собственный systemd-resolved [desktop] bus API.
   - Леннарт Поеттеринг, 2016-06-25

   Управление, которое выходит далеко за рамки общего вопроса, и ответьте вроде этого.

Для программных средств DNS-серверов, которые напрасно надевают сразу все, как DNS-сервер Microsoft, BIND ISC, dnsmasq и т. Д., Существуют сложные сценарии, которые выглядят как смесь вариантов # 1, №2 и №3; или которые выглядят как действительно сложная версия варианта №2. Но тщетно носить все шляпы сразу в течение почти двух десятилетий в большинстве стран мира DNS считалось плохой идеей.(Даже в мире DNS-серверов Microsoft, примерно в течение одного десятилетия.) Ваши DNS-серверы не должны быть одновременно содержательными DNS-серверами и прокси-DNS-серверами. (Есть люди, такие как OpenResolver Project , которые активно выкапывают публичные DNS-серверы людей, чтобы попытаться добиться этого.) Правильно разделите типы сервисов на отдельные серверы, как вы, вероятно, уже делаете. с сервисами SMTP и HTTP, и выбор упрощается до одного из вышеупомянутых.

Дополнительная литература

• Джонатан де Бойн Поллард (2000). "контент" и "прокси" DNS-серверы. Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2002). Предоставление службы DNS «расщепленного горизонта». Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2003). Вы забыли заполнить вашу «внутреннюю» базу данных DNS данными. Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2004). Используйте службу DNS с разделением горизонта, если вы используете непубличные диапазоны IP-адресов. Часто задаваемые ответы.
• Корпорация Microsoft (2015 г.). Как создать сервер имен только для кэширования с помощью Microsoft DNS . # 167234. База знаний.
• Группа по работе с сетями Windows (12 мая 2015 г.). Развертывание раздельно-мозговой системы DNS с использованием политик Windows DNS-сервера . Корпорация Майкрософт.
• Крикет Лю и Пол Альбиц (2006). "Безопасность". DNS и BIND . О'Рейли. ISBN 978-0596100575.