você está aqui: Home  → Colunistas  →  Sysadmin

Resolução de Problemas em Servidores DNS

Por Rubens Queiroz de Almeida

Data de Publicação: 03 de Junho de 2007

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.

Vejamos um exemplo de registro SOA:

  $TTL 604800
  $ORIGIN example.com.br.
  @ IN SOA example. dnsmaster.example.com.br. (
                    2004120101   ; Serial
                        604800   ; Refresh (7 days)
                         86400   ; Retry   (24 hours)
                       259200 0  ; Expire  (30 days)
                        604800 ) ; Neg TTL (7 days)

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

 

 

Veja a relação completa dos artigos desta coluna