Summary
- On 11 July 1997, an operator reported that one resolver mapped
www.internic.netto an AlterNIC address and marked the record as additional data. - The episode joined a dispute about who could register popular names to a separate technical failure: a resolver trusted and retained a mapping it should not have served as an answer.
One web address, two kinds of authority
AlterNIC challenged Network Solutions’ role in registering commercial top-level domains. The dispute was about who should be allowed to add names such as .com and .net, and under whose rules. But the most revealing surviving record is smaller than that argument. On 11 July 1997, network operator Kevin Brintnall posted a lookup and cache dump from his Visi Internet name server. A request for www.internic.net returned 207.51.48.15; a lookup of that address identified aragorn.alternic.net.
Brintnall’s dump tagged the unexpected address record addtnl, shorthand for additional data in the DNS response. He also said his resolver’s root cache contained no AlterNIC hints. In this one case, a user had not selected an alternative root. An answer learned through recursive resolution had changed what that resolver returned for InterNIC’s web host.
The distinction matters because the names in the argument were doing different work. A root zone delegates top-level names. A registrar accepts registrations under a top-level domain. A recursive resolver follows DNS referrals and keeps records in a cache so later queries can be answered locally. AlterNIC’s political challenge concerned the naming system’s rules; Brintnall’s evidence showed a cached mapping at one resolver. It did not show that AlterNIC had rewritten the public root zone.
What the cache proves—and what it cannot
The original NANOG post is unusually concrete for a history of DNS. It includes the server address, the returned A record, the cached source address, and the resolver’s own cache annotation. The source address mapped to an AlterNIC host. The record’s addtnl provenance is consistent with the technical explanation reported later by WIRED: DNS responses could carry extra records, and an improperly trusting resolver could keep one for a name that was not the question it had asked.
That evidence establishes one bad answer in one cache. It does not count all affected resolvers, prove that every visitor was redirected, or show that the public root servers were under AlterNIC’s control. Contemporary reports used expansive language about “the Internet” being redirected. The packet-level record narrows the claim: the resolver presented a destination different from the authoritative one for a particular web name. The 146598 value in the cache dump is a field in that record, not a global outage duration or a user count.
The political context was real. The Washington Post reported that Network Solutions held an NSF agreement giving it exclusive registration rights for .com, .org, and .net. AlterNIC presented itself as a competing registry and objected to what its operator described as NSI’s claim over those names. That contract role was powerful, but it was not ownership of every name or of the entire Internet root. A redirect to AlterNIC made the argument visible to users; it did not settle who had legitimate authority to define the public namespace.
A cache incident was not a policy decision
The response moved through software and operations. CERT’s August 1997 BIND advisory described cache poisoning as remote name-server data saved by another server and served to client programs. It said the vulnerability had been fixed in BIND 4.9.6 and recommended an upgrade path including BIND 8.1.1. The warning applied to a class of resolver behavior, not just to AlterNIC.
RFC 2181, published in July 1997, ranks additional-section information among the least trustworthy DNS data and says unauthenticated additional records should not later be returned as answers. It clarifies how DNS data should be treated; the available record does not show that the RFC was written in response to this episode. Nor does a standard’s publication prove that operators had upgraded or configured every resolver accordingly.
The US domain-name debate continued on its own track. The Department of Commerce opened a public comment process in July 1997; the Green Paper, White Paper and ICANN’s formation followed in 1998. The Internet Society’s history records that sequence but does not attribute it to the AlterNIC redirect. In 2000, the IAB later argued in RFC 2826 that the public DNS needed one unique root to preserve consistent names. That is a later institutional position, not a forensic description of Brintnall’s cache.
The episode therefore belongs to two histories at once. It was a protest against a concentrated registration role, and an operational demonstration that a local resolver could convert questionable extra data into a different destination. The first question was who should set the rules for names. The second was what data a resolver should trust. Confusing them would make a cache entry look like a root-zone transfer—and would mistake a visible redirect for proof of universal control.
Sources
- Kevin Brintnall’s NANOG cache report, 11 July 1997
- WIRED: “InterNIC Who?” (16 July 1997)
- The Washington Post: Network Solutions and the AlterNIC redirect (23 July 1997)
- CERT Advisory CA-1997-22: BIND
- RFC 2181, section 5.4.1
- Internet Society: The History of IANA
- RFC 2826: IAB Technical Comment on the Unique DNS Root
- WIRED: “Network Solutions Takes AlterNIC to Court”
- WIRED: “Domain Guerrilla Says He’s Sorry”
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
