{"position": 5, "domain_name": "kxulsrwcq.com", "date": "2025-07-10"}
What the
https://www.ipaddress.com/website/kxulsrwcq.com/
> Safety/Trust: Unknown
{"position": 26, "domain_name": "cmidphnvq.com", "date": "2025-07-10"}
{"position": 28, "domain_name": "xmqkychtb.com", "date": "2025-07-10"}
{"position": 37, "domain_name": "ezdrtpvsa.com", "date": "2025-07-10"}
{"position": 38, "domain_name": "wvdbozpfc.com", "date": "2025-07-10"}
{"position": 46, "domain_name": "bldrdoc.gov", "date": "2025-07-10"}
{"position": 52, "domain_name": "gadf99632rm.xyz", "date": "2025-07-10"}
Geniuses...
I added it in the first place as it was a non-resolving .gov in the top 50 list which seemed out of place to me.
> bldrdoc.gov: No address associated with hostname
I see that the time related subdomains in your link do resolve to the nist.gov timeserver.
But I really am wondering what's up with all of the rest of these domains.
They calculate a random domain name based on the timestamp (so it’s constantly changing every X days in case it gets seized), and have some validation to make sure commands are signed (to prevent someone name squatting to control their botnet).
Time-lock puzzles come close, but but it requires that the bots have computing power comparable to the security researchers.
I remember a couple legitimate sites getting slammed by accidental DDOS because the algorithm happened to generate their domain, but having a hard time finding a reference to that.
There is a fairly simple method which achieves the same advantage for a botnet controller.
1. Use a hash of the current day to derive, for that day, an infinite stream of domain names. This could be something as simple as `to_human_readable_domain(sha256(daily_hash + i))`.
2. A botnet slave attempts to access servers in a diagonal order over (days, domains), starting at the first domain for today and working backwards in days and forwards in domains. An image best describes what I mean by this: https://i.imgur.com/lcEbHwz.png
3. So long as one of those domains is controlled by the botnet operator (which can be verified using a signed response from the server), they can control the botnet.
This means that the botnet operator only needs to purchase one domain every couple of days to keep controlling their botnet, while someone trying to stop them will have to buy thousands and thousands every day.
And when you successfully purchase a domain you can publish the new domain to any connected slaves, so this scheme is only necessary for recruitment into the network, not continued control.
https://files.catbox.moe/gilmd1.png
Imgur has been inaccessible for me for months, they're one of those organizations that consider it proper to block whole countries to counter bot abuse.
I believe one issue with this strategy is many corporate VPNs block fresh domains. I guess if the software was pinned to use encrypted DNS instead of whatever the OS recommends, then the DNS blocking could be avoided...
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?...
In technical terms, the device asks the private corporate DNS server for the IP address of the hostname. The private DNS server checks the requested domain against a threat intelligence feed that tracks domain registration dates (and security risks). If the domain is deemed a threat, either return an IP address which points at a server that shows a warning message (if http traffic) or return an invalid IP (0.0.0.0).
When getting a query for a domain you have not heard about, query whois for it. Store it's registration date in the cache.
the best thing to do afaik is use services normal user shave access to, and communicate via those. its hard to tell for anyone who's extracting the data from the third party so the server is hidden. (e.g bot posts images to twitter, and server scrapes the images from twitter, this is also already old news but easier and more likely to sail through that next gen firewall -_-)
i'd say having ur 'own' servers and domains is maybe even a bit dated ( though sadly still very effective!)
Each time you resolve, the resulting IP can be part of the hash for predicting a future hostname.
hiwd.kxulsrwcq.com is pointing to vdd.cachefly.net
Ex:
https://dnsarchive.net/search?q=cmidphnvq.com
That said, I think it's entirely reasonable for them to log domains alone if they're completely disconnected from any user activity, i.e. a simple "increment the counter for foo.com" is reasonable since that's unrelated to user privacy.
Just for fun I have added some of these into my cron job.
Which policy are you referring to that implies they don’t?
Also I think you are assuming they store query logs and then aggregate this data later. It is much simpler just to maintain an integer counter for monitoring as the queries come in, and ingest that into a time series database (not sure if that’s what they actually do). Maybe it needs to be a bit fancier to handle the cardinality of DNS names dimension, but re-constructing this from logs would be much more expensive.
If an organization is going to be this specific about what they count, it implies that this is everything they count, not that there may also be other junk unmentioned.
EDIT: I see they went out of their way to say "this is the complete list of everything we count" and they did not include counters by label, so I see your point!
https://github.com/Quad9DNS/quad9-domains-top500/blob/dfd513...
{"position": 127, "domain_name": "amazon.dev", "date": "2025-07-10"}
Source: https://github.com/Quad9DNS/quad9-domains-top500/blob/main/t...
Looks like their customer support rep portal. Presumably there are not A/CNAME records at the top level, but na.headphones.whs.amazon.dev resolves.
By almost every metric this is one of the 10 busiest websites, and some sources are already putting it in the top 5.
Are they just disproportionately not using Quad9?
I understand that there's a lot of overlap with Google having several spots in the top 50 itself, several being infrastructure like cloudflare and akamai, and several others being malware - but it still seems surprising.
It's just kind of shocking to see Slack, Zoom, LinkedIn, and even DropBox, Roku, and Yandex much higher up.
Some of those have many trackers and background sub domains that add up.
For example, Linkedin their most popular sub domain is: px.ads.linkedin.com
Here is a more comprehensive list with top 10k domains (including sub domains):
For example, there are many records under amazonaws.com that have 5 second TTL's mostly EC2 instances. As such clients will query them at a much higher rate whereas grammarly.io have a number of records with a 900 second TTL. This will skew the ranking positions of the two apex domains. I suppose if one wanted to game this they could have an A record to a non-critical part of a site that is not visibly rendered by the end-user and has a TTL of 1 second assuming quad9 is not rewrite min/max-ttl which some resolvers do.
Examples of just some of the TTL's used on these apex domains excluding individual records:
30 32 60 300 600 900 1200 1800 3600 7200 10800 21600 28800 43200 86400 90000 3600000
for Resolver in 1.1.1.1 8.8.8.8 9.9.9.9 216.128.176.142;do echo -en "${Resolver}:\t"; dig @${Resolver} +nocookie +noall +answer -t a big.ohcdn.net;done | column -t
1.1.1.1: big.ohcdn.net. 3628800 IN A 227.227.227.227
8.8.8.8: big.ohcdn.net. 21422 IN A 227.227.227.227
9.9.9.9: big.ohcdn.net. 43200 IN A 227.227.227.227
216.128.176.142: big.ohcdn.net. 3628800 IN A 227.227.227.227 # authoritative server
Really interesting to know though.
Some just look way high up and could mean buggy implementation without proper cache usage or persistently banging the domain.
54.in-addr.arpa looks to be Amazon's range and there are several others.
Edit: I've found that sometimes they're pretty poor at caching responses so you end up with a lot of these requests.
cbsks•4h ago
There’s a bunch of random looking domain names: cmidphnvq.com, rpqihexdb.com, facebook.com. I’d guess they for advertising?
forty•4h ago
maxmcd•3h ago
so does router.blockdh100c.co
t0mas88•4h ago
0points•4h ago
netsharc•4h ago
BearOso•4h ago
gmuslera•4h ago
mammuth•4h ago
I'd assume the domains change regularly if it's malware or bot networks, but because they rank so high in this list, it sounds like it should be feasible to keep a blocklist somewhat up to date.
danudey•4h ago
homebrewer•3h ago
Some of these lists are already in uBO out of the box.