Как создать Stealth или DMZ Name Server? [duplicate]
У меня есть внутренняя сеть с DNS-сервером под управлением BIND, подключенная к Интернету через один шлюз. Мой домен "example.com" управляется внешним DNS-провайдером. Некоторые записи в этом домене, например, "host1.example.com" и "host2.example.com", а также запись верхнего уровня "example.com", указывают на публичный IP-адрес шлюза.
Я бы хотел, чтобы хосты, расположенные во внутренней сети, разрешали "host1.example.com", "host2.example.com" и "example.com" на внутренние IP-адреса, а не на IP-адрес шлюза. Другие хосты, такие как "otherhost.example.com", должны по-прежнему разрешаться внешним DNS-провайдером.
Мне удалось сделать это для записей host1 и host2, определив две одновходовые зоны в BIND для "host1.example.com" и "host2.example.com". Однако, если я добавляю зону для "example.com", все запросы для этого домена разрешаются моим локальным DNS-сервером, и, например, запрос "otherhost.example.com" приводит к ошибке.
Можно ли настроить 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";
};
В приведенном выше руководстве говорится о добавлении дополнительных материалов в зону «rpz» {} , но это не обязательно в простых настройках - то, что я показал здесь, является минимальным, чтобы заставить его работать на вашем локальном преобразователе.
Отредактируйте named.conf.options и где-нибудь в разделе options {} добавьте response-policy option:
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, необходимые для тестирования.
В 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 с API моего провайдера динамического DNS, я запускаю этот скрипт через cron каждые 5 минут:
1) получаю свой внешний IP. это изменилось? нет выхода.
2) изменил IP, вызов API dyndns-provider с новым IP-адресом,
3) привязал db.mydomain.com к внешнему IP
4) перезапустил привязку.
Работает очень надежно в моей домашней сети