O Registro SOA é o registro mais importante dentro do DNS. Ele sozinho consegue determinar grande parte das informações necessárias para a correta resolução de um domínio, seja internamente ou na internet. É a partir dele que se iniciam a maioria dos troubleshootings relacionados ao DNS. Neste artigo, vamos detalhar campo a campo e tentar reduzir a complexidade deste registro.
O acrônimo SOA significa Start Of Authority o que, traduzindo ao pé da letra, significa início de autoridade. Na linguagem técnica, o SOA mostra onde começa e onde termina a delegação de um domínio no DNS. O registro SOA é criado automaticamente durante a criação de uma zona de DNS no Infoblox. Num servidor Bind/Named, este é o primeiro registro que deve encabeçar o arquivo de configuração de uma zona. Naturalmente, cada zona deve ter seu próprio SOA.
Esta é a estrutura de um registro SOA
clienteabc.com.br. IN SOA ns1.clienteabc.com.br root.clienteabc.com.br. (
2114201 ; serial
28800 ; refresh (8 hours)
900 ; retry (15 minutes)
2419200 ; expire (4 weeks)
60 ; minimum (1 minute)
Este é basicamente o que encontramos na grande maioria dos domínios configurados no DNS.
Vamos começar pela primeira linha:
clienteabc.com.br.: Nome do domínio (zona). Essa informação é óbvia, mas note que no final de clienteabc.com.br existe um “.”. Este ponto simboliza o maior ponto na cadeia de resolução de nomes, o root, responsável por encaminhar consultas recebidas aos servidores do tipo TLD (Top Level Domain), como por exemplo o .com, .org ou .gov. Sua utilização é obrigatória
IN SOA ns1.clienteabc.com.br hostmaster.clienteabc.com.br.
IN diz para nós que a classe do registro declarado à seguir é do tipo Internet. SOA nos diz que o tipo do registro é do tipo SOA.
ns1.clienteabc.com.br.: Este campo é tão especial que até recebe um nome próprio: MNAME. Este campo identifica quem é o servidor primário da zona, também podendo ser interpretado como o servidor que contém os arquivos originais que dizem respeito à zona. Justamente por este motivo, somente neste servidor pode ser alterado o conteúdo deste domínio. Outro aspecto importante deste campo é sua utilização quando o DNS é dinâmico, muito comum em ambientes Microsoft, nos quais a estação de trabalho do usuário tenta, por padrão, atualizar o próprio registro (A e PTR) no DNS. Se o DNS Server utilizado pelo usuário não for o primário e este não estiver configurado para encaminhar atualizações dinâmicas ao servidor primário, esta operação falhará, causando impactos visíveis no ambiente.
hostmaster.clienteabc.com.br.: Não parece, mas isso é um endereço de e-mail. Este campo, também possui nome próprio (RNAME) e identifica o e-mail do responsável pela manutenção deste domínio. O primeiro ponto antes do nome do domínio deve interpretado como um “@”. Inclusive, manter o nome hostmaster é uma boa prática.
Para domínios que são divulgados na internet, por meio do Registro.br, por exemplo, é este e-mail que será utilizado caso exista algum problema de comunicação dos DNS Servers do Registro.br com os IPs dos servidores autoritativos por este domínio. Por isso, não basta configurar qualquer endereço de e-mail. DNS é coisa séria e deve ser tratado como tal.
2114201 ; serial:
Podemos entender o serial como sendo o número de versão da zona. Sempre que uma alteração é realizada na zona, devemos somar 1 à este número para que essas alterações sejam divulgadas aos servidores secundários, o que nos leva a um importante componente do DNS: Transferências de Zona. Vamos voltar aos primórdios para recordar que o DNS nada mais é que um grande banco de dados distribuído. O servidor primário possui o arquivo editável deste banco de dados (um para cada domínio pelo qual é autoritativo) e os outros servidores (secundários, porém também autoritativos) apenas uma cópia dele. Sempre que o serial muda (aumenta) o primário notifica os demais servidores de que há conteúdo novo num processo chamado Notify. Estes, por sua vez, devem fazer o esforço para comparar o serial que possui com o que existe no primário e obter (transferir) a cópia mais recente dos dados. Este processo de comparação e transferência é repetido sempre que há uma alteração no DNS, sempre que o tempo de refresh/retry da zona se esgote (veremos isto mais à frente) ou sempre que o serviço de DNS for reiniciado em um servidor.
Outro aspecto importante sobre este número diz respeito a como é definido pelos administradores. É comum o preenchimento deste campo com a última data de alteração no formato “20150621”. Neste exemplo, podemos inferir que a última modificação foi realizada dia 21 de junho de 2015. Se outra mudança foi realizada no dia 01 do mês de julho, este valor seria 20150701. Lendo este valor como um número inteiro temos 20.150.701, que é maior que 20.150.621, portanto, válido. Entretanto, o valor no campo serial é definido como um inteiro de 32 bits, não como um campo de data. Em outro exemplo, caso fosse necessário realizar a correção de um registro para o valor anterior ao de uma mudança executada com insucesso, por exemplo, não poderíamos colocar 20150621 como serial. Isso inutilizaria o conteúdo de toda a zona e os servidores slaves cujo primário é este servidor nunca transfeririam o conteúdo da zona por um motivo óbvio: o serial da zona configurada no servidor master é menor do que o que existe no slave. O servidor slave interpretaria isso como um “tenho a versão mais atual da zona, pois meu serial é maior” e isso é um grande erro de configuração, porém, bastante comum.
Plataformas como o Infoblox fazem o acréscimo automático (somando 1 ao valor existente) sempre que identificam alguma alteração em qualquer configuração da zona, fazendo esta notação de data perder o sentido, mas livrando o administrador de ter que lembrar toda vez que adicionar um registro de incrementar o serial da zona.
28800 ; refresh (8 hours)
900 ; retry (15 minutes)
2419200 ; expire (4 weeks)
60 ; minimum (1 minute)
Os campos acima determinam outras características relacionadas ao TTL de uma zona, em ordem:
- Refresh: Tempo (em segundos) que deve passar antes de um servidor slave checar se o conteúdo local da zona sofreu alteração, por meio de consulta ao serial da zona. Pode ser entendido também como parâmetro que define a recorrência entre uma atualização e outra do conteúdo local.
Voltando a falar de transferências de zona, durante a tentativa de refresh existem dois caminhos que o servidor pode seguir:
Caso o serial da zona local seja maior do que o configurado no servidor master:
- Se o valor local for zero, o cliente solicita uma transferência de zona do tipo AXFR (Transferência de Zona Completa)
- Se o valor for maior que zero, o cliente solicita uma transferência de zona do tipo IXFR (transferência de zona incremental), transferindo apenas os registros que foram alterados do serial existente até o mais recente.
Caso o serial da zona local seja igual ao configurado no servidor master
- O nameserver revalida o conteúdo da zona e inicia novamente a contagem do tempo de refresh, até que este se acabe e o processo se repita.
- Retry:Indica por quanto tempo (em segundos) o servidor deve aguardar para checar novamente o conteúdo da zona, caso a primeira tentativa de refresh falhe.
- Este valor geralmente é menor do que o tempo de refresh. Em um cenário de problema de comunicação entre slave e master, o servidor slave deve tentar executar o refresh com uma recorrência maior.
- Expire:Especifica o tempo (em segundos) em que os dados locais no nameserver secundário perdem a validade no caso de todas as tentativas de refresh falhem. Este servidor considera os dados locais expirados e simplemente para de fornecer resolução de nome para esta zona.
- Este campo é interpretado muitas vezes erroneamente como um problema no DNS. Na verdade, ele é um item que auxilia o DNS a se manter consistente. Sem a visibilidade do servidor master, o servidor slave não tem como garantir que os dados existentes em sua configuração são confiáveis. Parar de fornecer resolução de nome é na verdade, um mecanismo de controle do próprio DNS para evitar que clientes resolvam nomes antigos, inexistentes ou até mesmo falsos.
- Default TTL:Tempo máximo (em segundos) em que clientes ou outros nameservers podem manter os dados da zona em cache;
- O DNS é uma ferramenta que faz uso do cache em outros servidores para diminuir a carga sobre si mesmo e para propagar os dados configurados nos servidores autoritativos nos servidores slaves configurados e nos clientes, evitando que todo mundo tenha que acessar repetidas vezes o mesmo servidor para resolver um nome. Esta linha indica o TTL (Time-To-Live) padrão da zona, configurado para 60 segundos (ou 1 minuto). Isto significa que os registros desta zona (salvo quando não possuírem TTL diferente), poderão viver no cache de outras estações ou servidores por 1 minuto. Após este período, o registro sai do cache, forçando o cliente a efetuar uma nova consulta.
Este artigo buscou exibir uma visão geral e simples sobre todas as informações que existem no registro SOA de uma zona (e vimos que não são poucas), onde são aplicadas e como podem ser interpretadas. O Registro SOA, além de prover essas informações, mostra-nos como o nosso ambiente se porta em relação ao DNS. Entender esses comportamentos e fluxos é de suma importancia para garantir ambientes sempre operacionais e menos complexos. Até o próximo artigo.