Step by step
- Confirm it is a mirror rather than the original. Compare the mirror's domain against bunkr.sk exactly, character by character. Look-alike domains differ by a suffix, a hyphen or a single letter, and a notice sent to the wrong party achieves nothing.
- Resolve who answers for the mirror's domain. Run the DNS and registry lookups against the mirror's own domain, not against bunkr.sk. A mirror frequently sits behind a different network with a different published process.
- Check whether the mirror is fronted by a large network. Most mirrors sit behind a network that publishes an abuse process. Detecting that network is what turns an anonymous domain into a recipient with a documented complaint route.
- File against the mirror as its own host. Send a complete notice naming the mirror's URLs and the original work, addressed to the parties the mirror's own lookups returned. Referencing the bunkr.sk filing as context is useful; substituting it is not.
- Delist the mirror separately. A mirror is a distinct domain and a distinct set of search results. Delisting requests filed against bunkr.sk URLs do not cover it, so the mirror needs its own submission.
How openDMCA identifies the host behind a bunkr.sk mirror
Detection runs over DNS-over-HTTPS: the domain is resolved to see which network is answering for it, and where a large network is fronting the origin, the abuse report is filed with that network rather than with the anonymous domain.
That report does not remove the file. It reaches the origin host and the origin host's provider, which is the part a creator cannot do from the outside — the whole point of the mirror is that the operator is not directly reachable.
Each mirror is stored as its own leak with its own host and its own routing history, so a mirror that ignores notices builds its own record rather than inheriting bunkr.sk's.
openDMCA gives the first two hops away: you can open the network-behind-the-domain check and run it on a URL of your own, with no account and nothing uploaded.
One thing that catches people out on bunkr.sk
A mirror is stored against its own hostname rather than folded into the bunkr.sk record, which means it accumulates its own removal-rate history from the first notice. That matters because a mirror operator and the original host respond differently, and inheriting the original's routing decisions would send a mirror straight to delisting before anyone had tested whether it answers email.