003 - When Chinese Domains Appeared in My DNS Logs

by: David Einslow (a.k.a. - That Private Dude)

TL;DR: I discovered hundreds of DNS queries to unfamiliar Chinese domains in my logs and initially feared my network was compromised. After days of investigation, I discovered someone in China was using my NextDNS configuration ID—likely through brute-forcing or an unknown leak. The fix was simple: regenerate your NextDNS config ID. If you use NextDNS, check your logs now to ensure you're the only one using your configuration.

The Discovery: Something Wasn't Right

Five days ago, during my routine check of DNS logs (I periodically review them to whitelist false positives), I noticed something alarming: hundreds of queries to Chinese domains I'd never heard of, let alone visited.

Some were legitimate services—Apple's iCloud China servers (gateway(dot)icloud(dot)com(dot)cn, *-imap(dot)mail(dot)icloud(dot)com(dot)cn)—but I don't use Chinese Apple services. Others were completely unfamiliar: ebike(dot)ninebot(dot)com, *(dot)ninebot(dot)com. I don't own a Ninebot scooter or any related devices.

My immediate thought: I'm being hacked.

Was one of my devices compromised? Had someone joined my network? Was I unknowingly part of a botnet? The pattern was especially suspicious because these queries happened overnight while I was asleep—exactly when you'd expect malicious activity to hide.

The Investigation: Ruling Out the Obvious

I run a GL.iNet router with NextDNS configured over TLS, along with local DNS filtering. My first instinct was to check for the usual suspects:

Could It Be My Router?

I initially suspected my GL.iNet Flint router might be "phoning home" to Chinese servers. GL.iNet is a Chinese company, and there have been community discussions about privacy and telemetry. However:

• GL.iNet's firmware is largely open-source (based on OpenWrt), making backdoors easy to discover
• Their cloud services are disabled by default
• The company has been transparent about hosting infrastructure in the US and Europe

I checked my router's connected devices list—every device was one I recognized and owned. No unauthorized clients, no strange MAC addresses, no neighbors piggybacking on my WiFi.

Could It Be a Device on My Network?

The Ninebot domains pointed to Segway electric scooters or e-bikes. I don't own any such devices. The iCloud China queries suggested an Apple device with Chinese region settings—but all my Apple devices are set to my actual region in the Western Hemisphere.

I cross-referenced the DNS query timestamps with my device activity. The pattern didn't match. These queries were happening in the middle of my night—which would be daytime in China.

The Breakthrough: It Wasn't My Network At All

After days of confusion, I took a closer look at where I was seeing these logs: NextDNS's dashboard.

NextDNS shows not just the domains being queried, but also the source IP making the request. When I examined the client IP associated with these Chinese domain queries, I found something shocking:

The source IP wasn't mine. It was a Chinese IP address on the ChinaNet network (China Telecom's ISP).

This wasn't my router. This wasn't my device. Someone in China was using my NextDNS configuration ID.

How NextDNS Configuration IDs Work (And Why This Matters)

NextDNS uses a configuration ID system. When you set up NextDNS, you get a unique 6-character alphanumeric identifier (like abc123). Your devices use this ID to apply your custom filtering rules, blocklists, and settings.

Here's the problem: anyone who has your configuration ID can use it.

There's no authentication beyond the ID itself. No username, no password, no device verification. If someone discovers or guesses your ID, they can route their DNS queries through your NextDNS configuration, and their activity will appear in your logs.

How Did My ID Leak?

I genuinely don't know. I never:

• Shared it in forums or social media
• Posted screenshots containing it
• Sent it to anyone
• Included it in any public documentation

But here's the concerning math:

NextDNS configuration IDs are 6 characters long, using lowercase letters and numbers (36 possible characters per position).

Total possible combinations: 36⁶ = 2,176,782,336

While that sounds like a lot, there's nothing stopping someone from brute-forcing NextDNS configuration IDs. When you enter an ID into a DNS configuration, it just works—no additional verification required. Someone could theoretically script attempts to find valid IDs, and NextDNS (as far as I know) doesn't have rate limiting or lockout mechanisms for invalid configuration attempts.

The leak remains a mystery, but the vulnerability is real.

The Solution: Regenerate Your Configuration ID

Once I understood what was happening, the fix was straightforward:

Within hours of regenerating my ID, the Chinese IP queries disappeared completely. My logs returned to normal—only showing my devices, my queries, my actual usage patterns.

What I Learned: Reducing Your Attack Surface

This experience reinforced several important lessons about privacy and security:

1. Monitor Your DNS Logs Regularly

If I hadn't been checking my logs as part of routine security practice, I might never have noticed this. Set a reminder to review your DNS logs weekly or monthly. Look for:

• Unfamiliar domains
• Queries happening at odd hours
• Source IPs that don't match your location
• Unusual query volumes

2. NextDNS Needs Better Security Controls

I still recommend NextDNS—it's an excellent service—but I wish they offered IP allowlisting or device authentication. The ability to lock a configuration ID to specific IP ranges or require device linking would prevent this entire class of problem.

For now, treat your NextDNS configuration ID like a password: keep it private, don't share it, and consider regenerating it periodically.

3. Consider Self-Hosted Solutions

If you want complete control and eliminate third-party configuration ID risks, consider running Pi-hole or AdGuard Home locally. These self-hosted DNS solutions:

• Keep all DNS queries on your network
• Don't rely on shared configuration IDs
• Give you full control over logs and access
• Can't be "borrowed" by someone halfway around the world

I run both NextDNS (for upstream resolution and filtering) and local DNS filtering, which gives me layered visibility.

4. The More You Manage, The Greater the Risk

Every service, ID, token, and configuration you use expands your attack surface. This isn't an argument against using privacy tools—quite the opposite—but it's a reminder to:

• Audit what you're using regularly
• Understand how each service authenticates and authorizes access
• Assume anything with a simple ID/token system could be discovered or guessed

Check Your Logs Now

If you use NextDNS (or any cloud-based DNS service), I encourage you to check your logs right now:

1. Log into your NextDNS dashboard
2. Go to Analytics or Logs
3. Look at the "Devices" or "Client IPs" section
4. Do you recognize all of them?
5. Check the domains being queried—do they match your actual usage?
6. Look for activity patterns at unusual times (especially overnight if you're not a night owl)

If you see unfamiliar IPs or strange domain patterns, you might have the same issue I did.

Final Thoughts

What started as a terrifying "am I being hacked?" moment turned into a valuable lesson about how DNS privacy services work—and their limitations.

The good news: My router wasn't compromised. My devices weren't infected. My network wasn't breached. Someone simply stumbled upon or brute-forced my NextDNS configuration ID and used it for their own DNS resolution.

The bad news: This vulnerability exists for anyone using NextDNS, and there's currently no foolproof way to prevent it beyond keeping your configuration ID secret and regenerating it if you suspect unauthorized use.

Have you experienced something similar? I'm genuinely curious if others have discovered unauthorized use of their NextDNS configurations. If this has happened to you—or if you have theories about how IDs might be getting discovered—I'd love to hear about it.

Stay vigilant, check your logs, and remember: in privacy and security, trust but verify.