Em suma, deve funcionar da maneira que você precisa.
O DNS autoritativo foi projetado para ser rápido e tolerante a falhas. Resolvedores recursivos são gravados para obter uma resposta autoritativa válida de seu pool de servidores o mais rápido possível, o que inclui a suposição de que um ou mais pode ser lento, não responsivo ou estar mal configurado ( SERVFAIL responses). Um ou mais servidores inutilizáveis podem causar uma pequena sobrecarga (insignificante) na obtenção de uma resposta, mas uma vez obtida essa resposta, ela pode ser armazenada em cache pela duração especificada no TTL desse registro. Somente os usuários que fizeram a solicitação quando o registro não foi armazenado em cache veriam o pequeno atraso, e as outras solicitações seriam respondidas imediatamente.
O armazenamento em cache negativo de falhas de comunicação é opcional e frequentemente implementado (consulte RFC 2308 §7 ), mas não vai render muito em termos de backoff. As falhas só podem ser armazenadas por no máximo cinco minutos e só podem ser lembradas por consulta . ( <query name, type, class, server IP address> ) Como dito anteriormente, isso não deve apresentar um problema, e eu menciono esse detalhe principalmente para evitar confusão.
O maior problema que você terá é a sincronização. Você deve monitorar todos esses servidores autoritativos para que o número de série fique fora de sincronia. Os resolvedores recursivos vão confiar no primeiro de seus servidores que retorna uma resposta autoritativa. Se um servidor retornar NXDOMAIN , mas os outros não, a não existência desse registro pode ser armazenada em cache muito mais do que de cinco minutos, dependendo de como o registro SOA está configurado.
Para resumir, é muito importante que você saiba a diferença entre o armazenamento em cache negativo de servidores sem resposta / configurados incorretamente e servidores que respondem adequadamente. Servidores que são funcionais e respondem, mas que servem uma cópia obsoleta da zona, podem e farão muito mais danos do que suas contrapartes não funcionais nesta configuração. Se você puder evitar cair nessa armadilha, a nova configuração deve ser sólida no cenário de falha proposto.
(ressalva: Estou assumindo que o Provedor A e o Provedor B são ambos provedores geo-redundantes que sabem o que estão fazendo. Qualquer pessoa que pretenda assumir um desses papéis internamente deve ler BCP 16 na íntegra e garantir que eles tenham um especialista em DNS. Um administrador do servidor que já leu um livro sobre ele está brincando com fogo.)