Estou trabalhando na criação de um novo site, incluindo nova infraestrutura e serviços. Eu tenho um servidor DNS Bind em execução no CentOS 7.3 e recentemente notei que as pesquisas recursivas de recursos externos estão falhando. Isso não acontece na nossa infraestrutura do Legacy.
Tanto o novo sistema de legado quanto o legado têm acesso à Internet. Eu sou capaz de rotear para recursos externos em ambos (8.8.8.8 por exemplo). Embora o ISP e a rota sejam diferentes.
Para tentar solucionar problemas e eliminar diferenças de configuração entre os servidores DNS novos / antigos, configurei duas novas VMs do CentOS 7. Um no antigo infra e um no novo infra. Eu usei a mesma imagem e método para construir ambos para que eles fossem o mesmo (menos hostname / ip) post build.
Instalei o Bind (Ver 9.9.4) e configurei-os como simples servidores DNS recursivos (sem configuração específica de zona ou de outra forma). Ambos possuem as configurações padrão do CentOS em:
/etc/named.conf
/ var / named /
As únicas alterações que fiz foram no /etc/named.conf:
- removido 'porta de escuta 53 {127.0.0.1; }; ' (isso faz com que escute na porta 53 em todos os dispositivos).
- definir a porta listen-on-v6 53 {nenhum; }; (Não escute no ipv6)
- definir allow-query {any; }; (permitir que qualquer host consulte)
Isso resulta em um /etc/named.conf padrão que se parece com:
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
options {
listen-on-v6 port 53 { none; };
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 { any; };
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-enable no;
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";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
Eu também configuro cada servidor para resolver ele mesmo, e somente ele, em /etc/resolv.conf.
Da minha perspectiva, isso deve eliminar todas as outras diferenças, exceto:
- hipervisor físico / servidor
- Colo / rede / ISP
Eu testei consultas DNS recursivas em ambos (para recursos como google.com, amazon.com, dropbox.com, etc.).
Assim como no ambiente de produção, no ambiente de teste, as consultas recursivas funcionam do antigo infra, mas não do novo. O dig + trace para o servidor no novo infra indica que ele não pode obter o endereço IP para a raiz NS:
dig @10.50.60.111 google.com +trace +additional
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> @10.50.60.111 google.com +trace +additional
; (1 server found)
;; global options: +cmd
. 518400 IN NS b.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS m.root-servers.net.
dig: couldn't get address for 'b.root-servers.net': no more
A resposta para isso deve ser atendida pelo próprio servidor de ligação local, pois estamos usando as dicas de raiz padrão empacotadas em /var/named/root.ca
Uma rápida olhada no log (/var/named/data/named.run) revelou que o servidor no novo infra parece estar desconsiderando essas respostas porque recebeu uma 'resposta insegura':
validating @0x7fc3c8055510: . NS: got insecure response; parent indicates it should be secure
error (insecurity proof failed) resolving './NS/IN': 198.41.0.4#53
Mas, o servidor na infra antiga não tem esse problema. Eu tentei desabilitar o dnssec (em /var/named.conf) e também passar + nodnssec para a escavação. Isso resulta em um passo adiante na recursão, mas ainda não conseguimos obter o NS para o com. domínio para o que parece ser o mesmo motivo. Embora, nesse caso, a resposta viesse dos servidores raiz.
Estou procurando a resposta e continuarei a fazer isso. Mas, eu não entendo quais fatores causariam esse erro em uma colo / rede e não o outro quando a configuração Server / BIND é a mesma. Se alguém tem alguma idéia do que causaria isso ou onde eu deveria procurar, eu adoraria ouvi-lo.
Em geral, estou tentando entender o seguinte:
Isso ainda poderia ser um simples erro de configuração?
Isso poderia ser causado pela configuração da rede local?
Preciso configurar algo do ISP ou do DNS externo para que isso funcione com os novos ISPs / IPs?