Nosso pequeno escritório deve ter servidores DNS internos?


9

Eu administro um pequeno escritório (<50 pessoas). Sempre tivemos servidores DNS internos no escritório. Os servidores DNS são bem diretos, mas tivemos problemas com eles no passado. Temos alguns recursos de escritório que estão disponíveis apenas no escritório ou externamente através de VPN e também temos alguns recursos de escritório com endereço e registro públicos. Atualmente, esses recursos têm o mesmo nome DNS, embora isso não seja necessariamente um requisito, e há muito menos deles do que costumava existir.

Também já possuímos o espaço de nomes do escritório interno, portanto, é possível que eu possa preencher meu DNS público com todos os endereços IP privados dos recursos internos do escritório que temos e parar de usar o DNS interno completamente.

isso é uma boa ideia? Eu nunca trabalhei em um local que não possui DNS interno do escritório. Quais são algumas das razões pelas quais ainda devemos mantê-lo? Era uma vez crítico, agora ainda é conveniente, mas os problemas que encontramos não fazem mais com que pareça conveniente.

Razões atuais para manter:

  • O DNS dividido nos permite usar o mesmo nome de host para os recursos hospedados internamente, mas também disponíveis externamente
  • Temos alguns domínios de teste que não precisávamos comprar, mas precisávamos se nos livrarmos deles
  • ??? é familiar e reconfortante?

Razões para se livrar dele:

  • No momento, não há suporte para IPv6
  • Houve vários problemas com o DNS sendo dividido, principalmente com a configuração da VPN
  • Manutenção em um servidor que pode ser desnecessário

Eu acho que você deve levar em consideração outras coisas também, como o número de servidores que você possui e a estabilidade da conexão à Internet. se você confia em um servidor DNS externo, o que acontece se você perder sua conectividade com a Internet por um longo tempo? (quando não houver mais informações em cache), significa que ninguém de seus servidores também poderá se comunicar juntos e, portanto, todos os serviços estarão inoperantes. é um bônus ter um servidor DNS local pelo menos para armazenar em cache e executar resoluções locais.
olivierg

1
O principal motivo para ter servidores DNS internos, pelo menos em uma rede Windows, é oferecer suporte ao Active Directory e a um domínio do Windows. Se você estiver executando um domínio, não poderá se livrar do DNS integrado ao AD. Ou, pelo menos, você não deveria.
Appleoddity

Nós temos um servidor LDAP interno, não o AD. O DNS não está integrado a isso, embora eu me pergunte se ele tem alguma interdependência.
Aaron R.)

ele deve ter alguns requisitos de DNS, se houver vários servidores LDAP, o AD usará SRVregistros para a descoberta de serviço, assim como o Dir389.
Jacob Evans

Interessante, bom saber. Embora eu não tenha certeza de que precisaria ser interno em qualquer caso; Parece-me que poderíamos usar DNS público para isso.
Aaron R.)

Respostas:


5

Lendo seus comentários ...

Eu 100% manteria o DNS. Eu também estenderia sua implementação LDAP para o AD. Definitivamente, 50 pessoas são grandes o suficiente; Eu implementaria o DNS para> 10 usuários se eles não fossem técnicos e tivessem vários recursos internos que precisavam acessar.

Em relação aos contras:

  • No momento, não há suporte para IPv6

Qual plataforma você usa? Existem várias plataformas com suporte a IPv6 - ou seja, OpenDNS

  • Configuração da VPN causando problemas

Sem ofensas, mas talvez você deva entender por que as configurações da VPN estão quebrando o DNS e resolver isso? É melhor do que a bandaid alternativa de "Não, o DNS interno é muito complicado para trabalhar com a VPN!".

  • A manutenção

Automatize, automatize, automatize - não deve ser muito difícil, desde que você adote uma abordagem inteligente das entradas DNS e do gerenciamento do sistema como um todo. O DNS não precisa ser radicalmente alterado (pelo menos não com frequência).


1
Apenas cerca de um terço do escritório usa o Windows, então não estou realmente interessado em adicionar mais infraestrutura para implementar um controlador de domínio. Estou usando o Bind agora, que certamente oferece suporte ao IPv6, mas ele não foi ativado e isso levaria tempo e esforço da minha parte; esse é o principal impulso, na verdade; Estou me colocando em qualquer risco remover este recurso e usando apenas Public DNS, estou me preparando para mais trabalho mais tarde por causa de algum futuro recurso de escritório que faz DNS necessidade, etc.
Aaron R.

Desculpe - assumi que todo mundo estava em um dispositivo Windows (embora o AD funcione bem com o Linux e eu imagino que haja também algumas opções maduras para o OS X). Essas são decisões de design que você deve considerar e agir. Se você pensa em crescimento e especificações futuras. pode precisar de mais de um domínio controlado com DNS interno para recursos internos -, em seguida, mantê-lo por perto, ou em um mínimo tê-lo pronto para arrancar se você acha que pode precisar dele. Caso contrário, você é o capitão do seu próprio barco - sabia? Esse tipo de coisa é sempre uma troca entre esforço versus recompensa (s) antecipada (s). Boa sorte! :)
kilrainebc

4

Mantenha o DNS interno, se necessário, torne-o redundante.

  • O DNS do SplitBrain é uma bagunça, mas geralmente você tem (muito) mais registros internos do que externos. Além disso, você pode dividir seu tráfego: interno usa IPs internos, externamente usa externos.
  • O AD conta 100% no DNS
  • Você não depende do DNS do seu provedor de serviços de Internet, porque seu DNS poderá usar recursão.
  • Você não quer que todos possam procurar seu recurso interno
  • Você não deseja fornecer recursos internos ao seu ISP (DNS-)

Você não precisa do seu próprio DNS, quando todo mundo está apenas usando a Internet e você não precisa gerenciar seus próprios servidores. A VPN me parece serviços internos, jst kepp eles internos.

  • No momento, não há suporte para IPv6

Ainda existem servidores DNS sem a v6 por aí? Atualize-se aqui.

  • Houve vários problemas com o DNS sendo dividido, principalmente com a configuração da VPN

Os problemas de configuração não desaparecem com um serviço que desaparece. Você ainda precisará configurá-lo corretamente, agora incluindo regras de interrupção para o tráfego DNS externo.

  • Manutenção em um servidor que pode ser desnecessário

O DNS geralmente é pequeno e não precisa de uma caixa própria. Basta configurar um em um de seus servidores confiáveis (como arquivo ou email).


1
Você traz uma das perguntas reais que eu tinha, talvez uma que seria melhor como uma nova pergunta, mas você poderia explicar mais o que você quer dizer quando diz: "Você não quer que todos possam procurar seus recursos internos. " Adicionar endereços IP privados no DNS público é incomum, mas há algo realmente errado com isso? Por que eu me importaria se os hackers pudessem procurar os endereços IP privados da minha empresa? Eles ainda não são roteáveis.
Aaron R.

3
Você não deseja fornecer a um hacker nenhuma pista sobre sua rede interna, caso sua segurança seja violada. Vazamento de seu DNS interno dá pistas sobre estrutura interna da rede, possíveis alvos suculentos ( "Aha!" Servidor_HR está em 192.168.99.72 Graças I pode ir direto para aquele "!), Etc.
Brandon Xavier

1
Isso é realmente uma preocupação? Sei que há um sentimento geral na comunidade profissional de que é melhor proteger todos os fragmentos de informações possíveis, mas não tenho certeza de quão crítica é. Todo o nosso DNS não público poderia ser consultado e eles receberiam esses dados em 10 minutos. Então, talvez estejamos economizando 10 minutos em tempo de hackers? Isso não parece muito valioso para mim.
Aaron R.

Seu DNS não-pública não deve ser aberto a consultas .... Assim "não pública" ...
kilrainebc

2
Tecnicamente, você pode colocar seu pessoal em público, mas tecnicamente também não pode usar calças em público (ou apenas neste local de trabalho). Portanto, é possível , ninguém quer que você faça isso e, portanto, nenhum profissional de TI faria.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.