Um subdomínio da Internet Um ponto de registro para IP interno e é uma boa prática também?

Question

Em breve, estaremos executando um trabalho em que queremos que os usuários se conectem a um servidor baseado na Internet, mas se conectem a um servidor local quando estiverem no site devido a lentidão nos links de rede. Seremos subcontratados no local e a infraestrutura será fornecida pelo cliente principal.

Gostaríamos que nosso aplicativo tentasse se conectar ao servidor local primeiro e, se ele falhar ou não conseguir encontrá-lo, tente o servidor global na Internet. Eu estava pensando em usar nosso registrador de domínio para criar um subdomínio de projeto para cada um dos servidores localproject.domain.com e project.domain.com, em oposição aos desenvolvedores terem que usar endereços IP brutos na configuração do aplicativo.

Estou feliz o suficiente para dar ao project.domain.com o IP público da Internet do servidor web, mas posso dar o localproject.domain.com e o endereço interno 192.168.x.x?

Quanto às melhores práticas, devo, em vez disso, pedir ao cliente para adicionar uma entrada de DNS para localproject.domain.com ao seu DNS baseado em LAN que estaremos pegando carona em vez de ter que fazer uma viagem aos servidores DNS baseados na Internet?

    

Answer 1

Você não seria o primeiro a ter registros DNS apontando para o espaço IP interno em um domínio público. Meu entendimento da questão é basicamente três questões:

1) Você está expondo de alguma forma o funcionamento interno da entidade. Você está entregando a alguém que deseja saber um nome de host e um endereço IP interno ao qual está vinculado, o que pode permitir que eles deduzam qualquer número de coisas sobre a estrutura interna da rede / configuração dessa empresa. Isso pode ser um risco mínimo ou mitigável.

2) Qualquer pessoa que tente ir para esse endereço tentará atingir o IP local, mesmo que não seja interno - um possível ponto de confusão tanto para usuários externos aleatórios quanto para usuários reais de clientes em sites remotos com configurações inválidas (sem VPN, não na rede corporativa, blá blá) que podem levar a uma carga de trabalho adicional de TI.

3) Alinhado com o # 2 - e se alguém tentar acessar 'local.domain.com' quando não estiver no site corporativo e o IP resolver para um IP válido na rede em que ele está ? E se for um servidor que faz coisas ruins? Um risco de segurança é introduzido, mas, novamente, existem maneiras de mitigar isso (como o aplicativo ter seus próprios mecanismos de autenticação e segurança para realizar coisas como essa).

Se as 3 questões acima não forem muito preocupantes ou você estiver disposto a trabalhar para atenuá-las, não acho que seja um caminho particularmente ruim. Ter o aplicativo tentar 'local.domain.com' primeiro e se ele não resolver ou falhar ao tentar conectar '.domain.com' parece ser uma maneira sadia de lidar com a idéia de que o aplicativo deve sair para o servidor público se o privado não funcionar.

    

Answer 2

As for best practice should I instead be asking the client to add a DNS entry for localproject.domain.com to their LAN based DNS that we will be piggybacking off rather than having to make a trip to the Internet based DNS servers?

Sim, definitivamente. Você não só evita os problemas apontados pelo Nex7, mas também facilita a depuração / alteração de endereços para o cliente (e permite escalonar: por exemplo, quando os clientes abrem um segundo site com redes locais diferentes, eles podem apenas adicionar um servidor local com o IP correto).