You can do as I've suggested, and use a firewall that denies port 443 for www.google.com,
Others have suggested that a web proxy would be an alternative, especially one that can deny URLs with a bare IP address, and I'd agree that this is also going to prove useful. DNS is not your answer. Kurt On Mon, Feb 13, 2012 at 17:53, Kennedy, Jim <[email protected]> wrote: > > I really appreciate this and hate to impose more but....did anyone have any > ideas how to skin this cat. Bottom line is I need to CNAME www.google.com to > nosslsearch.google.com without having to run all of Google's DNS in house > manually. I skin this cat or I kill Google Docs for our students, and it > actually is really helpful for them, it helps a LOT. And I like to deliver > stuff to users that helps, minus the demons flying out of my nose of course. > Or I allow Google Docs and block Google search, that would be even worse. > > I am even open to putting up another DNS server that can CNAME this record > and fall over to root for the rest of google...then direct my AD DNS to that > on a conditional forwarder. The original suggestion to do this came from > Google specifically for the situation I am in. Get search off SSL so the > filter can append the request with safe search mode. I would be surprised if > their solution totally misses the mark. > > Again, I really appreciate your help on this. Free ticket to Derbycon this > fall if you want to go, just ping me. Ticket to get in, not an airplane > ticket. :) > > > ________________________________________ > From: Ben Scott [[email protected]] > Sent: Monday, February 13, 2012 5:48 PM > To: NT System Admin Issues > Subject: Re: DNS Partial zone CNAMEs? > > Okay, the consensus on dns-ops is that this is broken and shouldn't work. > > Specifically, a construct of the following form is invalid: > > www.example.com<http://www.example.com>. SOA blah blah blah > www.example.com<http://www.example.com>. NS > ns1.example.com<http://ns1.example.com>. > www.example.com<http://www.example.com>. DNAME > elsewhere.example.net<http://elsewhere.example.net>. > > The problem is that DNAME is intended to apply to child names of the LHS > name ("record owner"). It should not apply to the owner name itself. > > This is made explict in the next draft of the DNAME specification, which > states: "a DNAME RR redirects DNS names subordinate to its owner name; the > owner name of a DNAME is not redirected itself" (emphasis added). > (draft-ietf-dnsext-rfc2672bis-dname-25, section > 2.3<http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-25#section-2.3>) > > So, while you're of course free to do this anyway, it may cause demons to > fly out of your nose<http://catb.org/jargon/html/N/nasal-demons.html>. More > likely, some future hotfix or Service Pack may take it away. That's > especially likely if the proposed client-side support for DNAME ever makes it > out of committee. > > You Have Been Warned(TM). :-) > > -- Ben > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to > [email protected]<mailto:[email protected]> > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
