У меня есть bind9 в локальной системе шлюза, которая в настоящее время настроена как рекурсивный разрешающий сервер имен для нашей локальной сети. Я также хотел бы сделать его авторитетным для адресов RFC 1918 в нашей локальной сети, но попадать на удаленный сервер имен для имен в том же домене, которых нет в файле зоны для них. (Оба локальных хоста с адресами RFC 1918 и общедоступными именами, разрешенными через удаленный сервер, используют один и тот же sld.tld.) Я попытался поместить записи NS для удаленного сервера в таблицу зон, но это не сработало. Есть какой-либо способ сделать это?
У меня есть локальные имена в / etc / hosts, но некоторые службы требуют, чтобы они разрешались через поиск DNS, и не разрешают их из файла hosts.
Я также хотел бы сделать его авторитетным для адресов RFC 1918 в нашей локальной сети, но попадать на удаленный сервер имен для имен в том же домене, которых нет в файле зоны для них.
Проблема, с которой вы сталкиваетесь, заключается в том, что власть так не работает. Нет понятия провала. Когда сервер заявляет права доступа к зоне, он является полномочным для все данные в нем, за исключением двух сценариев:
NS запись) делегирует полномочия от него. NS записи вверху зон не определяют рефералов.К сожалению для этой проблемы, рефералы, полученные не из Интернета, не очень полезны. Это связано с тем, что ссылки служат только цели, когда встречаются на пути рекурсии, за которым внутренне управляемый DNS не следует.
Есть несколько разных подходов, которые вы можете использовать здесь для достижения аналогичного конечного результата.
Это то, что делают большинство компаний, и им, безусловно, легче всего управлять.
Самое простое решение - создать новый, исключительно «внутренний» субдомен для устройств RFC1918, в котором они будут жить. Это работает до тех пор, пока вы не пытаетесь создать конфликтующие определения DNS для записи DNS. (т.е. www.example.com имея как публичный, так и частный IP`)
Рекурсивные DNS-серверы, которым необходим доступ к этому внутреннему домену, должны быть настроены с использованием серверов пересылки, указывающих на авторитетные серверы. В BIND это будут зоны типа forward.
Преимущества:
Недостатки:
Если решение 1 не работает, нам нужно сделать шаг назад и на мгновение быть честными с собой. Ваш сервер не собственные полномочия для пространства имен, в котором вы пытаетесь создать записи DNS. Вы пытаетесь захватить пространство имен, за которое вы не несете операционной ответственности. Вместо того, чтобы пытаться создать авторитетную зону для данных, для которых вы не уполномочены, почему бы не использовать функцию, разработанную для этой цели?
В последние годы BIND получил новую функцию под названием Зоны политики реагирования (РПЗ). Это позволяет вам определить файл зоны запросов, которые вы хотите перехватить, а также ответы, которые ваш сервер должен предоставить, когда они будут видны. Это позволяет вам управлять списком записей, которые вы хотите перехватить, при этом все остальные разрешаются, как обычно.
Преимущества:
Недостатки:
Последний метод - это тот, где существует несколько версий зоны. Один обращен к Интернету, а один или несколько обращены к вашим частным сетям.
Есть два общих подхода.
Подход, основанный на взглядах. Обе версии авторитетной зоны находятся на одних и тех же серверах. Определены несколько представлений на основе IP-адреса источника, которые определяют файл, из которого будет получен ответ.
Серверный подход. Один сервер владеет версией зоны с выходом в Интернет, а другой сервер владеет частной версией зоны. Подобно Решению 1, версия зоны с частным доступом видна только рекурсивным серверам, для которых определены серверы пересылки, указывающие полномочия на альтернативных DNS-серверах.
Подход, основанный на сервере, имеет тенденцию быть уродливым, поскольку любые записи, которые должны быть видимы в обеих средах, должны добавляться отдельно. Это становится еще более сложным, если у серверов разные операционные владельцы, поскольку возникает необходимость задействовать две или более групп для записей DNS, которые должны быть видны в более чем одной среде. У ваших пользователей нет возможности узнать, что несколько команд участвуют в их «простом» запросе на добавление записи, и что мячи будут часто падать, что мешает хорошему общению в команде.
Преимущества:
Недостатки: