1. What is the goal of DNSSEC?
DNSSEC signs DNS records. It does not encrypt, it just confirms authenticity.
The root signs keys from TLDs (such as .org or .de), TLDs sign keys from registrars, and registrars sign the DNS records that you (probably) put in via their web interface.
You can also have them sign your keys so that you can maintain a signed zone yourself.
DNSSEC exists of fields added to domains, so it's not something that works for every website after you turn it on for your computer. If a registrar does not support it, or if a TLD does not support it, your computer just cannot verify the authenticity of the records of the domain you're querying.
2. Who has to have it enabled in order for it to work?
We've already covered the root, the TLD of your choice and the registrar. Now ISPs or other recursive resolvers (e.g. OpenDNS) can also have it enabled or not. Having it enabled means their resolvers will check signatures and return an error code if the validation fails.
The user's client also has to have something enabled in order for it to work: if your client (e.g. Firefox) does not alert on an invalid signature, the signatures will never add any value.
3. Who signs a domain?
The registrar either signs your records or the key with which you sign your records. So you trust the registrar. If you don't trust the registrar, you will have to get a different one. And you trust the TLD, since they could just sign it with any key they like (since they can sign registrar's keys). And you trust the root for the same reason.
4. How can clients detect a signature being removed?
If someone removes the signature, presumably to modify records without triggering a signature validation error, it might appear that the domain simply does not have DNSSEC enabled. However, the parent signer (the TLD) will have mentioned that DNSSEC should have been enabled for the domain, and the TLD's response is signed so cannot be forged.
So what if we remove the TLD's signature as well? Alright, then the root will tell us (with signature) that the TLD should have had it enabled.
If the root is trustworthy, and the root only signs legitimate TLDs, and the TLD is trustworthy, and the TLD only signs registrars, and the registrar is trustworthy, then you can be sure the signed records came directly from the domain owners.
5. Bonus: Does DNSSEC have any issues of its own?
It makes responses bigger (not a security but a performance issue) and helps domain enumeration.
Domain enumeration is made possible because of the way they solved NXDOMAIN signing. Signing is meant to be done offline so name servers don't have to sign things on the fly. But how do you sign a response, in advance, for something that doesn't exist? By signing a response that says "between ftp.example.com. and mail.example.com. there are no other records" and returning that when anyone asks for something like jkl.example.com.
Now to enumerate, you start with aaaa.example.com. and it will tell you the first record, like ftp.example.com. Then you request ftq.example.com (one character incremented) and it will give you the next record.
This was solved by hashing the names and going "between hashes a8fba8[...] and da8a8bfdf[...] there are no other records". This is called NSEC3. This still allows for hash enumeration and then offline cracking the hashes, which is orders of magnitudes faster and stealthier than guessing by querying the name servers.
It's an ongoing discussion whether it's an issue that names can be enumerated. The people who design DNSSEC typically say that the DNS system was supposed to be a public phone book; the people who deploy DNS servers typically prefer to keep their phone book private.
 "you tell your registrar your signing key's fingerprint by creating a DS record" https://security.stackexchange.com/a/11571/10863
 "they enable their DNS resolvers (which you use to translate fancy domain names into IP addresses) to verify DNSSEC. So from now on, if you ask your ISP for the IP for a domain and the signature is invalid, you will get an error instead of the wrong IP." security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626
 "It's up to the client to prefer (or alert) on non-signed responses, just like TLS on a web browser." security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604
 https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Recursive_name_servers "If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on"
 https://security.stackexchange.com/a/11571/10863 "DNS (and DNSSec) was designed largely by folks in the first camp; [...] the servers tend to be run by people in the second camp"
 https://dnscurve.org/nsec3walker.html See "Future work"