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
