Wildcard DNS dengan BIND

Saya mencoba untuk mengatur BIND sehingga menangkap setiap dan semua permintaan yang dibuat untuk itu, dan mengarahkan mereka ke set tertentu dari server NS, dan catatan A tertentu.

Saya memiliki sekitar 500 domain, dan saya menambahkan yang baru dengan kecepatan 10-15 hari, jadi saya tidak ingin secara eksplisit menambahkan zona untuk setiap domain.

Pengaturan saya saat ini adalah: di named.conf saya, saya memiliki tampilan (bernama eksternal) dengan zona berikut di dalamnya:

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

Ini cocok dengan semua permintaan.

ext.zone adalah:

$ TTL 3600
@ DALAM SOA. root.nsdomain.com. (
                              1; Serial
                         3600; Menyegarkan
                          300; Mencoba kembali
                         3600; Berakhir
                         300); TTL Cache Negatif


        DI NS ns1.example.com
        DI NS ns2.example.com

ns1 DALAM A 192.0.2.4
ns2 DALAM A 192.0.2.5

*. DALAM A 192.0.2.6

jadi, tujuannya adalah: untuk semua permintaan NS, kembalikan ns1.example.comdan ns2.example.com untuk semua permintaan A, kecuali jika ada ns1.example.comatau ns2.example.com, kembalikan 192.0.2.6. Untuk ns1.example.comkembali 192.0.2.4, untuk ns2.example.comkembali 192.0.2.5.

Ini hampir berhasil, satu-satunya masalah adalah ketika saya menggali, saya mendapatkan:

gali @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @localhost somedomain.example
; (1 server ditemukan)
;; opsi global: printcmd
;; Mendapat jawaban:
;; opcode: QUERY, status: NOERROR, id: 37733
;; bendera: qr aa rd; QUERY: 1, JAWABAN: 1, OTORITAS: 2, TAMBAHAN: 2

;; BAGIAN PERTANYAAN:
; somedomain.example. DI SEBUAH

;; BAGIAN JAWABAN:
somedomain.contoh. 3600 IN A 192.0.2.6 // seperti yang diharapkan

;; BAGIAN OTORITAS:
. 3600 IN NS ns1.example.com. Aku berharap, aku tidak tahu apakah "." pada awalnya itu buruk.
. 3600 IN NS ns2.example.com. // Lihat di atas.

;; BAGIAN TAMBAHAN:
ns1.example.com. 3600 DALAM A 192.0.2.6 // tidak diharapkan, ini harus 192.0.2.4
ns2.example.com. 3600 DALAM A 192.0.2.6 // tidak diharapkan, ini harus 192.0.2.5

Bagaimana cara saya memperbaikinya? Apakah saya melakukan sesuatu yang mengerikan? Apakah ada cara yang lebih baik untuk melakukan ini?

Asal Anda untuk zona ini .sesuai konfigurasi Anda. Anda membuat catatan untuk ns1.dan ns2.bukannya ns1.example.com.dan ns2.example.com. Karena ns1.example.comdan ns2.example.comtidak ditentukan, mereka dicocokkan dengan wildcard.

EDIT: inilah hasil edit konfigurasi dan zona Anda:

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

Segala sesuatu di zona itu relatif terhadap nama zona di konfigurasi yang dinamai, jadi menambahkan zona kedua hanya menunjuk ke file yang sama:

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

Untuk mengatur wildcard subdomain di bindAnda harus menggunakan format berikut:

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

Contoh:

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

Berdasarkan konfigurasi Anda ns1.example.comadalah 192.0.2.4dan ns2.example.comadalah 192.0.2.5. Anda harus mengkonfigurasi resolusi nama server NS di example.comzona untuk mendapatkan IP yang tepat.

Saya harap saya membuat diri saya jelas. Kembalilah padaku jika kamu membutuhkan info lebih lanjut.

Wildcard DNS dapat menyebabkan masalah!

jadi saya tidak ingin secara eksplisit menambahkan zona untuk setiap domain.

Ada banyak cara untuk dilakukan - dari SHELL-scripting hingga DNS-server berbasis SQL.

UPD. (2019-11) : Jadi seperti yang saya katakan 8 tahun yang lalu , SHELL-scripting adalah cara untuk pergi dan itu telah dibuktikan dengan solusi yang diajukan jawaban yang diterima "menambahkan entri zona" - jelas tidak didasarkan pada penggunaan wildcard. ;-)

Pada tahun 2019 bahkan lebih mudah untuk menemukan sumber daya yang menjelaskan kelemahan dari wildcard DNS dan meskipun kebanyakan dari mereka ditulis "pada awal Internet" mereka masih memiliki nilai. Misalnya, RFC1912 menyebutkan beberapa hal yang terkait dengan penggunaan wildcard DNS. Masalah utama jelas dijelaskan sebagai "...

Wildcard MX dapat menjadi buruk, karena mereka membuat beberapa operasi berhasil ketika mereka seharusnya gagal . … "

Ini juga memiliki beberapa contoh kehidupan nyata yang agak kuno sekalipun.