Resumo

  • RFC 1279 representou domínios no X.500, mas manteve domínio e organização, mailbox e pessoa como objetos diferentes. Por isso, alias não servia para ligar as duas árvores.
  • AssociatedDomain e AssociatedName preservavam relações direcionadas. A entrada de domínio deveria ser enxuta e apontar para os dados organizacionais, não copiá-los; a associação podia ainda ser muitos-para-muitos.
  • A zone transfer podia atualizar records DNS em um DSA, mas não atributos vizinhos. Origem, pedido, conclusão, escrita, preservação, link, consulta e efeito precisavam de registros separados.

O experimento começava longe da promessa final

RFC 1279, X.500 and Domains, foi publicado em novembro de 1991 como Experimental. Ele propôs representar a hierarquia DNS no Directory Information Tree do X.500, permitindo busca por domínios, mailboxes, responsáveis e outras informações relacionadas.

O documento não declarou que X.500 já substituía DNS. Para o trabalho inicial, considerou mais provável que os dados continuassem sob controle das Domain Databases e fossem enviados ao DIT. O apêndice listou uma sequência de ferramentas e testes antes de imaginar alguma parte da hierarquia DNS sendo administrada originalmente no diretório.

Uma arquitetura descrita não é uma instalação ativa. Um pedido de transferência não é a conclusão, e a última etapa de um plano não é evidência de adoção.

Na árvore com formato DNS, cada parte de um nome podia virar DomainComponent. O local part de uma mailbox RFC 822 era tratado como componente especial. Em outra árvore, organizações, unidades, pessoas e funções mantinham suas próprias entradas.

Os nomes podiam se aproximar, mas os objetos não. Um domain era uma posição no namespace; uma organisation era uma entidade com atributos próprios. Uma mailbox era um endereço funcional, não a pessoa que eventualmente a usava.

RFC 1279 concluiu que aliasing não era adequado. Alias implica dois nomes para o mesmo objeto. A conexão necessária aqui era uma relação entre objetos distintos.

A seta guardava uma afirmação, não uma identidade

AssociatedDomain saía da entrada organizacional e indicava o domínio relacionado. AssociatedName saía da entrada de domínio e indicava a organização no DIT.

Cada direção podia ter autor e momento próprios. Se o link reverso faltasse, o diretório mostraria a ausência em vez de fabricar simetria. Se surgisse depois, sua história continuaria visível.

O caso tampouco era sempre um-para-um. Um domínio podia se associar a várias organizações e uma organização a vários domínios. Reduzir isso a um único campo owner apagaria parte expressa do modelo.

Um vínculo não comprovava propriedade legal, autenticação ou autorização. A organização relacionada não se tornava automaticamente operadora de todo serviço no domínio. Uma mailbox ligada a uma pessoa não certificava o remetente de uma mensagem.

Relações auditáveis guardam predicado, direção, fonte e validade. Sem isso, proximidade vira identidade e identidade aparente vira poder.

Uma fonte, não várias cópias plausíveis

Informações próprias do domínio podiam permanecer na entrada de domínio, inclusive DNS records. Quando a árvore organizacional já tinha o dado relevante, porém, RFC 1279 recomendava uma entrada enxuta com ponteiro, evitando duplicação.

Copiar um contato cria dois relógios de atualização. Após uma troca de responsável, o registro organizacional pode estar correto enquanto a versão no domínio continua formalmente válida. A interface não sabe qual custodiante tinha mandato para corrigir o valor.

Se a cópia antiga aparece em vários domínios, repetição ainda parece confirmação independente. Na realidade, todas as ocorrências podem descender de uma única afirmação desatualizada.

O ponteiro preserva a divisão de responsabilidade. A organização cuida de seus atributos descritivos; o domínio cuida da associação. A tela pode combinar os dois sem mudar a procedência.

Isso torna a correção menos destrutiva. Um link errado é corrigido sem reescrever a organização. Um telefone muda em sua fonte sem exigir caça a todas as cópias.

Levar o TTL não levava o comportamento do cache

RFC 1279 escolheu uma forma textual para DNS resource records no DIT. Nomes precisavam estar completos e cada record precisava incluir TTL. Um atributo DNSRecord único permitia aceitar novos tipos.

O conteúdo deveria ser equivalente ao DNS para circular nos dois sentidos. Mesmo assim, o OSI Directory não tentava imitar caching ou TTL handling do DNS. As master entries seriam mantidas por zone transfer ou mecanismo equivalente.

RFC 1035 deu ao TTL uma função temporal no cache: depois do intervalo, a fonte deveria ser consultada novamente. Zone data, cache data, refresh e expiry exercem papéis diferentes. Copiar o número para X.500 não inicia o mesmo relógio.

Para avaliar atualidade, é preciso saber source zone, serial, transfer realizada, conjunto recebido, aceite do DSA, refresh posterior e consulta que exibiu o valor. Um campo TTL sem essa cadeia preserva a forma, não a vigência.

O escritor DNS não ganhava o restante da entrada

A ferramenta do apêndice moveria dados entre DNS server e DSA. Ao escrever no DSA, atributos que não fossem DNS records deveriam permanecer intocados.

Esse era um limite de mandato. O transportador podia atualizar sua família de records; não podia alterar manager, telefone, descrição organizacional ou ponteiros apenas porque estavam no mesmo container.

Conectar ao DSA não prova concluir a transferência. Concluir não prova aceitar cada item. Uma escrita DNS não prova preservar os vizinhos sem comparação de estado. Uma consulta posterior não prova ação do leitor.

O histórico útil separa estado da zone, solicitação, conjunto recebido, resultado da escrita, atributos protegidos antes e depois, links, resposta da busca e ação. A palavra “sincronizado” esconde essas etapas.

Etapas futuras continuavam futuras

RFC 1279 enumerou ferramenta de usuário, biblioteca, zone transfer, reparo de links, gerência DNS, download de mailboxes e servidor DNS emulado. Um teste inicial copiaria parte do espaço DNS para um DSA; etapas posteriores distribuiriam os dados e comparariam desempenho. Só ao final alguma parte poderia ter origem no DIT.

O texto não comprovou que a sequência terminou, que os links ficaram completos, que os dados permaneceram atuais ou que DNS foi substituído. Seu status Experimental limitava a conclusão.

RFC 1309 explicou entradas X.500 e a possibilidade de organizações dominarem localmente seus dados em DSAs distribuídos. Esse contexto não fornece o resultado que RFC 1279 não publicou. O próprio RFC 1279 também não tratou diretamente da segurança; apenas apontou uma possibilidade de gestão mais segura, não uma autenticação observada.

Fontes e limites

RFC 1279 sustenta representação, recusa de alias, links, não duplicação, limite de transferência e experimento. RFC 1274 confirma atributos e object classes relacionados. RFC 1035 oferece apenas contexto de TTL e operação de zones. RFC 1309 oferece o modelo geral de entradas e domínio local distribuído.

As fontes não provam implantação nomeada, propriedade jurídica, identidade autenticada, transferência concluída, valor atual, consulta bem-sucedida, resultado de segurança ou ação de usuário.