Resumo

  • O RFC 1794 descreve uma discussão de 1995 sobre como adaptar a ordem dos endereços DNS à carga dos servidores sem mudar o protocolo.
  • Um servidor autoritativo podia publicar uma preferência, mas caches, servidores secundários e reordenação feita pelo cliente impediam que ela funcionasse como uma designação obrigatória.

Uma resposta ordenada não abre a conexão

Um nome pode apontar para várias máquinas equivalentes. Se uma estiver mais livre, faz sentido colocá-la primeiro. Mas o DNS entrega registros; não estabelece a conexão da aplicação. Essa distinção estrutura o RFC 1794: a ordem pode orientar e ser previsível, sem que o protocolo garanta que o cliente vá segui-la.

Publicado em abril de 1995 como Informational, o documento declara que não define um padrão da Internet. Seu autor pretendia registrar uma incursão no grupo de trabalho de DNS e as alternativas então discutidas. Também reconheceu que havia lacunas na própria reconstrução histórica. O texto é fonte para um debate de projeto, não um levantamento de implantações ou resultados de desempenho.

Da rotação à leitura da carga

O autor situa por volta de 1986 o surgimento de modificações no BIND que alteravam a ordem dos registros de endereço. Cita as mudanças Shuffle Address de Bryan Beecher e o código Round Robin de Marshall Rose como exemplos que provavelmente se espalharam bastante. Essa datação é uma lembrança retrospectiva, não um censo independente.

Alternar a ordem mudava qual endereço aparecia primeiro, mas não media a carga real das máquinas. O RFC compara isso a alterações atribuídas a Matt Madison, da TGV, que usavam recursos próprios do VMS para examinar a carga dos sistemas e ordenar os registros A do menos ocupado ao mais ocupado. A solução acompanhava melhor o estado do host, mas dependia de um sistema operacional específico e exigia mudanças no processamento dos registros. Uma abordagem era simples e portátil, mas não observava a carga; a outra era mais informada, mas menos geral.

A compatibilidade deslocou a parte dinâmica

Os critérios registrados pelo grupo de trabalho incluíam compatibilidade com o DNS existente, atualização frequente das informações, envio de vários endereços, tratamento adequado de outros registros, flexibilidade para diferentes tipos de carga e cálculo rápido. Cinco minutos era descrito como intervalo normal; sessenta segundos aparecia como possibilidade, não como uma métrica comprovada. Enviar mais de um endereço também deveria oferecer alternativas caso o servidor preferido falhasse antes do fim do TTL.

Alterar o protocolo ou criar outro tipo de registro parecia arriscado diante da base instalada. O RFC relata outra proposta de Rob Austein: tornar mais inteligente o programa de transferência de zona. Ele poderia obter os dados de carga, reordenar as informações da zona e entregá-las ao servidor de nomes sem mudar o formato das mensagens DNS. A consulta permanecia igual; o processo de preparação dos dados passava a variar.

A complexidade mudava de lugar, não desaparecia. A transferência atualiza servidores secundários; o primário não consulta uma transferência para responder às próprias perguntas. Uma subzona sujeita a mudanças rápidas dependia do intervalo de atualização, enquanto os TTLs enviados aos resolvers precisavam ser baixos para que a nova ordem se propagasse depressa. O cálculo ainda tinha de terminar antes de a informação ficar velha. Mesmo um ranking recente na origem podia envelhecer enquanto permanecesse em cache.

A última decisão ficava com o cliente

O RFC 1794 afirma que o DNS não garante a ordem dos registros na resposta. O autor a chama de previsível, mas observa que o cliente pode reordenar os endereços localmente, inclusive por meio de uma sortlist. O programa de transferência não poderia prever essas decisões remotas. Receber vários endereços tampouco prova que o cliente tentará todos, que o próximo host está saudável ou que a aplicação concluirá sua operação.

O interesse histórico está menos em dizer que o DNS virou um distribuidor de tráfego do que em mostrar como os limites foram reconhecidos. O operador podia calcular e publicar uma preferência. Secundários e caches definiam quando ela chegava adiante. O cliente escolhia o destino real. O RFC 1794 descreve uma forma de trabalhar dentro dessas fronteiras; não demonstra o quanto foi adotada nem seus resultados em produção.

Fontes