Existe uma razão para usar o DNS interno sobre 8.8.8.8?

Question

Eu herdei uma LAN onde realmente não há resolução de nomes sendo feita para recursos locais ... ou seja, todos os usuários inserem endereços IP manualmente para acessar impressoras e compartilhamentos de rede. Não há servidores ou domínios LDAP ou .... estações de trabalho simplesmente conectam-se à rede sem autenticação. O DHCP é tratado através de um comutador central ... E as configurações de DNS também são fornecidas por esse mesmo comutador central. Atualmente, as atribuições do DNS são assim e, nessa ordem:

10.1.1.50     / old Pentium III Windows 2003 box running DNS service- 128 MB RAM
169.200.x.x   / ISP
4.2.2.2.      / the well known public one

Há alguns milhares de clientes na LAN ... e a maior parte da atividade é navegação na Web (essa é uma configuração educacional).

Primeiro de tudo, o servidor parece insuficientemente fraco para esta tarefa ... ainda não há praticamente nenhuma lentidão quando a navegação na web por clientes ....

Quanta potência deve ter um servidor DNS muito usado?

Eu também ouvi usando 4.2.2.2 é uma má idéia .... desde que tenha sido tão usado ...

Finalmente, não faria sentido ter um servidor DNS externo robusto listado primeiro? (o 8.8.8.8 do Google parece ser um candidato lógico)

    

Answer 1

Como esse servidor claramente não está sendo estressado, estou inclinado a pensar que não há razão para mudar nada. A rede que você descreveu realmente não precisa de DNS interno, e não tê-la pode até diminuir (brevemente?) As tentativas de hacking dos alunos, já que não será imediatamente óbvio o que a máquina faz o quê.

Como você não deu nenhuma indicação de que o sistema atual não está funcionando perfeitamente, não há uma necessidade real de mudar nada.

Em relação a

Google's 8.8.8.8 would seem to be a logical candidate

Por que isso é lógico? Por que não apenas usar o DNS do ISP ou alguma outra fonte não filtrada?

Eu iria ainda mais longe e removeria 4.2.2.2, já que a probabilidade de ser atingida pelos clientes é quase nula. Afinal, tanto a máquina de 2003 quanto o DNS do ISP precisariam estar inativos para que isso acontecesse. Se você realmente sentir necessidade de uma terceira fonte de DNS, adicione o secundário do ISP.

    

Answer 2

Quando você terceirizar para outra empresa, especialmente uma que está fazendo isso de graça, você pode considerar o que eles estão recebendo fora dela. O Google está no setor de informações e está recebendo outro aspecto do padrão de tráfego do seu (ou do usuário).

Se eu estivesse em uma universidade que usasse o serviço de nomes do Google, estaria aumentando os problemas de privacidade rapidamente.

Algumas coisas são mais bem guardadas internamente, e a resolução de DNS parece ser uma delas. Se você não puder ou não quiser executar um servidor estável como BIND , adquira um appliance para fazer a resolução de DNS local.

O DNS de um site pequeno pode ser executado em uma máquina muito pequena, mas eu não habilitaria o DNSSEC. :)

    

Answer 3

Eu trabalho para uma universidade e usamos o servidor DNS interno para entradas somente internas, além disso, todas as pesquisas são encaminhadas para o 8.8.8.8/8.8.4.4 do Google sem problemas.

    

Answer 4

Você obterá uma resposta mais rápida para navegação na Web e reduzirá o tráfego da sua rede se configurar um servidor DNS local, mesmo se usá-lo apenas como um servidor DNS proxy (por exemplo, todas as suas máquinas clientes realizam pesquisas no DNS local servidor, que então faz as pesquisas no DNS público / ISP de sua escolha e, em seguida, armazena em cache as respostas). Por que você vai ter uma resposta mais rápida? Faça ping de um host na sua rede 10/100/1000 Mbit e compare o resultado ao ping de um servidor DNS público pela sua conexão com a Internet de 1/2/8/10 Mbit. Meu palpite é que você se beneficiará imediatamente de uma infraestrutura de DNS local que não custará tanto a você.

Se você também usá-lo para a resolução do nome do host local, você se beneficiará de nomes de host mais fáceis de lembrar e significativos para os hosts em sua rede.

    

Answer 5

Razões para usar um servidor DNS interno:

• Você tem domínios internos que não são públicos ou são diferentes do que está disponível publicamente.
• Você gostaria de mexer com o cache e outras coisas de desempenho.
• Você gostaria de registrar as consultas DNS para monitorar quem vai aonde.
• Você gostaria de bloquear certas coisas (observe que as pessoas irão contornar isso alterando o servidor DNS para 8.8.8.8 ou qualquer outra coisa, então você terá que bloquear o DNS para algo diferente de seu servidor no firewall)
• Você gostaria de redirecionar determinados domínios (por exemplo, redirecionar facebook.com para a política de Termos de emprego) (obviamente, você terá os mesmos problemas de bloquear domínios)
• Você gostaria de entender realmente como o DNS funciona.
• Você é uma aberração no controle.
• Você é um bisbilhoteiro.

Answer 6

Eu mal ouvi falar de 4.2.2.2, mas isso é o que eu ouvi.

Eu recomendaria que você usasse pelo menos dois servidores DNS para uma grande rede de milhares de clientes. Eu não gostaria de ser você se (ou melhor, quando) o UM DNS cair ...

Se você está procurando o mesmo tipo de simplicidade e não quer hospedar o seu, então eu recomendo que você confira OpenDNS onde você pode até mesmo configurar alguns filtros (pornografia etc) que você pode querer em uma rede educacional. Especialmente em uma rede educacional.

É claro que eu definitivamente usaria as versões 8.8.8.8 e 8.8.4.4 do Google, em vez de 4.2.2.2.

    

Answer 7

Esse servidor Win2003 é usado para mais alguma coisa? Eu nuke, jogue na sua distribuição de Linux / BSD e instale o DNSMasq nele.

    

Answer 8

Bem, configurar um servidor dns com um pouco mais de potência pode fazer sentido. Você pode usar o log de depuração do DNS nas propriedades DNS do Windows 2003 para registrar as solicitações DNS para ver qual volume de tráfego DNS você está obtendo. Para solicitações internas, você pode definir o TTL em registros locais como um valor alto para reduzir o número de solicitações. 3600 segundos, talvez?

Solicitações externas serão armazenadas em cache no servidor interno se este for o primeiro servidor DNS listado para solicitação dos clientes. Acredito que, dependendo das configurações do servidor DNS, se ele não for encontrado no servidor interno, esse servidor encaminhará o cliente para um que possa responder, ou ele recalculará a solicitação - obtenha a resposta e, em seguida, passe para o cliente .

Vale a pena ser lido, já que a usabilidade e a estabilidade da sua rede provavelmente aumentarão com a possibilidade de usar nomes de host em vez de IPs para recursos internos, mas para ser útil, ele precisa ser cuidadosamente configurado.

    

Answer 9

Por razões de desempenho, o DNS local é difícil de superar. Se você não precisa do seu próprio servidor para a resolução de nomes locais, a segunda melhor opção é usar o servidor DNS fornecido pelo seu ISP por um motivo simples: teoricamente, você não pode fazer uma resolução DNS mais rápida do que através do seu ISP simplesmente porque solicitações a qualquer outro servidor DNS público (como 8.8.8.8 ou 4.2.2.2) passará por seus servidores ISP de qualquer maneira. (obviamente, existe a possibilidade de que a configuração do DNS seja configurada incorretamente pelo seu ISP, mas eu assumirei que ele funciona como esperado).

Quando qualquer aplicativo tenta resolver um nome de host, primeiro o SO tenta resolvê-lo usando o cache interno, se o cache não estiver disponível, ele entrará em contato com o servidor DNS. Ao usar o dig , você pode ignorar o cache do sistema operacional, consultar diretamente o seu ou qualquer servidor DNS aleatório e ver as horas que ele leva para resolver usando esse servidor DNS.

Por exemplo, se eu quiser resolver google.com usando o servidor DNS do meu provedor:

> dig -4 -u +notcp google.com @76.14.0.8
...
google.com.             210     IN      A       172.217.6.46
;; Query time: 9027 usec
...

Demorou 9027 microssegundos para resolvê-lo. Se eu correr como 10 vezes, obtenho valores consistentes dentro do intervalo de 9 a 10 ms. Agora, se eu tentar usar o servidor DNS do google:

> dig -4 -u +notcp google.com @76.14.0.8
...
google.com.             168     IN      A       216.58.192.14
;; Query time: 30024 usec
...

Demorou 30024 microssegundos. Se eu cavar usando seus servidores, recebo valores que variam de 20 a 60 ms, o que é muito pior do que usar o servidor DNS fornecido pelo meu provedor local. Estou fisicamente localizado a alguns quilômetros da sede do Google, talvez meu ponto local que lida com 8.8.8.8 também não esteja tão longe, mas para alguém distante de 8.8.8.8 a diferença será muito pior.

Se você tiver um servidor DNS local (o roteador pode tê-lo), então:

> dig -4 -u +notcp google.com @192.168.0.1
...
google.com.             4       IN      A       216.58.195.78
;; Query time: 9368 usec
...

Demorou 9368 microssegundos, porque o meu router não tinha cache para google.com e tinha de contactar o meu ISP para o resolver. Mas, se eu executar na segunda vez, sempre obtenho resultados em cache que sejam consistentemente menores que 1 ms:

> dig -4 -u +notcp google.com @192.168.0.1
...
google.com.             2       IN      A       216.58.195.78
;; Query time: 493 usec
...

Difícil de bater esse tipo de performance.

No geral, na ordem de desempenho:

1. O cache do sistema operacional é o mais rápido (talvez um microssegundo ou menos para resolver ), pois não há solicitações de rede envolvidas

2. Servidor DNS local com tempos de resolução de 0,5 a 1 ms

3. O servidor DNS do ISP (pode ser qualquer coisa, vamos supor que 10ms)

4. Qualquer outro servidor DNS que adicione aproximadamente o tempo extra necessário para processar a solicitação dos seus servidores ISP para o outro servidor DNS, pode ser de 20 a 60ms, na melhor das hipóteses.

Então, quando você usaria 8.8.8.8, a quarta opção de desempenho seria a segunda?

• quando a sua rede estiver mal configurada ou você não souber o IP do seu servidor DNS quando precisar inseri-lo, basta usar o 8.8.8.8 como solução rápida.

• use-o como um servidor DNS de backup secundário.

• use-o se o seu servidor DNS primário filtrar alguns domínios (em alguns países para bloquear o acesso a determinados sites).