☰

Как можно разрешить различные записи DNS в зависимости от исходной подсети?

tag-icon • tag-icon domain-name-system bind internal-dns dns-zone
Как можно разрешить различные записи DNS в зависимости от исходной подсети?

У меня есть новый внутренний веб-сайт, который размещается на нескольких сайтах, и я хочу разрешить fqdn для него в поддомен конкретного сайта в зависимости от используемой исходной подсети. Наш DNS-сервер привязки в настоящее время настроен так, что разрешение fqdn является главным на сайте a и подчиненным на сайтах b и c (все через puppet), поэтому я не могу настроить отдельные файлы записей на сайтах b и c с разными ответами, чтобы сделать это.

Например, я хочу, чтобы IP-адреса на сайте a 172.10.0.0/16 преобразовывали server.domain.com в server.a.domain.com, а IP-адреса на сайте b 172.11.0.0/16 преобразовывали server.domain.com в server.b.domain.com и т. д.

Я рассматривал Bind RPZ, но, похоже, он не предлагает конкретных вариантов разрешения для подсетей, только возможность отбрасывать или блокировать целые подсети, если я не ошибаюсь. Я могу заставить его работать, чтобы перенаправлять cname вместо пересылки в правильную зону для разрешения, но тогда это применяется в целом ко всем серверам, не использующим триггер клиентского IP, как я пытаюсь использовать, и я мог бы также обновить CNAME в зоне domain.com.

добавлено в name.d.conf.options

response-policy { zone "rpz"; };

файл зоны rpz

zone "rpz" {
  type master;
  file "/etc/named/zones/rpz/db.rpz.conf";
  allow-query { none; };
};

dbfile

@       IN    SOA  nstest.domain.com. domain.com.  (
                      2   ; serial
                      3H  ; refresh
                      1H  ; retry
                      1W  ; expiry
                      1H) ; minimum

@        IN    NS    nstest.domain.com. ; destination IP rewrite

16.0.0.16.172.rpz-ip CNAME server.domain.com.
server.domain.com     CNAME   server.a.domain.com.

При этих настройках все запросы к server.domain.com через этот ns, независимо от исходного IP-адреса, разрешаются в server.a.domain.com

Или попытка использовать RPZ — неправильный метод для этого? В своих исследованиях я также видел представления привязки, но похоже, что вам придется заново создавать весь файл зоны для каждого сайта, а я просто хочу изменить одну запись CNAME.

Любая помощь приветствуется.

решение1

  • выделенный сервер для локации B

в этом случае вы можете легко использовать RPZ. Решением может быть даже запуск этого DNS-сервера на нестандартном порту (то есть, отличном от 53 TCP/UDP) и настройка на уровне брандмауэра перенаправления портов, так что как только запрос приходит из определенной сети, он перенаправляется на эти порты. Все остальные запросы будут обрабатываться DNS-сервером на стандартных портах (поскольку "глобальная" RPZ является проблемой, я полагаю, что необходимо иметь DNS-сервер также и для другого трафика).

  • «общий» DNS-сервер не только для местоположения B

Views — это, скорее всего, правильное направление для вас. В случае, если вам не нужен явно CNAME, но это может быть даже запись A, вы можете легко определить только «определенный поддомен» в представлении, а для остального сохранить «нормальное» разрешение / переадресацию на другой DNS-сервер».

Допустим, у вас есть доменпример.comна DNS-сервере в локации A. Существуетсервер.example.comкоторый обычно разрешается как запись A для 192.0.2.10. Также есть еще одна записьдругой.пример.comразрешается в A со значением 192.0.2.20.

Затем у вас есть где-то локально (расположение B) сервер привязки, разрешающий для некоторых локальных клиентов. Вы можете создать локальное представление для определенного клиента (локальные IP-адреса в расположении B), где вы можете создать доменсервер.example.com.

@       IN    SOA  dns.example.com. admin.example.com.  (
                      2   ; serial
                      3H  ; refresh
                      1H  ; retry
                      1W  ; expiry
                      1H) ; minimum

@        IN    NS    dns.example.com ; destination IP rewrite

@        IN    A     192.0.2.30

Как только клиент отправит запрос на server.example.com, он будет разрешен локально как локальная "главная" зона в поле зрения. Как только клиент запросит что-либо еще (кроме поддомена на server.example.com), он выполнит обычное разрешение или переадресацию на основе другой конфигурации...

Таким образом, в точке А результат будет следующим:

server.example.com => 192.0.2.10
another.example.com => 192.0.2.20

На месте B это будет:

server.example.com => 192.0.2.30
another.example.com => 192.0.2.20

Таким образом, вы можете переопределить только явный список поддоменов. Минус в том, что поскольку это дополнительная зона, должна быть как минимум SOA и, скорее всего, NS-запись, поэтому в этом случае невозможно использовать CNAME.

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