4.2.2.1: legacy recursive resolver
4.2.2.1 is the first address in a small series of legacy recursive DNS resolvers inside 4.0.0.0/8, a block now held by Lumen Technologies. It has answered queries from the open internet for decades without ever being launched, documented, or supported as a public service.
Operated by Lumen Technologies, formerly Level 3 and Genuity (AS3356).
Live data
- Classification
- public
- Reverse DNS
- a.resolvers.level3.net
- ASN
- AS3356
- AS name
- Level 3 Parent, LLC
- Netname
- LVLT-ORG-4-8
- Registry
- ARIN — American Registry for Internet Numbers
- Country
- United States
- Block
- 4.0.0.0/9
- Registered
- 1992-12-01T00:00:00-05:00
- Abuse contact
- abuse@level3.com
- Blocklists
- 1 of 9 zones list it
Hostname: DNS PTR via 1.1.1.1 · ASN: IPinfo Lite · AS name: IPinfo Lite · Geo: IPinfo Lite · Registry record: rdap.arin.net. Registry data from RDAP. Reverse DNS and blocklist checks over DNS-over-HTTPS. Run a full lookup on 4.2.2.1.
4.2.2.1 is the first address in a small series of legacy recursive DNS resolvers inside 4.0.0.0/8, a block now held by Lumen Technologies. It has answered queries from the open internet for decades without ever being launched, documented, or supported as a public service.
A /8 with an unusual history
4.0.0.0/8 is one of the original class A allocations, handed to BBN Technologies, the contractor that built the ARPANET’s first routers. Ownership followed the commercial internet’s consolidation: GTE Internetworking, then Genuity, then Level 3 Communications in 2003, then CenturyLink in 2017, then the Lumen Technologies rebrand in 2020.
The resolver addresses survived every one of those transitions. Their old PTR names, vnsc-pri.sys.gtei.net for 4.2.2.1 and vnsc-bak.sys.gtei.net for 4.2.2.2, kept the GTE Internetworking suffix long after GTE stopped existing. Run the address through /reverse-dns to see what it answers with now.
Why it appears in so many configurations
Short addresses stick. Before public resolvers existed as products, engineers needed a nameserver they could type into a console from memory during an outage, and this series was as short as IPv4 gets while still being a real resolver on a tier 1 network. It spread through Cisco configuration templates, forum troubleshooting threads, and study guides, and it has been copied forward ever since.
You still find it in:
ip name-server 4.2.2.1lines in router configs inherited from a previous administrator.- Static DNS fields on appliances that were racked years ago.
- Shell scripts that use it as a “is the internet up” probe.
- Documentation that predates 8.8.8.8 and was never revised.
Using it responsibly
As a diagnostic, it is useful. dig @4.2.2.1 example.com +short gives you an answer from a resolver on a different network than yours, which separates a local DNS fault from a wider one. Add +dnssec or +trace if you want to see how it behaves.
As a permanent setting, it is a liability. Lumen publishes no service level, no privacy policy for these queries, and no status page. It has rate-limited or restricted non-customer access before. A resolver that can be turned off without an announcement is not something to build a network on.
Privacy and policy
There is no published privacy policy for 4.2.2.1. That is the important fact. Every other resolver on this site can be judged against a document its operator wrote: Google tells you how long temporary logs live, Cloudflare commits to not writing client addresses to disk, Quad9 publishes a policy under Swiss law. Here you get nothing, and your query history is subject to whatever Lumen’s general corporate policy allows.
What it is not
4.2.2.1 is not a public service with a brand behind it, and it is not run by Google, Verizon, or the United States military, three claims that circulate in forum answers. It is not anycast in the modern sense either, so latency depends entirely on where your traffic enters AS3356. And it is not a router address you can log into, despite the number looking like a LAN gateway to people used to 192.168 ranges.
Check who holds the block today with /whois-lookup, or trace the path in /traceroute.
Questions people ask
- Is 4.2.2.1 different from 4.2.2.2?
- Historically they were the primary and backup of the same resolver pair, named vnsc-pri and vnsc-bak. Both answer recursively. Neither has documented behaviour, so differences can appear without notice.
- How many addresses are in the series?
- 4.2.2.1 through 4.2.2.6 have all answered at various times. The later ones have been less consistently available.
- Does 4.2.2.1 validate DNSSEC?
- There is no published statement either way. Test it yourself with a known bad signature domain if it matters, and prefer a resolver whose operator documents the behaviour.
Related
Last reviewed 2026-09-04. editorial