Erro ao adicionar um subdomínio DNS usando Bind9.9, com o NS no subdomínio

Question

Eu tive uma configuração usando um Bind antigo que não está mais funcionando depois que comecei a usar o Bind9.9 ... O named.conf ainda é o mesmo, com a recursão ativa e a zona que estou usando não tem forwarders. No entanto, recebo o erro de que não há registro de cola para o NS, embora esteja lá ... é algo que o novo Bind não permitirá; ou seja, ter o NS no próprio subdomínio?

No antigo Bind eu estava usando o Red Hat, agora usando o CentOS7.

Aqui está o arquivo de zona:

$TTL 86400

rd2t9g9.redes.intranet. IN SOA  pc9-1-v1-9 root (

                                        42      ; serial
                                        3H      ; refresh
                                        15M     ; retry
                                        1W      ; expire
                                        1D )    ; minimum
                        IN NS pc9-1-v1-9

pc9-1-v1-9              IN A 192.168.99.11

pc9-1-v2-9              IN A 192.168.99.12

area1                   IN NS pc9-2-v2-9.area1

area1                   IN NS duplicate

duplicate               IN A 192.168.99.23

pc9-2-v2-9.area1        IN A 192.168.99.22

Ao executar o checkzone, recebo a mensagem

zone rd2t9g9.redes.intranet/IN: area1.rd2t9g9.redes.intranet/NS 'pc9-2-v2-9.area1.rd2t9g9.redes.intranet' (out of zone) has no addresses records (A or AAAA)
zone rd2t9g9.redes.intranet/IN: loaded serial 42
OK

O arquivo é exatamente o mesmo que ao executar o antigo Bind; ele funcionará se o NS estiver no domínio (ou seja, duplicado), mas não permitirá que eu tenha um NS no subdomínio (mas é usado para isso!)

Alguma idéia?

Também adicionará o arquivo named.conf:

options {

    listen-on port 53 { 127.0.0.1; };

    listen-on-v6 port 53 { ::1; };

    directory   "/var/named";

    dump-file   "/var/named/data/cache_dump.db";

    statistics-file "/var/named/data/named_stats.txt";

    memstatistics-file "/var/named/data/named_mem_stats.txt";

    allow-query     { localhost; };

    recursion yes;

    dnssec-enable no;
    dnssec-validation no;
    dnssec-lookaside auto;

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";

    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {

    type hint;

    file "named.ca";

};

zone "rd2t9g9.redes.intranet" IN {

    type master;

    file "zone_A";

    allow-update { none; };

    forwarders { };
};

zone "99.168.192.in-addr.arpa" IN {

    type master;

    file "rev_zone";

    allow-update { none; };

};


include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

    

Answer 1

Nada mudou em termos do que é permitido a esse respeito. Possivelmente named-checkzone tem mais validação, dependendo de qual versão mais antiga você está comparando, ou o ambiente onde você executa isso é configurado de forma diferente.

Como o nome para o qual esse NS record aponta não está dentro da zona que você está validando, named-checkzone está procurando o nome no DNS (usando o servidor de resolução configurado do sistema).

O pc9-2-v2-9.area1.rd2t9g9.redes.intranet tem um registro de endereço se você tentar procurá-lo no mesmo host em que você executa named-checkzone ?

Ou seja, dig pc9-2-v2-9.area1.rd2t9g9.redes.intranet A e / ou dig pc9-2-v2-9.area1.rd2t9g9.redes.intranet AAAA geram uma resposta positiva?
Caso contrário, a mensagem de aviso é esperada.

Se você, por qualquer motivo, não quiser que named-checkzone faça esse tipo de validação (provavelmente você faz isso, é um problema real se esses registros de endereços estiverem faltando no final autoritativo), há a -i option , que pode ser usado para especificar uma validação diferente modo (por exemplo, -i local ).

    

Answer 2

Você está tentando usar os elementos area1.rd2t9g9.redes.intranet dentro de rd2t9g9.redes.intranet.

Isso leva a named-checkzone de reclamações de que há elementos fora de zona, porque o servidor para o qual o subdomínio areas1.rd2t9g9.redes.intranet provavelmente ainda não existe e, como tal, named-checkzone não pode resolver os nomes. O aviso desaparecerá quando os subdomínios estiverem configurados corretamente.

A configuração como você deve funcionar - no entanto, como as versões posteriores do BIND são mais rigorosas, não posso garantir isso. Uma maneira de não ter o aviso seria remover o ". Area1" e configurá-lo para seus propósitos.

$TTL 86400
@                       IN SOA  pc9-1-v1-9 root.localhost. (
                                    42      ; serial
                                    3H      ; refresh
                                    15M     ; retry
                                    1W      ; expire
                                    1D )    ; minimum

                        IN NS pc9-1-v1-9

pc9-1-v1-9              IN A 192.168.99.11
pc9-1-v2-9              IN A 192.168.99.12
area1                   IN NS pc9-2-v2-9
area1                   IN NS duplicate
duplicate               IN A 192.168.99.23
pc9-2-v2-9              IN A 192.168.99.22

Eu também prefiro a abreviação @ em vez de anotar a zona mais uma vez, pois ela reduz erros ao lidar com várias zonas.

Eu também alterei a raiz em SOA da raiz para a raiz.localhost como o RFC especifica que é um email com um "." indo para "@". Você pode usar seu próprio email em vez de root @ localhost.

Lembre-se que o BIND 9.9 tem várias mudanças novas, e uma que provavelmente fará diferença nos laboratórios é que os novos arquivos escravos estão agora em formato raw / binário por motivos de desempenho. Se necessário para fins educacionais, o BIND 9.9 pode ser configurado para mantê-los em formato de texto.