4.2.2.2: the Level 3 legacy resolver

4.2.2.2 is a recursive DNS resolver inside 4.0.0.0/8, a block held today by Lumen Technologies. It became famous in the 1990s and 2000s because it answered queries from anyone, but it was never launched as a public service and carries no support commitment or privacy policy.

The corporate paper trail

4.0.0.0/8 was originally allocated to BBN, the company that built the ARPANET. The block passed to GTE Internetworking, then to Genuity, then to Level 3 Communications in 2003. Level 3 merged with CenturyLink in 2017, and CenturyLink renamed itself Lumen Technologies in 2020. The resolvers came along at each step.

The reverse DNS records tell the story. For years 4.2.2.1 and 4.2.2.2 resolved to vnsc-pri.sys.gtei.net and vnsc-bak.sys.gtei.net, names inherited from GTE Internetworking. Later they answered as a.resolvers.level3.net and b.resolvers.level3.net. A PTR lookup on the address is a quick way to see which era of naming is live.

Why administrators memorised it

Before 2009 there was no short, well-known public resolver. Network engineers needed an address they could type from memory while a customer’s DNS was down, and 4.2.2.2 was short, sat on a tier 1 backbone, and answered. It spread through forum posts, Cisco configuration examples, and troubleshooting scripts until it became folklore.

When you see it

• In old router configurations and firewall rules that nobody has revisited.
• In Cisco IOS ip name-server lines copied from a decade-old template.
• As the ping target in scripts that want “something on the internet” to test.
• In vendor documentation and certification study material from the 2000s.
• In resolv.conf on long-lived servers, usually alongside an ISP resolver.

How to use it, and when not to

If you want to check whether name resolution works at all, dig @4.2.2.2 example.com or nslookup example.com 4.2.2.2 is a fine one-off test. Configuring it as your permanent resolver is a different matter.

There is no published service level, no privacy policy covering your queries, and no support channel. Lumen has filtered or rate-limited access from outside its own customer base at various points, so a resolver that worked yesterday can start timing out with no announcement and no status page to check. It also has no DNSSEC or filtering guarantees you can rely on, because nothing about its configuration is documented.

For a permanent setting, use an operator that has published its terms: 1.1.1.1 and 8.8.8.8 for plain resolution, 9.9.9.9 if you want threat blocking.

What it is not

4.2.2.2 is not a Google, Cloudflare, or Verizon service, despite all three claims appearing in forum answers. It is not anycast in the way modern public resolvers are, so its latency depends heavily on how your traffic reaches AS3356. And it is not a stable landmark: treating a resolver with no operator commitment as infrastructure is how a monitoring script ends up paging someone at three in the morning for a name lookup that used to work.

Look up who announces the prefix today in /whois-lookup, or measure the path in /ping-test.