What is www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com?¶
I found bizarre DNS queries coming from a Galaxy S23 on my network. Queries for wildcard domains, uppercase GOOGLE.COM, .onion addresses, and a domain with 58 o's. Here's what I found after pulling the APK and reversing it.
The Discovery¶
I run ntopng on my home network, and I noticed something strange. Every time a Samsung Galaxy S23 connected to my WiFi, it immediately fired off a burst of bizarre DNS queries. Here's what tcpdump showed:
S23 > fritz.box.domain: A? www.google.com.
S23 > fritz.box.domain: stat+ A? google.com.
S23 > fritz.box.domain: inv_q+
S23 > fritz.box.domain: A? *google.com.
S23 > fritz.box.domain: A? www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com.
S23 > fritz.box.domain: A? GOOGLE.COM.
S23 > fritz.box.domain: A? google.com.onion.
S23 > fritz.box.domain: [1au] A? google.com.
This wasn't normal browsing. Something was systematically testing my DNS resolver with edge cases: malformed long domains, wildcard queries, obsolete opcodes, uppercase domain names, .onion TLDs, and various record types. And it happened identically every single time the phone connected. Automated, not manual.
First Guess¶
At first I just tried to figure out whose domain this even is. A quick search revealed that www.goooooo...gle.com historically redirected to domains like ww99.goooooo...gle.com and ww7.goooooo...gle.com — which are automatic ad-parking domains. So my initial assumption was that something on the phone was hitting an ad/malware domain. That sent me down the wrong path for a while before I started looking at the full tcpdump and realized the query was part of a much larger pattern.
Tracking It Down¶
I used adb logcat to trace which process on the phone was making the queries:
The answer came in a single log line:
MobileWips::ds: Dns server responded
NetdEventListenerService: DNS Requested by 10086(com.samsung.android.server.wifi.mobilewips), SUCCESS
The culprit: Samsung MobileWips — a built-in Wireless Intrusion Prevention System that ships on every Samsung Galaxy phone. It's part of Samsung Knox.
Reversing the APK¶
I pulled the APK via ADB:
adb shell pm path com.samsung.android.server.wifi.mobilewips
adb pull /system/priv-app/MobileWips/MobileWips.apk
A quick strings confirmed the domains are hardcoded in the binary:
*google.com
=====DnsSpoofingDetector=====
MobileWips::DnsFeatureExtractor
google.com
google.com.onion
www.google.com
Classification over dns spoofing model: %s
Dns spoofing model input:
Start DnsSpoofingDetector
I decompiled the DEX with jadx and traced the obfuscated classes back to their real identities through string references. The package is com.samsung.android.server.wifi.mobilewips, version 1.8.01.1, targeting Android 15.
The Full Probe Sequence¶
MobileWips sends 25 crafted DNS queries every time your phone joins a WiFi network. Each query tests a specific behavior of the DNS resolver:
| # | Query | What It Tests |
|---|---|---|
| 0 | A? www.google.com |
Baseline — normal lookup, all other responses compared against this |
| 1 | A? google.com |
Standard recursive query |
| 2 | stat+ A? google.com |
STATUS opcode — does the resolver handle non-standard opcodes? |
| 3 | [0x140] A? google.com |
Non-standard flags (AD+CD bits set) |
| 4 | A? google.com (RD=0) |
Recursion disabled — does the resolver answer non-recursive queries differently? |
| 5 | PTR? 216.58.202.4 |
Reverse lookup of a known Google IP — does the answer match? |
| 6 | A? *google.com |
Wildcard query — real DNS doesn't support this, spoofing proxies might respond |
| 7 | A? www.gooo...gle.com |
58-char malformed domain — should return NXDOMAIN |
| 8 | A? GOOGLE.COM |
Case sensitivity — response differences fingerprint the resolver |
| 10–11 | EDNS bare probes | Minimal EDNS OPT record handling |
| 12 | EDNS + client subnet cookie | EDNS0 with client subnet option |
| 13 | EDNS + double OPT | Two OPT records in one query — tests malformed EDNS handling |
| 14 | EDNS version=1 | EDNS version negotiation (most resolvers only support version 0) |
| 15 | EDNS + DO bit | DNSSEC OK flag support |
| 17 | A? google.com.onion |
.onion TLD leak — does the resolver try to resolve Tor addresses? |
| 18 | NS? google.com |
Nameserver record query |
| 19 | SOA? google.com |
Start of Authority query |
| 20 | CNAME? google.com |
CNAME record type query |
| 21 | PTR? 216.58.202.4 |
Second reverse lookup — consistency check against probe 5 |
| 22 | HINFO? google.com |
Host info — obsolete record type, tests resolver tolerance |
| 23 | WKS? google.com |
Well Known Services — another obsolete type |
| 24 | A? google.com |
Final A query (marked as sequence terminator in the code) |
| 25 | EDNS + different cookie | EDNS with alternate client subnet cookie — response consistency check |
The logic is clever: a legitimate DNS resolver (like your router or Cloudflare) will respond to these queries in predictable ways. A DNS spoofing proxy — the kind used in evil twin attacks or captive portal phishing — will get some of them wrong. It might resolve the wildcard, answer the 58-character nonsense domain, or mishandle obsolete opcodes.
The goooo...gle.com domain is actually built dynamically in the code by appending "o" characters in a loop between "www.g" and "gle.com" — that's why it doesn't appear as a single string in the binary.
StringBuilder sb = new StringBuilder("www.g");
for (int i2 = 0; i2 < 58; i2++) {
sb.append("o");
}
sb.append("gle.com");
How to See It Yourself¶
If you're running tcpdump or any network monitor, filter for DNS traffic from a Samsung device:
Toggle WiFi on the Samsung phone and watch the burst. From the phone side with ADB:
To pull and inspect the APK:
adb shell pm path com.samsung.android.server.wifi.mobilewips
adb pull /system/priv-app/MobileWips/MobileWips.apk
strings MobileWips.apk | grep -i google
Verdict: Not Harmful¶
The queries are Samsung's built-in WiFi Intrusion Prevention System probing your DNS resolver for signs of spoofing. It ships on every Galaxy phone as part of Knox. Weird-looking traffic, but by design.