Resumo

  • A RFC 3663 estimou que representar sem normalização um conjunto relacional de cerca de 20 milhões de objetos poderia gerar mais de 115 milhões de objetos no diretório LDAP.
  • As referências deveriam preservar relações e limites operacionais, mas clientes diferentes as tratavam de formas inconsistentes e alguns entravam em loops. O experimento adotou um backend normalizado com uma visão desnormalizada para o cliente; ainda assim, cada cliente precisava entender aquele diretório específico.

O primeiro obstáculo foi o formato dos dados

Um domínio tem relações com outros registros. Pode ter vários contatos e servidores de nomes; um mesmo servidor pode atender diversos domínios. Registro e registrador também respondem por partes diferentes da administração. Se cada vínculo for copiado diretamente para uma árvore, os mesmos contatos e servidores podem aparecer repetidos em muitos lugares.

Publicada em dezembro de 2003 como documento Experimental, a RFC 3663 descreve o Referral LDAP Service, projeto lançado pela VeriSign para testar LDAP como diretório de dados administrativos de domínio. A estimativa de arquitetura era expressiva: um conjunto relacional com aproximadamente 20 milhões de objetos poderia ultrapassar 115 milhões na representação não normalizada proposta para a Directory Information Tree (DIT). A RFC não diz que um serviço com esse volume foi construído; trata-se de uma projeção usada para escolher o desenho. Assim, a forma do diretório deixou de ser uma preferência de modelagem e virou uma questão de armazenamento e operação. RFC 3663

O teste fazia parte de uma história anterior. O contrato inicial da InterNIC previa um diretório X.500 para informações administrativas de domínios. Dificuldades com implementações de servidores disponíveis levaram à instalação temporária de um serviço NICNAME/WHOIS. O RWhois veio depois para ampliar essa abordagem, mas a RFC 3663 afirma que ele não teve ampla aceitação para dados de domínio. O objetivo do Referral LDAP era mais limitado: estruturar buscas e resultados, facilitar o processamento por máquinas e encaminhar consultas do registro ao registrador responsável, em um momento de divisão funcional entre os dois. RFC 954 RFC 2167 RFC 3663

As referências mudaram de lugar a complexidade

A primeira DIT usou muitas referências internas entre a árvore de domínios de nível superior e as árvores de servidores de nomes e contatos. A ideia era evitar duplicação e talvez distribuir dados entre servidores diferentes. Só que uma referência LDAP não funciona como mais uma linha no resultado. O cliente precisa decidir se vai segui-la, preservar o objetivo da consulta original e lidar com a resposta que chegará depois.

Os testes iniciais com ldapsearch encontraram interpretações e comportamentos diferentes no tratamento das referências. Alguns clientes entravam facilmente em loops. A solução final foi um backend feito sob medida, que mantinha os dados normalizados e apresentava ao cliente uma visão desnormalizada, sem depender de referências internas entre servidores. A RFC avalia que conjuntos grandes provavelmente precisariam desse backend personalizado, enquanto conjuntos menores poderiam funcionar em servidores prontos. As relações não sumiram: mudou o componente responsável por reuni-las na forma que a aplicação esperava. RFC 3663

As referências entre servidores tinham outro propósito: representar que registro e registrador poderiam operar em organizações, máquinas ou redes diferentes. Mesmo assim, as referências podiam entrar nos resultados sem corresponder ao filtro da busca e ocupar o limite comum de 50 itens. Em vez dos registros procurados, o cliente podia receber uma lista de próximos destinos. A RFC descreve uma dificuldade de distribuição de consultas, e não uma falha geral do protocolo LDAP. RFC 3663 RFC 2251

Protocolo genérico, cliente específico

O LDAP fornecia uma forma comum de acesso, mas os clientes gráficos precisavam conhecer a DIT e o esquema usados pelo serviço. Não era possível apontá-los sem alterações para outro diretório LDAP e esperar que aproveitassem os dados da mesma maneira. Um cliente universal que escondesse todas as diferenças poderia deixar de mostrar parte do conteúdo ou ficar complexo demais para o usuário comum. RFC 3663

Essa distância também aparecia na interface. Segundo o documento, algumas pessoas achavam que o cliente web era a única maneira de consultar os dados e não entendiam o LDAP intermediário nem a relação entre registro, registrador e registrante. As bibliotecas C e Java tinham recursos suficientes para consultas aninhadas e acompanhamento avançado de referências, mas muitos problemas percebidos eram de usabilidade. A própria RFC admite que não era possível medir com precisão a popularidade de cada cliente. São observações do experimento, não uma pesquisa representativa de usuários. RFC 3663

Limitar buscas também não encerrava a questão da coleta de dados. Uma pesquisa LDAP arbitrária podia custar demais para um serviço público, então o experimento restringia os formatos aceitos. Usuários ainda perguntavam como contornar as regras com consultas recursivas de dicionário; muitos operadores de WHOIS chamavam isso de mineração de dados. A seção de segurança é explícita: o uso demonstrativo de nome distinto e senha não deveria ser tratado como modelo de produção. RFC 3663 RFC 2026

A decisão era quem faria a tradução

O valor histórico da RFC 3663 está na franqueza sobre os compromissos. A tecnologia genérica de diretório não entregava uma experiência portátil por conta própria. Normalizar os dados reduzia a multiplicação de objetos, mas exigia um backend personalizado para reconstruir a visão desejada pelos clientes. As referências preservavam a divisão entre operadores, mas o resultado passava a depender do comportamento de cada cliente e das regras de cada camada.

A RFC observa que as pesquisas continuavam começando no registro, mesmo quando o usuário queria chegar a um registrador ou registrante específico. O serviço não implementou descoberta por DNS SRV ou NAPTR. O levantamento de servidores LDAP também tinha escopo limitado: usou arquivos de zona de .com, .net, .org e .edu, testou a porta 389 nos nomes dos domínios e nos hosts ldap e dir, e não procurou registros SRV. A estimativa de que cerca de 0,5% dos domínios ativos da amostra tinham um servidor LDAP não é um censo da Internet nem descreve a situação atual. RFC 3663

Portanto, a escolha não era simplesmente árvore ou banco relacional. Alguém precisava converter o registro relacional em uma visão de diretório, transformar uma referência em próxima conexão e devolver ao usuário o que ele realmente queria encontrar. O piloto colocou parte desse trabalho num servidor especializado e em clientes que conheciam a estrutura do serviço, em vez de aceitar milhões de objetos repetidos ou uma cadeia frágil de referências. O protocolo comum tornava as peças reconhecíveis, mas não desenhava o caminho.

Fontes