O nome de domínio da minha organização é example.com . Os servidores de nomes da organização são denominados ns1.example.com e ns2.example.com .
Eu sou o administrador do subdomínio project.example.com . Nosso espaço de endereço IP é 10.0.0.0/22 (10.0.0.0 - 10.0.3.255) .
Eu tenho um nameserver primário e um nameserver secundário ( ns1.project.example.com (10.0.0.2) e ns2.project.example.com (10.0.1.2) , respectivamente).
Estes servidores de nomes são Bind 9.10.3 em execução no Debian 9.5.
Eu configurei estas zonas (para as quais sou autoritativo ou delegue autoridade:
Os servidores de nomes da minha organização encaminham (não delegam) consultas dentro do namespace project.example.com para os meus servidores de nomes.
Para consultas de nomes para os quais não sou autoritativo, não delegue, não encaminhe e não tenha cache, uso o modo "Somente encaminhamento" para encaminhar a consulta para ns1.example.com / ns2.example.com .
Eu dividi uma parte do meu namespace no subdomínio sub.project.example.com . O espaço de endereço IP para este subdomínio é 10.0.3.0/24 .
Existe apenas um servidor de nomes para sub.project.example.com . Seu nome de host é ns1.sub.project.example.com (10.0.3.2) .
Este servidor de nomes é Bind 9.9.4 em execução no CentOS 7.3.
Para pesquisas diretas em sub.project.example.com , eu delegue para ns1.sub.project.example.com (10.0.3.2) . Eu tenho o registro de cola necessário no lugar.
Para pesquisas reversas em 3.0.10.in-addr.arpa , eu encaminhar (não delegar) para ns1.sub.project.example.com (10.0.3.2) . Não posso delegar, pois não controlo 0.10.in-addr.arpa .
Existe um caso particular em que as coisas não estão funcionando. Este caso ocorre quando eu desligo meu servidor de nomes primário para testar o servidor de nomes secundário .
Suponha que eu abra um prompt de comando na minha máquina desktop do Windows, que é my-host.example.com . Não consigo consultar host-1.sub.project.example.com . O pedido expira.
Quando executo o tcpdump no servidor de nomes secundário ns2.project.example.com (10.0.1.2) , vejo a consulta chegando de ns1. example.com . No entanto, em vez de delegá-lo para ns1.sub.project.example.com , ele o encaminha de volta para ns1.example.com .
Para reescrever o parágrafo de abertura desta seção, a consulta será bem-sucedida se o meu primário servidor de nomes ns1.project.example.com (10.0.0.2) estiver em execução. Se o servidor de nomes primário estiver inativo e o servidor de nomes secundário ns2.project.example.com (10.0.1.2) for consultado, esse é o caso de falha.
Eu incluí meus arquivos de configuração abaixo.
Como posso resolver este problema?
; project.example.com
@ NS ns1
@ NS ns2
sub NS ns1.sub
; Forward 3.0.10.in-addr.arpa rather than delegate it
; We can't delegate since we don't own 0.10.in-addr.arpa.
; That's why the line below is commented out.
; 203.240.10.in-addr.arpa. NS centos-s1.ipa
; Glue record
ns1.sub A 10.0.3.2
controls {};
acl "internal-hosts" { 10.0.0/22; 127/8; };
acl "external-hosts" { 10/8; 192.168/16; 172.16/12; };
view "internal-view" {
match-clients { "internal-hosts"; };
zone "project.example.com" {
type master;
file "db.project.example.com_internalView";
forwarders { };
};
zone "0.0.10.in-addr.arpa" {
type master;
file "db.10.0.0";
forwarders { };
};
zone "1.0.10.in-addr.arpa" {
type master;
file "db.10.0.1";
forwarders { };
};
zone "2.0.10.in-addr.arpa" {
type master;
file "db.10.0.2";
forwarders { };
};
zone "3.0.10.in-addr.arpa" {
type forward;
forwarders { 10.0.3.2; };
};
// Internal-only zone
zone "31.172.in-addr.arpa" {
type master;
file "db.172.31";
forwarders { };
};
};
view "external-view" {
match-clients { "external-hosts"; };
zone "project.example.com" {
type master;
file "db.project.example.com_externalView";
forwarders { };
};
zone "0.0.10.in-addr.arpa" {
type master;
file "db.10.0.0";
forwarders { };
};
zone "1.0.10.in-addr.arpa" {
type master;
file "db.10.0.1";
forwarders { };
};
zone "2.0.10.in-addr.arpa" {
type master;
file "db.10.0.2";
forwarders { };
};
zone "3.0.10.in-addr.arpa" {
type forward;
forwarders { 10.0.3.2; };
};
};
controls {};
acl "internal-hosts" { 10.0.0/22; 127/8; };
acl "external-hosts" { 10/8; 192.168/16; 172.16/12; };
masters "my-master" { 10.0.0.2; };
view "internal-view" {
match-clients { "internal-hosts"; };
zone "project.example.com" {
type slave;
file "bak.project.example.com_internalView";
masters { my-master; };
forwarders { };
};
zone "0.0.10.in-addr.arpa" {
type slave;
file "bak.10.0.0";
masters { my-master; };
forwarders { };
};
zone "1.0.10.in-addr.arpa" {
type slave;
file "bak.10.0.1";
masters { my-master; };
forwarders { };
};
zone "2.0.10.in-addr.arpa" {
type slave;
file "bak.10.0.2";
masters { my-master; };
forwarders { };
};
zone "3.0.10.in-addr.arpa" {
type forward;
forwarders { 10.0.3.2; };
};
// Internal-only zone
zone "31.172.in-addr.arpa" {
type slave;
file "bak.172.31";
masters { my-master; };
forwarders { };
};
};
view "external-view" {
match-clients { "external-hosts"; };
zone "project.example.com" {
in-view "internal-view";
};
zone "0.0.10.in-addr.arpa" {
in-view "internal-view";
};
zone "1.0.10.in-addr.arpa" {
in-view "internal-view";
};
zone "2.0.10.in-addr.arpa" {
in-view "internal-view";
};
zone "3.0.10.in-addr.arpa" {
// in-view "internal-view";
type forward;
forwarders { 10.0.3.2; };
};
};