registrador de domínio de spam com vários registros de host, mesmo IP

1

Ontem, notei que um cliente (que tem conhecimento suficiente de redes para ser perigoso) tinha bagunçado um dos seus registros de servidor de nomes. Nós recentemente nos mudamos para um provedor de colocation diferente, e o ns2.his-domain.com estava apontando de volta para a rede no gabinete recentemente desocupado. Eu o instruí, "vá ao seu registrador, e mude o IP para o qual esse servidor de nomes aponta, porque até lá você tem apenas um servidor de nomes para todos os domínios dos seus clientes".

Devido a diferenças de fuso horário - ele mora na Europa e eu estou nos EUA - não pudemos conversar ao vivo.

Esta manhã, descobri que ele usou uma espingarda para resolver este problema. Ele não apenas alterou ns2.his-domain.com para apontar para o IP correto, como também criou mais registros de host - no nível de registrador, usando suas ferramentas da Web para criar servidores de nomes - para todos nome do host que ele já usou no passado, e alguns que ele pensou que poderia querer no futuro, todos apontando para o mesmo IP.

ns3.his-domain.com, ns4.his-domain.com, www.his-domain.com, ftp.his-domain.com, kirk.his-domain.com, spock.his-domain.com , scotty.his-domain.com, etc. - tudo isso agora pode ser consultado com o Whois, ignorando o nosso servidor de nomes local, bagunçando o espaço do nome da raiz. Ele criou cerca de vinte registros de host no registro de domínios, todos apontando para o mesmo IP exato.

Minha intuição é de que isso é muito, muito ruim. Ele derrota o design fundamental do DNS, que é supostamente hierárquico!

Quais são as conseqüências disso? Existe alguma coisa nos padrões - em RFCs ou em outro lugar - que proíba isso e descreve o que pode acontecer como resultado?

Exemplo (nome alterado para proteger o culpado:)

$ whois spock.his-domain.com

Whois Server Version 2.0

   Server Name: SPOCK.HIS-DOMAIN.COM
   IP Address: 22.33.44.55
   Registrar: COMPUTER SERVICES LANGENBACH GMBH DBA JOKER.COM
   Whois Server: whois.joker.com
   Referral URL: http://www.joker.com
    
por Matt Hucke 16.02.2010 / 16:11

2 respostas

4

Algumas coisas:

Eu não acho que isso seja muito, muito ruim do ponto de vista de que nada vai acontecer além do fato de que seu namespace não será resolvido de forma correta e consistente até que isso seja resolvido.

No que diz respeito à hierarquia, isso não mudou. Seu namespace e registros DNS ainda estão no mesmo nível da hierarquia. A criação de vários servidores de nomes não muda onde seu namespace está na hierarquia.

Os servidores de gTLDs não se importam com quantos servidores de nome ele possui. Eles vão procurar pelo NS no seu namespace e encaminhar solicitações de DNS para o seu namespace para qualquer servidor de nomes listado. Como os servidores de gTLDs não executam recursão, isso não sobrecarrega os usuários. Um cliente DNS (servidor DNS em nome de um cliente) perguntará ao servidor gTLD responsável pelo domínio gTLD relevante (.com, .edu, etc.) onde encontrar seu namespace e o servidor gTLD os encaminhará aos servidores de nomes. listado. O cliente DNS consultará um dos servidores de nomes listados.

Além de ter alguma resolução de nomes e falhas esquisitas, não vejo isso como um problema de quebra de terra. A correção é simplesmente entrar novamente no site de seu registrador e remover os registros errados.

    
por 16.02.2010 / 16:26
0

Até onde sei, nada nos padrões proíbe fazer o que ele fez, mas definitivamente não é "correto" - os registros criados no seu registrador só devem ser usados para cola NS, e incluir outros registros pode colocar uma carga excessiva nos servidores raiz.

Neste caso, acredito que os servidores de nível superior (.com) retornarão o registro A que possuem, em vez de referenciar a consulta ao servidor de nomes do seu cliente - isso certamente não é o que eles querem, portanto os registros errados devem ser removidos .

Se alguém puder apontar para um documento específico de RFC / STD que proíba ou deprecie esse comportamento, seria bom poder citar também: -)

    
por 16.02.2010 / 16:38