Wildcard DNS con BIND

Sto provando a configurare BIND in modo tale da catturare tutte le richieste fatte e indirizzarle verso un set specifico di server NS e un record A specifico.

Ho circa 500 domini e ne sto aggiungendo di nuovi al ritmo di 10-15 al giorno, quindi non voglio aggiungere esplicitamente una zona per ogni dominio.

La mia configurazione attuale è: nel mio named.conf, ho una vista (denominata esterna) con la seguente zona al suo interno:

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

Questo corrisponde a tutte le richieste.

ext.zone è:

$ TTL 3600
@ IN SOA. root.nsdomain.com. (
                              1; Seriale
                         3600; ricaricare
                          300; Riprova
                         3600; scadere
                         300); Cache negativa 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

quindi, l'obiettivo è: per tutte le richieste NS, ritorno ns1.example.come ns2.example.com per tutte le richieste A, tranne dove si trova ns1.example.como ns2.example.com, ritorno 192.0.2.6. Per il ns1.example.comritorno 192.0.2.4, per il ns2.example.comritorno 192.0.2.5.

Questo funziona quasi, l'unico problema è che quando faccio uno scavo, ottengo:

dig @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @localhost somedomain.example
; (1 server trovato)
;; opzioni globali: printcmd
;; Risposta ottenuta:
;; codice operativo: QUERY, stato: NOERROR, id: 37733
;; flag: qr aa rd; QUERY: 1, RISPOSTA: 1, AUTORITÀ: 2, AGGIUNTIVO: 2

;; SEZIONE DOMANDA:
; Somedomain.example. IN UN

;; SEZIONE RISPOSTA:
somedomain.example. 3600 IN A 192.0.2.6 // come previsto

;; SEZIONE AUTORITÀ:
. 3600 IN NS ns1.example.com. // previsto, non so se il "." all'inizio è male, però.
. 3600 IN NS ns2.example.com. // vedi sopra.

;; SEZIONE AGGIUNTIVA:
ns1.example.com. 3600 IN A 192.0.2.6 // non previsto, dovrebbe essere 192.0.2.4
ns2.example.com. 3600 IN A 192.0.2.6 // non previsto, dovrebbe essere 192.0.2.5

Come posso risolvere questo problema? Sto facendo qualcosa di orribile? C'è un modo migliore per farlo?

La tua origine per la zona dipende dalla .tua configurazione. Stai creando record per ns1.e ns2.anziché ns1.example.com.e ns2.example.com. Since ns1.example.come ns2.example.comnon sono definiti, sono associati al carattere jolly.

EDIT: ecco una modifica della tua configurazione e zona:

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

Tutto nella zona è relativo al nome della zona nella configurazione denominata, quindi l'aggiunta di una seconda zona punta semplicemente allo stesso file:

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

Per impostare un jolly sottodominio bindè necessario utilizzare il seguente formato:

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

Esempio:

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

In base alla configurazione ns1.example.comè 192.0.2.4ed ns2.example.comè 192.0.2.5. È necessario configurare la risoluzione del nome del server NS nella example.comzona per ottenere gli IP corretti.

Spero di chiarirmi. Torna da me se hai bisogno di maggiori informazioni.

I caratteri jolly DNS possono causare problemi!

quindi non voglio aggiungere esplicitamente una zona per ogni dominio.

Esistono molti modi per procedere: dallo SHELL-scripting ai server DNS basati su SQL.

UPD. (2019-11) : Quindi, come ho detto 8 anni fa , SHELL-scripting è un modo per procedere ed è stato dimostrato con la soluzione proposta di risposta accettata "aggiunta dell'ingresso alla zona" - chiaramente non basata sull'uso di caratteri jolly. ;-)

Nel 2019 è ancora più facile trovare risorse che spieghino i lati negativi dei caratteri jolly DNS e sebbene la maggior parte di essi sia stata scritta "all'alba di Internet", mantengono comunque un certo valore. Ad esempio, RFC1912 menziona alcune cose relative all'uso dei caratteri jolly DNS. Il problema principale è chiaramente spiegato come "...

I MX con caratteri jolly possono essere dannosi, perché rendono alcune operazioni riuscite quando invece dovrebbero fallire . ..."

Ha anche alcuni esempi di vita reale in qualche modo vecchio stile però.