How to block Bing Chat public for organization users and allowing Bing Chat Enterprise

[Vimaleshwara Gajanana]

Bing Chat Enterprise is made available for enterprise users.  However there is possibility that users might be using Bing Chat public.  Is there a way to force BCE for Organization users and block Bing Chat public.

[#2]

Hi Vimaleshwara, currently there is not a way to block Bing Chat public without also blocking Bing Chat Enterprise. If this changes, we will update our documentation and notify customers. We recommend leaving BCE turned on, as turning BCE off does not turn off all chat; instead, chat reverts to Bing Chat public, which does not offer BCE's commercial data protection.

[#3]

You can block the public version of Bing chat by creating a CNAME in DNS for www.bing.com that points to nochat.bing.com. Of course if you are running MS DNS servers this task is nearly impossible without screwing up the rest of the bing.com domain. What I had to do was install DNS on a secondary server that my clients do not use directly with the primary zone bing.com and a CNAME for www pointing to nochat.bing.com. Then I setup a conditional forwarder for www.bing.com on my real DNS servers that forwards the request to the secondary server.

[#4]

@Vimaleshwara Gajanana @Bradley Fox 

I followed the above suggestion to block the public version, and it worked great.  Users could only get to bing.com/chat when signed into edge with corporate profile.

Ignite today announced copilot.microsoft.com.  It's basically the same thing, hosted from a different dedicated URL.  Unfortunately, this bypasses the previously suggested method to block the public version.  Looking for info on how to now force enterprise only version.

[#5]

But how do you create a primary zone bing.com and a CNAME for www pointing to nochat.bing.com hosted by bing.com DNS servers? Won't the secondary DNS server also be answering for nochat.bing.com? Since the bing.com zone is on it.
Wouldn't you need to create a A record for nochat.bing.com as well? Thereby losing the whole point of using a CNAME?

[#6]

No, because you only have a conditional forwarder setup for www.bing.com which then forwards to the secondary DNS server that holds the CNAME for www.bing.com which sends the client to nochat.bing.com which would be queried on the primary DNS server.  Since there is no bing.com domain on the primary and no conditional forwarder it will use either root hints or your regular forwarders to lookup nochat.bing.com.

[#7]

Yes, you are right! I just figured it out as well. It only forwards the www.bing.com query to my secondary DNS server. nochat.bing.com it looks up via bing.com DNS servers. Works like a charm.
:)

[#8]

For now, I've just blocked copilot.microsoft.com and informed my users to access Bing chat from Edge or from www.bing.com/chat.  Microsoft says this functionality is coming for copilot.micrsoft.com but they don't say when...

Manage Copilot | Microsoft Learn

[#9]

Worked great, thanks.

[#10]

@Vimaleshwara Gajanana I tried this and it does not work in MS DNS.  You cannot create a conditional forward at the zone root level so on the production DNS this means to create a conditional forwarder for www.bing.com you must create the bing.com zone.  After doing this the prod DNS server answers bing.com queries. When I try to create a delegation at the root the "Next" box is greyed out unless I input a subdomain so I am unable to create a delegation for www.bing.com in the www.bing.com zone.  Likewise, I am unable to create a CNAME at the root of the zone either. As it was described it does not work.  Maybe you could provide the steps that worked or the work around that made it possible to delegate only www.domain.com without have a zone record for domain.com in MS DNS.

[#11]

You have to use two DNS servers. Your regular Prod server that's setup in client DNS settings and another secondary DNS server that clients know nothing about. Zone bing.com with Alias goes on the secondary, conditional forwarder goes on the primary.

[#12]

OK, Here goes for copilot.microsoft.com. This one requires TWO conditional forwarders because Microsoft, in their infantine wisdom, made the redirect a subdomain of the original domain which effs everything up.

What we're trying to do: Redirect copilot.microsoft.com to cdp.copilot.microsoft.com to force data protection in copilot.

On your secondary DNS server (the ones the clients know nothing of) create the primary zone microsoft.com. Add a CNAME for copilot.microsoft.com and point it at cdp.copilot.microsoft.com.

Back to the production server. Create TWO conditional forwarders here.
The first is copilot.microsoft.com that sends the requests to your secondary DNS server to get the CNAME.
The second is cdp.copilot.microsoft.com which should send the request out to the internet (I'm using 8.8.8.8 and 8.8.4.4).

The second is required because if it tries to resolve itself, it just uses the first conditional forwarder again which sends the request in an infinite loop between your DNS servers.

[#13]

@Bradley Fox , great hack! 

I'll mention that anyone using some kind of DNS firewall or Response Policy Zone for DNS can easily create a policy rule to match both names and have the DNS server artificially generate the CNAME response without all the configuration flaming hoops...

As Microsoft DNS Policies do not appear to support a redirect action (see: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverqueryresolutionpolicy?vie... ), one is left to implement the feature at the forwarding/recursion/caching level of your DNS infrastructure with BIND or other non-microsoft DNS solutions. 

https://bind9.readthedocs.io/en/latest/chapter6.html#dns-firewalls-and-response-policy-zones

for examples of how to get RPZ to generate a CNAME based on a policy match. 

And RPZ is a standard feature on pretty much any Protected DNS service out there.