Como fazer com que o systemd-resolvido pare de tentar usar servidores DNS off-line?

Question

Configurei meu servidor DHCP para fornecer dois servidores de nomes para redundância, para que, se um estiver offline, o outro possa ser usado.

Eu configurei meus PCs com systemd-resolved e, de acordo com resolvectl status , ele pegou todos os servidores DNS (endereços IPv4 e IPv6 para ambos) e está usando um como o atual.

No entanto, se o servidor DNS ficar off-line, systemd-resolved não alternará para o próximo servidor, mas continuará tentando se conectar ao servidor off-line, fazendo com que toda a resolução de nomes sem cache falhe.

Se eu executar systemctl restart systemd-resolved , ele alternará para outro servidor e continuará trabalhando, mas ele retornará ao servidor off-line após algum tempo e a resolução do nome falhará novamente.

Como posso dizer a systemd-resolved para parar de usar um servidor DNS off-line e alternar rapidamente para um dos outros que ele conhece?

journalctl só mostra isso quando passa a usar o servidor off-line:

systemd-resolved[1985]: Using degraded feature set (UDP) for DNS server fdxx::x.
systemd-resolved[1985]: Using degraded feature set (TCP) for DNS server fdxx::x.

O servidor em questão está completamente offline quando isso acontece e não responde a pings.

    

Answer 1

Os profissionais de DNS sabem há muito tempo que, se você quiser resiliência do serviço DNS em qualquer rede, não deixe essa decisão para a implementação do cliente.

É uma decisão muito importante deixar as implementações do resolvedor dos clientes para fazer.

Embora, teoricamente, os clientes devam retornar ao segundo DNS após a falha do primeiro, muitas vezes isso não acontece por vários motivos. Ao longo dos anos em minha carreira tenho visto grandes falhas em redes completas sobre pessoas implementando coisas contando com o sistema operacional cliente resolvendo ser inteligente o suficiente.

O que você normalmente faz é, na verdade, o que os servidores de nomes estão fazendo, que é criar clusters de DNS para assumir os endereços IP virtuais de seus servidores DNS. A tecnologia mais usada para isso é o DNS anycast. Você também pode tentar arquiteturas mais simples, como usar keepdalived.

No entanto, faça o que fizer, insisto em não deixar essa decisão para o cliente.

veja IPv4 Anycast com Linux e Quagga

The traditional safeguard is to establish multiple DNS servers for a given site. Each DNS client on the network is configured with each of those servers' IP addresses. The chances of all of those servers failing in a catastrophic way are fairly small, so you have a margin of safety.

On the other hand, many stub resolvers will take only two DNS servers, making it nearly impossible to have any meaningful geographical dispersion in your DNS topology. DNS stub resolvers generally use the first of two configured DNS servers exclusively. Consequently, you end up with one server taking the entire query load and one idling, waiting for a failure. Not optimal, but hey, that's the price of redundancy...right? It doesn't have to be.

DNS redundancy and failover is a classic use case for anycast. Anycast is the concept of taking one IP address and sharing it between multiple servers, each unaware of the others. The DNS root nameservers make extensive use of anycast.

PS. Implementei DNS anycast com iBGP e OSPF em dois ISPs e uma universidade no passado, com melhorias drásticas na disponibilidade do serviço DNS em tempo de atividade.

    

Answer 2

O uso de vários servidores de nomes via DHCP é para resiliência, não redundância. Parece que você está tentando usar vários servidores de nomes no sentido de que cada cliente rastreará se um servidor de nomes não responder e parar de usá-lo. Se você realmente quer esse tipo de comportamento / design, então você precisa utilizar isso através de um servidor DNS, os clientes DNS normalmente não são capazes de fazer isso. A abordagem que você verá com frequência aqui é tornar o seu servidor DNS HA (altamente disponível), com relação aos servidores DNS upstream que ele está resolvendo.

Para mostrar por que isso não funciona, dê uma olhada em como funciona o arquivo /etc/resolv.conf . Adicionar vários servidores de nomes ao DHCP fornecerá a cada cliente 2 entradas em seus arquivos /etc/resolv.conf . Este arquivo pode fornecer apenas o seguinte mecanismo para lidar com vários servidores de nomes:

man resolv.conf

  nameserver Name server IP address

          Internet address of a name server that the resolver should query, either 
          an IPv4 address (in dot notation), or an IPv6 address in colon (and 
          possibly dot) notation as per RFC  2373. Up  to MAXNS (currently 3, see 
          <resolv.h>) name servers may be listed, one per keyword.  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.)

Esta sentença afirma:

If there are multiple servers, the resolver library queries them in the order listed.

O resolvedor não faz nada para gerenciar esta lista, ele continuará cegamente usando a lista, começando de novo a cada vez com a primeira entrada e depois com a segunda, etc. A única coisa que você pode fazer para controlá-la é mudar o timeout , retries e rotate .

timeout:n

sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a different name server. Measured in
seconds, the default is RES_TIMEOUT (currently 5, see ). The value for this option is silently capped to 30.

attempts:n

sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see ). The value for this option is silently capped to 5.

rotate

sets RES_ROTATE in _res.options, which causes round-robin selection of nameservers from among those listed. This has the effect of spreading the query load among all
listed servers, rather than having all clients try the first listed server first every time.

Referências

• segundo servidor de nomes em / etc / resolv .conf não selecionado pelo wget
• man resolv.conf