Propósito do registro SOA no DNS (além da transferência de zona)

Question

O registro SOA em um arquivo de zona DNS tem algum qualquer fim, além das transferências de arquivos de zona? Se um servidor DNS não depender da transferência de arquivo de zona para replicação (mas depender de algum banco de dados de back-end distribuído), existe algum motivo para ter um registro SOA? Olhando através de logs de consulta DNS, eu nunca vi um cliente solicitar um registro SOA.

Suponho que os campos "primary nameserver" e "admin" possam ser de alguma utilidade, mas geralmente o servidor de nomes primário é obtido através de um registro NS.

    

Answer 1

Sim, o registro SOA serve a um propósito independente disso. Embora o registro SOA não seja normalmente consultado diretamente por clientes regulares, ele é retornado em respostas negativas!

Se você analisasse as respostas do seu servidor de nomes em vez das consultas recebidas, acho que veria o SOA gravar muito mais.

No entanto, alguns dos campos do registro SOA não são mais relevantes se o método de transferência de zona que faz parte da especificação do DNS não for usado.

Se dermos uma olhada nos campos do registro SOA :

MNAME : nome do servidor de nomes principal. Usado no contexto de atualizações dinâmicas e, em alguns casos, como parte da implementação da transferência de zona.

RNAME : email de contato técnico. Não é realmente usado pelo sistema em si, mas sim informacional.

SERIAL : número de série da zona, usado para transferências de zona.

REFRESH : intervalo de atualização, usado para transferências de zona.

RETRY : intervalo de repetição, usado para transferências de zona.

EXPIRE : intervalo de expiração, usado para transferências de zona.

MINIMUM : costumava ser o TTL mínimo, mas atualmente é usado como TTL para respostas negativas.

Assim, podemos ver que MNAME , RNAME e MINIMUM não são específicos da especificação de transferência de zona.

Além disso, eu diria que a forma como as respostas negativas funcionam no DNS e o campo SOA MINIMUM em particular é a principal razão pela qual um registro SOA é necessário, independentemente de como a sincronização de zona é implementada. br> Por causa disso, você simplesmente não pode implementar um servidor de nomes autoritativo funcionando adequadamente sem ter SOA em cada zona.

    

Answer 2

Eu encontrei esta pergunta enquanto fazia uma pergunta semelhante: "Quais são as formas como um registro SOA é usado?"

Para adicionar respostas à resposta de Håkan Lindqvist aqui, eu diria:

• SOA significa "Início de autoridade". Isso é uma espécie de 'âncora' para saber qual servidor é autoritativo para qual zona. Se você se livrou do registro SOA, como você teria isso? Você pode ter muitos servidores nos registros NS, mas eles podem ser autoritativos para muitas (e diferentes) zonas. Se o seu serviço DNS vai funcionar, no mínimo, você deve ser capaz de saber o que um servidor vai funcionar - o que se diz ser autoritário para a zona no registro SOA.
• Minha ferramenta para DNS possui um banco de dados proprietário que é implantado em todos os servidores (executando o BIND) de tempos em tempos e é um equipamento independente dos servidores DNS reais. Isso fornece um nível de buffer de problemas no serviço de produção. (ou seja, posso atualizar o servidor proprietário sem afetar o serviço DNS.) Se essa máquina ficar inativa por um longo período de tempo, ainda haverá um conjunto de comportamentos de servidor DNS definidos no registro SOA para que o serviço continue (negativo cache, atualizar, repetir, etc.). Se o registro SOA não estiver lá, esse comportamento não será definido. De que outra forma você conheceria o comportamento? Você teria que defini-lo em outro lugar, e isso poderia estar em outro tipo de registro (definido em algum outro RFC) ou em algum documento proprietário oculto. Se você está indo para esse problema, por que reinventar a roda? Por que não usar o registro SOA?