Design de hospedagem DNS - o servidor secundário não deve ser distribuído por países, redes, etc.? [duplicado]

1

Meu registrador de DNS e meu provedor de DNS tiveram recentemente uma longa interrupção, tornando todos os meus domínios inutilizáveis (e-mail, sites próprios e de clientes, etc.).

Eles têm 3 servidores DNS, que estão todos na mesma instalação de co-hospedagem!

Eu sei o suficiente sobre o trabalho em rede para fazer minha superinteligia, mas não o suficiente para condenar isso. Isso não é um design atroz?

Eles não deveriam ter sido espalhados por linhas, redes e até mesmo continentes?

(Fonte: link )

    
por Kjensen 01.10.2017 / 11:45

2 respostas

5

Não coloque peso nos registros geo-ip, apenas porque um serviço como pairar (provavelmente um mau exemplo) ou cloudflare (exemplo perfeito) tem uma pequena lista de endereços IP que não indica escala.

8.8.8.8 por exemplo, é anunciado no bgp via anycast para muitos pontos de presença (PoP), enquanto para você é um único IP e, portanto, um único ponto de falha, que não indica toda a história.

Examinar esses IPs especificamente usando o lg.he.net não faz isso.

Para responder, sim, eles deveriam ter, não, não, mas ter 3 nomes de servidores listados não é necessariamente o problema.

Além disso, o Google tem 4 nameservers, cada um com 24 anycast próprios / envoltos em / unicast / 23 para failback de rede.

Veja um exemplo do primeiro servidor de nomes do Google , ns1.google.com

Agoravamosverns1.hover.com

Ouch, não ótimo, o hoover pode ter (2) rotas para uma rede, enquanto o google provavelmente tem várias rotas para vários PoPs com o mesmo IP anunciado.

Eu sugeriria olhar para cloudflare, NS1 ou um dos muitos outros ... Multi-Vendor e / ou executar seus próprios escravos se a zona for realmente importante para você.

    
por 01.10.2017 / 18:46
3

Sem entrar nas especificidades da configuração deste operador em particular (que eu não conheço), a resposta para a pergunta geral é clara.

O DNS tem um longo histórico de design com a redundância em mente (o protocolo tem recursos internos para sincronizar dados de zona entre servidores, vários servidores de nomes autorizados recebem suporte nativo simplesmente adicionando vários registros NS, a maioria dos registros exige pelo menos dois servidores de nomes ao delegar seu nome de domínio registrado, etc, etc.).

Também é uma prática recomendada de longa data ter diversidade entre seus servidores de nomes oficiais, tanto em termos de localização geográfica quanto de topologia de rede.

Um exemplo disso é RFC2181 - Seleção e operação de servidores DNS secundários (também conhecido como BCP16 desde que recebeu Melhor Atuação atual status), um documento de 1997 especificamente sobre este assunto.

A seção sobre Seleção de servidores secundários (ou seja, qual deve ser o conjunto completo de servidores de nomes oficiais ) neste documento lê:

3.1. Selecting Secondary Servers

When selecting secondary servers, attention should be given to the various likely failure modes. Servers should be placed so that it is likely that at least one server will be available to all significant parts of the Internet, for any likely failure.

Consequently, placing all servers at the local site, while easy to arrange, and easy to manage, is not a good policy. Should a single link fail, or there be a site, or perhaps even building, or room, power failure, such a configuration can lead to all servers being disconnected from the Internet.

Secondary servers must be placed at both topologically and geographically dispersed locations on the Internet, to minimise the likelihood of a single failure disabling all of them.

That is, secondary servers should be at geographically distant locations, so it is unlikely that events like power loss, etc, will disrupt all of them simultaneously. They should also be connected to the net via quite diverse paths. This means that the failure of any one link, or of routing within some segment of the network (such as a service provider) will not make all of the servers unreachable.


As práticas recomendadas acima para implantações DNS em geral. Obviamente, um terá que ajustar as expectativas de alguma forma com base na situação, mas quando se trata de uma implantação em grande escala operada por uma empresa que tem esses serviços como parte de seu core business, o que está acima realmente faz sentido.

    
por 01.10.2017 / 18:25