Esta contribuição está participando do sorteio da Mochila Targus Matrix. Envie seu texto e participe você também, você contribui com outros usuários e ainda pode faturar uma mochila novinha em folha para o seu laptop. Saiba mais sobre como participar.
Sobre o Autor:
Evandro Guglielmeli
miware@mednet.com.br
DNS (Domain Name Service) é um sistema de base de dados distribuído que traduz nomes para endereços IP; os protocolos de rede usados na Internet permitem a comunicação entre computadores com base em um sistema de endereços na forma 192.168.0.1 (endereçamento IP versão 4), o DNS permite que um URL como www.uftm.edu.br, por exemplo, seja traduzido para o endereço 200.131.62.17.
Por norma do órgão que gerencia a Internet no Brasil, FAPESP, todos os domínios registrados no país devem ter configurados dois servidores DNS, um primário ou mestre, e um secundário ou escravo; ambos fornecendo a mesma informação de forma consistente.
Uma configuração split DNS serve para atender de modo diferenciado a diferentes segmentos de rede, podendo responder à consulta de um URL com endereços IP diferentes ou traduzindo diferentes conjuntos de nomes, conforme o segmento origem da consulta.
1- Configuração master + slave
Na configuração de um sistema DNS com 2 servidores, o servidor master é configurado normalmente, com os arquivos de definição de zonas do domínio, e acrescido de definições para transferência de dados para o servidor slave.
O servidor slave, por sua vez, é configurado quase que só por definições para transferência de dados do servidor master, nas próprias definições das zonas do domínio.
1.1- Seção options
A seção de opções no servidor master deve parecer:
// global options
options {
directory “/var/named”;
auth-nxdomain no;
allow-transfer { ip_ns_slave; };
transfer-format many-answers;
version “Not avaliable”;
};
onde as definições allow-transfer e transfer-format são responsáveis pela configuração da transferência de dados para o servidor slave.
Enquanto no servidor slave deve parecer:
// global options
options {
directory “/var/named”;
auth-nxdomain no;
version “Not avaliable”;
};
1.2- Seção server
A transferência incremental (envia apenas dados novos) entre os servidores é definida na seção server, que no servidor master tem a forma:
// the slave server definition
server ip_ns_slave {
provide-ixfr yes;
};
dizendo que “pode fazer transferência incremental para o servidor” slave, e no servidor slave tem a forma:
// the master server definition
server ip_ns_master {
request-ixfr yes;
};
dizendo que “pode solicitar transferência incremental ao servidor” master.
1.3- Declarações de zone
Ambos servidores declaram cada zona sob o domínio DNS, com a diferença que o servidor slave indica o servidor master como fonte das definições da zona; cada zona é declarada para conversão direta e reversa.
No servidor master uma zona é declarada na forma:
zone “nome.dominio” IN {
type master;
file “arquivo_zona”;
allow-update { none; };
};
zone “0.168.192.in-addr.arpa” IN {
type master;
file “arquivo_reverso”;
allow-update { none; };
};
Nota: A declaração allow-update é exclusiva de zonas master (não confundir com servidor master) e relaciona os endereços que podem atualizar os dados da zona; é usado para implementação de DNS dinâmico, o padrão é não permitir atualizações.
No servidor slave a mesma zona é declarada na forma:
zone “nome.dominio” IN {
type slave;
masters { ip_ns_master; };
file “arquivo_zona”;
};
zone “0.168.192.in-addr.arpa” IN {
type slave;
masters { ip_ns_master; };
file “arquivo_reverso”;
};
2- Configuração split DNS
Até a versão 8.x do BIND uma configuração “split DNS” era feita basicamente com múltiplos servidores, cada um respondendo por um mesmo domínio a segmentos de rede diferentes.
A partir da versão 9.0 foi incluída a declaração view, que permite definir várias “visões” de um domínio para atender a diferentes segmentos de rede.
Uma view inclui declarações de especificação do segmento que ela atende e de definição das zonas que ela abrange, ela também pode incluir muitas das declarações da seção options.
Um split DNS para atender dois segmentos (a rede interna e a Internet) tem declarações view na forma:
view “private” IN {
match-clients { ip_rede_interna; };
zone-statistics yes;
recursion yes;
# private view’s zones declarations
};
view “public” IN {
match-clients { !ip_rede_interna; any; };
zone-statistics yes;
recursion no;
# public view’s zones declarations
};
A declaração match-clients lista os segmentos de rede com acesso à view; o valor “any” indica clientes em qualquer segmento de rede, um sinal “!” inverte a condição de acesso (acesso negado) do segmento indicado.
A opção recursion determina se consultas recursivas (resolução de nomes em outros domínios) dos clientes são atendidas ou não na view, por segurança deve ser permitido apenas na view interna.
3- O problema das view no servidor slave
Normalmente os servidores master e slave de um domínio estão num mesmo segmento de rede, o da rede interna. Assim, quando o servidor slave solicita uma transferência de dados ao sevidor master, a view usada para resposta é sempre a que atende ao segmento interno e todas as views do slave resultam idênticas.
A solução proposta pelos desenvolvdores do BIND para este problema é forçar uma diferenciação no endereço IP do servidor slave para que o master possa selecionar a view correta na hora da transferência de zonas.
3.1- Declaração transfer-source
A declaração transfer-source é usada exclusivamente em zonas do tipo slave, ela especifica o endereço IP a ser usado nas operações de transferência de zonas.
Uma declaração na forma:
transfer-source ip_alias_ns_slave;
especifica que as transferências de zona usarão ip_alias_ns_slave como endereço do servidor slave. O endereço especificado na declaração transfer-source deve estar configurado como alias na interface de rede do servidor.
# ifconfig eth0:1 ip_alias_ns_slave
3.2- Ajustes das view para transferência de zonas
É preciso criar um “canal” de transferência de zonas para cada view definida no split DNS.
Supondo que nosso sistema DNS usa os endereços ip_ns_master e ip_ns_slave para os servidores master e slave, respectivamente, e usará o ip_alias_ns_slave como IP alias no servidor slave para transferência de zonas da view “private”.
3.2.1- Servidor master
No servidor master as declarações view devem:
- excluir o ip_ns_slave da lista de clientes da view “private”
- autorizar a transferência de zonas para o ip_alias_ns_slave na view “private”
- incluir o ip_ns_slave na lista de clientes da view “public”
- autorizar a transferência de zonas para o ip_ns_slave na view “public”
As declarações view no servidor master, então, tomam a forma:
view “private” IN {
match-clients { !ip_ns_slave;
ip_rede_interna; };
allow-transfer { ip_alias_ns_slave; };
zone-statistics yes;
recursion yes;
# private view’s zones declarations
};
view “public” IN {
match-clients { ip_ns_slave;
!ip_rede_interna;
any; };
allow-transfer { ip_ns_slave; };
zone-statistics yes;
recursion no;
# public view’s zones declarations
};
3.2.2- Servidor slave
No servidor slave as declarações view devem:
- declarar o uso do ip_alias_ns_slave nas transferências de zonas da view “private”
- opcionalmente, declarar o uso do ip_ns_slave nas transferências de zonas da view “public”
As declarações view no servidor master, então, tomam a forma:
view “private” IN {
match-clients { ip_rede_interna; };
transfer-source ip_alias_ns_slave;
zone-statistics yes;
recursion yes;
# private view’s zones declarations
};
view “public” IN {
match-clients { !ip_rede_interna; any; };
transfer-source ip_ns_slave;
zone-statistics yes;
recursion no;
# public view’s zones declarations
};
A publicação original deste texto pode ser conferida aqui: http://www.miware.com.br/~toko/splitdns.html
