Passei vários meses configurando o que eu considerava uma configuração eficiente e de práticas recomendadas para a infraestrutura de DNS da organização.
DNS1 - servidor principal que hospeda arquivos de zona internos e encaminha as consultas externas para NS1 / NS2
DNS2 - servidor escravo para DNS1 para os mesmos fins
NS1 - servidor DNS que hospeda os arquivos de zona da WAN e também realiza consultas recursivas passadas do DNS1 / 2 para clientes internos
NS2 - escravo para NS1 para os mesmos fins
Todos os quatro servidores DNS são máquinas virtuais do OpenBSD 5.4 no ambiente VMware.
Em circunstâncias normais, essa configuração funcionou muito bem nos últimos dois meses. No entanto, estamos vendo que, quando o DNS1 fica inativo (paralisação do servidor VM ou ESX), a capacidade de toda nossa organização de resolver IPs diminui.
Eu implementei essa solução inteira com a intenção de que nossos clientes resolvessem rapidamente o DNS2 se o DNS1 estivesse indisponível. Os clientes recebem ambos os IPs do DNS por meio do DHCP. Nesta interrupção em particular hoje, o DNS1 era pingável, acessível via SSH, escutando na porta 53 (netstat -an), mas o telnet para a porta 53 estava expirando na linha de comando do cliente (provavelmente devido a um problema de travamento do host ESX). No entanto, independentemente do que há de errado com o DNS1, eu diria que isso não afetaria o DNS2 do ponto de vista de resolução de consulta do cliente (o DNS2 estava em um host ESX diferente).
Por meio de pesquisa adicional , estou vendo que o Mac OS X (99% do nossos clientes internos) não tem uma ordem de servidor definida para a resolução IP - o que significa que escolherá o servidor DNS fornecido que desejar. Também estou vendo que o tempo limite para a resolução de DNS pode levar de 30 segundos a 15 minutos antes que o servidor DNS seja considerado "não qualificado".
Outro problema neste site parecia estar enfrentando problemas semelhantes de alguns anos atrás, mas nenhuma resolução foi fornecida.
Perguntas :
1) O "tempo de inatividade" dos nossos clientes é relatado devido a todos os que tentam usar o DNS1 primeiro e o tempo limite (o que eu achei que não aconteceria no Mac agora)? Por que eles não estão tentando consultar o DNS2?
2) Se eles estão tentando consultar o DNS2, por que ele não está respondendo a consultas diretas (mesmo usando dig) quando o meu servidor DNS mestre está indisponível (tanto quando é pingável como não pingável)?
2) Há algo que eu preciso configurar nos clientes Mac para garantir que eles possam consultar com êxito o segundo servidor DNS em tempo hábil quando o outro está inativo? (ex: opção de tempo limite )
Cabeçalho do arquivo de zona de amostra DNS1 / 2:
$TTL 10800
@ IN SOA dns1.myorganization.edu. admin.myorganization.edu. (
2014111301 ;Serial
3600 ;Refresh for secondary servers to check for updates
600 ;Retry wait time if secondary server update fails
604800 ;Expire
86400 ;Negative caching TTL
)
Eu também posso fornecer arquivos named.conf, se necessário.
Eu quero continuar pensando que uma configuração de DNS redundante é inteligente, mas se o servidor secundário recusar consultas toda vez que o DNS1 cair e esse for o comportamento esperado, parecerá sem sentido e apenas adicionará complexidade desnecessária. Toda e qualquer ajuda é apreciada!
// $OpenBSD: named-simple.conf,v 1.10 2009/11/02 21:12:56 jakob Exp $
//
// Example file for a simple named configuration, processing both
// recursive and authoritative queries using one cache.
// Update this list to include only the networks for which you want
// to execute recursive queries. The default setting allows all hosts
// on any IPv4 networks for which the system has an interface, and
// the IPv6 localhost address.
//
acl "internal" {
127/8; 10.0.0.0/8; 192.168.1.0/24;
};
options {
version "BIND"; // remove this to allow version queries
#listen-on { any; };
listen-on port 53 { 127.0.0.1; 10.10.250.35; };
listen-on-v6 { none; };
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";
#empty-zones-enable yes;
# This DNS server is responsible for fully answering the query
recursion yes;
allow-recursion { "internal"; };
allow-query { "internal"; };
# Forward all non-authoritative queries to external DNS servers (ns1/2)
forwarders { 10.10.250.36; 10.10.250.37; };
# Only forward these queries, don't attempt to find it yourself
forward only;
# Don't notify the other NS servers in the zone files of zone updates
notify no;
allow-transfer { none; };
max-cache-size 512M;
zone-statistics yes;
};
key dns1-dns2.myorganization.edu. {
algorithm hmac-md5;
secret "xBBxdjaocjbe33js99zsAG0s/+3g==";
};
# Master server IP
server 10.10.250.1 {
keys { dns1-dns2.myorganization.edu.; };
};
logging {
channel my_query_logging {
#file "log/queries.log";
syslog local6;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel my_security {
#file "log/security.log";
syslog local6;
severity notice;
print-time yes;
print-severity yes;
print-category yes;
};
channel my_default {
#file "log/messages.log";
syslog local6;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category queries { my_query_logging; };
category default { my_default; };
category security { my_security; };
category lame-servers { null; };
};
key "rndc-key" {
algorithm hmac-md5;
secret "PId3xd9Swlc7sniOSGntyDxw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; }
keys { "rndc-key"; };
};
// Standard zones
//
zone "." {
type hint;
file "etc/root.hint";
};
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "standard/loopback6.arpa";
allow-transfer { localhost; };
};
zone "myorganization.edu" IN {
type slave;
file "slave/db.myorganization.edu.zone";
masters { 10.10.250.1; };
forwarders { };
};
zone "250.10.10.in-addr.arpa" IN {
type slave;
file "slave/db.250.10.10.in-addr.arpa.zone";
masters { 10.10.250.1; };
forwarders { };
};
client-osx$ dig @10.10.250.35 server1.myorganization.edu
; <<>> DiG 9.8.5-P1 <<>> @10.10.250.35 server1.myorganization.edu
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ cat /etc/resolv.conf
lookup file bind
nameserver 127.0.0.1
nameserver 10.10.250.36 (NS1)
nameserver 10.10.250.37 (NS2)
Estou pensando que o DNS1 estava em um estado "na maioria, mas não totalmente completo" que pode ter afetado o DNS2 de alguma forma (mas como e por que é a verdadeira questão). Vou testar isso novamente desligando o DNS1 e certificando-se de que o DNS2 funcione conforme o esperado. Supondo que o DNS2 responda às consultas normalmente, isso me levará a descobrir como diminuir o tempo que um cliente Mac OS X leva para um segundo servidor DNS em sua configuração. Alguma sugestão sobre isso? Como explicado acima, modificar o arquivo resolv.conf seria a melhor abordagem com um opção de tempo limite ?
admin@dns2:~ $ route -nv show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface Label
default 10.10.250.254 UGS 2 469221 - 8 em0
10.10.250/24 link#1 UC 12 0 - 4 em0
10.10.250.1 (DNS1) 00:50:56:a2:01:fe UHLc 1 1658 - 4 em0
10.10.250.4 40:6c:8f:39:f6:81 UHLc 0 1617 - 4 em0
10.10.250.27 00:0c:29:84:9c:3d UHLc 0 16 - 4 em0
10.10.250.36 (NS1) 00:50:56:a2:09:06 UHLc 0 1480 - 4 em0
10.10.250.37 (NS2) 00:50:56:a2:41:7c UHLc 0 2591 - 4 em0
10.10.250.41 00:24:36:f4:83:84 UHLc 0 108 - 4 em0
10.10.250.46 3c:07:54:10:b2:ba UHLc 0 1 - 4 em0
10.10.250.48 00:50:56:a2:04:a6 UHLc 1 663 - 4 em0
10.10.250.49 00:50:56:a2:2d:fb UHLc 1 577 - 4 em0
10.10.250.60 00:50:56:a2:73:2e UHLc 0 45587 - 4 em0
10.10.250.253 00:17:c5:16:53:80 UHLc 0 0 - 4 em0
10.10.250.254 02:04:96:35:e1:8a UHLc 1 0 - 4 em0
127/8 127.0.0.1 UGRS 0 0 33192 8 lo0
127.0.0.1 127.0.0.1 UH 2 3599 33192 4 lo0
224/4 127.0.0.1 URS 0 0 33192 8 lo0
Tags domain-name-system