following up on my previous post:
it turns out that, like anything else weird in infrastructure, it was DNS
I registered mydomain.com as my primary router’s domain, re-ran the experiment with a fresh 128 char subdomain, and I received zero scans on the new domain.
Now my question is, who’s making that one query that leaks my domain name? Is it Apache on startup?
One solution is to resolve all my subdomains on /etc/hosts so it never has to leave the box, but I’m curious what a more experienced net admin would suggest.
The full-blown solution would be to have your own recursive DNS server on your local network, and to block or redirect any other DNS server to your own, and possibly blocking all know DoH servers.
This would solve the DNS leakage issue, since your recursive server would learn the authoritative NS for your domain, and so would contact that NS directly when processing any queries for any of your subdomains. This cuts out the possibility of any espionage by your ISP/Google/Quad9’s DNS servers, because they’re now uninvolved. That said, your ISP could still spy in the raw traffic to the authoritative NS, but from your experiment, they don’t seem to be doing that.
Is a recursive DNS server at home a tad extreme? I used to think so, but we now have people running Pi-hole and similar software, which can run in recursive mode (being built atop Unbound, the DNS server software).
/<minor nitpick>
“It was DNS” typically means that name resolution failed or did not propagate per its specification. Whereas I’m of the opinion that if DNS is working as expected, then it’s hard to pin the blame on DNS. For example, forgetting to renew a domain is not a DNS problem. And setting a bad TTL or a bad record is not a DNS problem (but may be a problem with your DNS software). And so too do I think that DNS leakage is not a DNS problem, because the protocol itself is functioning as documented.
It’s just that the operators of the upstream servers see dollar-signs by selling their user’s data. Not DNS, but rather a capitalism problem, IMO.
/</minor nitpick>
We would need to know your DNS query path and whether you are querying from inside or outside your private IP space. If you are querying against public servers, then that is completely public.
I registered mydomain.com as my primary router’s domain
Routers don’t typically deal with dns except to forward requests upstream or hand out server addresses as dhcp options. Can you elaborate what you mean by your “primary router’s domain”?
One solution is to resolve all my subdomains on /etc/hosts so it never has to leave the box, but I’m curious what a more experienced net admin would suggest.
Not a net admin but I would enforce a LAN-only DNS server for all relevant clients and put the records there. And/or put such an infra behind a VPN like Tailscale so bots don’t see it.
Okay I saw your previous post but I’m curious now. What happens if you curl your IP address on port 80? Does it send back a 30X redirect for SSL to your newly configured subdomain as the new default location for r do you get back your IP but using SSL?
Now my question is, who’s making that one query that leaks my domain name? Is it Apache on startup
If you’re wanting a list of DNS queries from your system, assuming that it’s DNS and not DoH, maybe:
# tcpdump port domainThen go start Apache or whatever.
That’s handy – thanks!
(I missed the first part so I’m not sure I follow)
How are the the subdomains resolved? If you registered them on a public DNS that might be what leaks them. Otherwise… maybe your browser?
Previous post says it is wildcard at the DNS.
Yeah they registered a wildcard but queries contain the full domain
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System IP Internet Protocol SSL Secure Sockets Layer, for transparent encryption
3 acronyms in this thread; the most compressed thread commented on today has 21 acronyms.
[Thread #1002 for this comm, first seen 15th Jan 2026, 00:05] [FAQ] [Full list] [Contact] [Source code]




