Redundancia de entrada
-
mesmo se cliente estiver resolvendo com o dns que esta off, ao identificar isso automaticamente é direcionado para o próximo registro, eu fiz os testes aqui e funcionou perfeitamente. o tempo de para abrir a página foi em torno de 40 segundos.
Retry não significa detectar automaticamente e usar o proximo.
De toda forma, você já sabe o conceito. Aplicar ou não é decisão sua ;)
-
jack
Foi exatamente isso que eu fizPara todos os serviços que são acessador externamente.
-
Ao que parece (a imagem está mto escura) estas são as entradas do tipo "A RECORD". Você precisa configurar adequadamente as entradas do tipo "PTR" quando falamos de DNS REVERSO.
Leia (conceito) mais sobre aqui: http://www.hardware.com.br/livros/linux-redes/dns-reverso.html
Abraços!
Jack -
o meu reverso é na operadora.
E ja esta cada um pra uma operadora.
Vou cadastrar o mx2 e vou fazer os testes -
o meu reverso é na operadora.
E ja esta cada um pra uma operadora.
Vou cadastrar o mx2 e vou fazer os testesSe o REVERSO é resolvido pela operadora, não deveria estar encontrando problemas. Apenas cadastre as entradas "A RECORD'' de modo que sejam compatíveis com o Reverso e pronto!
;)
Abraços!
Jack -
Pois é foi isso que fiz.
Mas como cada consulta ele sai por um ip da problema.
Pois uma hora ele vai ver que o meu mx resolve o ip da operadora 1, ná próxima consulta vai ver que o mx responde pelo ip da operadora 2 dai o reverso não vai bater.Eu cadastrei o mx2 agora e deixei o mx1 pra uma operadora e o 2 pra outra. Vamos ver o que vai dar.
-
Mas como cada consulta ele sai por um ip da problema.
Se o problema está na saída, me parece que não se trata de uma questão de DNS REVERSO, mas sim de SPF. Tens certeza que não está confundindo as coisas?
Abraços!
Jack -
Creio que não, pois o spf esta configurado certo.
"v=spf1 a:mx1.xxx.xxx.br"Se as 2 entradas estão configuradas como mx1 então não era pra dar problema.
Como vc pode ver nas imagens que eu mandei junto com o primeiro post de hoje, se eu conferir pelo site ipok, a cada consulta que faço o resultado muda alternando entre ok e erro.
-
Eu cadastrei o mx2 agora e deixei o mx1 pra uma operadora e o 2 pra outra. Vamos ver o que vai dar.
já viu o que deu?
-
Creio que não, pois o spf esta configurado certo.
"v=spf1 a:mx1.xxx.xxx.br"Certo,
Bem, então cadastrando o mx2 como uma entrada do tipo "MX" no teu DNS Server em outro "runlevel" deve resolver.
Nota: Continuo achando esta solução altamente "não profissional"! :-[
Abraços!
Jack -
Nota: Continuo achando esta solução altamente "não profissional"! :-[
[/quote]Eu assinaria uma solução destas apenas se integrado com ferramentas de monitoria(nagios ou zabix) para que em caso de falha, o dns se ajustaria ao link em funcionamento.
Conheço ferramentas pagas de alta disponibilidade que para trabalhar com redundancia de link sem BGP, configuram o dns com ttl zero para poder publicar mudanças de rota de acesso em poucos segundos apos a falha do link.
EDIT
Só para tentar me fazer entender sem passar por arrogante ou qualquer coisa do tipo.
O caminho é este, mas falta a cereja em cima do bolo.att,
Marcello Coutinho -
O caminho é este, mas falta a cereja em cima do bolo.
Cereja esta, que pode trazer grandes prejuízos (não só financeiros, mas conceituais também) quando a gente fala de uma estrutura corporativa e que dependa de alta-disponibilidade na web! ;)
Abraços!
Jack -
Opa galera parece que deu certo os testes com os reversos estão dando certo agora.
Em relação ao recurso utilizado acho que vcs mas do que ninguém sabem que as vezes temos que fazer as coisas funcionarem sem gastar dinheiro e sem muitos recurso, nesse caso não foi diferente, cotei as soluções pagas e as mesmas não foram aprovadas, sendo assim esta forma foi a melhor que pude fazer.
Em relação ao BGP conseguir um bloco de ip próprio é um parto e a empresa não se enquadra nos requisitos para o mesmo.E diga-se de passagem funcionou melhor do que eu esperava fiz os testes desligando as interfaces e o tempo de espera foi pouco.
Eu tenho uma outra rede wan fora de qualquer firewall completamente separada da minha rede pra fazer os testes, agora é sentar e esperar o link cair e ver oque dá.Mas segue ai a dica pra que quiser fazer um fail over e LB de entrada barato.
Duplicas as entradas A do dns colocando cada uma com o ip de uma operadora, depois publicar o master com o ip de uma operadora e o slave com o ip de outra operadora no registro br.Como o Marcello falou falta a cereja do bolo mas ainda sim é um bolo, de fuba mas é… kKKKKKK
Obrigado a todos pela ajuda e o tempo gasto. Vcs são 10.
-
Opa galera parece que deu certo os testes com os reversos estão dando certo agora.
Em relação ao recurso utilizado acho que vcs mas do que ninguém sabem que as vezes temos que fazer as coisas funcionarem sem gastar dinheiro e sem muitos recurso, nesse caso não foi diferente, cotei as soluções pagas e as mesmas não foram aprovadas, sendo assim esta forma foi a melhor que pude fazer.Blz leandruco… Sem querer criar qualquer polêmica ou estender esta thread, a única ressalva que faço aqui é que cabe a nós (profissionais da área), alertar de forma clara e amparados por subsídios técnicos, os gestores (quem decide sobre o $$$ nas empresas) sobre o que é o "ideal" e o que é o "realizável" pelos recursos dispensados. E qual o impacto disso no negócio (não na TI, mas no cerne do negócio mesmo - enquanto estratégia corporativa).
"Você é responsável pelo que cativas"! :-D
Em relação ao BGP conseguir um bloco de ip próprio é um parto e a empresa não se enquadra nos requisitos para o mesmo.
Sim… só se você fosse um AS (Sistema Autônomo)!
PS: Fico feliz em saber que o "realizável" funcionou pra você com o nosso pfSense. É pra isso mesmo que este fórum existe! ;)
Abraços!
Jack
