Summary

  • RFC 1912 defined lame delegation as a server being listed through NS records for a zone while not actually providing name service for it. Parent publication was a referral claim, not proof of remote configuration.
  • The failure crossed independently controlled steps: secondary consent, zone loading and refresh, parent and child NS consistency, cache aging, endpoint reachability and an authoritative answer.
  • Redundancy existed only when the listed servers really served current data. Counting NS records could therefore overstate resilience and produce anything from extra traffic to unresolved hosts and bounced mail.

The successful half of a broken delegation

DNS made delegation look like a compact transaction. At a zone cut, the parent published NS records naming servers for the child. If a server name fell beneath that cut, address records supplied the glue needed to reach it. A resolver could then leave the parent and continue toward the child.

RFC 1034 placed an important sequence around that mechanism. Servers were to be installed first. Adding the delegation NS and necessary glue to the parent was the last installation step. Administrators on both sides of the cut were supposed to keep the records consistent. The ordering made operational sense because the parent could only point; it could not configure the machine it named.

A lame delegation preserved the first half of this system. The parent answered. The referral looked syntactically useful. The address might even be reachable. The break appeared only when the chosen server failed the next claim: it did not answer as an authority for the child zone.

That distinction is sharper than “DNS was down.” It identifies a receipt boundary. An NS record proved that a parent-side administrator had published a server name. It did not prove that the remote hostmaster had agreed, created the zone, loaded its data, transferred a current copy, kept the service running or returned an authoritative response for the question now being asked.

A server could be volunteered from afar

The problem was already visible in 1993. RFC 1537 called one form “secondary server surprise.” Hosts were bombarded with name-server requests and only later discovered that registration information said they were secondary servers. Their managers had not necessarily been asked or even told. A coordination record had assigned work to another operational domain without completing the human agreement that would make the work real.

RFC 1713 approached the same gap through debugging. A listed machine had to be queried and its behavior examined. The parent record could nominate a destination, but observation at that destination determined whether it actually served the zone. This was running-code evidence in a literal sense: authority was not inferred solely from the declaration above the cut.

RFC 1912 consolidated the operational lesson in February 1996. It was an Informational memo, not an Internet Standard, and it described recurring mistakes rather than legislating a registry system. Its classic example paired a newly configured server inside a fictional child with an external server whose hostmaster had not finished—or perhaps had never begun—setting it up as a proper secondary. The DNS said the external server was supposed to know the zone. The server did not.

The memo also reported a more presumptuous practice: some sites placed popular name servers into NS lists hoping they would somehow supply extra service. That statement records a contemporary operational report. It does not identify a verified perpetrator or establish how common the practice was. It does show why publication could not substitute for consent.

Five states hid behind one server name

A name in an NS set could occupy several different states.

First, it was named. The parent or child data contained the server identity. Second, it was reachable: packets could arrive at an address associated with that identity. Third, it was configured for the child. Fourth, it held a sufficiently current copy of the zone. Fifth, it answered authoritatively.

These states were related but not interchangeable. A reachable DNS process might be authoritative for other zones and know nothing about this one. A configured secondary might have failed to refresh and eventually expire its copy. Parent and child NS sets might agree while one server remained incorrectly configured. A working server might be removed at the child but remain cached elsewhere. An authoritative response proved service for a particular observation; it did not guarantee every listed peer or every future query.

RFC 2181 later clarified the structure around the cut. The child apex contains the authoritative NS set, while the parent holds delegation data used to send resolvers downward. The names are expected to align, but their roles and authority are not identical. RFC 8499 preserved the same vocabulary years later: a referral directs resolution, while an authoritative server is configured to answer for a zone.

The practical audit therefore could not stop at set comparison. It had to ask every listed endpoint the child-zone question, inspect the authoritative-answer state, compare useful zone evidence and repeat the observation across refresh and failure intervals.

Two servers on paper were not two working copies

The old recommendation to provide at least two name servers aimed at resilience. A secondary on another network could survive a local failure and reduce dependence on one path. But the number two described intended diversity, not proven service.

If one of two entries was lame, resolvers did not all experience one stable outcome. Their server selection, cached addresses, retry logic and timing mattered. Some queries reached the healthy server. Others first spent time and traffic on the broken member. At best, RFC 1912 said, lame delegation produced extra DNS traffic. At worst it could leave hosts unresolved and bounce mail. The RFC did not say that every resolver or every query followed the worst path.

This intermittent quality made the error easy to misread. An operator could test once, hit the healthy server and conclude that delegation worked. A user elsewhere could select the lame member and see failure. Aggregate uptime might hide that the advertised redundancy set contained only one functioning authority.

Resilience required independent observations: each server reachable from relevant networks, each configured for the zone, each holding a current-enough copy and each able to answer authoritatively. Geographic separation without operational acceptance was only geographic distribution of names.

Removal had a tail

Correcting the source configuration did not instantly erase every old path. RFC 1912 warned that cached NS records could keep sites treating a former secondary as current after it moved or was removed. It recommended continuing service on the old server during the relevant cache-aging interval rather than assuming the edit itself completed the transition.

The change crossed at least three administrative surfaces: the site controlling the child, the parent hosting the delegation and the organization hosting the secondary. A primary move required secondaries to update and reload their configuration. A secondary move required address and delegation records to change at the appropriate child and parent levels. Caches then expired according to time set earlier.

This is why one timestamp could not certify completion. The child-zone edit time, parent publication time, server reload time, successful transfer time and last expiry of cached old data were different events. The rollback path also depended on which stage had failed. Restoring an NS record could not repair an unconfigured secondary; restoring a server could not flush a stale address from every resolver.

The record had to follow the service

The lasting lesson is not that DNS delegation should be distrusted. It is that a coordination record works when it describes an accepted operational relationship and remains testable against it.

At this unusually small scale, the record and the running relationship are visibly different things. The parent possessed legitimate authority to publish its side of a zone cut. That authority did not extend into the remote server's configuration. The secondary operator possessed authority over the machine. That control did not update the parent. Resolvers made local choices among the advertised paths. No participant controlled the whole outcome.

The narrow common layer was the referral format and the rules that let independently run systems interoperate. The future decision—whether a particular host would serve a particular zone—became real only when the host operator configured it and the running server answered. Publishing first and hoping adoption followed inverted that order.

Lame delegation gave the Internet an early, concrete name for a recurring governance error: a record can direct consequences before the actor named by it has accepted the responsibility. The repair is not to pretend that records lack value. It is to make their claim narrow, test every handoff and keep the ledger behind the service it describes.

Sources