DNS de caractere curinga com BIND

10

Estou tentando configurar o BIND para que ele capture todos os pedidos feitos a ele e os aponte para um conjunto específico de servidores NS e um registro A específico.

Tenho cerca de 500 domínios e adiciono novos a uma taxa de 10 a 15 por dia, por isso não pretendo adicionar explicitamente uma zona para todos os domínios.

Minha configuração atual é: no meu named.conf, eu tenho uma visão (chamada external) com a seguinte zona:

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

Isso corresponde a todas as solicitações.

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

então, o objetivo é: para todas as solicitações NS, retorne ns1.example.com e ns2.example.com para todos Os pedidos, exceto onde é ns1.example.com ou ns2.example.com , devolve 192.0.2.6 . Por ns1.example.com return 192.0.2.4 , por ns2.example.com return 192.0.2.5 .

Isso quase funciona, o único problema é que quando eu faço uma escavação, fico:

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

Como faço para corrigir isso? Estou fazendo algo horrível? Existe uma maneira melhor de fazer isso?

    
por Jon Wu 31.01.2011 / 11:47

3 respostas

9

Sua origem para a zona é . por sua configuração. Você está criando registros para ns1. e ns2. em vez de ns1.example.com. e ns2.example.com. Como ns1.example.com e ns2.example.com não estão definidos, eles são correspondidos pelo curinga.

EDIT: aqui está uma edição da sua configuração 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

Tudo na zona é relativo ao nome da zona na configuração nomeada, portanto, adicionar uma segunda zona apenas aponta para o mesmo arquivo:

zone "example.net." {
    type master;
    file "ext.zone";
};
    
por 31.01.2011 / 11:56
0

Com base na sua configuração ns1.example.com is 192.0.2.4 e ns2.example.com is 192.0.2.5 . Você precisa configurar a resolução do nome do servidor NS na example.com zone para obter os IPs adequados.

Espero estar claro. Volte para mim se precisar de mais informações.

    
por 31.01.2011 / 11:56
-3

Os curingas de DNS são malvados principalmente, evite usá-los.

so I don't want to explicitely add a zone for every domain.

Existem muitas maneiras de ir - desde scripts de shell até servidores DNS baseados em SQL.

    
por 31.01.2011 / 12:01

Tags