Назад | Перейти на главную страницу

Переопределение некоторых записей DNS в BIND для внутренних сетей

У меня есть внутренняя сеть с DNS-сервером под управлением BIND, подключенным к Интернету через единственный шлюз. Мой домен example.com управляется внешним поставщиком DNS. Некоторые записи в этом домене, например «host1.example.com» и «host2.example.com», а также запись верхнего уровня «example.com» указывают на общедоступный IP-адрес шлюза.

Я хотел бы, чтобы хосты, расположенные во внутренней сети, разрешали host1.example.com, host2.example.com и example.com во внутренние IP-адреса вместо адреса шлюза. Другие хосты, такие как "otherhost.example.com", по-прежнему должны разрешаться внешним поставщиком DNS.

Мне удалось сделать это для записей host1 и host2, определив две зоны с одной записью в BIND для «host1.example.com» и «host2.example.com». Однако, если я добавлю зону для "example.com", все запросы для этого домена будут разрешены моим локальным DNS-сервером, и, например, запрос "otherhost.example.com" приводит к ошибке.

Можно ли настроить BIND на переопределение только некоторые записи домена, а остальное разрешить рекурсивно?

domain-name-system bind

Лучший способ - через зону политики ответа в Bind 9.8.1 или новее. Он позволяет вам переопределять отдельные записи в произвольных зонах (и нет необходимости создавать для этого целый поддомен, только одну запись, которую вы хотите изменить), он позволяет вам переопределять CNAME и т. Д. Другие решения, такие как Unbound, не могут переопределять CNAME. .

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html

РЕДАКТИРОВАТЬ: Тогда давайте сделаем это как следует. Я задокументирую то, что я сделал, на основе руководства, указанного выше.

Моя ОС - Raspbian 4.4 для Raspberry Pi, но этот метод должен работать без каких-либо изменений в Debian и Ubuntu или с минимальными изменениями на других платформах.

Перейдите туда, где ваши файлы конфигурации Bind хранятся в вашей системе - вот это в /etc/bind. Создайте там файл с именем db.rpz со следующим содержанием:

$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2015112501   ; serial
                          1h           ; refresh
                          30m          ; retry
                          1w           ; expiry
                          30m)         ; minimum
                   IN     NS    localhost.

localhost       A   127.0.0.1

www.some-website.com    A        127.0.0.1

www.other-website.com   CNAME    fake-hostname.com.

Что оно делает?

он заменяет IP-адрес для www.some-website.com с поддельным адресом 127.0.0.1, эффективно отправляя весь трафик для этого сайта на адрес обратной связи
он отправляет трафик для www.other-website.com на другой сайт под названием fake-hostname.com

Все, что может войти в файл зоны привязки, вы можете использовать здесь.

Чтобы активировать эти изменения, необходимо выполнить еще несколько шагов:

редактировать named.conf.local и добавьте этот раздел:

zone "rpz" {
  type master;
  file "/etc/bind/db.rpz";
};

В приведенном выше руководстве рассказывается, как добавить больше вещей в zone "rpz" { } но в простых настройках это не обязательно - то, что я показал здесь, - это минимум, чтобы заставить его работать на вашем локальном преобразователе.

редактировать named.conf.options и где-то в options { } раздел добавить response-policy вариант:

options {
  // bunch
  // of
  // stuff
  // please
  // ignore

  response-policy { zone "rpz"; };
}

Теперь перезапустите Bind:

service bind9 restart

Вот и все. Сервер имен должен начать заменять эти записи сейчас.

Если вам нужно внести изменения, просто отредактируйте db.rpz, затем снова перезапустите Bind.

Бонус: если вы хотите регистрировать DNS-запросы в системном журнале, чтобы вы могли следить за процессом, отредактируйте named.conf.local и убедитесь, что есть logging раздел, который включает эти утверждения:

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

Снова перезапускаем Bind и все.

Протестируйте его на машине, на которой запущен Bind:

dig @127.0.0.1 www.other-website.com. any

Если вы запустите dig на другом компьютере, просто используйте @ the-ip-address-of-Bind-server вместо @ 127.0.0.1

Я с большим успехом использовал эту технику, чтобы переопределить CNAME для веб-сайта, над которым я работал, отправив его в новый балансировщик нагрузки AWS, который я только что тестировал. Raspberry Pi использовался для запуска Bind, и RPi также был настроен для работы в качестве маршрутизатора WiFi - поэтому, подключив устройства к SSID, работающему на RPi, я получал переопределения DNS, которые мне нужны для тестирования.

В Несвязанный рекурсивный DNS-сервер имеет возможность переопределять отдельные записи ресурсов.

Посмотрите на local-zone и local-data параметры конфигурации в руководство, например:

local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"

В transparent установка на local-zone сообщает ему выполнять обычные рекурсивные поиски для любых имен, не предоставленных local-data.

Вы можете изучить "dnsmasq", который позволяет вам делать некоторые довольно умные вещи с изменением разрешения.

Вам нужен разделенный DNS, который определяется Вебопедия так как:

В разделенной инфраструктуре DNS вы создаете две зоны для одного и того же домена, одну для внутренней сети, а другую для внешней сети. Разделенный DNS направляет внутренние узлы на внутренний сервер доменных имен для разрешения имен, а внешние узлы направляются на внешний сервер доменных имен для разрешения имен.

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

Это может быть реализовано независимо от того, какую реализацию DNS-сервера вы используете. В большинстве случаев у вас будет один DNS-сервер, который обслуживает внешнюю сеть, и другой, который обслуживает внутреннюю сеть. С BIND, как и с возможными другими реализациями, вы можете иметь обе версии зоны на одном сервере с помощью оператора "allow-query" в разделе зоны файла named.conf.

Еще одна возможность в BIND (а я никогда не пробовал этого) - установить домен example.com на внутреннем DNS-сервере только с теми записями, которые вы используете внутри. Затем установите оператор «вперед» с аргументом «первый» (вместе с «серверы пересылки»). Теоретически это будет запрашивать ответ у внешнего DNS-сервера (как установлено в «пересылках», который не будет иметь ваших внутренних записей и вернет ответ об ошибке. Затем внутренний сервер будет искать ответ сам. уверен, что это сработает, но это мысль.

Использование dnsmasq упрощает задачу. http://www.thekelleys.org.uk/dnsmasq/doc.html Действует как DNS-сервер, но получает ответы от локального DNS-сервера. Приятно то, что вы можете переопределить записи одного домена, не вмешиваясь в файлы зон.

В BIND я получаю эти результаты, определяя зону с использованием желаемого имени хоста. Подход хорош, если вы хотите переопределить только несколько хостов.

Объявление моей зоны выглядит так:

zone "override.example.com" {
        type master;
        notify no;
        file "zone-config/override.example.com";
};

Мое определение зоны выглядит так:

$TTL 4H
@       IN      SOA     ns.override.example.com.    root.override.example.com. (
                        2009072215      ; Serial
                        3600            ; Refresh
                        600             ; Retry
                        604800          ; Expire
                        3600    )       ; Minimum
;
                NS      ns
        IN      NS      ns.override.example.com.
        IN      A       192.168.1.100
ns      IN      A       192.168.1.100

Поэтому, если я запрашиваю example.com в DNS интрасети и DNS провайдера, я получаю тот же IP, но если я запрашиваю override.example.com, я получаю разные результаты, если DNS интрасети (первичный) доступен.

Вы уже на правильном пути.

На ваших внутренних DNS-серверах вам необходимо определить зону для каждого хоста исключения сразу под «example.com». Чтобы свести к минимуму эти исключения, принято называть все внутренние машины «hosta.internal.example.com», при этом DNS-сервер отправляет большинство запросов внешним DNS-серверам, но является полномочным для зоны «internal.example.com». (После небольших операций обычно есть пара DNS-серверов, на которые направляются клиенты, и отдельный авторитетный DNS, на который эти серверы направляются для "internal.example.com".)

Обычно исключения, которые вы описываете, создаются только тогда, когда хост должен быть доступен как извне, так и изнутри. Даже в этом случае вы можете захотеть использовать host1.example.com извне и host1.internal.example.com изнутри. Внутренние хосты настраиваются на поиск имен в пределах "internal.example.com". Бывают ситуации, когда то, что вы уже делаете, уместно, например, если сертификат для сервера идентифицирует сервер как «host1.example.com», и в этом случае вы хотите, чтобы это было имя, к которому подключаются клиенты.

На самом деле есть другой, хотя, возможно, и немного другой способ сделать это. У меня такая же ситуация, у меня есть домен, который используется внешне и внутренне, и у меня есть внешние статические и динамические хосты. По-настоящему болезненны только внешние динамические. Решение, возможно, не самое элегантное, но реализуемое с помощью небольшого скрипта. В основном я делаю свой собственный скрипт динамического DNS с API моего провайдера динамического DNS, я запускаю этот скрипт с помощью cron каждые 5 минут:

1) получить мой внешний IP. это изменилось? выхода нет.

2) изменен IP, вызов API dyndns-провайдера, с новым IP-адресом,

3) соберите db.mydomain.com с внешним IP

4) перезапустите привязку.

Очень надежно работает в моей домашней сети