This won't produce the results you expect:
Most client OSs will cache DNS results for successfully resolved domains up to until their TTL expires. For some youtube domains, that may be hours or even days. (EDIT: Note that youtube does also utilise other domains to serve content, not only those named *.youtube.com, and be aware that a client streaming a video from an already known IP address may have no cause to request DNS resolution again until that stream ends.)
Blocking DNS resolution for specific domains at certain times won't prevent a client with such a cached resolution result from talking to a domain's IP address, as DNS is not needed and hence never queried then.
You'd have to resort to other means, e.g. blocking all associated IP addresses at gateway level (i.e your router's firewall).
Hi @yubiuser yes, the scripts work when I manually run them on the terminal. What I expected was for the domains to be added/removed from the blacklist page, and that happens when I manually run it. But it does not happen when I run it with cron.
Thanks @Bucking_Horn, you're right. I need to account for the TTL as well. Looking at the dig output it seems to cache for 5 minutes (except for the www.youtube.com CNAME record).
So I might have mixed results, but I am happy with that.
For the moment I really would like to understand what is different between running the pihole command in the terminal and in a crontab.
Youtube is serving content from a multitude of domains, not only *.youtube.com. I think you will find that most video content domains have TTLs much longer than 5 minutes.
Also, note that it's the returned DNS record that expires with the TTL, not the IP address. If a client can successfully stream content from an already known IP address, it may have little cause to request DNS resolution again before the stream ends.
(I've also updated my initial answer to make this clearer for any casual readers who happen upon it.)