LSN โ€” Local Sovereign Network

The Wildcard: Why Every Hostname They Invent Comes Back Alive

Letter G ended on a page that never existed, requested eight hundred times because a client fabricated its address.

This letter is about the same problem at a larger scale and from the other direction. Not one invented URL, but 324 invented hostnames, requested 92,466 times by 6,578 addresses โ€” and unlike Letter G, this one is our fault, by design, and the design is defensible.

Here is the whole thing in one experiment. I invented a hostname while writing this sentence โ€” this-name-was-invented-right-now-9z8q.shuffle-on.com โ€” a string that had never been typed before, that exists in no configuration, no DNS zone file entry of its own, no database.

Question a guesser asksAnswer this estate gives
Does the name resolve?Yes. To the same address as every real service.
Is there a valid certificate?Yes. Let's Encrypt, CN=*.shuffle-on.com, valid to 30 September.
Is a real server listening?Yes. nginx/1.31.0, HTTP/2, security headers set.
Does the page exist?No โ€” 404. Delivered as 6,679 bytes of branded HTML.

Three of the four signals say this host is real. Only the last one disagrees, and it disagrees politely, in a styled page that looks exactly like a site that exists and is missing a page.

The shape of the thing

Guessed hostnames observed324
Requests to them92,466
Distinct addresses guessing6,578
Real public hosts, for comparison41 (168,867 hits)
Auth-protected hosts3 (18,514 hits)
Guessed-host share of all traffic~32%

Nearly a third of everything arriving at this edge is addressed to a hostname that does not exist.

What they guess

The top of the list is not a wordlist:

Guessed hostnameHitsAddresses
onyx.shuffle-on.com4,405219
lsn-pihole.shuffle-on.com3,504223
guacamole.shuffle-on.com3,16484
portainer.shuffle-on.com2,941264
library1.shuffle-on.com2,32367
lsn-grafs.shuffle-on.com2,311149
lsn-auth-manager.shuffle-on.com2,264166
lsn-wireguard.shuffle-on.com2,178150
lsn-docling.shuffle-on.com2,137156
books.shuffle-on.com2,10274
lsn-ai-staging.shuffle-on.com2,040142
kiwix.shuffle-on.com1,95575
lsn-jupyter.shuffle-on.com1,863143
lsn-netdata.shuffle-on.com1,716123
lsn-pma.shuffle-on.com1,524139

Two things about that list are worth stopping on.

First, it has learned the naming convention. This estate prefixes internal services with lsn-. The guesses are lsn-pihole, lsn-grafs, lsn-wireguard, lsn-docling, lsn-jupyter, lsn-netdata, lsn-auth-manager, lsn-ai-staging, lsn-pma. That is not a generic subdomain list โ€” a generic list guesses mail, vpn, dev, staging, admin. This one guesses our pattern, applied to a catalogue of self-hosted software.

Second, a substantial fraction of the guesses are correct about the service. Cross-referencing against the estate's actual Traefik routes:

GuessedReal service here?
kiwixyes โ€” kiwix-ingress
libraryyes โ€” library-search
lsn-jupyteryes โ€” jupyter
lsn-doclingyes โ€” docling
drawyes โ€” drawio
lsn-pmayes โ€” phpmyadmin

They are not guessing whether a service exists. They are guessing, correctly, which software this estate runs โ€” and getting the hostname wrong only in which domain it is published under.

The extrapolation, caught in the act

The strongest evidence that the guessing is derived from us rather than from a wordlist is what sits beside it in the same taxonomy. These are the estate's real, publicly served hostnames:

Real hostHitsAddresses
lsn-ai.shuffle-on.com4,852203
lsn-ai-comfyui.shuffle-on.com4,379153
lsn-ragflow.shuffle-on.com4,261215
lsn-docsearch.shuffle-on.com3,664143
lsn-maps.shuffle-on.com3,276202
lsn-photos.shuffle-on.com3,212281
lsn-wifi.shuffle-on.com3,060176
lsn-classroom.shuffle-on.com2,562301
lsn-ai-images.shuffle-on.com2,346202

Now put the guessed list beside it. The real estate publishes an lsn-ai family: lsn-ai, lsn-ai-comfyui, lsn-ai-images. Among the guesses, receiving 2,040 requests from 142 addresses:

lsn-ai-staging.shuffle-on.com

Nobody arrives at that name from a wordlist. staging is a generic guess, but lsn-ai-staging is the generic guess applied to a family it has observed โ€” the same construction a person would make after seeing three lsn-ai-* hosts and wondering whether a fourth exists. The same logic produces library1 (2,323 hits) sitting next to the real library-search, and lsn-auth-manager (2,264 hits) next to the real lsn-auth.

This is the difference between guessing that a door exists and guessing that this building has another door on the same corridor. The first is enumeration. The second is inference from published structure, and it means the published structure is the thing being read.

Note also what is not being guessed. The estate runs internal services on .lsn and .home.lsn โ€” lsn-pgadmin.home.lsn, redis-commander, dozzle, focalboard, coolercontrol, llama-factory, headlamp. Those domains are served entirely from wildcard certificates and publish no per-host name anywhere. They receive 5 hits total across 2 addresses in the whole corpus. The guessing follows the published names and stops precisely where publication stops.

Who is actually knocking

The estate's own enrichment already answers this, and the answer is not one actor but four distinct populations sharing a doorway. The campaign detector had already clustered the sweeps before this letter was written:

CampaignNetworkIPsRequests
#33632AS8075 Microsoft2311,221
#33635AS396982 Google Cloud291,404
#33634AS16509 Amazon131,182
#33633AS14618 Amazon41572
#655575AS14061 DigitalOcean6115
#186085AS2024225143

1. The WordPress mass-scanners. The largest population by address count. 34.24.35.72 on Google Cloud arrives at lsn-pihole.shuffle-on.com โ€” a host that does not exist โ€” and runs a CMS path list against it: /cms/wp-includes/wlwmanifest.xml, /shop/โ€ฆ, /test/โ€ฆ, /2019/โ€ฆ, /wp/โ€ฆ, /xmlrpc.php?rsd. Eight requests, eight paths, one invented host. It is classified cms_detect and it is not alone: /wp/wp-includes/wlwmanifest.xml alone has taken 383 hits from 194 distinct addresses, /shop/โ€ฆ 366 from 191, /test/โ€ฆ 352 from 191. On portainer.shuffle-on.com, 115.70.67.247 POSTs xmlrpc.php across eight path variants in seven seconds.

This is the multiplier. A guessed hostname does not cost one request โ€” it costs a scanner's entire path list. 324 invented names times a CMS wordlist is where 92,466 comes from.

2. The credential harvesters, wearing an AI crawler's name. 136.110.61.242, AS396982 Google Cloud, thirty distinct paths against lsn-grafs.shuffle-on.com in a single pass:

/fetch?url=โ€ฆ169.254.169.254/latest/meta-data/iam/security-credentials/
/fetch?uri=โ€ฆ169.254.169.254/latest/meta-data/iam/security-credentials/
/.aws/credentials
/.env.local
/actuator/env
/@fs/etc/passwd?import&raw??
/media../etc/passwd

That is cloud-metadata SSRF aimed at IAM credentials, plus path traversal, plus framework config exposure. Its declared identity is perplexity/PerplexityBot, classified spoofed. It is already banned โ€” CrowdSec watchdog-http-probing, MikroTik crowdsec-blacklist and http-flood.

Letter F measured PerplexityBot at 43 spoofed addresses against 8 verified, and found that AS396982 hosts 51.7% of all impersonation on this estate. This is one of those addresses, doing the thing the costume was worn to do, against a hostname that has never existed.

3. The www. permutation cluster. A quieter and more targeted technique. 54.157.93.91 (AS14618 Amazon, AbuseIPDB 100/100 with 18 reports, already MikroTik-banned) does not invent names at all โ€” it takes real ones and prefixes them:

www.lsn-auth.shuffle-on.com
www.lsn-auth-manager.shuffle-on.com
www.lsn-pma.shuffle-on.com
www.lsn-wireguard.shuffle-on.com
www.auth.sonatural.life

Every one is an authentication or administration surface. The estate's entity graph labels it vhost_enumerator and records each probe as probed_sensitive_host. Its Shodan record carries the hostnames ec2-54-157-93-91.compute-1.amazonaws.com and stg.splunkcloud.com. Siblings in the same 54.156.0.0/14 prefix carry abuse scores of 100 apiece.

4. The AI crawlers โ€” and this is the one worth sitting with. The single largest sweep, campaign #33632, is AS8075 Microsoft: 23 addresses, 11,221 requests. Those addresses include 74.7.227.6 and 74.7.244.34, and the classifier's verdict on them is unambiguous:

agent: openai/GPTBot class=ai purpose=training confidence=verified

A verified OpenAI training crawler is crawling hostnames that do not exist. It fetched lsn-grafs.shuffle-on.com/, then /login, then robots.txt โ€” politely, correctly, exactly as a well-behaved crawler should, against a host this estate has never operated.

Letter F established these are the genuine article: AS8075, inside OpenAI's published Azure ranges, passing provenance verification. There is no impersonation here and no attack. There is a wildcard that answered yes to a hostname somebody, somewhere, wrote down.

Why the guessing never stops

On an ordinary estate, subdomain guessing is self-limiting. You try pihole.example.com, the resolver returns NXDOMAIN, and the attempt costs you a DNS query and teaches you the name is wrong. A wordlist of ten thousand entries produces ten thousand NXDOMAINs and one or two hits, and the failures are unambiguous.

Here, nothing fails.

The DNS model is a wildcard CNAME: *.shuffle-on.com points at a dynamic-IP host, so every conceivable subdomain resolves. The TLS model is a wildcard Let's Encrypt certificate installed as Traefik's default TLSStore, so every conceivable subdomain also presents a valid, trusted certificate. Traefik then hands unmatched hosts to a branded 404.

Each of those decisions is individually sensible. The wildcard CNAME means a new service needs no DNS change. The wildcard certificate means a new subdomain is immediately trusted without waiting on issuance. The branded 404 means a mistyped link from a real user looks like the site rather than a server error.

Together they produce an estate that answers maybe to every question about whether a host exists โ€” and a guesser who cannot tell a wrong guess from a right one until the fourth signal, which is the only one that costs a full HTTP request.

That is why 324 names accumulated 92,466 requests. The feedback that would normally kill a wordlist never arrives.

Where the convention leaked

The lsn- pattern had to come from somewhere, and the honest answer is that we publish it ourselves.

Per-service subdomains on this estate keep their own HTTP-01 certificates rather than relying on the wildcard. Every one of those certificates is submitted to Certificate Transparency, where the exact hostname is recorded permanently and publicly, by design. CT exists so that mis-issued certificates can be detected; the cost of that guarantee is that certificate issuance is a public announcement of a hostname.

So the estate leaks its naming scheme through the same mechanism that secures it. A wildcard certificate publishes only *.shuffle-on.com and reveals nothing โ€” which is why the internal .lsn and .home.lsn domains, served entirely from wildcards, do not appear in this dataset at all. A per-service certificate publishes the name.

I could not confirm the CT hypothesis directly: crt.sh returned HTTP 502 on three consecutive attempts during this investigation, and rather than substitute a plausible-sounding narrative for a failed lookup, I am marking it what it is. The mechanism is inference, not measurement. It fits โ€” the convention is public wherever a per-service certificate exists, the guesses match the convention, and the internal wildcard-only domains are absent from the guessing โ€” but a direct CT query is the test that would settle it, and it did not run.

The names we did not choose

Three entries in the guessed-host list are not subdomains of anything we own, and they are the most uncomfortable part of the dataset:

HostHitsAddressesWhose name is it?
5d9104581876.sn.mynetname.net3,384149MikroTik's dynamic-DNS service
lsn-nas1.direct.quickconnect.to2,561167Synology QuickConnect
lsn-nas2.direct.quickconnect.to1,897122Synology QuickConnect

These are hostnames assigned by vendors, published by vendors, pointing at this estate. The MikroTik router registers itself under a serial-derived label in sn.mynetname.net; the Synology NAS registers itself in direct.quickconnect.to. Neither name was chosen here, neither appears in any configuration under our control, and neither can be unpublished without giving up the feature that created it.

Together they carry 7,842 requests from 438 addresses โ€” more traffic than most of the invented lsn- names.

The distinction matters. The lsn-* guessing is downstream of our own publication decisions, and this letter's recommendation about per-service certificates would reduce it. This is not: it is downstream of someone else's naming scheme, applied to our hardware, discoverable by anyone enumerating that vendor's namespace. A scanner walking *.sn.mynetname.net finds this estate without ever having heard of shuffle-on.com.

It is also a reminder that the attack surface of a self-hosted estate includes every appliance's phone-home convenience feature. The router and the NAS each decided, by default, to be findable.

And the enumeration recurses. Searching the corpus for quickconnect.to returns not two hostnames but eleven, because the vendor-assigned name is itself being used as a base to guess against:

lsn-nas1.direct.quickconnect.to          2,561 hits
lsn-nas2.direct.quickconnect.to          1,897 hits
a.lsn-nas2.direct.quickconnect.to          271 hits
a.lsn-nas1.direct.quickconnect.to          247 hits
info.lsn-nas2.direct.quickconnect.to        30 hits
www.lsn-nas2.direct.quickconnect.to         15 hits
mail.lsn-nas2.direct.quickconnect.to         2 hits
owa.lsn-nas2.direct.quickconnect.to          2 hits
secure.lsn-nas1.direct.quickconnect.to       2 hits

www, mail, owa, secure, info โ€” that is the generic wordlist, applied on top of a name we never chose. The two layers are visible in one dataset: derived guessing against our published lsn-* convention, and generic guessing against the vendor's.

What the 404 tells them

The branded 404 is worth its own examination, because Letter D established that a status code is a reply.

A guesser who reaches the fourth signal gets 6,679 bytes of styled HTML from nginx/1.31.0, with x-content-type-options: nosniff and x-frame-options: DENY set. That page tells them: this is a real, competently configured web estate; the hostname pattern is plausible enough to be served; and someone maintains it.

Compare what a non-existent host on a normal estate returns โ€” a connection failure, a default Apache error, or nothing at all. The difference is the difference between a closed door and a door that opens onto a receptionist who says "not that one."

None of this is a vulnerability. No information about real services leaks in the 404; it is the same page for every unmatched host, so it cannot distinguish lsn-pihole (guessed) from lsn-nonsense-xyz (invented). But it is an invitation to continue, and 6,578 addresses have accepted it.

The part that is genuinely defensible

It would be easy to write this letter as a criticism and the arithmetic does not support that.

The cost of the wildcard design is 92,466 requests to nowhere โ€” noise, answered by a static file server, consuming no application resources, exposing nothing, and reaching no service. The benefit is an estate where adding a service requires no DNS work and no certificate wait, on infrastructure run by one person alongside a full-time job.

The alternative designs each cost something real:

The first two trade a large operational cost for a reduction in noise that harms nobody. The third trades a small operational cost for the estate's naming scheme staying private. That asymmetry is the actionable finding of this letter.

Steelmanning the boring explanation

Is this just background internet scanning that every host receives? Partly, and the volume alone would not be interesting. What makes it a finding is the shape: generic scanning guesses mail, webmail, cpanel, vpn, admin. This traffic guesses lsn-docling and lsn-ai-staging. A pattern that specific is not in any public wordlist, because the pattern is ours.

Could the guessed names come from our own published dossiers rather than CT? Worth testing and it fails. The dossiers discuss infrastructure in general terms and do not enumerate internal hostnames; lsn-docling and lsn-grafs appear nowhere in published content. CT is a better fit because it is machine-readable, exhaustive, and specifically designed to be monitored.

Is onyx.shuffle-on.com at the top because it is ours? No โ€” there is no service called onyx here, and no certificate has been issued for that name. It is the clearest evidence that some of the guessing is ordinary product-name enumeration (Onyx being a self-hosted search platform) rather than reconnaissance derived from us. The list is a mixture of both, and the letter should not claim otherwise.

Does the branded 404 leak anything? Checked directly. The invented hostname and a real-looking guessed hostname return the identical page, identical length, identical headers. Nothing in the response distinguishes a plausible guess from an absurd one.

What to take from it

A wildcard answers maybe to every question. Wildcard DNS plus a wildcard certificate plus a friendly 404 removes every cheap negative signal a guesser relies on. Each component is reasonable; the combination means wrong guesses cost the guesser nothing and are never disconfirmed until the last possible step.

Certificate Transparency publishes your topology. Every per-service certificate is a permanent public announcement of a hostname. That is the intended behaviour and the price of the guarantee CT provides. If a naming convention is worth keeping private, the wildcard is not just convenient โ€” it is the privacy-preserving option, and the per-service certificate is the leak.

A wildcard feeds fiction to things that remember. The largest single sweep here is not an attacker: it is a verified OpenAI training crawler, 23 addresses and 11,221 requests, politely fetching /, /login and robots.txt on hostnames this estate has never operated. Every one of those fetches is a well-behaved crawler doing exactly what it should, against a host that exists only because a wildcard said it did. Letter G showed a client inventing a URL and our log recording it; this is the same shape one level up and with a longer memory โ€” invented hostnames entering a training corpus, indistinguishable from real ones, because the DNS and the certificate both vouched for them. Scanners forget. Crawlers do not.

Noise you can see is better than noise you cannot. The temptation is to drop unmatched hosts at the edge and make the number go away. The number is not the problem; it is the measurement. 92,466 requests to 324 invented names is how this letter exists at all, and an estate that silently discards them knows less about itself, which Letter E already showed is the expensive kind of ignorance.

Distinguish the defensible from the accidental. Three of the four design decisions here buy real operational value for one operator running an estate this size, and the noise they generate harms nothing. One of them โ€” publishing per-service certificates for hosts that could be served from the wildcard โ€” buys convenience and pays for it in permanent public disclosure of the naming scheme. Only that last one is worth changing, and this letter would be dishonest if it demanded the other three.

Confidence: HIGH โ€” that 324 non-existent hostnames received 92,466 requests from 6,578 addresses, and that guessed hosts represent roughly a third of edge traffic. Direct measurement from the host taxonomy over the request corpus.

Confidence: HIGH โ€” that any invented subdomain resolves, receives a valid wildcard certificate and is served a branded 404. Demonstrated live during this investigation against a hostname created for the purpose: DNS returned the estate's own address, TLS returned a Let's Encrypt certificate with CN=*.shuffle-on.com valid to 2026-09-30, and HTTP returned 404 with 6,679 bytes from nginx/1.31.0.

Confidence: HIGH โ€” that the guessing is derived from this estate's published hostnames rather than from a generic wordlist. Three independent supports: the guesses use the lsn- prefix convention; lsn-ai-staging is a construction from the observed real lsn-ai / lsn-ai-comfyui / lsn-ai-images family, as library1 is from library-search and lsn-auth-manager from lsn-auth; and the internal .lsn / .home.lsn estate, which publishes no per-host names because it is served entirely from wildcards, attracts 5 hits from 2 addresses in the entire corpus against 92,466 hits to guessed public names. The guessing tracks publication exactly.

Confidence: HIGH โ€” on actor attribution, which comes from the estate's existing enrichment rather than from new analysis. Campaign clustering had already grouped the sweeps by network before this letter was written; per-address dossiers supply agent identity, CrowdSec state and MikroTik ban status; the entity graph supplies the vhost_enumerator and probed_sensitive_host relationships. 74.7.227.6 is openai/GPTBot, confidence=verified. 136.110.61.242 is perplexity/PerplexityBot, confidence=spoofed, and already banned.

Confidence: MODERATE โ€” that Certificate Transparency specifically is the publication channel. The reasoning is consistent (per-service certificates publish exact hostnames permanently and machine-readably; wildcard-only domains publish nothing and are correspondingly unguessed) but the direct test did not run: crt.sh returned HTTP 502 on three consecutive attempts. Other channels could contribute โ€” a hostname appearing in a browser history, a link, a referer header forwarded to a third party. CT is the best-fitting single explanation, not a demonstrated one, and this letter distinguishes the two.

Verification. wt_hosts(host_type="nonexistent_guessed") for the taxonomy and counts; wt_campaigns(method="vhost_sweep") for the clusters; wt_ip_dossier(<ip>) for per-actor identity and enforcement state; wt_requests(host=โ€ฆ) for what each guessed host actually received. Reproduce the live demonstration by inventing any subdomain of shuffle-on.com and running a DNS lookup, an SSL check and an HTTP HEAD against it.

โš  Personal capacity. Research published independently โ€” not reflecting employer views. Derived from passive observation of attacks against personal infrastructure. Full disclaimer โ†’
โ† Previous The Census โ€” 8 / 14 Next โ†’