About 3 or 4 weeks ago (that I know of) Google started using https to send google searches if at a machine a user is or has been logged into their gmail/google apps account. For example, if I sit down at a client machine and bring up google and do a search it goes through http, but if I log into my gmail account and then go to google and do a search for anything web or images it will go through https. My problem with this is that I am at a high school that uses Google Apps for Education. If one of my students logs into his/her own private gmail account or their school account and then does a google search their google search is not filtered by our web content filter in any way shape or form. I've tried 2 different, well known web filtering hardware devices (Fortinet's Fortiguard and cipafilter) and neither of them can turn an https google search into a safe-search that doesn't produce offensive results, especially images. I was helped greatly by a support tech at cipafilter in everything we've found so far.
Google has a fix for this, but the fix doesn't work for Windows Server 2008R2. I contacted Google Support and had them step through the steps to create the fix, but every time I got an error at the end and it wouldn't create the cname record that is needed in Google's fix. (My conversation with Google and the errors associated with this post are below). Google told me that I performed the procedure correctly, so it must be a problem on my server. I went to another school last night. This school also has a Windows Server 2008R2 DC so I tried to perform the fix for them and we got the same error on the Win Server 2008R2 machine, but they also have a Windows Server 2003 DC and we got the fix to work on the 2003 machine and then it did replicate to the 2008R2 machine. Another guy I know has a 2008R2 server and he tried it on his and he got the same exact error also, but he has a 2008 Server DC also in his domain, and it did allow him to add Google's fix to the 2008 server and then it replicated to the Windows Server 2008R2 DC fine. I DON'T HAVE ANOTHER SERVER OS IN MY DOMAIN!!!!
I do have a very flimsly workaround up and running. I created a host A name record pointing to the ip address of nosslsearch.google.com, but that IP could change at any moment and already did change overnight last night.
My recap of my conversation with Google Support emailed to the support tech I talked to:
Samir,
To recap, Google is now automatically forcing all signed-in Google accounts to use their SSL search, providing a workaround for school network adminitrators. The reference material for this resides within the following Google write-up:
http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=173733
As Google has stated in this article, "To utilize the NoSSLSearch option for your network, please configure the DNS entry forwww.google.com to be a CNAME fornosslsearch.google.com. We will not serve SSL search results for requests that we receive on this hostname."
Following those instructions, we have written an article within our knowledge base that conforms to the specifications in which Google has deemed necessary, in order to disable SSL-based searches. Please refer to the write-up, which is attached to this email in PDF format. As we have supplied this information to school adminitrators, a trend has become visible: This solution is not possible in Windows Server 2008 R2. The attached screen capture demonstrates what happens when attempting to follow Google's recommendation, creating a forward lookup zone for "www.google.com" and creating a corresponding CNAME for "nosslsearch.google.com". The error states:
=================
DNS
=================
A new record cannot be created.
An alias (CNAME) record cannot be added to the DNS name. The DNS name contains records that are incompatible with the CNAME record.
I've spent a great deal of time researching this issue. After much troubleshooting, research, and review of forum postings, there is one major issue with Google's offered solution. Google is requiring administrators to perform an action that is prohibited under RFC 1034, section 3.6.2. "Aliases and canonical names", which can be referenced here:
http://tools.ietf.org/html/rfc1034
The specification states:
"If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types."
Microsoft has also published a Technet article discussing the additon of a Resource Record to Forward Lookup Zone:
http://technet.microsoft.com/en-us/library/cc816819(WS.10).aspx
Contained within this article, you will find an important note which explains the occurance of the error in the DNS Manager. As the note states:
"You cannot create an Alias (CNAME) resource record for a name if there is already a DNS record for that name.This includes the root of a zone; that is, you cannot create an alias (CNAME) record for the root of a zone."
To sum up the issue, it is not possible for a Windows Server 2008 R2 administrator to create a CNAME record at the root of the zone "www.google.com". The only way to accomplish this would be to create a forward lookup zone of "google.com", and then create a CNAME for the alias "www", and redirect the traffic to "nosslsearch.google.com". However, doing this turns the local DNS server into the authoritative DNS server forgoogle.com, effectively breaking every single other service that Google offers (Docs, Gmail, Calendar, etc.).
At this time, the only functional workaround I have devised is to create a forward lookup zone for "www.google.com", and create an A record for the root that points at the IP "74.125.45.114". While performing this action appears to be effective in my testing, it is not an acceptable solution as Google can change IPs, or distribute the work among several IP addresses at any point in the future.
I am under the belief that Google cannot offer this as a solution, nor my proposed workaround, and must come up with an appropriate solution to this issue that is RFC compliant. Please resolve.
Google's Response was:
Hello Jim,
Thank you for your message.
I contacted my support team about the matter. The set up looks like it was done correctly through the screenshot. The only support I have is the articles that you shared. We at Google Apps, cannot assist you further in troubleshooting as for why the issue is still happening. I was told that you must check the settings on your servers. The settings that you entered correctly are the same for different domains and different servers wanting to do the same as you are. If this fails, escalate with the DNS or our admin. I have no one who can help with the error you are getting.
Feel free to answer to this email with any other comments or questions, it would be a pleasure. This case will close in 3 business days.
Sincerely,
Samir
Enterprise Support
So at this point I'm screwed. I can't do google searches with safe-search turned on automatically without the A host record pointing to an IP address that can change any second and will. Google says it's my settings, but they don't know they didn't even look at my settings. Every other Windows Server 2008R2 machine I either, personally try it on or know that someone is using these exact directions to make the safe-search fix (which Google has seen and approved - I sent them a copy of the article we made to use and they said it was perfect), has the exact same error.
So...hopefully someone here can give me a clue of where to look OR someone from Microsoft who is looking at this forum and somehow get Google to believe it's an prohibited fix and cajole Google to fix this issue. I can't be the only school that is going to encounter this problem and only has Windows Server 2008R2 DCs.