Подстановочный знак DNS с BIND

Я пытаюсь настроить BIND так, чтобы он перехватывал все запросы, сделанные к нему, и указывал их на определенный набор серверов NS и конкретную запись A.

У меня около 500 доменов, и я добавляю новые со скоростью 10-15 в день, поэтому я не хочу явно добавлять зону для каждого домена.

Моя текущая настройка: в моем named.conf у меня есть представление (с именем external) со следующей зоной:

zone "." {
        type master;
        file "ext.zone";
};

Это соответствует всем запросам.

ext.zone это:

TTL 3600
@ В SOA. root.nsdomain.com. (
                              1; последовательный
                         3600; обновление
                          300; Retry
                         3600; истекать
                         300); Отрицательный кэш TTL


        IN NS ns1.example.com
        IN NS ns2.example.com

ns1 IN A 192.0.2.4
ns2 IN A 192.0.2.5

*. В 192.0.2.6

Итак, цель: для всех NS-запросов return ns1.example.comи ns2.example.com для всех A-запросов, кроме тех, где она есть ns1.example.comили ns2.example.com, return 192.0.2.6. Для ns1.example.comвозвращения 192.0.2.4, для ns2.example.comвозвращения 192.0.2.5.

Это почти работает, единственная проблема в том, что когда я копаю, я получаю:

копать @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @localhost somedomain.example
; (Найден 1 сервер)
;; глобальные параметры: printcmd
;; Получил ответ:
;; код операции: QUERY, статус: NOERROR, id: 37733
;; флаги: qr aa rd; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 2, ДОПОЛНИТЕЛЬНО: 2

;; РАЗДЕЛ ВОПРОСА:
; Somedomain.example. В

;; ОТВЕТ РАЗДЕЛ:
somedomain.example. 3600 В 192.0.2.6 // как и ожидалось

;; РАЗДЕЛ ВЛАСТИ:
, 3600 IN NS ns1.example.com. // ожидается, я не знаю, если "." в начале это плохо, хотя.
, 3600 IN NS ns2.example.com. // см. выше.

;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ:
ns1.example.com. 3600 IN A 192.0.2.6 // не ожидается, это должно быть 192.0.2.4
ns2.example.com. 3600 IN A 192.0.2.6 // не ожидается, это должно быть 192.0.2.5

Как я могу это исправить? Я делаю что-то ужасное? Есть лучший способ это сделать?

Ваше происхождение для зоны .соответствует вашей конфигурации. Вы создаете записи для ns1.и ns2.вместо ns1.example.com.и ns2.example.com. С ns1.example.comи ns2.example.comне определены, они сопоставляются с подстановочным знаком.

РЕДАКТИРОВАТЬ: вот редактирование вашей конфигурации и зоны:

zone "example.com." {
        type master;
        file "ext.zone";
};

ext.zone:

$TTL    3600
@       IN      SOA     ns1 root (
                              1         ; Serial
                         3600         ; Refresh
                          300         ; Retry
                         3600         ; Expire
                         300 )        ; Negative Cache TTL


        IN      NS      ns1
        IN      NS      ns2
        IN      A       192.0.2.6


ns1     IN      A       192.0.2.4
ns2     IN      A       192.0.2.5

*      IN      A       192.0.2.6

Все в зоне относится к имени зоны в именованной конфигурации, поэтому добавление второй зоны просто указывает на тот же файл:

zone "example.net." {
    type master;
    file "ext.zone";
};

Чтобы установить подстановочный знак субдомена, bindвы должны использовать следующий формат:

name.tld.   IN  A   IP    # main domain ip
*.name.tld. IN  A   IP    # wildcard subdomains ip

Пример:

mydomain.com.   IN  A   1.1.1.1
*.mydomain.com. IN  A   1.1.1.1 

На основании вашей конфигурации ns1.example.comесть 192.0.2.4и ns2.example.comесть 192.0.2.5. Вы должны настроить разрешение имен серверов NS в example.comзоне, чтобы получить правильные IP-адреса.

Я надеюсь, что я проясню. Вернись ко мне, если тебе нужно больше информации.

Подстановочные знаки DNS могут вызвать проблемы!

поэтому я не хочу явно добавлять зону для каждого домена.

Существует множество способов - от SHELL-сценариев до DNS-серверов на основе SQL.

UPD. (2019-11) : Итак, как я уже говорил 8 лет назад , SHELL-скриптинг - это путь, и он был подтвержден предложенным решением с предложенным ответом «добавление входа в зону» - явно не основанным на использовании подстановочных знаков. ;-)

В 2019 году стало еще проще найти ресурсы, объясняющие недостатки подстановочных знаков DNS, и хотя большинство из них были написаны «на заре Интернета», они все еще имеют определенную ценность. Например, RFC1912 упоминает несколько вещей, связанных с использованием подстановочных знаков DNS. Основная проблема четко объясняется как «…

Подстановочные знаки MX могут быть плохими, потому что они делают некоторые операции успешными, когда они должны завершаться неудачей . ...»

У этого также есть некоторые реальные примеры, хотя немного старомодные все же.