Esta manhã, descobrimos que (devido a uma mudança) um dos nossos registros de DNS para um serviço importante está errado. Ele foi alterado em nosso servidor DNS primário, mas os clientes em sites secundários não vêem a alteração. (Nossa rede está funcionando quase inteiramente com os clientes OS X 10.5 e OS X 10.5).
Deixe-me nomear algumas máquinas para fins de exemplo:
No cliente, (que faz pesquisas de DNS através do secundário), ao verificar como as coisas estão configuradas, eu recebo:
nslookup service.ourdomain.com
** server can't find service.ourdomain.com: NXDOMAIN
nslookup service.ourdomain.com secondary
** server can't find service.ourdomain.com: NXDOMAIN
nslookup service.ourdomain.com primary
(returns appropriate information about how to contact the service)
Quando eu ssh em
Eu recebo:
nslookup service.ourdomain.com
(returns appropriate information about how to contact the service)
nslookup service.ourdomain.com secondary
** server can't find service.ourdomain.com: NXDOMAIN
nslookup service.ourdomain.com primary
(returns appropriate information about how to contact the service)
Eu tentei liberar o DNS no secundário e no cliente. (%código%). Eu também parei e reiniciei o DNS no secundário. ( dscacheutil -flushcache e sudo serveradmin stop dns )
Em nosso site principal, meu colega de trabalho reinicializou a primária e um cliente lá para que o nome fosse resolvido corretamente. Infelizmente, temos 14 sites secundários e preferimos não reinicializar os servidores, que estão compartilhando arquivos, durante o dia, se possível, mas faremos isso se resolver o problema.
por pedido:
host -C ourdomain.com # [with names substituted]:
ourdomain.com SOA record primary.ourdomain.com. admin.ourdomain.com. 2009121410 21600 3600 604800 345600
[Não tenho ideia do que é admin.ourdomain.com - não creio que tenhamos uma caixa com esse nome; Eu com certeza não posso fazer ping. O servidor DNS primário é exibido corretamente.]
Também por solicitação, aqui está a saída de sudo serveradmin start dns (com substituições de nome):
; <<>> DiG 9.4.3-P1 <<>> service.ourdomain.com @secondary
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19207
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;service.ourdomain.com. IN A
;; AUTHORITY SECTION:
ourdomain.com. 10800 IN SOA primary.ourdomain.com. admin.ourdomain.com. 2009121409 21600 3600 604800 345600
;; Query time: 3 msec
;; SERVER: [IP of secondary]#53([IP of secondary])
;; WHEN: Mon Dec 14 10:34:11 2009
;; MSG SIZE rcvd: 88
E a saída de dig service.ourdomain.com @secondary :
; <<>> DiG 9.4.3-P1 <<>> service.ourdomain.com @primary
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47885
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;service.ourdomain.com. IN A
;; ANSWER SECTION:
service.ourdomain.com. 10800 IN A [IP of service]
;; AUTHORITY SECTION:
ourdomain.com. 10800 IN NS primary.ourdomain.com.
;; ADDITIONAL SECTION:
primary.ourdomain.com. 10800 IN A [IP of primary]
;; Query time: 8 msec
;; SERVER: [IP of primary]#53([IP of primary])
;; WHEN: Mon Dec 14 10:34:18 2009
;; MSG SIZE rcvd: 92
As diferenças mais marcantes são que o secundário não respondeu com uma resposta, e que o primário disse: ";; AVISO: recursão solicitada mas não disponível".
Você pode forçar manualmente uma transferência de zona usando o utilitário rndc . Execute este comando em todos os seus servidores DNS secundários:
rndc -p 54 retransfer mydomain.example.com IN com.apple.ServerAdmin.DNS.public
Você também pode usar esse utilitário para recarregar sua configuração sem reiniciar nomeado .
rndc -p 54 reload
Sem saber sua configuração, eu acho que isso é um problema de cache ou um problema de propagação de DNS.
Sem conhecer seu domínio, não posso testá-lo aqui. Eu pessoalmente não entendo por que as pessoas omitem esse tipo de informação relevante, mas elas geralmente fazem isso.
Tente "host-yourdomain.com" e diga-me o que você vê. Se você vir diferentes registros SOA com diferentes números de série, precisará corrigir a propagação do DNS. Se o secundário não estiver listado nos registros NS para esta zona, adicione uma linha "também notificar" se estiver executando o BIND.
Tente alterar o número de série no mestre para garantir que ele foi alterado corretamente, bem como para testar a propagação.
Tente definir um tempo de cache negativo melhor que seja muito menor, digamos 600 (10 minutos) ou mais. Este é um dos valores no registro SOA.
Tente um "dig hostname.yourdomain.com @secondaryserver" e veja o que ele retorna. Faça o mesmo no primário. Se eles diferem, isso é o quebrantamento.
Se cada um desses sites que estão retornando dados inválidos tiver um tempo de cache enorme, você poderá ssh para eles e simplesmente reiniciar o servidor de nomes, não reinicializar cada site completamente. O BIND irá reiniciar rapidamente se estiver em uso.
Seu servidor secundário está tentando responder de forma recursiva ( RD - recursão desejada, RA - recursão disponível) mas com falha ( NXDOMAIN ) enquanto, ao mesmo tempo, atende também o registro SOA com autoridade ( AA - resposta oficial).
Você parece ter uma mistura um pouco estranha aqui ... precisamos estabelecer como o seu servidor secundário sabe sobre a zona (o registro SOA ), mas não sabe sobre o registro dentro da zona.
Eu ficaria com a recomendação de Michael - aumente o número de série no mestre e reinicie o BIND no secundário para garantir que o cache esteja limpo.