Resposta errada de DNS com CNAME e A Record ao mesmo tempo

Question

Tivemos um cliente que definiu um registro CNAME para o domínio dele. De alguma forma ele conseguiu definir um registro A também, o que não deveria ser possível e é proibido pelo DNS. Mas o resultado foi:

$ dig @ns1.your-server.de tippspiel-bl1.unternehmen-frische.de 
...
;; ANSWER SECTION:
tippspiel-bl1.unternehmen-frische.de. 7200 IN CNAME www.kicktipp.de.
tippspiel-bl1.unternehmen-frische.de. 7200 IN A 78.46.10.156

O segundo registro é ilegal. Mas isso levou a alguma confusão de outro servidor DNS em cache que retornou 78.46.10.156 quando foi perguntado sobre www.kicktipp.de . Mas isso é completamente errado.

O outro servidor DNS usou as duas respostas e as misturou. Resultado final: os usuários que visitaram o site www.kicktipp.de foram enviados para 78.46.10.156 , que é o IP de unternehmen-frische.de

Parece que eu posso invadir um domínio ao configurar o DNS para um domínio com um CNAME e um registro A. Isto é um erro conhecido? Como posso proteger meu domínio contra isso?

    

Answer 1

Para abordar especificamente sua (s) pergunta (s):

• Não, esse não é um problema frequentemente vivenciado. Dito isso, o envenenamento acontece , mas geralmente depende de respostas falsificadas e não de um registro A que vive ao lado de CNAME . O DNSSEC foi projetado com os ataques de envenenamento em mente.
• Se o DNSSEC fosse implementado aqui, seria claro para validar os resolvedores que o registro A não foi assinado por você. Não há mais nada que você possa fazer dentro de sua própria zona que possa ter influenciado esse problema.

Como você não tem informações adicionais, você precisará levar o assunto ao seu ISP. O padrão mais aplicável para a definição de RFC é RFC2181 , pois é menos ambíguo do que RFC1034 sobre o assunto de CNAMEs coexistindo com outros dados. (RFC1034 franze a testa, RFC2181 proíbe a menos que os registros sejam relacionados ao DNSSEC)

Tudo isso dito, eu sou um pouco cético quanto ao problema ser exatamente como você descreveu. Seria um erro muito complicado, pois tippspiel-bl1.unternehmen-frische.de. IN A causaria uma colisão em www.kicktipp.de. IN A .

    

Answer 2

Há uma verificação personalizada que você pode ativar para proteger essas coisas se estiver gerenciando seu servidor DNS por conta própria. Por favor, leia o ponto abaixo que é obtido diretamente do RFC. Isso é apenas um erro humano e pode ser evitado usando algum script ou checagem antes de recarregar a configuração da zona.

Registros CNAME

A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record. Especially do not try to combine CNAMEs and NS records like this!:

   podunk.xx.      IN      NS      ns1
                   IN      NS      ns2
                   IN      CNAME   mary
   mary            IN      A       1.2.3.4

This is often attempted by inexperienced administrators as an obvious way to allow your domain name to also be a host. However, DNS servers like BIND will see the CNAME and refuse to add any other resources for that name. Since no other records are allowed to coexist with a CNAME, the NS entries are ignored.

Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged:

       podunk.xx.      IN      MX      mailhost
       mailhost        IN      CNAME   mary
       mary            IN      A       1.2.3.4

[RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer. If you really want to do this, you can accomplish the same thing by using a preprocessor such as m4 on your host files.

Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result some hosts may not be able to resolve such names.

Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation. There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records. Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.