Summary

  • RFC 1279 represented domains in an X.500 directory while keeping a domain separate from an organisation and a mailbox separate from a person. Because the objects differed, the memo rejected aliasing as their cross-tree link.
  • AssociatedDomain and AssociatedName recorded directed relationships. The preferred domain entry stayed skeletal and pointed toward organisational information instead of copying it, while allowing many domains to relate to many organisations.
  • DNS records could move between a DNS server and a Directory System Agent, but a write into the directory had to leave non-DNS attributes untouched. Record transfer, retained attributes, pointer insertion, lookup, identity resolution and operational result remained separate evidence.

Two trees described different kinds of thing

RFC 1279 appeared in November 1991 as an Experimental proposal called X.500 and Domains. Its ambition was substantial: represent the DNS domain hierarchy inside an X.500 Directory Information Tree, expose domain information to directory tools and examine whether X.500 could eventually help manage parts of DNS.

The proposal did not begin by declaring one naming system the winner. It expected the first experiments to run in the other direction. Information would probably continue to be mastered in domain databases and then be uploaded into the directory. Only after tools, repeated transfers, browsing and distribution had been tested did the appendix imagine mastering some parts of the DNS hierarchy in X.500.

That chronology matters. A representation was not a migration, a transfer was not a change of authority, and a proposed final stage was not a completed deployment. RFC 1279 described an experiment whose utility and performance still had to be evaluated.

Inside the directory, domain labels became DomainComponent values. The sequence for a name such as CS.UCL.AC.UK could be represented as successive entries in a DNS-shaped branch. A local part of an RFC 822 mailbox could extend the branch as a special kind of domain component.

But the same directory could also contain an organisational branch: a university, unit, person or role represented according to its own object type. Similar words might appear in both branches. That visual resemblance did not make the records interchangeable.

RFC 1279 stated the reason plainly. A domain was not an organisation. A person was not an RFC 822 mailbox. A domain label described a position in one namespace; an organisational entry described a different object in another part of the directory. The design therefore refused to use an alias as though one entry were merely another name for the same thing.

A pointer preserved the difference it crossed

Instead of aliasing, the proposal used directional associations. An organisational entry could carry AssociatedDomain, naming the domain related to it. A domain entry could carry AssociatedName, pointing into the organisational tree.

The two directions were not redundant. They answered different questions from different starting records. Looking at an organisation, which domain was associated with it? Looking at a domain, which organisational entry supplied the richer context? Keeping both assertions explicit also made it possible to observe a missing reverse link rather than silently invent one.

Nor did the proposal assume a universal one-to-one relation. RFC 1279 noted that a domain could be associated with several organisations, or an organisation with several domains. The pointer was therefore evidence of a stated relationship, not a uniqueness certificate.

That boundary blocks several attractive but invalid conclusions. A linked domain did not by itself prove legal ownership. A domain entry pointing at an organisation did not authenticate the operator of a service. A mailbox-shaped entry did not turn a string before @ into a verified person. The directory could retain an association without acquiring evidence that the association carried every meaning a reader might want.

This is the difference between a relation and identity. Identity permits substitution: if two records represent the same object, one name may stand in for the other within defined rules. A relation does not. It needs a predicate, a direction, a source and a time. Remove those qualifiers and the graph becomes a machine for laundering proximity into authority.

Skeletal entries reduced the number of competing truths

RFC 1279 allowed information that truly belonged to a domain to remain in the domain entry. It could hold DNS data and domain-specific management details. Yet when the organisational tree already contained the relevant information, the memo recommended that the domain-side record remain relatively skeletal and point to that richer entry.

It said information should not be duplicated. This was not merely a storage-saving preference. Two copies create two writers, two update clocks and an unresolved question when the values diverge.

Suppose a domain record copied a manager's telephone number from an organisational record. A later personnel change updated the organisational side but not the domain side. Both values would still be syntactically valid. A search result could display either. Repetition would look like corroboration even though both copies came from one old assertion.

A pointer keeps the custody visible. The organisational entry owns its descriptive attributes. The domain entry owns the association. A consumer may follow the link and present the combined view, but the presentation does not rewrite the origin of either fact.

This also improves correction. If the association is wrong, the link can be changed without rewriting the organisation. If a contact detail changes, it can be corrected at its source without scanning every domain that once copied it. The system preserves both the object and the reason a reader reached it.

DNS syntax did not carry DNS runtime behavior with it

RFC 1279 proposed storing DNS resource records in the directory in a text-derived form. It required fully specified domain names and an explicit TTL in each record. A single extensible DNSRecord attribute avoided defining a new directory attribute every time DNS gained a record type.

The document wanted the stored DNS information to be exactly equivalent so data could move between DNS and X.500. Yet it also drew a limit: the OSI Directory would not emulate DNS caching or TTL handling. Master entries were assumed to be maintained through DNS zone transfer or an equivalent method and could then be treated as authoritative within the experiment.

An explicit TTL field and a running cache clock are not the same record. RFC 1035 defined TTL as the interval for which a resource record may be cached before consulting the source again. In DNS operation, authoritative zone data, cached data, refresh state and expiry behavior occupy different roles. Copying the characters of a record into X.500 did not automatically recreate those roles.

For an investigator, this creates a necessary chain. Which DNS source supplied the record? Which zone version or transfer carried it? Did the transfer complete? When did the DSA accept the write? Was the directory entry refreshed later? Which lookup returned it? A field labelled TTL cannot answer those questions alone.

The distinction is especially important when a copied record outlives the observation that produced it. The value may still contain a number while the operational basis for treating it as current has expired. Syntax can survive its authority window.

The transfer tool received a narrow mandate

The appendix proposed a zone-transfer tool that could move information between a DNS server and a DSA in both directions. The proposal included one precise protection: when writing to the DSA, attributes that were not DNS records should remain untouched.

That sentence defines a control surface. The tool could update the record family it transported. It did not become the owner of manager details, telephone numbers, organisational descriptions, association pointers or other neighbouring attributes merely because they occupied the same entry.

A successful connection to the DSA would still not prove a completed transfer. A completed transfer would not prove that every record passed validation. A DNS-record write would not prove that protected attributes were preserved unless the before-and-after state was observed. A later lookup would not prove that a user acted on the result.

The useful evidence is therefore layered: source-zone state, requested transfer, received set, accepted write, retained non-DNS state, pointer state, lookup response and downstream action. Combining them into one “synchronised” flag would hide the exact boundary RFC 1279 tried to protect.

A staged experiment was honest about what did not yet exist

RFC 1279 listed the machinery an experiment would need: a user tool, a procedural library, a zone-transfer tool, a linkage-patching tool, a DNS manager, a mailbox downloader and an emulation DNS server. An initial stage could copy a large part of DNS space into one DSA where zone transfer was permitted. Later stages could distribute the directory data and compare performance. Only a final stage would master some DNS hierarchy in the DIT.

The list was a plan, not an operating receipt. The memo did not report that every component had been built, that copied data stayed fresh, that reverse pointers were complete, that users trusted the results or that DNS had been displaced. Experimental status narrowed the claim even when the architecture was detailed.

RFC 1309 later explained the broader X.500 model: entries represented objects through attributes and object classes, while local organisations could master local information in their own DSAs inside a distributed directory. That background clarifies why RFC 1279's pointers mattered, but it does not turn the RFC 1279 pilot into a completed global service.

The security boundary is equally explicit. RFC 1279 said it did not directly address security issues, although X.500 facilities might enable more secure access and management. A possibility was not authentication evidence. Neither a pointer nor a copied DNS record certified the person, organisation or operator behind it.

Sources and limits

RFC 1279 supplies the domain representation, rejection of aliasing, directed linkage, no-duplication rule, DNS-record transfer boundary and staged experiment. RFC 1274 confirms the related domain object classes and association attributes. RFC 1035 supplies the DNS TTL and zone-operation context. RFC 1309 supplies only the general X.500 entry and distributed local-mastery context.

These documents establish historical definitions and proposed controls. They do not prove a named deployment, current directory content, legal ownership, authenticated identity, completed transfer, fresh value, successful lookup, security outcome or user action.