Much like swatting, it's rather difficult to trace the action of a ddos back to the actual instigator, since the instigator is so far removed from the situation.
Here's a loose and totally imaginary scenario, but it illustrates the point:
Attacker wants to initiate a large-scale DDoS attack on a site.
Attacker coerces a stranger to take an action for them, either by threatening them online (I have nudes of you, etc - you'd be shocked how often that works) or by taking something of theirs hostage (like using a cryptolocker variant that encrypts a person's HDD after they download a malicious file - the malware then phones home to a dead drop like an IRC channel, which the Attacker connects to via several layers of spoofing and anonymizing.
So now the Attacker has a Rube they can give commands to, like, download this file, install it, run it, enter in such and such information, and your credit card details.
What Rube has now done, is paid for airtime on one of many black market botnets - massive networks of zombie computers all infected with malware, that don't even know they're infected.
Rube's payment goes through, and Attacker gets the pass for the botnet from Rube. Attacker never sees Rube again, and Rube still has no idea who encrypted their HDD.
Now, Attacker logs into botnet - which is just an IRC channel somewhere with a password on it (via lots of proxies, etc), and tells it to attack a series of IPs. Like say, the IP addresses that show up when you do a very basic packet sniff of your network when the Xbox boots and connects to XBL. You can't hide those ip adresses, the TCP protocol is rather honest to a fault.
So now, the botnet wakes up, and millions of zombie PCs all start sending SYN packets to the IP addresses. Some of the servers, seeing the familiar SYN request for a synchronize, answer. They have to - that's how the internet works. They ACK, acknowledge. Now they wait for a SYN-ACK from the client who was trying to connect. Except the client isn't trying to connect, and while this was happening, a million other SYN requests came in. And the server has to ACK them all, and if it tries, it falls over.
However, most servers have mitigation in place - which is a complex process, this video explains it better:
http://www.dailymotion.com/video/x14...os-attack_news
At best, the mitigation keeps the server alive, but now end-users might find themselves having a hard time connecting, since there's all this checking going on. They might go into a queue, or just be denied outright and told to try later.
And so the botnet continues to slam the servers, and others along the way, depending on how the command and control is set up. If it can't take down its target, it tries for one layer back, like the datacenter, or the ISP the datacenter uses, or the main trunk that leads to that ISP, and so fourth.
Meanwhile, who is Attacker? Nobody knows. How do you find out? That's a damn hard question to answer. You might, at best, discover Rube through investigations, and initially think Rube is Attacker, since they paid for the botnet access - but Rube claims innocence, but there's no way for anyone to figure out who Attacker was. Unless Attacker was sloppy, and left something in the malware that might lead back to them. Perhaps the investigation might get to the IRC channel the info is shared on, and the investigation team "fakes" being caught in the malware encryption trap, and tries to use the situation to get Attacker to out themselves. That's happened once or twice, but it's still rare.
(Ack, sorry for the wall of text)