Disponibilidade em risco devido a um servidor de nomes de domínio offline?

Question

Um domínio pode ter muitos servidores de nomes registrados no registro de domínio. Os servidores de nomes são escolhidos aleatoriamente e não como primeiro primário esperado, segundo secundário e assim por diante.

Sabendo disso, isso significa que, quando um servidor de nomes está inativo, há 50% de chance de que os visitantes que questionam o servidor de nomes off-line nunca acessem seu site? Enquanto os outros 50% conseguem navegar no seu site muito bem, afetando a disponibilidade do servidor?

Por último, por que os clientes não questionariam por padrão o próximo servidor de nomes na lista quando um deles estiver inoperante?

O mesmo se aplica ao IPv4 e IPv6. Se um dos servidores de nomes suportar apenas IPv6 e nenhum IPv4 e um usuário sem conectividade IPv6 questionar esse servidor de nomes específico, o site ficará inacessível, suponho.

Além disso, estou falando explicitamente sobre a maneira como o servidor autoritário é escolhido e o tratamento de uma falha caso o servidor autoritativo escolhido não esteja disponível devido a incompatibilidades entre o cliente e o servidor. / em>

    

Answer 1

Lastly, why would clients not by default question the next name server in the list when one is down?

Isso é exatamente o que os servidores recursivos fazem quando falam com servidores autoritativos. RFC 1035 §7.2 descreve o processo geral se você estiver interessado, mas os trechos a seguir são os mais imediatos relevante:

The key algorithm uses the state information of the request to select the next name server address to query, and also computes a timeout which will cause the next action should a response not arrive. The next action will usually be a transmission to some other server, but may be a temporary error to the client.

[snip]

• If a resolver gets a server error or other bizarre response from a name server, it should remove it from SLIST, and may wish to schedule an immediate transmission to the next candidate server address.

Existem alguns outros fatores considerados na seleção do servidor autoritativo, como o tempo de resposta observado com base no histórico de comunicação anterior. Está lá no RFC, se você estiver interessado.

A chave para garantir que você não seja afetado pela inacessibilidade do servidor de nomes é coberta pelo BCP 16 . Em particular, a Seção 3.1 declara:

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.

Isso é responsável pelo fato de que a resiliência do seu domínio é severamente afetada por pontos únicos de falha na rede ou no site físico. O estado ideal é ter vários servidores de nomes autoritativos que não sejam afetados por nenhuma alteração na rede ou estado físico experimentado pelos outros.

    

Answer 2

Eu diria que a resposta para o sentimento geral da pergunta é "não".

Primeiro, a máquina cliente tradicionalmente tem apenas um resolvedor stub, enviando cegamente todas as consultas (com o conjunto "recursão desejada") para algum endereço de servidor de nomes configurado ( resolv.conf ).

É realmente o que acontece na próxima etapa, quando esse servidor de nomes processa a solicitação de recursão, fazendo consultas iterativas até atingir a autoridade, que sua pergunta é aplicável.

Embora exista algum tipo de comportamento específico de implementação, é absolutamente esperado que ele tente trabalhar por meio dos servidores de nomes oficiais até encontrar um que seja responsivo.
A advertência aqui é que haverá um tempo limite total, portanto, há um risco de que ele não possa terminar no tempo.
Dito isso, também é comum manter abas de quais servidores estão funcionando e quais não estão, aumentando as chances de que consultas sucessivas sejam bem-sucedidas em tempo hábil e, é claro, consultas para dados já armazenados em cache nem exigirão comunicação com os servidores autoritativos.

Ao todo, não, você não deve esperar 50% de chance de erro visível ao usuário se houver dois servidores de nomes e um estiver inativo. É mais provável que a primeira pesquisa em um cenário de cache completamente frio seja apenas um pouco lenta.

    

Answer 3

Dizer que há 50% de chance de que os visitantes que questionam o servidor de nomes off-line nunca acessem seu site não sejam precisos. Do manual do resolvedor Linux man resolv.conf , na seção que descreve a opção nameserver , você pode ler:

If there are multiple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.

Então, eles serão testados de acordo com a ordem especificada no arquivo de configuração. Dizer isso não significa necessariamente que todos os resolvedores devem se comportar da mesma maneira.