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

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

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

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

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

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

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

ext.zone - это:

$TTL    3600
@       IN      SOA     . root.nsdomain.com. (
                              1         ; Serial
                         3600         ; Refresh
                          300         ; Retry
                         3600         ; Expire
                         300 )        ; Negative Cache 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

*.      IN      A       192.0.2.6

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

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

dig @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 > @localhost somedomain.example
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; opcode: QUERY, status: NOERROR, id: 37733
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;somedomain.example.                        IN      A

;; ANSWER SECTION:
somedomain.example.         3600    IN      A       192.0.2.6 // as expected

;; AUTHORITY SECTION:
.                       3600    IN      NS      ns1.example.com. // expected, I don't know if the "." at the start is bad, though.
.                       3600    IN      NS      ns2.example.com. // see above.

;; ADDITIONAL SECTION:
ns1.example.com.  3600    IN      A       192.0.2.6 // not expected, this should be 192.0.2.4
ns2.example.com.  3600    IN      A       192.0.2.6 // not expected, this should be 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";
};

внешняя зона:

$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 zone, чтобы получить правильные IP-адреса.

Надеюсь, я ясно выражаюсь. Вернись ко мне, если тебе понадобится дополнительная информация.

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

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

Есть много вариантов - от сценариев SHELL до DNS-серверов на базе SQL.

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

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

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

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