DNS curinga com BIND

Estou tentando configurar o BIND para que ele capture toda e qualquer solicitação feita e os aponte para um conjunto específico de servidores NS e um registro A específico.

Eu tenho cerca de 500 domínios e estou adicionando novos na taxa de 10 a 15 por dia, portanto, não quero adicionar explicitamente uma zona para cada domínio.

Minha configuração atual é: no named.conf, tenho uma view (nomeada external) com a seguinte zona:

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

Isso corresponde a todos os pedidos.

ext.zone é:

$ TTL 3600
@ EM SOA. root.nsdomain.com. (
                              1; Serial
                         3600; Atualizar
                          300; Repetir
                         3600; Expirar
                         300); TTL de cache negativo


        EM NS ns1.example.com
        NO NS ns2.example.com

ns1 EM A 192.0.2.4
ns2 IN A 192.0.2.5

* EM A 192.0.2.6

portanto, o objetivo é: para todas as solicitações de NS, retorne ns1.example.come ns2.example.com para todas as solicitações de A, exceto onde está ns1.example.comou ns2.example.comretorne 192.0.2.6. Para ns1.example.comretorno 192.0.2.4, para ns2.example.comretorno 192.0.2.5.

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

dig @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @localhost somedomain.example
; (1 servidor encontrado)
;; opções globais: printcmd
;; Resposta obtida:
;; opcode: QUERY, status: NOERROR, identificação: 37733
;; sinalizadores: qr aa rd; CONSULTA: 1, RESPOSTA: 1, AUTORIDADE: 2, ADICIONAL: 2

;; SEÇÃO PERGUNTA:
; somedomain.example. EM UM

;; SEÇÃO DE RESPOSTA:
somedomain.example. 3600 IN A 192.0.2.6 // conforme o esperado

;; SEÇÃO DA AUTORIDADE:
. 3600 IN NS ns1.example.com. // esperado, não sei se o "." no início é ruim, no entanto.
. 3600 IN NS ns2.example.com. // Veja acima.

;; SEÇÃO ADICIONAL:
ns1.example.com. 3600 IN A 192.0.2.6 // não esperado, deve ser 192.0.2.4
ns2.example.com. 3600 IN A 192.0.2.6 // não esperado, deve ser 192.0.2.5

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

Sua origem para a zona é de .acordo com sua configuração. Você está criando registros para ns1.e em ns2.vez de ns1.example.com.e ns2.example.com. Desde ns1.example.comens2.example.com não sã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";
};

Para definir um curinga de subdomínio, bindvocê deve usar o seguinte formato:

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

Exemplo:

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

Com base na sua configuração ns1.example.comé 192.0.2.4e ns2.example.comé 192.0.2.5. Você precisa configurar a resolução de nomes do servidor NS no diretórioexample.com zona para obter os IPs adequados.

Espero me esclarecer. Volte para mim se precisar de mais informações.

Os curingas de DNS podem causar problemas!

portanto, não quero adicionar explicitamente uma zona para cada domínio.

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

UPD. (2019-11) : Então, como eu disse há 8 anos , o SHELL-scripting é um caminho a percorrer e foi provado com a solução proposta pela resposta aceita "adicionando entrada de zona" - claramente não baseada no uso de curingas. ;-)

Em 2019, é ainda mais fácil encontrar recursos explicando as desvantagens dos curingas DNS e, embora a maioria deles tenha sido escrita "no início da Internet", eles ainda têm algum valor. Por exemplo, o RFC1912 menciona algumas coisas relacionadas ao uso de curingas DNS. A questão principal é explicada claramente como "…

Os MXs curinga podem ser ruins, porque eles fazem algumas operações serem bem-sucedidas quando devem falhar . ... "

Ele também tem alguns exemplos da vida real, meio antiquados.