That would still be a terrible idea. If you do it domain-based it's obviously insecure (validate -> change a-record -> attack), if you do it IP based you basically allow attacks on cloud services that rent cheap virtual servers.
Also keep in mind that a DDoS affects infrastructure on the way whose operators have not consented.
I don't really think there's an ethical way to run a DDoS "stresser" service on the public Internet.
What about a file-based validation? Require that a file be located at the root of the server with a validation code, and check that file regularly during the stress test.
The only way I can think around that would be to have a reverse proxy that forwards most traffic but not requests for that one file, but then your DDoS isn't actually distributed.
I wonder why people even do ddos attacks. What possible gain could there be from denying a service for a short while? Maybe competing webshops? It’s still seems overly childish to me. That said I never really looked into this.
1. Money. Most online business can't make money if they are offline. If being offline or unstable is costing you $x / hour and you can stop it by just paying a fee. It's an easy way to end it.
2. Hurt your competition. In some online businesses DDoS attacks are used to compete with other businesses since if your competitor is offline more people will come to you.
3. Power. Some people want to flex the power they have over others.
4. Fame. You can get notoriety for taking something offline.
DDOS can be the definition of a heckler's veto. It's like blasting super loud music so nobody can hear what a person is saying.
Dont like what a site is saying? DDOS so it cant load and people cant read it. For bonus points you are preventing site from getting clicks and thus ad revenue.
There are communities on discord that setup donation links to make sure sites they dont like keep getting hit by DDOS via crowdfunding.
How is domain-based insecure? There are tons of services that use DNS records to validate ownership of a domain. If someone has managed to get control of a domain and modify its DNS records, they can do a lot more damage than a DDOS.
Domain verification doesn't do anything to prove that the target is a willing participant. A DNS record doesn't indicate that you own the underlying IP or CNAME target. At best DNS based verification are only good at verifying things that specifically relate to the domain (SSL for example).
But the DDOS attack isn't against the domain, it's against whatever server the domain points at.
Requiring the owner to post a file at a specific URL would prove actual control of the server in a way that domain records don't. I can point a domain at whatever server I want, no need for it to be my own.
Agreed, when I read this my first thought was it'd have to be some sort of IP based authentication, so you'd have to have a way to prove ownership of the target IP itself, however this doesn't really solve the problem of upstream impacts. Your ISP, colo facility or dedicated service provider probably won't be ok with you running these kinds of tests on their network.
Would be nice for ISPs if they could get something from the DDoS site that their customer authorized it, then they could drop the account and not feel bad about it.
Typically a service using domain verification will ask you to create a specific, randomly generated TXT or similar record on your domain. After you’ve created the record you click a button or something and they do a query for it.
Only someone with access to DNS for the domain can create such a record.
No I didn’t. I was speaking to domain name validation generally - as in a way for you to prove your ownership and control over a domain name.
Yes, of course DDoS or any kind of traffic can be pointed at an IP or any arbitrarily created DNS record.
The only way for a “reputable” stress testing platform to validate IP space would be RIR validation via WHOIS or similar, PTR records, etc. Of course this isn’t practical because most people don’t control their IP space or even have the foggiest idea what any of that means (because why should they).
> Only someone with access to DNS for the domain can create such a record.
That's why OP specified their DNS record. You buy/use a random domain name you own, point the A record at the IP you wish to attach, and then simply complete the TXT record verification since you have full control over the domain, while the booter resolves the A record to the true target.
I wouldn't, but all of the incoming requests would be served on your domain name, so it would be pretty easy for me to find out who that was registered to (or at least who the registrar is) and have it flagged for abuse. Bonus points if the "legit" booster site add their abuse contact info as header or user-agent.
> all of the incoming requests would be served on your domain name
No, most (?) DDoS attacks aren’t botnets sending HTTP requests directly, those would have terrible throughput and be trivial to mitigate. Instead they use amplification from third party servers where you send a small packet to get a big packet in response, mistakenly routed to the victim. There’s usually no way to attach a Referer to those, most of which aren’t even HTTP-based.
Because you don’t control my domain. Suppose I own joespizza.com and you want to attack it using a supposedly legit load-testing service. You would go to the service, sign up, enter joespizza.com/order as the page you want to test, and then be given a random string to add to a TXT record on joespizza.com. You don’t own joespizza.com, and you haven’t compromised my hosting service account, so you can’t create a legit DNS record. The service refuses to stress test my site, and you move on to the next thing.
I imagine that I would register tedspizza.com, create a TXT record that says blast away, and set the A record to point to the same IP as joespizza.com.
Also keep in mind that a DDoS affects infrastructure on the way whose operators have not consented.
I don't really think there's an ethical way to run a DDoS "stresser" service on the public Internet.