Existem alguns erros clássicos, que a maioria dos administradores cometem ao configurar seus serviços DNS. Este capítulo aborda estes erros com o objetivo de impedir que o administrador de sistema gaste diversas horas, ou mesmo dias, procurando a solução para problemas amplamente conhecidos e de fácil resolução.
1. Problemas mais comuns
1.1. Registro SOA
O registro SOA (Start of Authority) contém informações importantes que regulam a forma como o servidor DNS interage com seus clientes e com servidores secundários.
Como em muitas situações os arquivos de configuração do DNS são simplesmente copiados de outras fontes, raramente um administrador avalia a adequação dos valores contidos no registro SOA.
Como podemos ver do exemplo acima, o registro SOA especifica cinco valores numéricos:
Número serial: indica a versão do mapa que está sendo usado e será discutido no item X, a seguir.
Refresh (atualização): este valor indica o intervalo de tempo que os servidores secundários devem obedecer para contactar os servidores primários dos domínios que servem para verificar se houveram atualizações ou acréscimos nos dados da zona. Caso tenha ocorrido uma mudança, os dados são então transferidos do servidor primário para os servidores secundários. Em nosso exemplo as sincronizações se darão a cada 604800 segundos (7 dias).
Retry (novas tentativas): caso tenha ocorrido uma falha em uma das tentativas de conexão com o servidor primário, o servidor secundário deve aguardar um período de tempo, especificado nesta diretiva, antes de tentar uma nova conexão. Em nosso exemplo as novas tentativas se darão após 86400 segundos (24 horas).
Expire (expiração): este valor indica depois de quanto tempo os servidores secundários devem desistir de tentar uma sincronização com o servidor primário. Não apenas isto, mas depois do tempo especificado, os servidores secundários removem de seus sistemas todas as informações relativas ao domínio em questão e param de responder consultas sobre estes dados. Em nosso exemplo isto se dará após 2592000 segundos (30 dias).
Negative Cache TTL: o cache negativo armazena informações sobre recursos que não existem. O comportamento padrão para diversas versões do Bind era o armazenamento em cache de informações sobre recursos existentes. Da mesma forma que o cache de informações válidas reduz o tráfego e consequentemente a carga sobre servidores DNS, a implementação do cache negativo, ou seja, de informações inválidas, contribui de forma significativa para a redução da carga sobre servidores DNS. O TTL (Time to Live) especificado, de 6048000 segundos (7 dias), instrui os servidores DNS clientes a armazenarem por sete dias informações sobre recursos não existentes do domínio em questão.
Na primeira linha temos o valor $TTL 604800. Este valor indica o prazo de validade de cada registro obtido pelos servidores que realizam consultas a informações do domínio example.com.br. Este valor se aplica a todos os registros do arquivo, ou seja é o valor padrão (default), a não ser que outro valor seja especificado. Isto significa que após 604800 segundos, ou sete dias, todos os servidores DNS que possuirem informações sobre este domínio terão que descartá-las. Novas consultas relativas ao domínio example.com.br terão que ser novamente encaminhadas ao servidor DNS deste domínio, o que representa uma carga adicional nos servidores e também consumo de banda de rede.
Pela explicação acima podemos ver que valores incorretamente configurados podem representar um consumo desnecessário de recursos computacionais e de rede. O correto é que estes valores sejam analisados caso a caso e que registros mais estáveis tenham um valor mais alto, proporcionando uma vida maior no cache dos servidores que solicitarem informações.
Da mesma forma, registros que são alterados com frequência devem ter valores menores de forma a facilitar a propagação das alterações. Em nosso exemplo o prazo de validade padrão (TTL) é de 7 dias, que é um valor totalmente impróprio para representar informações que são alteradas diariamente. Valores altos como acima podem também acarretar problemas em casos de mudanças de domínio. Clientes que desejam mudar seus provedores web podem solicitar que no período de transição estes valores sejam menores, algo como um dia ou menos, de forma a facilitar a propagação da informação correta assim que o novo provedor web esteja configurado.
Estas recomendações, embora importantes para um melhor funcionamento de seu servidor DNS, não acarretam na indisponibilidade do serviço, no máximo o que ocorre são situações estranhas, como a demora para a propagação de alterações realizadas. example.com.br
Entretanto, ainda no âmbito do registro SOA, existe algo que a maioria dos administradores se esquece de fazer ao alterar
1.2. Alterações não entram em vigor
Falta alterar o número de série do arquivo.
1.3. Consultas não funcionam
Checar se servidor está funcionando.{br}
Checar logs.{br}
1.4. Nomes retornados possuem duas vezes o domínio
Falta "." na configuração.
1.5. RNDC
Checar MD5 do arquivo named.conf e rndc.conf
1.6. Não funciona fora do servidor
Verificar diretiva listen.
Verificar logs.
1.7. Lame server
Verificar autoridade do servidor.
1.8. Não é feita a transferência de zonas para os secundários
Verificar autorização de quem pode realizar este tipo de transferência
1.9. Resolução reversa de nomes não funciona
Verificar cadastro do mapa reverso.
2. Referências
RFC 2308 - Negative Caching of DNS Queries, Março 1998
RFC 1537 - Common DNS Data File Configuration Errors, Outubro 1993
Gostei do artigo, embora meu erro DNS ainda não esteja resolvido, alguem que saiba um pouco de DNS por favor me contate por e-mail dogao852@hotmail.com com urgência, meu problema é o seguinte, meus navegadores IE, CHROME e Firefox estão funcionando normalmente, mas meus programas que não fazem pré busca de DNS pararam depois que eu troquei o IP usando o 'Renovar-Ip-Virtua', eu uso duas partições do Windows 7 e esse erro só havia afetado uma de minhas partições, até que eu usei o programa na outra também (para ter certeza de que foi ele que causou o defeito), por favor bem rápido pq esse problema já está em meu computador faz três dias.
Luana
05 Mai 2010, 22:22
Super me esclareceu esse artigo... rápido e direto.
:DDD
Flavio Barbosa
07 Dez 2009, 23:34
A correção da concordância verbal é válida. Porém inapropriada, tendo em vista que a finalidade do amigo é ajudar (e como ajudou !) com as informações aqui prestadas.
Ao responsável pela página, os meus PARABÉNS !
Att,
Dr Samuel
09 Jun 2007, 19:40
Muito bom, essas dicas podem nos salvar horas de dor de cabeça :)
Socorro Lingua Portuguesa
05 Jun 2007, 08:48
Cuidado para não derrapar no português (não o da padaria, por favor). :-)
"Refresh: [snip] servem para verificar se houveram atualizações" -> verificar se houve atualizações. Verbo haver, sentido de existir, sempre singular. Lembram do ginásio (não o de esportes, por favor)?
Renato Rudnicki
04 Jun 2007, 08:48
Excelente artigo ! Muitas vezes nós nos preocupamos em escrever artigos para falar de uma nova tecnologia, ou uma meneira mais efetiva de fazer uma tarefa. Muitas vezes, nos esquecemos de antes de tentar ensinar ou aprender algo novo, é de tentar resolver os problemas e dúvidas que temos.
Existem alguns erros clássicos, que a maioria dos administradores cometem ao configurar seus serviços DNS. Este capítulo aborda estes erros com o objetivo de impedir que o administrador de sistema gaste diversas horas, ou mesmo dias, procurando a solução para problemas amplamente conhecidos e de fácil resolução.
1. Problemas mais comuns
1.1. Registro SOA
O registro SOA (Start of Authority) contém informações importantes que regulam a forma como o servidor DNS interage com seus clientes e com servidores secundários.
Como em muitas situações os arquivos de configuração do DNS são simplesmente copiados de outras fontes, raramente um administrador avalia a adequação dos valores contidos no registro SOA.
Como podemos ver do exemplo acima, o registro SOA especifica cinco valores numéricos:
Número serial: indica a versão do mapa que está sendo usado e será discutido no item X, a seguir.
Refresh (atualização): este valor indica o intervalo de tempo que os servidores secundários devem obedecer para contactar os servidores primários dos domínios que servem para verificar se houveram atualizações ou acréscimos nos dados da zona. Caso tenha ocorrido uma mudança, os dados são então transferidos do servidor primário para os servidores secundários. Em nosso exemplo as sincronizações se darão a cada 604800 segundos (7 dias).
Retry (novas tentativas): caso tenha ocorrido uma falha em uma das tentativas de conexão com o servidor primário, o servidor secundário deve aguardar um período de tempo, especificado nesta diretiva, antes de tentar uma nova conexão. Em nosso exemplo as novas tentativas se darão após 86400 segundos (24 horas).
Expire (expiração): este valor indica depois de quanto tempo os servidores secundários devem desistir de tentar uma sincronização com o servidor primário. Não apenas isto, mas depois do tempo especificado, os servidores secundários removem de seus sistemas todas as informações relativas ao domínio em questão e param de responder consultas sobre estes dados. Em nosso exemplo isto se dará após 2592000 segundos (30 dias).
Negative Cache TTL: o cache negativo armazena informações sobre recursos que não existem. O comportamento padrão para diversas versões do Bind era o armazenamento em cache de informações sobre recursos existentes. Da mesma forma que o cache de informações válidas reduz o tráfego e consequentemente a carga sobre servidores DNS, a implementação do cache negativo, ou seja, de informações inválidas, contribui de forma significativa para a redução da carga sobre servidores DNS. O TTL (Time to Live) especificado, de 6048000 segundos (7 dias), instrui os servidores DNS clientes a armazenarem por sete dias informações sobre recursos não existentes do domínio em questão.
Na primeira linha temos o valor $TTL 604800. Este valor indica o prazo de validade de cada registro obtido pelos servidores que realizam consultas a informações do domínio example.com.br. Este valor se aplica a todos os registros do arquivo, ou seja é o valor padrão (default), a não ser que outro valor seja especificado. Isto significa que após 604800 segundos, ou sete dias, todos os servidores DNS que possuirem informações sobre este domínio terão que descartá-las. Novas consultas relativas ao domínio example.com.br terão que ser novamente encaminhadas ao servidor DNS deste domínio, o que representa uma carga adicional nos servidores e também consumo de banda de rede.
Pela explicação acima podemos ver que valores incorretamente configurados podem representar um consumo desnecessário de recursos computacionais e de rede. O correto é que estes valores sejam analisados caso a caso e que registros mais estáveis tenham um valor mais alto, proporcionando uma vida maior no cache dos servidores que solicitarem informações.
Da mesma forma, registros que são alterados com frequência devem ter valores menores de forma a facilitar a propagação das alterações. Em nosso exemplo o prazo de validade padrão (TTL) é de 7 dias, que é um valor totalmente impróprio para representar informações que são alteradas diariamente. Valores altos como acima podem também acarretar problemas em casos de mudanças de domínio. Clientes que desejam mudar seus provedores web podem solicitar que no período de transição estes valores sejam menores, algo como um dia ou menos, de forma a facilitar a propagação da informação correta assim que o novo provedor web esteja configurado.
Estas recomendações, embora importantes para um melhor funcionamento de seu servidor DNS, não acarretam na indisponibilidade do serviço, no máximo o que ocorre são situações estranhas, como a demora para a propagação de alterações realizadas. example.com.br
Entretanto, ainda no âmbito do registro SOA, existe algo que a maioria dos administradores se esquece de fazer ao alterar
1.2. Alterações não entram em vigor
Falta alterar o número de série do arquivo.
1.3. Consultas não funcionam
Checar se servidor está funcionando.{br}
Checar logs.{br}
1.4. Nomes retornados possuem duas vezes o domínio
Falta "." na configuração.
1.5. RNDC
Checar MD5 do arquivo named.conf e rndc.conf
1.6. Não funciona fora do servidor
Verificar diretiva listen.
Verificar logs.
1.7. Lame server
Verificar autoridade do servidor.
1.8. Não é feita a transferência de zonas para os secundários
Verificar autorização de quem pode realizar este tipo de transferência
1.9. Resolução reversa de nomes não funciona
Verificar cadastro do mapa reverso.
2. Referências
RFC 2308 - Negative Caching of DNS Queries, Março 1998
RFC 1537 - Common DNS Data File Configuration Errors, Outubro 1993
Gostei do artigo, embora meu erro DNS ainda não esteja resolvido, alguem que saiba um pouco de DNS por favor me contate por e-mail dogao852@hotmail.com com urgência, meu problema é o seguinte, meus navegadores IE, CHROME e Firefox estão funcionando normalmente, mas meus programas que não fazem pré busca de DNS pararam depois que eu troquei o IP usando o 'Renovar-Ip-Virtua', eu uso duas partições do Windows 7 e esse erro só havia afetado uma de minhas partições, até que eu usei o programa na outra também (para ter certeza de que foi ele que causou o defeito), por favor bem rápido pq esse problema já está em meu computador faz três dias.
Luana
05 Mai 2010, 22:22
Super me esclareceu esse artigo... rápido e direto.
:DDD
Flavio Barbosa
07 Dez 2009, 23:34
A correção da concordância verbal é válida. Porém inapropriada, tendo em vista que a finalidade do amigo é ajudar (e como ajudou !) com as informações aqui prestadas.
Ao responsável pela página, os meus PARABÉNS !
Att,
Dr Samuel
09 Jun 2007, 19:40
Muito bom, essas dicas podem nos salvar horas de dor de cabeça :)
Socorro Lingua Portuguesa
05 Jun 2007, 08:48
Cuidado para não derrapar no português (não o da padaria, por favor). :-)
"Refresh: [snip] servem para verificar se houveram atualizações" -> verificar se houve atualizações. Verbo haver, sentido de existir, sempre singular. Lembram do ginásio (não o de esportes, por favor)?
Renato Rudnicki
04 Jun 2007, 08:48
Excelente artigo ! Muitas vezes nós nos preocupamos em escrever artigos para falar de uma nova tecnologia, ou uma meneira mais efetiva de fazer uma tarefa. Muitas vezes, nos esquecemos de antes de tentar ensinar ou aprender algo novo, é de tentar resolver os problemas e dúvidas que temos.
