Resumo

  • O WKS descrevia os serviços de um endereço IPv4 por meio de um protocolo IP e de um mapa em que cada posição correspondia a uma porta. Um bit ligado publicava uma expectativa de escuta, não uma observação atual.
  • A RFC 974 incentivou o uso de WKS para retirar da lista MX os destinos sem SMTP. A RFC 1123 revogou essa prática porque o registro era pouco usado e sua ausência não demonstrava ausência do serviço.
  • Registro de números, publicação DNS, processo servidor, política de rede e identidade da aplicação são evidências diferentes. O cliente continuava precisando estabelecer a conexão para descobrir o que realmente respondia.

A decisão tomada antes do primeiro SYN

Um programa de correio recebe vários destinos MX e procura o mais adequado. Antes de tentar uma conexão, consulta o DNS mais uma vez. O registro WKS devolve um endereço, o número do protocolo e um mapa de bits. Para TCP, a posição 25 representa a porta 25. Se estiver ligada, deveria haver um servidor SMTP escutando ali.

O ganho esperado parecia simples. Uma conexão que falha por tempo esgotado custa espera. Se o DNS já informa onde está o host, poderia também evitar que o cliente procurasse um serviço inexistente. A lista de candidatos ficaria menor sem que o programa precisasse tocar em cada máquina.

Mas esse atalho trocava uma observação por uma declaração. O servidor DNS não consultava o processo SMTP no instante da resposta. Também não percorria o caminho do cliente nem verificava as regras de acesso. Devolvia uma informação publicada pelo responsável pela zona, talvez guardada em cache. A precisão de um bit não dava atualidade àquilo que ele descrevia.

Um inventário preso ao endereço

A RFC 883 definiu WKS em novembro de 1983. A RFC 1035, de novembro de 1987, manteve a estrutura: endereço Internet de 32 bits, número de protocolo IP de oito bits e um mapa de comprimento variável em múltiplos de oito bits.

A primeira posição representa a porta zero; a segunda, a porta um. Bits além do fim transmitido são considerados zero. O exemplo da especificação usa TCP e SMTP: a vigésima sexta posição, numerada 25, indica que deveria existir um servidor na porta 25. Zero significa que o serviço não é suportado naquele endereço.

O endereço literal é uma escolha importante. WKS não aponta para um nome de destino que possa mudar de endereço depois, nem descreve uma instância independente. Cada combinação de endereço e protocolo exige seu próprio registro. Uma máquina com várias interfaces ou serviços em TCP e UDP precisa de vários WKS.

O mapa é denso: seu tamanho acompanha a porta mais alta anunciada, não a quantidade de serviços. Duas portas distantes obrigam a carregar as posições intermediárias. É possível omitir zeros no fim, mas não saltar os do meio. Essa é uma consequência aritmética da codificação, não uma medição de desperdício em redes reais.

Também faltam campos para prioridade, peso, destino alternativo, manutenção ou porta específica de uma instância. Vários registros ampliam o catálogo, mas não dão ao cliente uma regra para escolher. O modelo funciona como uma ficha de serviços de um host, não como uma política de localização distribuída.

O zero ganhou poder sobre o correio

Em janeiro de 1986, a RFC 974 deu ao WKS um papel concreto. Para cada MX, recomendava fortemente consultar WKS e descartar os nomes que não oferecessem o serviço de correio desejado. A etapa era opcional, mas encorajada.

Se o catálogo fosse completo e atualizado, a decisão economizaria trabalho. Um destino sem SMTP não mereceria uma tentativa. Só que a publicação era uma prática adicional, não uma condição para executar o serviço. Um site podia aceitar correio perfeitamente sem jamais criar WKS.

Além da não adoção, havia possibilidades de desencontro: DNS e servidores administrados por equipes diferentes, novo processo iniciado antes da atualização de zona, alteração de MX sem ajuste do mapa ou cache ainda com dados antigos. O formato não oferecia garantia de sincronização entre essas ações.

Assim, um bit ausente podia excluir um servidor válido antes de qualquer pacote. A tentativa de evitar falhas passava a produzi-las. O problema não era apenas ter dados incompletos, mas permitir que essa incompletude vetasse uma operação que poderia dar certo.

O lado positivo também era limitado. Um processo podia parar durante o TTL. Um filtro podia bloquear certos clientes. Uma máquina podia receber outro endereço ou outro programa na mesma porta. Mesmo a abertura de TCP não bastava para provar SMTP, autenticar a contraparte ou garantir a aceitação da mensagem.

Cache não é um acidente indesejado do DNS. É o mecanismo que evita consultar a origem a cada uso. Exatamente por permitir reutilização, uma resposta DNS não pode ser confundida com uma sonda instantânea do serviço que descreve.

A correção de 1989 foi voltar a tentar

A RFC 1123, de outubro de 1989, registrou a experiência acumulada. Aplicações não deveriam depender da possibilidade de encontrar WKS com uma lista correta de todos os serviços de um endereço, pois os sites Internet usavam pouco esse tipo. A confirmação da presença de um serviço deveria vir da tentativa de utilizá-lo.

No caso específico do correio, o documento retirou a etapa WKS do processamento MX recomendado. A experiência posterior à RFC 974 mostrara suporte insuficiente. A consulta extra não melhorava necessariamente a decisão; podia impedir uma entrega legítima.

Isso não declarou que todo WKS era falso. Um registro bem mantido podia ser correto. Tampouco apagou o tipo 11. O registro de parâmetros DNS da IANA continua reservando esse código a WKS. A permanência evita reutilização incompatível e permite interpretar dados antigos, mas não demonstra uso atual.

O que mudou foi o valor atribuído à ausência. Um catálogo facultativo e pouco difundido não pode definir tudo o que não existe. Para um cliente de correio, descartar por engano uma boa alternativa pode custar mais que uma conexão malsucedida. A regra de robustez devolveu a verificação ao protocolo real.

As autoridades que o mapa não conseguia reunir

O número de porta é coordenado por um registro. A zona DNS é controlada por quem a publica. O processo que escuta pertence à administração do host. O caminho depende de roteamento, filtros e políticas. A identidade do serviço depende do diálogo e dos mecanismos de autenticação.

Essas autoridades podem trabalhar juntas, mas não se tornam uma só porque seus efeitos cabem em uma frase. Uma resposta DNS autêntica pode conter configuração antiga. Um serviço corretamente configurado pode ser inacessível de determinada origem. Um socket aberto pode executar uma aplicação diferente.

A RFC 6335 explicitou posteriormente o limite do registro: atribuir um nome ou número não é endossar um produto, e tráfego numa porta atribuída não é necessariamente seguro nem sequer pertence ao serviço registrado. Administradores devem decidir políticas com base no conhecimento do tráfego, não no número como selo.

Essa formulação é posterior à história inicial do WKS. Ela serve como contraste conceitual, não como explicação retroativa atribuída aos autores de 1983. Mostra por que um mapa indexado pelo registro não pode ser uma lista de confiança: a coordenação do vocabulário não observa a execução.

A mudança de unidade em SRV

A RFC 2782 apresenta outra unidade de localização. Em SRV, a consulta identifica serviço, transporte e domínio; a resposta fornece prioridade, peso, porta e nome de destino. Esse nome possui registros de endereço, em vez de carregar uma única coordenada IPv4 dentro do registro de serviço.

O cliente passa a receber um conjunto limitado de candidatos. Pode separar principais e reservas, usar a porta anunciada para cada destino e acompanhar mudanças entre hosts. O serviço deixa de ser apenas a posição de um bit num catálogo de máquina.

A RFC 6335 também permitiu registrar nomes de serviço sem porta fixa quando mecanismos como SRV a descobrem durante a execução. Nomear um serviço e reservar um número tornam-se atos relacionados, mas separáveis.

Ainda assim, SRV não prova saúde em tempo real. O peso não mede a fila atual; o destino pode parar enquanto a resposta permanece em cache. Resolver, conectar e verificar continuam sendo tarefas do cliente. A evolução aumentou a capacidade de expressar intenção, sem conceder ao DNS autoridade sobre todos os fatos operacionais.

O limite do que sabemos

O conjunto fechado reúne sete fontes oficiais: RFC 883, 974, 1035, 1123, 2782, 6335 e o registro DNS da IANA. Elas sustentam a cronologia, o formato, a recomendação de filtragem, sua retirada e o contraste com a localização posterior por nomes.

Não sustentam números sobre consultas WKS atuais, quantidade de zonas, comportamento de produtos ou conformidade de implementações. Não demonstram que uma entrada histórica específica estava desatualizada nem que todos os agentes de correio seguiram a mesma recomendação. O custo do mapa é analisado a partir da estrutura, não de uma coleta de tráfego.

A lição é mais precisa que dizer que DNS “não é confiável”. WKS podia dizer corretamente o que uma zona declarava. Não podia manter um processo vivo nem tornar uma rota permitida. O erro começava quando a ausência de sua declaração impedia a tentativa que poderia produzir evidência melhor.