Mostrar mensagens com a etiqueta DNS. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta DNS. Mostrar todas as mensagens

terça-feira, 9 de junho de 2020

DNS Windows - Algumas notas

Causa de alguns Problemas no dns 

DNS request timed out.

    timeout was 2 seconds.


A causa principal deve-se ao fato de você ter servidores DNS públicos (8.8.8.8, 195.229.241.222, 213.42.20.20) configurados na NIC do seu cliente/servidor.

Os clientes/servidores estão tentando procurar registros internos do AD e esses servidores DNS públicos não possuem registros para seus controladores de domínio internos, etc .. Este é um erro muito comum (iniciante) e pode causar todos os tipos de problemas com o seu clientes de domínio. 

Não use servidores DNS públicos em computadores ingressados ​​no domínio.

Esses servidores DNS públicos devem ser configurados como encaminhadores no (s) servidor (es) DNS interno (s) e todos os clientes do domínio devem ser configurados para apontar APENAS para o (s) servidor (s) DNS interno (s).

 

Resumindo:

Os clientes do domínio devem apontar para os servidores DNS internos para resolução de nomes. NENHUM SERVIDOR PÚBLICO

Os servidores DNS internos devem apontar para um servidor DNS interno diferente (se disponível) e para seu próprio IP. Se você tiver apenas um servidor DNS, ele apontará apenas para si. Você deve definir os encaminhadores no servidor DNS para apontar para os servidores DNS públicos desejados.

quinta-feira, 4 de abril de 2013

DNS - A zona de pesquisa direta foi excluída acidentalmente

 

A zona de pesquisa direta foi criada usando o nome errado ou foi excluída acidentalmente. Para recriar a zona, siga estas etapas:

  1. Certifique-se de que o adaptador de rede interna (e adaptador de rede externo se houver uma) aponte para o IP do servidor para a resolução DNS na caixa de diálogo Propriedades de TCP/IP ..

Aqui coloquei a placa da rede com servidor

  1. No MMC do DNS, clique com o botão direito no objeto do servidor e, em seguida, clique em Nova zona. Inicia o Assistente de nova zona. Em Tipo de zona, clique em Integrado ao Active Directory. Na próxima página, clique em Zona de pesquisa diretae, em seguida, digite um nome de domínio (por exemplo, domain.com).
  2. Expanda a pasta zonas de pesquisa direta, clique com o botão direito na zona e, em seguida, clique em Propriedades.
  3. Na guia Geral , certifique-se de que somente atualizações seguras está selecionado na Permitir atualizações? lista (que é a configuração padrão). Clique em OKe, em seguida, feche o MMC de DNS.
  4. Em um prompt de comando, reinicie o serviço Netlogon usando a seguinte linha de comando:
    • net stop netlogon
    • net start netlogon
    • ipconfig /registerdns

Verifique se o arquivo de zona agora tem os seguintes subdomínios:

  • msdcs
  • sites
  • TCP
  • UDP

terça-feira, 25 de outubro de 2011

Configurando interfaces de rede manualmente no Centos

Autor:eu próprio.

Tendo como base a interface eth0 (a primeira) devemos aceder ao seguinte da seguinte forma ao à configuração da interface:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Utilizo o vi para a edição.

Observe a sintaxe abaixo:

DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:31:25:56:A6:B2
IPADDR=192.168.1.181
NETMASK=255.255.255.0
ONBOOT=yes

Fazendo isto (com  sintaxe semelhante) estamos a colocar o ip da interface estaticamente como 192.168.1.181 e dizendo que isto será feito no momento do boot do sistema.

Em seguida entre aqui:

vi /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=CentOS
GATEWAY=192.168.1.230

Aqui definimos a rede com o hostname CentOS e o gateway 192.168.1.230

Após isto reinicie o serviço de rede:

/etc/init.d/network restart

Depois podemos até alterar os dns para acesso a web:

vi /etc/resolv.conf

Neste ficheiro colocamos assim:

nameserver 200.165.132.148
nameserver 200.165.132.155

Este é o modo simples de definir os dns que queremos.

Para concluir ficou assim

FILE:icfg-eth0
DEVICE="eth0"
NM_CONTROLLED="yes"
ONBOOT="yes"
HWADDR=00:0C:29:FC:CC:DB
TYPE=Ethernet
#BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
#novo
BOOTPROTO=static
IPADDR=192.168.1.181
NETMASK=255.255.255.0

FILE:network
NETWORKING=yes
HOSTNAME=CentOS6
#novo
GATEWAY=192.168.1.230

FILE:resolv.conf
nameserver 192.168.1.5
nameserver 192.168.1.230

sábado, 9 de janeiro de 2010

Replicação e balanceamento de carga em servidores usando DNS

Introdução

Esse artigo tem o objetivo de ensinar ao leitor como implantar um sistema de balanceamento de carga e replicação de servidores web utilizando os softwares mais comuns no mundoLinux, como o servidor web Apache e o servidor DNS Bind. 

Esse artigo abordará o exemplo específico de replicação e balanceamento de servidores web. Mas nada impede a implantação desse sistema para outros tipos de serviços. É sugerido que o leitor tenha um conhecimento básico de DNS (preferencialmente BIND). 

O problema


Suponhamos que eu possua um servidor web rodando em uma máquina relativamente boa, mas o número de requisições em meu servidor aumentam muito mês à mês, pois minhaempresa disponibilizou um sistema via web para que os clientes façam pedidos, consultem e tudo mais. 

Minha empresa está crescendo assim como o número de acessos ao meu servidor e sua importância de estar sempre on-line. Mas o problema é que meu servidor não está aguentando mais a carga de requisições e muitas vezes preciso fazer manutenção no mesmo, deixando todo sistema "fora do ar". 

Além disso, hoje na minha empresa "exemplo" a importância do meu serviço estar sempre no ar é muito maior. Porque eu estou perdendo dinheiro e credibilidade cada vez que o serviço está fora. 

Além de tudo isso, não estou afim de jogar fora o meu servidor e comprar um ainda mais caro. Quero poder reutilizar o que eu possuo e comprar outro igual, porque sai mais barato pra mim. E quando um servidor sair fora do ar, quero que automaticamente o outro entre em ação e aceite todas as requisições automaticamente! 

E pior de tudo... não quero pagar caro e nem gastar muito tempo para implantação de um sistema que me permita tudo isso! 

 



900 ; retry
604800 ; expiry
1D ) ; minimum

IN NS dns1
IN NS dns2
IN MX 10 mail

dns1 IN A 1.2.3.41
dns2 IN A 1.2.3.42
mail IN A 1.2.3.50

www IN A 1.2.3.1
IN A 1.2.3.2
IN A 1.2.3.3
IN A 1.2.3.4

....
; assim por diante.


Assim, quando o DNS for resolver www.exemplo.com.br, usará round robin para balancear a carga entre os servidores. Uma parte do problema está resolvida. Não preciso mais comprar um servidor tão potente, posso usar o que eu tenho e comprar outro igual. O outro problema era o serviço sempre estar disponível. Isso nosso caro BIND cuida também! 

Quando um servidor www "cair", o bind notará e passará as resoluções de nomes apenas para os servidores que estão em pleno funcionamento, não deixando assim o nosso serviço "fora" e permitindo assim tolerar falhas de hardware, software, ou então nos permitir fazer manutenções programadas. Ótimo não? Diria que é ótimo em relação ao trabalho que se tem para configurar essa replicação/balanceamento. Mas existem alguns problemas. Vamos à eles: 

1 - A atualização dos servidores web é muito custosa se eu tiver vários replicados. Uma possível solução para isso seria utilizar um sistema de arquivos distribuído (compartilhado) como o NFS. Assim bastaria a atualização no servidor que exportaria o diretório da página web. 

2 - O problema de cache de DNS. Porque os DNSs possuem uma cache para as últimas requisições realizadas para agilizar nesse processo de resolução. Isso pode ser um problema porque o balanceamento não seria feito de forma justa para todos os servidores www. Uma "solução" que apenas ameniza o problema é a diminuição do TTL (time to live), que é o tempo de vida de um registro em uma cache de DNS em segundos. Então com um TTL baixo eu faço com que o outros servidores DNS não guardem por muito tempo o registro em suas caches. Ou seja, amenizo o problema de cache. 

Se isso não for problema para seu tipo de replicação/balanceamento, recomendo fortemente o uso do DNS para esse propósito. Porque além de simples, é de fácil implementação e funciona muito bem. Testei isso em um sistema real e foi além das minhas expectativas. 

Conclusão





O uso do DNS (round robin) para replicação/balanceamento é extremamente simples e fácil de implementar. Além disso eu não preciso usar um middleware (stub ou proxy) para a distribuição do processamento (balanceamento), o que torna ainda mais simples de configurar, além de eliminar esse ponto único de falha que pode ser o middleware (se eu tiver apenas um). 

Espero ter ajudado alguém com esse artigo e espero principalmente, o contato de pessoas que realmente implementaram algo parecido em um sistema real para compartilharmos experiências e novas novidades nesse tipo de replicação/balanceamento.