The Internet is simultaneously incredibly useful for education, but also carries significant risk - and it is often a regulatory or other legal requirement to filter content for minors (or just something you know parents want done, or you believe is ethically desirable in less "controlling" regions of the world).
Google (having deprecated header-based mechanisms, which didn't even work properly) offer a number of very useful DNS-based mechanisms for enforcing control of questionable content for your users, both on YouTube and for Google search.
Of course, this requires some DNS hacks.
And when Microsoft changes the way their DNS hacks work, things break...
It seems simple enough. Get queries for various domain names to return safesearch.google.com or restrict.youtube.com.
Google suggests using CNAMEs for this. Of course, Microsoft's DNS server (MSDNS) doesn't support this (at least not the way they need to be done for this), and they say you should use DNAMEs instead.
This worked very nicely.
Until it didn't.
In particular, YouTube apps on mobile devices got grumpy at the authentication stage, and it seemed to be after a particular version of the YouTube app came out (presumably because they started using a different address for the authentication process). This meant no in-app YouTube for several months...
As you could still access it through a web browser, I left this for a while (amidst piles of more critical problems). Eventually, it got to be enough of an issue (embedded links in e-learning apps that just automagically open in the YouTube app, rather than giving you a choice to open in a browser) that I investigated further - after first (incorrectly) assuming a filtering problem with our firewall.
In their infinite wisdom, they (Microsoft) changed something in the way DNAMEs work. In typical fashion, they don't shout from the rooftops that things are broken now. Googling the issue, it seems to be widespread, and is apparently typically related to KB3133954. It seems to affect 2012 and later DNS servers (2008, if anyone is still running that, seems unaffected, apparently).
Hint: If you're not seeing expected traffic being logged through your firewall, even though you've set it to show you EVERYTHING, it's possible that there is a DNS problem.
This means that any DNS hacks using you have in place to make sure your users aren't exposed to questionable content through Google/YouTube probably broke if you did it "properly" using DNAMEs.
There is another even uglier hack (ugly because there is no way to keep up automatically if Google changes where those records need to point) that works around this impasse - create an A record in each hacked domain pointing to the correct IP address for the CNAME record corresponding to the level of restriction you would like to implement. I recommend fairly short TTLs (how long you can bear to be without service X should be a good guideline - for critical services, 5 minutes is often a reasonable rule of thumb). There is of course another option - dump MSDNS and use BIND or Unbound etc..
Make sure you query DNS outside of your hacked DNS servers to ensure you get the right IPs for the domain names Google suggests you CNAME to, and make a mental note (or write it in your documentation) that IF THESE IPs CHANGE THINGS WILL BREAK (and you need to go change them in your DNS).
Google SafeSearch Virtual IP Address (VIP)
See Google's Documentation for the records you need to create.
From here, at the time this post is written, the IP for this is: 216.239.38.120 - you should verify this is correct for you before using it.
You willl need to then enter this as an A record for www.google.com in your DNS server(s).
If you have sneaky users (children are sneaky users), you may also need to do this with all supported google ccTLDs (193 of them!), or otherwise block google ccTLDs that you don't think are really necessary.
YouTube Content Restriction VIP
See Google's Documentation for the records you need to create.
From here, at the time this post is written, the IPs for this are: 216.239.38.120 for restrict.youtube.com and 216.239.38.119 for restrictmoderate.youtube.com - you should verify these are correct for you before using either, and you need to determine which is appropriate for you. Make sure you update ALL the records needed for this to work. (see the Google guide linked above) - sadly, because DNAME is broken, you can't just "hack" restrict.youtube.com and point the others at that with DNAME - they all need A records. The nice thing about this is you can still give e.g. teachers more access through GSuite admin tools, so long as they are signed into their corporate accounts. This means they can all be "approvers" of content for your domain, meaning they don't have to bother (or wait for...) overburdened IT staff to get some random video to be playable.
 |
| Here is part of the YouTube DNS hack for www..youtube.com You can see the old (broken!) DNAME mechanism, and the still working A record mechanism (highlighted) You can see DNS hacks have a number of uses... (particularly when your ISP blocks NTP; most of those records make device NTP work again by redirecting clients to our internal NTP servers) |
You can also enforce some of the behaviour through various policies in GAFE/GSuite for Education admin control panel user settings (YouTube; see also Safe Search here), but these require the user to be signed into your Google domain account to be enforced.
What you want to ensure is that there isn't an easy workaround of "just don't sign in" or "use an alternative Google login" (seems harder to block)...
DNS hacking - so long as you block 3rd party DNS through your firewall - helps to achieve this.
No comments:
Post a Comment