Here is a valid reason for adopting DNSSEC or DNSCrypt. It's likely they're
using deep packet inspection. Using VPNs seems like the only valid solution
here for now.
Result from "dig youtube.com":
; <<>> DiG 9.8.3-P1 <<>> youtube.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21333
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;youtube.com. IN A
;; ANSWER SECTION:
youtube.com. 86091 IN A 195.175.254.2
;; Query time: 25 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat Mar 29 13:59:52 2014
;; MSG SIZE rcvd: 45
Result from "dig youtube.com @4.2.2.2":
; <<>> DiG 9.8.3-P1 <<>> youtube.com @4.2.2.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61182
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;youtube.com. IN A
;; ANSWER SECTION:
youtube.com. 197 IN A 173.194.113.38
youtube.com. 197 IN A 173.194.113.40
youtube.com. 197 IN A 173.194.113.33
youtube.com. 197 IN A 173.194.113.35
youtube.com. 197 IN A 173.194.113.41
youtube.com. 197 IN A 173.194.113.37
youtube.com. 197 IN A 173.194.113.39
youtube.com. 197 IN A 173.194.113.36
youtube.com. 197 IN A 173.194.113.34
youtube.com. 197 IN A 173.194.113.32
youtube.com. 197 IN A 173.194.113.46
;; Query time: 78 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Sat Mar 29 14:33:53 2014
;; MSG SIZE rcvd: 205
Clip from the whois result on 195.175.254.2:
inetnum: 195.174.0.0 - 195.175.255.255
netname: TR-TELEKOM-960902
descr: Turk Telekomunikasyon Anonim Sirketi
country: TR
If their goal is to manipulate traffic to www.youtube.com (probably to block access to certain videos), another solution would be for YouTube to require SSL for all connections coming from Turkish IPs. Of course, this wouldn't work if they got some Turkish (or other) CA to sign a bogus www.youtube.com certificate.
EDIT: As lawl points out, trying to require SSL on www.youtube.com won't work either, since they could just do an sslstrip type attack.
EDIT 2: Proof that they are in fact messing with routes to Google Public DNS anycast addresses (they're doing to same to OpenDNS): https://twitter.com/esesci/status/449902883933126659