Forcing Google Safe Search on LAN - ML Server DNS?

Ah, OK. You're trying to adjust searches, and not DNS queries. My bad.

You've got the right pieces and are almost there, but there'll be a few other steps — see below, and see my previous reply — beyond whatever documentation you're reading.

To set up what will be an unfortunately porous block against access to the Google search filters, yes, CNAMEs are alias entries. The description that you're following is setting up a different translation of www.google.com — users that enter that domain name will get their query forwarded to your DNS server, and your DNS server then returns the IP address associated with the "wrong" (alias, CNAME) host here; the address(es) of safesearch host server(s) at Google.

You'll need to set up DHCP and static hosts to refer to your DNS server, and no other DNS servers. Again, firewall outbound DNS traffic, except from your DNS server(s).

For background, http://labs.hoffmanlabs.com/node/1436provides an introduction to DNS terms and concepts as applied to OS X Server. No screen shots, though — feel free to complain to the author of that web page, of course.

If you really want to understand more about DNS, there's far more detail on DNS in Cricket Liu's DNS and BIND book — that was the 5th edition, last I checked — and BIND is the DNS server in OS X Server.

Why do I use "porous" here? This CNAME alias won't be particularly effective for anyone inclined to bypass it, so you're (still) going to have to block all of the (trivial) bypasses and all of outbound DNS queries except those from your DNS server. You'll also probably want to block Bing, DuckDuckGo, DogPile and other search engines, too. It'll also be possible to get to the full Google search with a simple edit to /etc/hosts, too — hopefully the clients are locked down against that. Also bypassed by entering the IP address 216.58.219.228 into the menu bar (dig www.google.com on some other network, then use the address on the locked-down network), or one of the various other Google servers are being offered from the pool of Google search engine web front-end servers. That list varies over time, and by network locality, too. That's all before discussing outbound VPNs and tunnels, too — those also bypass these blocks.

As for the domain usage here, I have watched more than a few sites crash and burn with ill-chosen domain names over the years, and all because of unfamiliarity with DNS and/or to save the cost of a yearly domain registration. FWIW, the longer this usage is in place, the more entrenched and more effort the domain names migration generally becomes, too.

I will presume this configuration uses network address translation; a private IP address space within one of the three designated private IP blocks.

Set the DNS forwarding server to refer to the specified Google DNS servers. This within the Server.app settings for your local DNS server. Click the edit off to the right of the forwarding server, and fill in the specified Google "safe" search servers. Configure all static-configured IP hosts to use and all DHCP servers to vend only the address of your local network DNS server(s). Reference no other DNS servers.

Configure your network firewall to block all outbound DNS queries, except for those originating from your OS X Server. That's TCP and UDP port 53, outbound, except for those queries arising from your designated DNS server(s). Do not allow inbound DNS queries — block all such queries at your network firewall.

Recognize too that none of this "safe" blocking actually works as envisioned, nor — short of a whole lot of hardware or of air-gapping the whole network — really can it work. It's easy to bypass these "safe" features.

I do not know if you are attempting to obfuscate your domain or if you are actually using .pvt as your top-level domain here. If the latter, please don't use a domain that you don't have registered. Please avoid trying to invent a top-level domain. This because you do not have that ".pvt" registered, and — with the ICANN plans to add thousands of new global top-level domains — avoiding a real domain is getting more difficult. There are a large number of existing and new global top-level domains active, just shy of 2000 new global top-level domains are pending, and sooner or later somebody's going to ask for that .pvt global top-level domain. Please either pay for the registration, or — where you have permission of the registrant — please use a subdomain of an already-registered domain.

Those Server.app alias entries are how you add CNAME (alias) entries. Exactly what you showed. It works, and I've used it here. No need to edit the zone files directly. Add a dot at the end of the names — what's called an FQDN or fully-qualified domain name — as that's part of DNS syntax.

I think I can answer your problem but first I think it will help to explain some of the basics of how DNS servers work.

A DNS server is responsible for mapping a human readable name, to a computer readable numeric address. As it is not really relevant here we will ignore the differences between IPv4 and IPv6 numeric addresses. Less widely known is that DNS servers also do the reverse process they can take a computer friendly numeric address and look up the matching human friendly name. (So called reverse DNS lookups.)

Now while all DNS servers do the above, they normally can only define records for domain names which they are responsible for i.e. own. So you are responsible for your internal private .pvt domain and if you had bought a domain like for example mydomain.com then you could also define records for that. However you don't own the google.com domain so strictly speaking you should not be creating records for this domain on your DNS server. In fact based on their instructions you would also need to create records for all the other google countries as well, e.g. google.co.uk, google.ie etc.

To do this using Apple's DNS server in Server.app you would first have to create each domain name as a zone i.e. creating google.com, google.co.uk, google.ie and so on. Then you would be able to create records in these domains including in this case an alias i.e. CNAME record.

However there is a big problem here, if you create for example the domain google.com this way then your client computers assume your DNS server will be responsible for looking up all hosts/records for that domain whatever they might be so not only www but mail, and any others that google use. If you don't also create these as well then they will fail when your clients try to look them up and as a result you will not be able to access them. Obviously it is impossible for you to know all the hosts/records they use in their domain names.

To summarise in order to create an alias in/for the google.com domain i.e. aliasing www.google.com and forcesafesearch.google.com you need to create the domain google.com (and the others) and this will to put it mildly break all other google records for those domains.

It appears that Google are assuming you can create a CNAME without having to create the entire google.com domain, something as I explained that Apple's Server.app software does not let you do. Apple actually use the standard BIND aka. named DNS server software the same software used by the majority of Linux servers and Unix servers. It is possible to manually edit the configuration files for this software and this is how Linux system administrators usually do it in any case. Apple store the configuration files in /Library/Server/named/

What I cannot tell you is how you could manually create or edit one of these files to accomplish this. I did find this article https://productforums.google.com/d/msg/websearch/srXRvrF1ERg/qtvZfsaWsIQJ which does appear to describe how to do this on a standard BIND server. You would need to create the suggested db.rpz file and what is not mentioned you would also have to modify the named.conf file produced by Apple to add instructions to load this additional db file. Whether this will work with Apple's software is something that you would have to try to find out.

The second approach which on the face of it is far simpler is to edit the /etc/hosts file on each client computer. One can then put records in which say that for example www.google.com is IP address 216.239.38.120 i.e. the current IP address of forcesafesearch.google.com then this will override a DNS lookup of www.google.com and redirect it to the IP address specified causing the search to go to the forcesafesearch.google.com server.

The problem with this /etc/hosts approach is that it needs to be done on each client computer rather than on a single server. Also it is not possible to do this on iPhones and iPads.

The third approach is to use a proxy server. With this approach you do not make any changes to your DNS server, you also do not make any changes to the /etc/hosts file on each computer. Instead all web traffic including for example http://www.google.com is sent via the proxy server. The proxy server would then be configured to send any traffic intended to go to www.google.com or www.google.co.uk or others to be sent instead to forcesafesearch.google.com.

This sounds like it may be the best solution for you. To do this will require the following.

1. Setup a proxy server, e.g. the free Squid software
2. Set the proxy server to redirect the desired addresses to forcesafesearch.google.com
3. Set all your client devices to send web-traffic via the proxy server

Note: I have previously setup and used Squid on a Mac server but you can also use a Linux server just as well. (Some would argue better 🙂)

There is a way to automatically advertise a proxy server to client devices called WPAD (Web Proxy Auto Discovery), this can be done using Apple's DHCP and/or DNS servers by adding the appropriate records and turning on an option on client devices including Macs. You also need to create a proxy.pac configuration file also known as a wpad.dat file and have this made available via an internal web server e.g. http://www.pvt/wpad.dat

A fourth approach is to use a dnsmasq server. This is a special type of DNS server which is solely used to 'spoof' DNS records and would in this case automatically and invisibly to users redirect www.google.com etc. to forcesafesearch.com. This is not available or at least not 'off the shelf' for a Mac server but is easily available for a Linux server. Some routers might have this built-in for example some Cisco boxes can do this.

As should by now be very clear what you are trying to do is very much an 'advanced' level issue. If you do not feel confident you should perhaps get someone in to assist you.

Finally, if the goal is merely to prevent displaying inappropriate images you could use a different approach which is to block access to websites holding those images. There are lots of solutions to 'filter' web activity and prevent accessing adult and other inappropriate categories. So in they they could try searching but should not be able to see such results. I would also remind you that there are other search engines besides Google such as Bing, DuckDuckGo and so on. I can also tell you that any appropriately knowledgable person will be able to get past any measures you put in place no matter how hard you try. All you can do is your best efforts and show to people that you have made such best and reasonable efforts.

John Lockwood has a much better idea: use a web proxy server, and configure the firewall to force all outbound traffic through that and through your DNS server.

As for your question, the zone files are located at /library/server/named. Use only TextWrangler or a command-line editor such as pico to edit the zone files. Only use a text editor that reads and writes plain-text ASCII files. Server.app might also become unstable, too.

To get the Safari clients to recognize the web proxy server, you'll have to configure the DHCP server to offer options 66 and 120. There's a discussion of that available in the forums, and — as discussed over there — the OpenSSL commands to decode and to encode the address settings string are available in that thread.

This too will involve hand-editing the DHCP configuration, which might also cause Server.app to become unstable if you're using OS X Server for DHCP.

MrHoffman wrote:

To get the Safari clients to recognize the web proxy server, you'll have to configure the DHCP server to offer options 66 and 120. There's a discussion of that available in the forums, and — as discussed over there — the OpenSSL commands to decode and to encode the address settings string are available in that thread.

This too will involve hand-editing the DHCP configuration, which might also cause Server.app to become unstable if you're using OS X Server for DHCP.

I only had to define DHCP option 252 which Apple call dhcp_proxy_auto_discovery_url

For the benefit of others the relevant text to insert in to /etc/bootpd.plist would be

<key>dhcp_proxy_auto_discovery_url</key>

<string>http://wpad.yourdomain.com/wpad.dat</string>

In this case because this option is a built-in one supported by Apple it is not necessary to encode the string using OpenSSL or my far friendlier utility. See http://jelockwood.blogspot.co.uk/2013/06/dhcp-server-on-os-x-server.html

As per my previous message in this thread you need to have a web server at that address 'serving' a suitable wpad.dat aka. proxy.pac file. To be double safe I created a Unix link between the names wpad.dat and proxy.pac so both file names work and return the same 'file'.

DHCP options 66 and 120 are for VoIP configurations and nothing to do with proxy servers.

Adding my 2¢ -

Our normal DNS servers are on a windows 2008 server box, but our windows network consultants were unable to force safe search without breaking the rest of the google domains. So they asked me to try on OS X server.

I spent a couple of days trying to get one of the DNS / BIND solutions to work on Mac OS X Server 5.0.15 to no avail.

In the process I came across a few posts relating to back to Windows Server configuration... finally when I got fed up with OS X server, I gave Windows 2008 a try myself.

For Windows 2008 Server R2, configuration is quick and easy and WORKS.

GOOGLE SAFESEARCH

- Forward Lookup Zones / New Zone Wizard

- Create Primary Zone leaving almost everything blank / www.google.com

- Within the new zone / Other New Records / Create DNAME record

- Leave alias name blank, enter forcesafesearch.google.com

YOUTUBE RESTRICTED MODE

- same process as above except use restrict.youtube.com for all the domains listed here:

https://support.google.com/a/answer/6214622?hl=en

After celebrating our success, WE HAD HEAPS OF COMPLAINTS FROM TEACHERS WHO COULDN'T ACCESS BENIGN VIDEOS.

Our solution was to create multiple profiles in our sonic wall, and use 2 different DNS servers. Our general profile pushed 1 DNS server as a force safe-search server, for all student machines & guests (it's the default that DHCP pushes); and then use a different DNS server without restrictions for teachers / staff (pushed by our sonic wall via teacher profile which is assigned to specific IPs, and teacher laptops assigned those IPs via mac address).

YOUTUBE RESTRICTED MODE DOES NOT APPLY TO THE YOUTUBE APP, the app just goes right around it. So if you're trying to protect iPads, delete the main Youtube app and just have people use youtube via Safari or the youtube kids app.

Some people decry the DNS solution as easy to work around. However we are finding it good for these reasons:

- K-8 students aren't typically savvy enough to manually change DNS settings

- our client computers have network & other settings locked out from student users, so they can't update them anyway

- The network-wide solution gives us less liability because even guest devices on DHCP are restricted (unless they have been manually tampered with)

Hope our journey helps some people!

- Koa Siu

Buellton Union School District, CA