Skip to content

Name Resolution Service

Resolver service — instantiates Registry-Mediated Discovery

Translates one stable, human-meaningful name into its current locator by walking a delegated hierarchical namespace, so callers hold a name that never changes while the address behind it does.

Version
v2 · 2026-08-28 · History
Mechanism #
5537
Type
Resolver Service
Form family
Control, Automation & Runtime
Solution family
Identity, Reference & Matching
Problem family
Identity, Provenance & Integrity Failure
Problem subfamily
Referent Individuation & Persistence
Origin domain
Computer Science & Software Engineering
Also from
Library & Information Science
Instantiates
Registry-Mediated Discovery

A Name Resolution Service answers exactly one question, extremely well: given this stable name, what is its current locator right now? What makes it this mechanism is the tight coupling of a durable, human-meaningful key to a resolution walk through a delegated hierarchical namespace. The name is the contract callers depend on — it is promised to outlive any particular address — and resolution is the act of following the name's structure, level by level, until an authority for that name hands back the current locator. It is not a query engine that filters by attributes and it is not a catalog you browse; you must already know the exact name, and what you get back is the one binding it currently points to.

Example

A browser needs to reach www.example.org. It hands that name to a DNS resolver, which walks the hierarchy: it asks a root server "who handles .org?", then asks that authority "who handles example.org?", then asks that authority for the current address of the www host. Each level owns and delegates a slice of the namespace, and only the final authority knows the actual IP — which the operator can change at will without the name ever changing. The user typed a name that has meant the same site for years; behind it the address may have moved across servers, providers, and continents. Resolution is the machinery that keeps that stable name pointed at wherever the thing currently lives, by delegating authority down a naming tree.

How it works

The namespace is partitioned into a tree, and authority over each subtree is delegated — a parent zone does not store its children's records, it stores who is authoritative for them. A resolver resolves a name by referral: start at the top, get pointed to the next authority, repeat until an authoritative answer returns the locator. The resolution contract is narrow and uniform — supply a fully-qualified name (and record type), receive a locator or an authoritative "no such name." Because the map from name to locator is many-writers-but-single-authority-per-name, the mechanism scales by delegation rather than centralization: no single server holds everything, yet any name resolves through a deterministic path down the tree.

Tuning parameters

  • Delegation depth — how finely the namespace is subdivided. Deep delegation distributes administrative control but lengthens the resolution walk.
  • Record types — how many kinds of locator a name can carry (address, mail handler, service record). More types make one name more useful and enlarge the resolution surface.
  • Authoritative propagation delay — how fast a changed binding reaches resolvers. Faster propagation cuts the window of wrong answers but raises coordination cost.
  • Resolution mode — recursive (resolver does the whole walk for you) versus iterative (caller follows referrals). Recursive is convenient; iterative gives the caller control and visibility.
  • Negative-answer handling — how confidently and how long a "no such name" is treated as final. Aggressive trust speeds failure but risks masking a not-yet-propagated new name.

When it helps, and when it misleads

It is the backbone mechanism whenever a stable, memorable name must survive a moving address — the single most common shape of discovery at scale. Callers get a name they can hardcode and trust; operators get freedom to relocate the thing behind it. Its failure modes cluster around trust in resolution: because resolvers accept an authority's answer, a forged or intercepted response can point a good name at a hostile locator[1] — cache poisoning — steering callers to the wrong place while they believe the name protected them. The misuse is treating resolution as inherently trustworthy and skipping end-to-end authentication of what you actually reach. The guarding discipline is to authenticate the thing you land on, not just the name you asked for, and to prefer resolution paths that carry integrity guarantees.

How it implements the components

  • stable_discovery_key — its reason for being: a durable, human-meaningful name that callers hold constant while the locator behind it changes.
  • resolver_or_query_contract — the narrow "name (and type) → current locator, or authoritative NXDOMAIN" contract every caller uses.
  • registry_partition_or_namespace — the delegated hierarchical namespace is the structure resolution walks; authority is partitioned by subtree.

It does not cache resolved answers on the caller under a resolver_cache_policy — that is Resolver Cache with TTL, which layers atop resolution — and it carries no per-instance health_signal, which is Service Registry; resolution maps one stable name to one current locator, it does not memoize or rank by liveness.

Editorial Notes

Form Classification

Form family: Control, Automation & Runtime

Rationale: The service automatically walks delegated authorities to translate a stable name into its current locator on each runtime request.

Nearest alternative: Organization, Role & Governance — Authority over namespace subtrees is institutionally delegated, but the mechanism practitioners deploy is the live resolving service.

Review outcome: Adjudicated after independent review; high confidence.

Origin Attribution

Primary origin: Computer Science & Software Engineering

Origin pattern: Single lineage

Present-day reach: Specialized

Rationale: Hierarchical delegation that resolves stable names to changing network locators is the architecture of computer naming systems such as DNS.

Related originating lineages:

Review outcome: Independent reviewer agreement; high confidence.

References

[1] Bellovin, S. M. "Using the Domain Name System for System Break-Ins". Proceedings of the 5th USENIX UNIX Security Symposium (1995). Shows how trusted DNS answers and forged responses can corrupt cached mappings and redirect a name to an attacker-controlled destination. registry