Resumo

  • A recomendação de três servidores listados para a maioria das zonas organizacionais pressupunha que pelo menos um estivesse distante dos demais, tanto geográfica quanto topologicamente.
  • Um endereço anunciado mas inalcançável faz resolvedores distribuídos sondarem, aguardarem e repetirem consultas, podendo reduzir a confiabilidade aparente da zona.
  • Registro NS, resposta autoritativa, serial SOA e transferência concluída comprovam etapas diferentes; nenhum deles, sozinho, garante dados atuais e idênticos ou disponibilidade fim a fim.

O arquivo dizia três; a infraestrutura dizia um

Publicado em julho de 1997 como BCP 16, o RFC 2182 tratou múltiplos servidores como meio para manter uma zona acessível quando um deles estivesse indisponível. Isso excluía a ideia de que qualquer réplica acrescentava resiliência. Três máquinas na mesma sala protegiam contra uma máquina defeituosa, mas não contra a perda da sala, da energia ou do enlace.

Separação física e separação de rede eram requisitos distintos. Distância ajuda contra eventos de local; diversidade de caminho ajuda contra falhas de enlace, roteamento ou provedor. Dois pontos no mapa podem continuar atrás da mesma dependência de trânsito. Dois nomes comerciais podem terminar na mesma instalação.

O número três era, portanto, uma recomendação condicionada. Duas máquinas bem posicionadas podiam bastar, mas uma parada prolongada deixaria apenas uma. Quatro ou cinco poderiam atender exigências maiores. A contagem só fazia sentido depois de demonstrar que as unidades não cairiam juntas.

O endereço ruim transfere o teste para o resolvedor

O endereço obtido de um nome NS precisava ser alcançável da região onde seria entregue. Uma máquina atrás de firewall, ligada de forma intermitente ou exposta por uma interface somente interna não virava backup público por constar na resposta.

O resolvedor descobre a falha tentando. Ele envia, espera e repete porque silêncio também pode ser perda de pacote. O aplicativo pode desistir antes do fim dessa sequência. Outros resolvedores executam o mesmo teste em outros momentos, multiplicando tráfego e latência sem criar uma autoridade utilizável.

O texto original afirmou de modo amplo que a ausência de resultado não era armazenada. A errata editorial 4631, mantida para atualização futura, incorpora a realidade do RFC 2308: respostas negativas podem ser colocadas em cache conforme implementação e configuração. A correção limita a frase histórica, não elimina o custo de anunciar um destino inalcançável.

As informações de delegação também podiam ser repassadas. Não bastava funcionar no primeiro resolvedor. Todo o RRset de endereços precisava ser apropriado ao público, sem ocultar um endereço ruim nem lhe atribuir TTL diferente. Ambientes internos e externos incompatíveis exigiam visões e nomes coerentes para cada lado.

O excesso também tem um domínio de risco

Mais servidores tornam pacotes maiores e aproximam respostas dos limites de tamanho. Mais importante: cada cópia acrescenta configuração, relação de transferência, software e responsabilidade operacional. A chance de uma instância ficar incorreta sem ser percebida cresce com o conjunto.

O documento separou servidores listados de stealth servers. Uma organização podia manter cópias locais não anunciadas para responder internamente durante isolamento externo. Listar todas faria o restante da Internet tentar cada máquina do mesmo local quando a ligação comum caísse. Valor local não é automaticamente uma promessa global.

A versão também precisa sobreviver

O secondary observa o serial SOA para decidir se atualiza a cópia. O primary deve incrementá-lo após mudanças. Se um erro produzir um valor alto demais, reduzir diretamente o número pode fazer servidores que já viram o valor alto ignorarem a correção.

O RFC descreve uma correção em etapas compatíveis com a aritmética do RFC 1982. O operador avança, espera que todos os secondaries relevantes adotem cada etapa e só então prossegue pelo retorno modular até o valor desejado. Verificar cada ponto é a parte decisiva.

Os recibos têm alcances diferentes. NS prova anúncio. Uma resposta prova que um processo respondeu. SOA mostra o serial visto de um ponto. Transferência completa prova o encerramento de um transporte. Ainda falta demonstrar carregamento, conteúdo pretendido, serviço por todos os processos, independência da infraestrutura e resultado da aplicação.

A seção de segurança também foi modesta. O BCP não afirmou resolver os riscos do DNS e advertiu que o comprometimento de um secondary podia afetar hosts do domínio. Diversidade só melhora disponibilidade se a nova autoridade continuar confiável.

O legado do RFC 2182 é trocar a planilha de ativos por uma cadeia de evidências. Quantidade, alcance, independência e convergência são perguntas relacionadas, mas não equivalentes.

Fontes

  1. RFC 2182 — Selection and Operation of Secondary DNS Servers
  2. Página informativa do RFC 2182
  3. RFC 1982 — Serial Number Arithmetic
  4. RFC 2181 — Clarifications to the DNS Specification
  5. RFC 2308 — Negative Caching of DNS Queries
  6. Errata do RFC 2182