Meus esquemas de zona BIND (DNS) são propostos?

1

Estou tentando fornecer um nível de controle de failover (entre dois sites) usando DNS (bind9), e não tenho certeza se o que estou planejando fazer é compatível com as especificações e se funcionará de forma confiável.

O núcleo da questão (simplificado - eu sei que preciso de mais de 1 nameserver na realidade e existem maneiras melhores de lidar com a versão simplificada abaixo - minha solução atual incluirá vários servidores de nomes, múltiplas visualizações e outras coisas como ganchos em um aplicação e subdomínios adicionais) é isso -

Se eu tiver 2 nameservers (um em LA e um no Reino Unido, por exemplo), com o servidor no Reino Unido sendo o servidor ativo, é aceitável ter o seguinte layout de zona:

no servidor LA:

                     (SOA Serial 2013013101)

domain.name.   NS    ns1.domain.name.
domain.name.   NS    ns2.domain.name.

ns1.domain.name.     A    LA.server.ip
ns2.domain.name.     A    UK.server.ip
www.domain.name.     NS   ns2.domain.name.
ww2.domain.name.     NS   ns2.domain.name.

no servidor do Reino Unido:

               (SOA Serial 2013013101)

domain.name.   NS    ns1.domain.name.
domain.name.   NS    ns2.domain.name.

ns1.domain.name.     A    LA.server.ip
ns2.domain.name.     A    UK.server.ip
www.domain.name.     A    UK.server.ip
ww2.domain.name.     A    UK.server.ip

A ideia aqui é que os pedidos para www.domain.name e ww2.domain.name sejam sempre direcionados para UK.server.IP via DNS. (Eu quero fazer isso para que, se houver uma interrupção prolongada no Reino Unido, eu possa mudar a zona no servidor LA e começar a trabalhar novamente - sem fazer alterações com o registrador). Naturalmente, tanto ns1.domain.name quanto ns2.domain.name serão fornecidos como endereços IP para o registrador.

Minhas preocupações giram em torno dos números de série de SOA e se estou quebrando especificações por ter respostas diferentes para as mesmas zonas e se a resolução / redirecionamento de DNS funcionarem como esperado. tudo funciona bem se eu dividir o servidor do Reino Unido em várias zonas, uma como a zona de Los Angeles, e zona para www.domain.name e ww2.domain.name - mas seria legal se eu pudesse evitar isso)

    
por davidgo 01.02.2013 / 02:14

2 respostas

0

Este SCHEMA NÃO É Válido.

Configurei um sistema de teste e servidores de nomes na Internet não resolvi corretamente o nome de domínio quando eles atingiram o servidor de nomes que tinha apenas DNS (e os registros de cola associados)

    
por 04.02.2013 / 02:12
2

O que você quer dizer com servidor "ativo"? Não há campo no DNS que permita definir uma preferência para servidores de nomes (existe apenas um para MX ). Então, para um cliente, que acabou de descobrir sobre sua zona, tanto LA quanto o Reino Unido estão no mesmo nível da hierarquia. Qual deles ele escolhe é específico da implementação e não é da nossa conta. Essa escolha pode até mudar para solicitações subsequentes (novamente, específicas da implementação).

Eu não acho que você vai encontrar problemas com esse layout, porque os servidores não contam histórias diferentes, apenas partes diferentes ...

Mas por que você não está usando um esquema mestre / escravo adequado com o Bind (supondo que você esteja disposto a usá-lo)? Meu mestre servidor de nomes (somente em minha própria hierarquia, não para o registrador) tem o único arquivo para a zona, e os escravos pedem cópias através de um AXFR, e são notificados sobre as atualizações. A duração em que os escravos mantêm os dados da zona é configurável. Se você quiser mais detalhes sobre como configurar isso, ficaria honrado em ajudá-lo.

EDITAR :

Eu proponho a seguinte abordagem (que deve estar totalmente em conformidade com as especificações):

Hosts

  • UK1: 1.0.0.1
  • UK2: 1.0.0.2
  • LA: 2.0.0.1

Zona de atendimento

ns1.serv.com A 1.0.0.1
ns2.serv.com A 1.0.0.2
ns3.serv.com A 1.0.0.3

serv.com NS ns1      <-- 
serv.com NS ns2      <-- this goes to registrar
serv.com NS ns3      <--

(forneça TTLs longos aqui, para fazer uso total do cache. Ele introduz uma camada de indireção, mas com TTLs longos, não deve ser tão ruim assim).

ans1.serv.com A 1.0.0.1
ans2.serv.com A 1.0.0.2

(TTLs curtos aqui, esses valores fornecem os servidores de nomes ativos para sua zona. Quanto menor o TTL, mais rápido será o uso dos outros servidores de nomes).

Todas as outras zonas

example1.com NS ans1.serv.com.  <-- this goes to registrar
example1.com NS ans2.serv.com.  <--          


anything you want to put in here...

Em caso de failover, o LA substituirá os servidores de nomes ativos na zona de serviço e, subsequentemente, obterá todas as solicitações para suas outras zonas.

    
por 01.02.2013 / 09:52

Tags