Verificando a validade dos registros de recursos em regiões DNS

Question

Estou usando o perl para fazer algumas tarefas de manipulação do DNS.

Estou usando NSD como meu servidor DNS.

Eu quero descobrir qual é a melhor maneira de verificar se os nomes de todos os Registros de Recursos em um arquivo de zona DNS são válidos.

Parece haver algumas possibilidades (que consigo pensar) para fazer a verificação:

1. nsd-checkzone
2. Um módulo Perl já feito link
3. Faça a verificação manualmente em perl, conhecendo todos os RFCs descrevendo o que é um nome válido e o que não é.

O principal problema, na minha opinião, surge quando nomes especiais de Registros de Recursos são questionados.

Por exemplo: vi on-line que há a possibilidade de usar um * como nome de um registro de recurso:

*                IN A      192.168.150.144

Isso supostamente significa retornar esse registro se nenhum outro registro corresponder.

Eu também vi alguns nomes "especiais" de Registros de Recursos (em zonas DNS reversas) como em esta RFC:

   192/26          NS      ns.C.domain.
   192/26          NS      some.other.third.name.server.
   0/25            NS      ns.A.domain.
   0/25            NS      some.other.name.server.

Eu também tenho uma pergunta adicional:

• Onde posso ver todos esses nomes especiais de Registros de recursos permitidos nas zonas DNS de encaminhamento e reversão e seu significado? (porque eu quero conhecer todos eles :))

Answer 1

Os arquivos de zona IMHO são um PITA para manipular como arquivos de texto ...

Para começar:

cada RR deve ser parecido com name ttl record_class record_type record_data BUT:

• name pode ser omitido e, em seguida, o registro herda o campo do registro anterior.
• ttl pode ser omitido e se tornará o valor de $TTL
• record_class geralmente também é omitido porque quase ninguém usa nada além do padrão IN

E isso é apenas o começo de seus problemas.

Especialmente se as suas zonas foram mantidas à mão, pode ser difícil distinguir entre a estampagem e os truques realmente complicados do comércio, o que pode tornar as entradas (ainda mais) dependentes do contexto. Suas dificuldades de análise podem ser ainda mais agravadas quando, por exemplo, $ -diretivas entram em jogo.

Depois, há também a diferença entre um arquivo de zona com uma sintaxe válida confirmada com os registros de recursos nsd-checkzone ou named-checkzone e que são semanticamente válidos e funcionam como pretendido .

Um exemplo bastante típico é um registro CNAME na zona example.com

www IN CNAME www.example.net

que é válido, mas como não há ponto final em www.example.net , isso não é um FQDN e a abreviação do arquivo de zona. O valor de $ ORIGIN será anexado e, por padrão, será:

www IN CNAME www.example.net.example.com.

Isso não é sempre o caso embora.
Em vez de usar um valor implícito de $ ORIGIN, ou seguir a convenção e definir explicitamente $ ORIGIN para o nome da zona, as pessoas às vezes explicitamente definem $ ORIGIN para apenas um . dot .

Novamente, o exemplo de um registro CNAME na zona example.com

$ORIGIN .

www IN CNAME www.example.net

Então, quando o valor de $ ORIGIN será anexado, isso se torna:

www IN CNAME www.example.net.

Este Q & A é um exemplo de onde a localização do registro MX resultou em uma sintaxe válida, mas quebrou o e-mail. mail.

Esta minha resposta é um exemplo de uma má ideia, mas uma sintaxe válida em que o contexto de um registro de recurso depende na posição exata dentro de um arquivo de zona e o efeito de taquigrafia será alterado devido ao uso / abuso repetido do $ ORIGIN $ -diretivo.