Resumo

  • Publicado como BCP 16 em julho de 1997, o RFC 2182 tratou o posicionamento dos servidores como um problema operacional de confiabilidade.
  • A recomendação de três servidores para a maioria das zonas organizacionais exigia que pelo menos um ficasse bem afastado dos demais.
  • O documento era uma orientação, não uma prova de que servidores listados tinham energia, rotas, provedores ou disponibilidade realmente independentes.

Uma zona podia listar três servidores de nomes e ainda contar com apenas um caminho prático até uma resposta. Se os três dependessem do mesmo enlace, prédio ou alimentação elétrica, uma falha poderia tirar o conjunto inteiro do ar. A quantidade parecia redundante; as dependências continuavam comuns.

Esse era o problema operacional tratado por Robert Elz, Randy Bush, Scott Bradner e Michael Patton no RFC 2182, “Selection and Operation of Secondary DNS Servers”. O IETF publicou o documento em julho de 1997 como Best Current Practice 16. Não era um protocolo DNS novo. A proposta era fazer a redundância prevista no sistema funcionar fora do arquivo de zona, na rede real.

O DNS já exigia vários servidores autoritativos para uma zona delegada. O RFC 2182 separou duas funções que podiam ser confundidas. O primário guarda os dados de zona configurados localmente; o secundário obtém esses dados do primário por transferência. Mas resolutores e a zona pai não classificam respostas segundo essa distinção. Para o restante do DNS, são apenas vários servidores autoritativos listados. O secundário só ajuda se os clientes ainda conseguirem alcançá-lo quando outro servidor — ou a infraestrutura que eles compartilham — falhar.

Os autores partiram de problemas operacionais que diziam já observar: escolhas ruins de servidores secundários. A localização geográfica e a diversidade de conectividade podiam melhorar a confiabilidade e o desempenho. Colocar todos os servidores no mesmo local era uma prática explicitamente ruim. Uma falha de enlace, local, prédio, sala ou energia podia desconectar todos de uma vez. A questão não era presumir que uma máquina remota fosse segura, mas descobrir quais falhas poderiam derrubar várias ao mesmo tempo.

O RFC 2182 recomendava três servidores para a maioria das zonas de organizações, com pelo menos um bem afastado dos outros. Quatro ou cinco poderiam fazer sentido quando a confiabilidade exigida fosse maior. Acrescentar servidores sem limite tampouco era melhor: conjuntos NS maiores aumentavam o tamanho dos pacotes DNS e as chances de uma configuração incorreta passar despercebida. O número era uma referência dentro de uma decisão de posicionamento, não um limite universal de conformidade.

A orientação também revelava uma dependência prática: alguém precisava hospedar a cópia remota. O RFC descreveu organizações de tamanho semelhante trocando serviço secundário. Como os dados de zona trocados já podiam ser obtidos publicamente, essa cooperação não expunha informações confidenciais. Ela distribuía a redundância entre operadores, mas exigia manter transferências, números de série e acessibilidade.

O BCP não mediu se os operadores seguiam as recomendações nem se uma implantação específica sobreviveria a uma falha. Uma lista NS publicada não prova que dois provedores usam upstreams diferentes, que os locais têm energia independente ou que as rotas continuarão separadas sob pressão. “Três servidores” comprova a quantidade, não uma auditoria dos caminhos de falha.

O documento de 1997 também contém uma afirmação sobre respostas DNS negativas que envelheceu. Ele dizia, de forma ampla, que resultados negativos normalmente não eram armazenados em cache. O RFC 2308 padronizou o cache negativo no ano seguinte; depois, a errata 4631 do RFC Editor apontou que aquela generalização era imprecisa. Até boas práticas operacionais têm data e histórico de manutenção.

A lição duradoura do RFC 2182 é mais específica do que um número mágico: a redundância depende das dependências. Um terceiro servidor só faz diferença quando muda o que pode falhar junto.

Fontes