Rackspace的“Cloud Files”如何知道我的CNAMElogging？

TLDR：当我做这个DNSlogging时：

whatever.mydomain.com. IN CNAME biglongjibberstring.r89.cf2.rackcdn.com. 

Rackspace如何知道我select的这个随机主机名应该转到我的Cloud Files容器/帐户而不是另一个客户？

我刚刚testing了一个使用Rackspace的Cloud文件的简单例子。 我做了一个云文件“容器”，并启用了“静态网站”选项。 我上传了一个示例图像和一个示例index.html文件。 这个容器中的这些文件现在可以在这个疯狂的URL中使用，UI告诉我可以将它用作我的域的CNAME：

• 通过F5 BigIP转发Akamai的True-Client-IP
• 不可能使用CloudFlare为WebP图像提供服务？
• 如何将Google Cloud CDN与Google Blobstore图像服务和Google App Engine结合使用？
• 使用https（SSL）在Nginx上运行多个域和子域
• 避免Amazon CloudFront CDN上的dynamicHTML页面

当然，添加一个CNAMElogging如下：

whatever.mydomain.com。 IN CNAME biglongjibberstring.r89.cf2.rackcdn.com。

浏览http://whatever.mydomain.com/作品（testing主页和图像）。 但是它怎么可能知道，当它看到一个“whatever.mydomain.com”的请求（在HTTP主机头），它是为我的特定的云文件容器？

这似乎与DNS有关，因为如果我只是把“blah.example.com”放在我的主机文件中，IP地址是biglongjibberstring.r89.cf2.rackcdn.com。 解决了 – 这不起作用（给出了一个关于无效的URL的错误 – 似乎来自Akamai）。 唯一的办法，我可能会看到这个工作是如果以某种方式DNS查找whatever.mydomain.com是以某种方式传回Rackspace / Akamai DNS服务器之间的这种关系“whatever.mydomain.com”和“biglongjibberstring.r89.cf2.rackcdn .COM“。 但是我从来没有见过这种方法，我甚至不认为返回到Rackspace / Akamai的DNS查询实际上包含了必要的信息（虽然我可能是错的）。

有谁知道这里发生了什么样的黑魔法？