Microsoft's DNS Solution for Enforcing CDP for Copilot and Bing Chat

What’s the deal?

Microsoft’s “Manage Copilot” page explains the solution as:

To ensure that your users have commercial data protection when they use Copilot, you need to:

Enforce commercial data protection

Enable the Copilot service plan for your eligible users

Prevent use of Copilot without commercial data protection

Update your DNS configuration by setting the DNS entry for www.bing.com to be a CNAME for nochat.bing.com

and:

To ensure that your users have commercial data protection when they access Copilot through copilot.microsoft.com and the Copilot mobile app, the solution is similar:

Enforce commercial data protection

Enable the Copilot service plan for your eligible users

Prevent use of Copilot without commercial data protection

Update your DNS configuration by setting the DNS entry for copilot.microsoft.com to be a CNAME for cdp.copilot.microsoft.com

This is weird.

“Setting the DNS entry” (for names in the microsoft.com) “… to be a CNAME…” is an extremely unusual thing for Microsoft to ask other organizations (that are not authoritative owners of the microft.com or bing.com domains) to do. That’s “novel” as in “we don’t do that for a good reason”, not “novel” as in “oh cool, how come nobody thought of that before.”

Challenges Associated with Solution

Microsoft’s solution requires anyone adopting it to implement a separate/dedicated DNS nameserver service along with nested, asymmetric forwarding zone definitions. Doing so is a feasible, but extremely novel exercise.

Why is a new/dedicated DNS nameserver instance required?

In short, because it is impossible to create a “CNAME” record at a DNZ zone “apex”, requiring anyone trying to create the specified CNAME records to actually host the “microsoft.com” and “bing.com” DNZ zones. That would break DNS resolution for any other hostnames in those domains (unless we somehow kept their contents – other than the names that we’re intentionally hosting – slaved to the current contents of the same zones in MS’s nameservers.)In short, because it is impossible to create a “CNAME” record at a DNZ zone “apex”, requiring anyone trying to create the specified CNAME records to actually host the “microsoft.com” and “bing.com” DNZ zones. That would break DNS resolution for any other hostnames in those domains (unless we somehow kept their contents – other than the names that we’re intentionally hosting – slaved to the current contents of the same zones in MS’s nameservers.)

Relevant DNS Fundamentals

What is a the DNS namespace / what is a DNS domain?

The DNS namespace is the set of all domain names registered with the DNS. It is a hierarchical construct, with the root domain of “.” Child-domains are signified by prepending a properly formatted text string to the parent domain. For example, 1st level children of the root domains include: “.com.”, “.net.” and “.org.” Note that, by convention, the root domain’s “.” is typically omitted when domain names are written. (E.g. “.com”, “.net”, “.org”, etc…)

The pattern for child domain is a properly formatted text-string (ending in “.”) prepended to the parent domain’s name. E.g. “bcbsnc.com” is a child domain of “.com”

What is a DNS Zone?

A DNS “zone” is a subset of the overall DNS namespace (“.com”, “.net”, “bcbsnc.com”, “microsoft.com”, etc..) that is under consolidated administrative control. A single DNS nameserver might be authoritative for multiple zones or just one zone. There is not a 1:1 correspondence between DNS “domains” and “zones.” Sub-domains of a single parent domain might be administered as a single zone, or might be delegated by the parent domain’s name-server to a separate name server where they exist as a separate zone.

What is a DNS Zone apex?

The “apex” of a DNS zone is collection of records in the zone using the name of the DNS zone itself. A zone’s apex records typically consist of SOA (source of authority) , “NS” (nameserver), and “A” (host) records.

For example, the A records in the “microsoft.com” DNS zone will typically have a large number of IP addresses (constantly updated by microsoft.) which are hosting the web-servers microsoft.com website. These “A” records can only accept IP addresses in the “address” field. If a user queries a DNS name and the nameserver returns an A record, the client will resolve the name to an IP address.

What is a CNAME record?

A “CNAME” (canonical name”) record is a DNS record-type that “aliases” one DNS name to another (“canonical”) name. For example, a DNS nameserver hosting the “microsoft.com” domain could create a CNAME record aliasing “copilot.microsoft.com” to “cdp.copilot.microsoft.com” When a device queries the nameserver to resolve “copilot.microsoft.com” the response will be that it resolves to “cdp.copilot.microsoft.com”

Why can’t you have a CNAME record at a zone apex?

The CNAME record-type, by definition, supersedes any other record-types hosted on the same node. So if there were an “A” record, an “MX” record, and a “CNAME” record for “hostname.com”, the DNS resolver would only return the CNAME record. However, the DNS standards require that a zone apex host an SOA record. If a CNAME record existed at the zone apex, no clients would ever receive the SOA record when querying the zone’s apex.

Because of this, most DNS resolver implementations (most noticably, BIND) do not permit the provisioning of CNAME records at a zone apex.

So, why do we need a separate DNS nameserver here?

We need our DNS nameservers to do two things that they physically can’t do at the same time:

Treat Microsoft’s nameservers as authoritative for “microsoft.com” and “bing.com” domains for all the names in them that aren’t “www.bing.com” or “copilot.microsoft.com”
Respond (authoritatively) with CNAME records that we populate for “copilot.microsoft.com” and “www.bing.com”

Since a DNS name-server can’t do both of those things concurrently, we need separate name-servers for each. Our existing nameservers/resolvers already treat microsoft.com and bing.com correctly, so we need a new nameserver that can host CNAME records for www.bing.com and copilot.microsoft.com.

Asymmetric/Mismatches Scoping of Zones

The new nameservers are configured to authoritatively host the entire bing.com and microsoft.com domains, but we only populate those zones with CNAME records (listing “www” as an alias for canonical-name “cdp” in the bing.com zone, and “copilot as an alias for canonical-name “cdp.copilot” in the microsoft zone.) Because these nameservers only have these specific CNAME records populated; we must be sure that nothing is referring to these new nameservers for anything other than these specific *FQDNs.

Our internal-facing DNS nameservers and/or DNS resolvers, correspondingly, are configured to explicitly forward only “www.bing.com” and “copilot.microsoft.com domains” to the new nameservers. (And no other devices should be configured to query those new name-servers for anything at all.)

How to Implement

As explained above, if we want to implement CNAME records for these two FQDNS (www.bing.com and copilot.microsoft.com), our DNS nameservers must host zones for their respective parent domains (“bing.com” and “microsoft.com”). Unfortunately, those parent domains (especially “microsoft.com”) are already operated by Microsoft, and their contents change constantly. We must retain the ability for enterprise users to resolve hostnames in those domains.

So, we can’t have our ${enterpriseDnsServers} thinking that they are authoritative for bing.com / microsoft.com, but we need to create CNAME records in those domains. The only viable solution is to:

Provision a new/separate DNS service (“${newDnsServers}”)
- The authoritative nameserver function is mandatory here
- Create “bing.com” and “microsoft.com” as hosted zones in ${newDnsServers}.
  - Create the desired CNAME records
    - Name “copilot.microsoft.com” as an alias for canonical name “cdp.copilot.microsoft.com”
    - Name “www.bing.com” as an alias for canonical name “nochat.bing.com”
- The recursive resolver function is not desirable here, but if it cannot be disabled, the following additional elements are required
  - Create “forward” zones for the alias names from the CNAME records in the previous step - “nochat.bing.com” and “cdp.microsoft.com” get defined as forwarding zones - Forwarding back to the original enterprise DDI DNS resolvers
Create “forward” zones for www.bing.com and copilot.microsoft.com in the original enterprise DNS servers
- Using the IP address of${newDnsServers} as the forwarding server.
Create a forward-zone in the enterprise DNS servers
Forward-zone = “cdp.copilot.microsoft.com”
Forwarding-server = ${3rdPartyResolvers}
(See “note” below.)

This scenario meets following design objectives:

Clients of the original enterprise DNS servers retain the ability resolve xxx.microsoft.com and xxx.bing.com names
- Assuming that the original enterprise DNS servers provided recursive lookup services to begin with
Enterprise users and IT workload now get the desired CNAME resolution for “www.bing.com” and “copilot.bcbsnc.com”

Conceptual and Functional Architecture

The following diagram illustrates the design described above, depicting the instances of and relationship between DNS clients, DNS servers, DNS zones, DNS records, and DNS messages.

The following tables enumerate the details of each of the DNS flows/messages in the preceding diagram. Each table represents a separate design/use case.

Resolving www.bing.com (with no recursion or zone-forwarding on ${newDnsServers})

Use Case 1

Flow Index Description Notes

a Client device send DNS query for resolution of “www.bing.com” to ${enterpriseDnsServers} DNS UDP flow. Query might specify “A” or “ANY” record types in the QTYPE field; will request recursion.

c ${enterpriseDnsServers} sends a query(requesting recursion) for http://www.bing.com to ${newDnsServers} On receiving flow “a”, ${enterpriseDnsServers}’ recursive resolver function sees “www.bing.com” defined as a zone of type “forward” and sees the IP address (or FQDN) of ${newDnsServers} listed as the forwarding-server

d ${newDnsServers} sends a response to flow “c” to ${enterpriseDnsServers} (with the CNAME record for http://www.bing.com) On receiving flow “c”, ${newDnsServers} executes the algorithm in section 4.3.2 of RFC1034. It observes that recursion is not enabled, but that it is authoritative for bing.com, and that the matching node is a CNAME record. It adds the CNAME record to the ANSWERS record-set and starts the algorithm again, using the canonical-name (nochat.bing.com) as the QNAME. It does not find any more matching nodes or helpful records, so it sends the response to ${enterpriseDnsServers} with only the CNAME record included, and indicating that recursion was not performed.

g ${enterpriseDnsServers} sends a query for “nochat.bing.com” to ${msDnsServers} On receiving flow “d” the ${enterpriseDnsServers} first appends the CNAME record it just received to the ANSWERS section of the response it is preparing to the original query from flow “a”. It then attempts to resolve the canonical name (“nochat.bing.com”) from that CNAME record.. Assuming that the “A” record for “nochat.bing.com” has not been previously cached, ${enterpriseDnsServers} attempts iterative resolution (of “nochat.bing.com”) and is eventually referred to ${msDnsServers}. It then sends a query for “nochat.bing.com” to ${msDnsServers}

h ${msDnsServers} send a response to ${enterpriseDnsServers} with the “A” record for “nochat.bing.com”) Took us long enough!

b ${enterpriseDnsServers} sends a response to the originating user/client (from flow “a”) On receiving flow “h”, the ${enterpriseDnsServers}extract the “A” record for “nochat.bing.com” and append it to the “answers” section of the response it has been preparing for the query from flow “a” – and it sends that response to the originating client. The “answers” section of the response contains the CNAME record aliasing http://www.bing.com to nochat.bing.com as well as the A record for nochat.bing.com.

Flow Index	Description	Notes
a	Client device send DNS query for resolution of “www.bing.com” to ${enterpriseDnsServers}	DNS UDP flow. Query might specify “A” or “ANY” record types in the QTYPE field; will request recursion.
c	${enterpriseDnsServers} sends a query(requesting recursion) for http://www.bing.com to ${newDnsServers}	On receiving flow “a”, ${enterpriseDnsServers}’ recursive resolver function sees “www.bing.com” defined as a zone of type “forward” and sees the IP address (or FQDN) of ${newDnsServers} listed as the forwarding-server
d	${newDnsServers} sends a response to flow “c” to ${enterpriseDnsServers} (with the CNAME record for http://www.bing.com)	On receiving flow “c”, ${newDnsServers} executes the algorithm in section 4.3.2 of RFC1034. It observes that recursion is not enabled, but that it is authoritative for bing.com, and that the matching node is a CNAME record. It adds the CNAME record to the ANSWERS record-set and starts the algorithm again, using the canonical-name (nochat.bing.com) as the QNAME. It does not find any more matching nodes or helpful records, so it sends the response to ${enterpriseDnsServers} with only the CNAME record included, and indicating that recursion was not performed.
g	${enterpriseDnsServers} sends a query for “nochat.bing.com” to ${msDnsServers}	On receiving flow “d” the ${enterpriseDnsServers} first appends the CNAME record it just received to the ANSWERS section of the response it is preparing to the original query from flow “a”. It then attempts to resolve the canonical name (“nochat.bing.com”) from that CNAME record.. Assuming that the “A” record for “nochat.bing.com” has not been previously cached, ${enterpriseDnsServers} attempts iterative resolution (of “nochat.bing.com”) and is eventually referred to ${msDnsServers}. It then sends a query for “nochat.bing.com” to ${msDnsServers}
h	${msDnsServers} send a response to ${enterpriseDnsServers} with the “A” record for “nochat.bing.com”)	Took us long enough!
b	${enterpriseDnsServers} sends a response to the originating user/client (from flow “a”)	On receiving flow “h”, the ${enterpriseDnsServers}extract the “A” record for “nochat.bing.com” and append it to the “answers” section of the response it has been preparing for the query from flow “a” – and it sends that response to the originating client. The “answers” section of the response contains the CNAME record aliasing http://www.bing.com to nochat.bing.com as well as the A record for nochat.bing.com.