☰

Как переслать DNS-запрос для локальной зоны на внешний DNS, если он не совпадает локально (BIND9)

tag-icon • tag-icon domain-name-system bind
Как переслать DNS-запрос для локальной зоны на внешний DNS, если он не совпадает локально (BIND9)

У меня есть домен example.com, и я использую Azure DNS для разрешения всех имен хостов, которые должны быть видны из интернета. Я определил, mail.example.comчто нужно указать 198.51.100.123, и это может быть разрешено внешними клиентами без каких-либо проблем.

Также используется example.comв моей локальной сети, и использование bind разрешает все локальные IP-адреса, что отлично работает для локальных имен хостов. Мой DHCP-сервер также знает, как с этим справиться, и обновляет файлы зон должным образом. Все DNS-запросы для других зон перенаправляются в Cloudflare DNS.

Я хотел бы, чтобы мой сервер использовал локальный сервер имен, и если он не может найти запись в локальном файле зоны, он должен связаться с сервером Azure и проверить ее. Когда я добавляю следующие записи в свой файл зоны, то он работает для этих имен хостов:

external-dns            A       1.1.1.1
vpn                     NS      external-dns
www                     NS      external-dns
ftp                     NS      external-dns

Подстановочные знаки больше не работают в Bind9, поэтому я не могу использовать * NS external-dns. Есть ли другой способ сделать это?

решение1

Используйте response-policyзону вместо главной зоны дляexample.com

При попытке определить имя хоста bind сначала просматривает response-policyфайл зоны и, если не находит ответа, продолжает поиск.

Вот пример настройки:

options {
    # Your normal options
    response-policy { zone "local_example_com"; };
};
zone "local_example_com" {
    type master;
    file "master/local_example.zone";
    allow-query {none;};
};

Затем добавьте файл зоны с именем, master/local_example.zoneсодержащий следующее:

$TTL 24H
@    SOA LOCALHOST. named-mgr.example.com (1 1d 1h 30d 2h)
     NS  LOCALHOST.

host1.example.com     A   192.168.1.1
host2.example.com     A   192.168.1.2
host3.example.com     A   192.168.1.3
host4.example.com     A   192.168.1.4

При попытке разрешения host1.example.comон получит ответ из response-policyзоны, а при попытке разрешения mail.example.comон разрешит его с помощью example.comсерверов имен.

решение2

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

  1. Все внешние сайты размещены на example.comдомене.
  2. Все внутренние сайты размещены на int.example.comдомене.

Не изменяется example.comникаким образом и по-прежнему доступен в Azure DNS (как и всегда). Внутренний сервер Bind теперь размещает домен int.example.com, а сервер DHCP также обновляется для push int.example.comв качестве локального домена.

Я хочу, чтобы мои внутренние сайты были доступны через HTTPS, поэтому мне нужно иметь возможность создавать сертификаты с помощью LetsEncrypt для домена int.example.com. LetsEncrypt не может получить доступ к моим внутренним сервисам, поэтому мне приходится возвращаться к проверке DNS.

Я добавил int.example.comзону как дочернюю зону example.comв Azure DNS. Эта зона не будет иметь никаких записей DNS, потому что мы используем для этого локальный сервер. Мы не хотим раскрывать какую-либо внутреннюю информацию внешним DNS-серверам. Ее единственное назначение — проверка DNS для LetsEncrypt, поэтому AcmeSh должен иметь соответствующие учетные данные для создания/удаления записей TXT. Я следовалэто руководстводля создания правильных учетных данных. Моя настройка использует Azure DNS, но она должна работать для любого DNS, поддерживающего подзоны.

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