Wildcard DNS з BIND

Я намагаюся налаштувати BIND так, щоб він вловлював будь-які запити, зроблені до нього, і вказував їх на певний набір NS-серверів та конкретний запис A.

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

Моя поточна настройка: у моєму імені.conf у мене є вид (названий зовнішній) із наступною зоною в ньому:

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

Це відповідає всім запитам.

ext.zone - це:

$ 3600 TTL
@ В SOA. root.nsdomain.com. (
                              1; Серійний
                         3600; Оновити
                          300; Повторіть спробу
                         3600; Термін дії
                         300); Негативний кеш TTL


        В НС ns1.example.com
        В НС ns2.example.com

ns1 IN A 192.0.2.4
ns2 В А 192.0.2.5

*. В А 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.

Це майже працює, єдина проблема полягає в тому, що коли я роблю, я отримую:

копати @localhost somedomain.example

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

;; РОЗДІЛ ЗАПИТАННЯ:
; somedomain.example. В

;; ВІДПОВІДЬ:
somedomain.example. 3600 В А 192.0.2.6 // як очікувалося

;; РОЗДІЛ ВЛАДИ:
. 3600 В нс ns1.example.com. // Очікується, я не знаю, чи "". на початку погано, хоча.
. 3600 В нс 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не визначені, вони збігаються по груповому символу.

EDIT: ось редагування вашої конфігурації та зони:

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-символи DNS можуть спричинити неприємності!

тому я не хочу чітко додавати зону для кожного домену.

Існує безліч способів - від SHELL-сценаріїв до DNS-серверів на базі SQL.

UPD. (2019-11) : Отже, як я вже говорив 8 років тому , сценарій SHELL - це спосіб пройти, і це було доведено запропонованим рішенням прийнятої відповіді "додавання зони входу" - явно не засноване на використанні макіяжів. ;-)

У 2019 році ще простіше знайти ресурси, що пояснюють недоліки макіяжів DNS, і хоча більшість з них були написані «на зорі Інтернету», вони все ще мають певне значення. Наприклад, RFC1912 згадує декілька речей, пов’язаних із використанням символів DNS. Основне питання чітко пояснено як "...

Wildcard MX може бути поганим, оскільки вони роблять деякі операції успішними, коли замість цього вони повинні вийти з ладу . … "

Він також має кілька прикладів із реального життя.